A possible bug in

A possible bug in

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

6 posts / novo 0
Último post
Para obter mais informações sobre otimizações de compiladores, consulte Aviso sobre otimizações.

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

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

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

Any progress on this issue ?

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

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.

Deixar um comentário

Faça login para adicionar um comentário. Não é membro? Inscreva-se hoje mesmo!