I am having two kind of h264 streams, first one is created by Intel Media_SDK_2016.0.1 h264 encoder on Windows OS and second one is created by VAAPI h264 encoder on Fedora20 OS. Both streams are encoded in Display order and both are being played well in VLC.
Now when i am decoding these streams using Intel Media_SDK_2016.0.1 h264 decoder (API version 1.17), then output frames are not coming in correct order for VAAPI encoded h264 stream, but for Media SDK encoded stream output is in proper order.
Later I set the DecodedOrder parameter to 1 (m_mfxVideoParams.mfx.DecodedOrder = 1) before decoder init then output frames started coming in proper order for VAPPI encoded stream too.
Now, i have following queries and need the resolution:
1. I read in media sdk manual (API version 1.17) that:
DecodedOrder: Deprecated; Used to instruct the decoder to decoded output in the decoded order. Always set this parameter to zero.
If this option is deprecated, then what is the alternative now to get the decoder output in display order?
2. I noticed that if I set DecodedOrder parameter to 1 and try to run it on a old Graphic card/driver (which supports API version 1.4) then decoder initialization is always failing with error code MFX_ERR_UNSUPPORTED. If i change it to 0 then it init is successful.
So can you please let me know form which API version onward this option is supported and from which version onward it got depricated?
3. h264 stream encoded in display order using intel media sdk is getting decoded in proper order even if I dont't set DecodedOrder value to 1, but VAAPI encoded stream not. So it creates a doubt that probably VAPPI encoded stream is not correctly encoded in display order. But at the same time VLC player is able to decode and render both streams in correct order, so I am not sure which module to look for proper solution. Can you guide me here?
i. I am attaching two streams: "Dump_Windows_Encoder.h264" is created by intel media sdk encoder on WIndows and "Dump_Linux_Encoder.h264" is created by VAAPI encoder on Fedora. If you play these streams in VLC, they will run properly.
ii. Decode and render these stream using sample_decode.exe and observe the output.
Command line options: [sample_decode.exe h264 -i Dump_Linux_Encoder.h264 -r -f 24]
I have reproduced this issue and submitted the bug to the develop team.
I am also trying to get the answer to your questions. I will give you update once I get back from them.
I am very apologized for the delay, I didn't keep up with this bug quite often.
I check the bug but it doesn't have updated yet, I have contacted the dev team and they are looking at it now.
Thanks for your reply. I would like to share an update on this issue through which I could make it to work .
I modified VAAPI h264 encoder in order to generate VUI and HRD parameters in SPS frame (it was not generated earlier). After this, the new encoded stream is getting decoded by intel SDK decoder properly and output is in correct order.
But as I am still unsure why and how it fixed the issue, it will be good to get the actual root cause and proper fix for this issue. Hope above input will help dev team to figure out the root cause.
Thanks so much,
I will let the dev team know.
By the way, I just posted this article to build the full set of the Intel media stack on the latest kernel with the generic Linux distribution:
You might try this method to look into the driver layer.
Sorry for being so long for this issue.
I have been trying to clean up this request and I just got feedback from dev team that DecodecOrder should work for both AVC and HEVC.
Here is the PR in GitHub:
Could you try the late release in GitHub to see if this being fixed?
Thanks Mark for the confirmation. I will be able to check the latest release in few days.
From my original queries, point 1 is clear now, point 2 is irrelevant for me now. but point 3 is still a grey area for me. Can you help to figure out this behaviour?
Sure, let's look at #3.
I think the question is about VAAPI encode, could you clarify followings?
I doubt the ordering difference was caused by i965.