Media (Intel® oneAPI Video Processing Library, Intel Media SDK)
Access community support with transcoding, decoding, and encoding in applications using media tools like Intel® oneAPI Video Processing Library and Intel® Media SDK

Wrong frame order coming out of the video decoder


I am using the sample_multi_transcode as a refernece for my live transcoding application.
First, I implemented a decoder code and it's seems to work except the output order is incorrect.

The input is coming from mpegts/udp being demultiplexed. I push the compressed video frames as they arrive, in stream order (not display order).
After getting MFX_ERR_NONE from the video decoder, I call SyncOperation, lock the frame, dump the output to a raw (YV12) file and unlock the frame.
examining of the YV12 file reveals that order is incorrect.
I see the same behaviour when I connect VPP->H264 Encoder and dump the H264 elementry stream to a file.

When initializing the decoder, I set DecodedOrder = 0 (and also EncodedOrder=0 for the encoder)
Any suggestions what can cause to this problem?

Thank you

0 Kudos
2 Replies

I've found FFmpeg can be very helpful for cases like this.  You can prototype both sides separately.

For example:

Server side:

ffmpeg -re -i (infile)  -f h264 udp://


Client side:

ffplay -i udp://


From your description, it seems like you may want EncodedOrder=1 on the server/encoder side.  This will give you a quick way to check.

By the way, Media SDK codecs are available in FFmpeg as h264_qsv, mpeg2_qsv, and hevc_qsv (if you install Professional Edition) in ffmpeg 2.8 and forward. This means you could use the Media SDK encoder simply by adding -vcodec h264_qsv to the first command line, though it wouldn't be quite as efficient as a custom implementation.  For more info on how to install (for Linux) see  The FFmpeg code or the tutorials may be a simpler starting point than sample_multi_transcode.

Regards, Jeff

0 Kudos

Thank you Jeff,

I found my problem.

I locked the output surface too late and the decoder used it again.

When the VPP/encoder tried to used the surface, the content was already overwriten by the decoder and the "old" frame was no longer exists in the memory.


0 Kudos