A possible bug in

[Jack_Chimasera]

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...

[Nina_K_Intel]

Hi Jack,

You are right, this behavior does look like an error. Can you tell which driver version you are using? (I assume that's the HW H264 decoder).

Thanks,

Nina

[Jack_Chimasera]

Hello Nina

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

Jack Chimasera

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: 8.15.10.2559
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




* Devices Connected to the Graphics Accelerator *


Active Notebook Displays: 1
* Built-in Display *


Monitor Name: Generic PnP Monitor
Display Type: Digital
Gamma Value: 2.2
DDC2 Protocol: Supported


Maximum Image Size:
Horizontal: 13.39 inches
Vertical: 07.48 inches


Monitor Supported Modes:
1366 by 768 (60 Hz)



Display Power Management Support:
Standby Mode: Not Supported
Suspend Mode: Not Supported
Active Off Mode: Not Supported


Raw EDID:
00 FF FF FF FF FF FF 00 06 AF EC 22 00 00 00 00
01 13 01 03 90 22 13 78 0A C8 95 9E 57 54 92 26
0F 50 54 00 00 00 01 01 01 01 01 01 01 01 01 01
01 01 01 01 01 01 6E 19 56 20 50 00 08 30 10 08
34 00 58 C1 10 00 00 1A 6E 19 56 20 50 00 08 30
10 08 34 00 58 C1 10 00 00 1A 00 00 00 FE 00 31
4A 43 32 4E 80 42 31 35 36 58 57 32 00 00 00 00
00 00 00 00 00 00 00 00 00 01 01 0A 20 20 00 D4


* Other names and brands are the property of their respective owners. *

[Jack_Chimasera]

Any progress on this issue ?

[Nina_K_Intel]

Hi Jack,

I'm sorry, no progress yet. I will check today and get back to you.

-Nina

[Nina_K_Intel]

Hi Jack,

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.

Thanks,

Nina