Unexpected MFX_ERR_NOT_ENOUGH_BUFFER error during h.264 encoding


We use Media SDK to do software h.264 video encoding.

We switched from Media SDK 2012 R2 to Media SDK 2014 R2. Long run tests revealed a problem: after a period (several hours, not constant), encoding stops working, no more video frames are encoded.
After investigations, we found that the function MFXVideoENCODE::EncodeFrameAsync(...) returns -5, i.e. MFX_ERR_NOT_ENOUGH_BUFFER

The documentation stipulates that this error happens when: The bitstream buffer size is insufficient.

A hardware QuickSync question

I would like to ask if you are going to change the way that hardware transcoding works right now.

From QuickSync version 1 (inside SandyBridge) till now, the transcoding process uses a lot of hardware resources of the iGPU (EUs) - besides ASIC - and we could say that it's not a pure hardware (ASIC only) implementation.

On the other hand, Nvidia and AMD use ASIC only transcoding.

For example NVenc from Nvidia and VCE from AMD, use only the ASIC inside the GPUs and very few GPU resources -> GPU load < 5%

Copy decoded video frame from video surface into system memory


I am using simple_decode_d3d example from MediaSDK tutorials for decoding 4K H.264 video.

Usage Example: simple_decode_d3d -i Test4KVideo.h264

The sample_decode_d3d gives 300fps (without saving/copying the output).

However, when I copy the decoded frame in NV12 format (size of the raw frame ~12MB) to local buffer using memcpy, the fps drops to <10fps.

libmfxsw64.dll VPP erroneous artifacts


Using the sample 'simple_6_decode_vpp_postproc' from the latest tutorials by Jeffrey Mcallister, I am seeing noisy/buggy video being output.

I have not modified the tutorial example, I am using it as-delivered.

I have isolated the problem.  Using hardware  mode (-hw) does not show the problem.

Also, using the tutorial simple_2_decode does not exhibit the problem.

I am using the following .BAT script to exhibit the problem. This tutorial sample resizes to 50% by 50% so use NV12 160x90 with your YUV viewer.


Processors that support QuickSync

I believe that there were a few Sandy Bridge processors that did not do QuickSync, and that the only way to be sure if it was supported was to look up the processor in the Intel Ark and look for QuickSync in its feature list.

Can we assume that ALL Ivy Bridge, Haswell and Broadwell processors can do Quicksync decoding/encoding, or are there still some annoying exceptions that mean we still always have to consult the ark website to find out ?



Encoder and VPP setting for 720p50 encoding


My application generating 50 progresive frames (resolution 1280 * 720) per second.

 I want to encode this frames using IQSV encoder in 720p50 mode (1280*720 50 frames)

So what will be the encoder setting and VPP setting?

Also I want to know we have to pass only 25 progressive frame to encoder or we can pass all 50 frames to encoder.

Currently if I send all 50 frames for encoding, then output file is duration is double than duration for which we record.

If I send alternate progressive frame to encoder then output file is proper.

multi transcode sample doesnt work with "-la" option


I have a PC with Intel(R) Core(TM) i7-4790 CPU @ 3.60GHz

I am running the precompiled sample binaries in the following way and this is the output


[root@localhost mediasdk_samples_bin]# ./sample_multi_transcode_drm -i::h264 /home/victor/Documents/MediaSDK/content/vq_src.264 -o::h264 /home/victor/Documents/MediaSDK/content/mss_out_5M_u1.265 -hw -la
Multi Transcoding Sample Version 5.0.1604371.71

Intel media sdk H.264 decoder handle leak

I think bug in MediaSDK.

OS : Windows7 (x64)
SDK:API version 1.11

1. Create instance and initialize.

2. Execute decode operation.

3. Close operation.(reference to the sample code)

When performing the above operation, handle count increases one.
If does not execute decode, handle count does not increase.(create instance -> initialize -> close)

I think the wait handle that was created in asynchronous decoding has not been released.
If this is a bug, I hope to be fixed in the next release.

Subscribe to Media