- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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-ffmpeg. The FFmpeg code or the tutorials may be a simpler starting point than sample_multi_transcode.
Regards, Jeff
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page