I've been using the MediaSDK for video conferencing (I work with VCon, an Israeli video conferencing company), and have encountered an oddity : When I start receiving the stream, I fill in the header-related structures using MFXVideoDECODE_DecodeHeader, per the documentation. That works splendidly if all of the NAL's generated by the encoder are develivered. However, if the FIRST NAL is dropped (by network issues or in synthetic testing), the function returns -10 (which is reasonable, as data is missing) for a very long time, after which it starts returning -16 (a mostly undefined error), and NEVER locks on to the stream's parameters. Dropping all of the NAL's (in my receiver code) until a NAL of type 7 is received, and then processing the received NAL's using MFXVideoDECODE_DecodeHeader in the exact same manner, everything works. I was under the impression that as long as the packets starting from a certain position in the stream are fed into the function, it'll eventually lock on to the stream's parameters, was I mistaken ?
P.S. the stream in question is generated by MediaSDK's encoder, hardware mode. The easiest way to show it is to blot-out the 00 00 01 07, the first time it appears in the stream, and then you'll see that while other decoders (FFMPEG) do recognize the file, MediaSDK's MFXVideoDECODE_DecodeHeader never returns MFX_ERR_NONE...
The details of a computer where the issue was reproduced follow. Note that this happened also on computers with just Intel graphics, running in hardware or software mode (software mode on older Intel processors).
thanks for the quick response
P.S. the SDK in use was the final SDK 3.0 2012.
Intel HD Graphics 3000
Report Date: 1/14/2012 Report Time[hr:mm:ss]: 21:7:7 Driver Version: 18.104.22.1689 Operating System: Windows 7 Service Pack 1(6.1.7601) Default Language: English (United States) DirectX* Version: 10.1 Physical Memory: 8099 MB Minimum Graphics Memory: 64 MB Maximum Graphics Memory: 4065 MB Graphics Memory in Use: 4 MB Processor: Intel64 Family 6 Model 42 Stepping 7 Processor Speed: 1995 MHz Vendor ID: 8086 Device ID: 0116 Device Revision: 09
* Processor Graphics Information *
Processor Graphics in Use: Intel HD Graphics 3000 Video BIOS: 2098.0 Current Graphics Mode: 1366 by 768
I was unable to reproduce the problem with DecodeHeader so far. I was using sample_decode and libmfxsw32.dll from MSDK 2012 Gold.
I take an elementary h264 stream with several SPSPPS sets and spoil the first SPS start code to be 00 ff ff ff 67 instead of 00 00 00 01 67 (HEX). After several iterations with MORE_DATA DecodeHeader is able to find the next SPS and returns an MFX_ERR_NONE. I also tried to limit bitstream size to smaller value - then it takes more iterations. This makes me thinks DecodeHeader is handling bitstream correctly.
I need to ask you for more details as I might be missing something. One thing which confused me is you mention 00 00 00 07 sequence. Can you clarify? or you just meant 0x67 instead of 0x07? Will you be able to share a stream on which you see the issue and also try to reproduce on sample_decode at your side? Maybe bitstream handling in your app is somewhat different from one in sample_decode. For diagnostic purposes would be really great to have a MSDK Tracer log file for the problem case and your app. This tool is in the MSDK 2012 Gold package under \tools\mediasdk_tracer.