MFXVideoDECODE_DecodeHeader oddity

[andrasjpeg]

I'm trying to come up with a robust way to useMFXVideoDECODE_DecodeHeader, however I do not understand the meaning of the bitstream member values after the call..

If I pass in the first 7 bytes of the stream (DataOffset=0,DataLength=7), then it returns MFX_ERR_MORE_DATA, and the bitstream will be unchanged (DataOffset=0,DataLength=7), which I assume means that I need to append more data to it.

However, if I only pass in the first 4 bytes of the stream (DataOffset=0,DataLength=4), then it returnsMFX_ERR_MORE_DATA (as expected), but the bitstream gets changed (DataOffset=4,DataLength=0). What does this mean? Why does passing less data behave different?? What am I supposed to do?

Also, if Icall itwith the first 1000 bytes (DataOffset=0,DataLength=1000), then it returnsMFX_ERR_NONE, and the bitstream will be (DataOffset=0,DataLength=1000). But now how do I know how much of it was actually processed?

A little explanation would be appreciated! Thanks!

Andras

[Nina_K_Intel]

Hi Andras,

You don't really need to know the internals of DecodeHeader behavior and why it modifies the bitstream parameters differently from one call to another. You should react only to the return statuses and handle the input bitstream structure in a consistent way:

- if MORE_DATA is returned - put more data in the input bitstream, starting at (Data + DataOffset + DataLength)

- if DataLength is non-zero after the call you have to preserve that actual Data which lies from (Data + DataOffset to Data + DataOffset + DataLength) in the input bitstream

- but you can handle DataOffset after the call at your discretion: reset it to zero and copy old data to the beginning, then append new data. Or leave it as it was after the call and just copy the new data at (Data + DataOffset + DataLength).

You also need to handle the case when the bitstream buffer needs to be reallocated for more space: if DecodeHeader or DecodeFrameAsync return MORE_DATA, but DataLength == MaxLength.

I suggest you check out the CSmplBitstreamReader::ReadNextFrameand theCDecodingPipeline::InitMfxParams methods of sample_decode under \samples.

Hope this is helpful.

Regards,

Nina

[andrasjpeg]

Hi Nina,

That's exactly what I was doing, however I found that in certain circumstances it didn't work, hence my asking.

If you feed in 4 bytes at a time, then DecodeHeader returns MORE_DATA, and sets DataOffset to 4 and DataLength to 0. Now, I reset DataOffset to 0 and copy in the next 4 bytes to Data + DataOffset + DataLenght (which will be the same as Data), and then set DataLenght to 4. Then I rinse and repeat, but DecodeHeader will never return ERR_NONE.

But then, if I fed in 8 bytes, then it worked perfectly. This seems like a bug in DecodeHeader. I can feed in more bytes, that's not a problem, I just wanted to make sure that I'm doing everything as I'm supposed to.

Thanks,

-Andras

[Nina_K_Intel]

Hi Andras,

This does look like a bug, we will investigate the issue and get back to you.

Thanks for drawing our attention to this.

Regards,

Nina

[Petter_L_Intel]

Hi Andras,

I looked into this a bit further.

Can I first ask you what type of stream you are decoding? H264, mpeg2 or VC1?
Also, what version of of Media SDK are you using and if you are using HW, what is the verison of your graphics driver?

I tried a couple of VC1 and H.264 streams using recent Media SDK 2012 R2 release and latest external driver. I do not observe the behavior you describe for HW or SW path. Regardless of the H.264 or VC1 content and DataLength I input the DataOffset is always 0 after calling DecodeHeader.

MPEG2 content input to DecodeHeader is known to behave a bit differently. We are looking into this and hope to align the behavior.

Regards,

Petter

[andrasjpeg]

Hi Petter,

This is actually an MPEG-2 stream, and I am using SW decoding with Media SDK 2012 (3.0.774.38156).

Thanks,

Andras

[Petter_L_Intel]

Hi Andras,

Thanks for providing this info. We will work on aligning the DecodeHeader behavior for the decoders so that the behavior is the same. However, this will likely not be available until next major release of the SDK.

One more thing. I do not see the same behavior as you describe when feeding MPEG2 content to DecodeHeader. Not sure why. Can you provide the stream (or at least the start of the stream) that you used so that I can try to reproduce?

Regards,

Petter

[andrasjpeg]

Try feeding this into DecodeHeader:

0x00, 0x00, 0x01, 0xb3, 0x28, 0x01, 0xe0, 0x24

If you feed this in one chunk of 8 bytes, then DecodeHeader will return MFX_ERR_NONE, and everything is fine. However, if you feed it in two 4byte chunks, then it will returnMFX_ERR_MORE_DATA, set DataLength to 0 and DataOffset to 4, and it will not figure out the stream parameters..

Thanks,

Andras

[Petter_L_Intel]

Andras,

Thanks for providing the specific input. We will include this info in our effort to improve the DecodeHeader behavior.

Regards,

Petter