Community
cancel
Showing results for 
Search instead for 
Did you mean: 
koby_s_
Beginner
86 Views

Wrong frame order coming out of the video decoder

Hi
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
Koby

0 Kudos
2 Replies
Jeffrey_M_Intel1
Employee
86 Views

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://127.0.0.1:10001

 

Client side:

ffplay -i udp://127.0.0.1:10001

 

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 https://software.intel.com/en-us/articles/accessing-intel-media-server-studio-for-linux-codecs-with-....  The FFmpeg code or the tutorials may be a simpler starting point than sample_multi_transcode.

Regards, Jeff

koby_s_
Beginner
86 Views

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.

Koby

Reply