- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
8 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Petter,
This is actually an MPEG-2 stream, and I am using SW decoding with Media SDK 2012 (3.0.774.38156).
Andras
This is actually an MPEG-2 stream, and I am using SW decoding with Media SDK 2012 (3.0.774.38156).
Thanks,
Andras
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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,
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Andras,
Thanks for providing the specific input. We will include this info in our effort to improve the DecodeHeader behavior.Regards,
Petter

Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page