On E3-1565L processor, running under 2017R3, I am having an issue with transcoding interlaced hevc input to interlaced AVC output. Specifically, on the boundaries between B and P fields, dts values step back, by multiples of fps.
The following line reproduces this problem:
sample_multi_transcode -i::h265 ~/Videos/1080i.h265 -gop_size 32 -dist 4 -o::h264 /dev/null -n 100 -b 5000 -hw
However, setting "-dist" to 2, i.e., IPBP..., does not show the same symptoms. Also, raw frames generated by
sample_multi_transcode -i::h265 ~/Videos/1080i.h265 -async 10 -o::raw ~/Videos/out.raw -n 300 -b 5000 -hw,
are properly playable with
ffplay -f rawvideo -pix_fmt yuv420p -s 1920x1080 -i ~/Videos/out.raw
I was wondering if this is a known issue or I am missing something in the command line.
Sorry for the late response, I am trying to reproduce what you observed but after reading your post, I can't figure out what the problem was.
For your first command, how do I see the problem?
Thank you for your reply. I've attached a short clip that produces this problem, i.e.,
sample_multi_transcode -i::h265 ~/Videos/1080i_short.h265 -o::h264 tmp.h264 -n 80 -b 5000 -hw -gop_size 30 -dist 4.
What is seen is that dts associated with encode frames are not incrementing monotonically. Problem seems to be specific to B frames, i.e.,
sample_multi_transcode -i::h265 ~/Videos/1080i_short.h265 -o::h264 /tmp/tmp.h264 -n 80 -b 5000 -hw -gop_size 30 -dist 1,
does not show the same symptoms.
Am I missing an argument, on the command line?
I downloaded the clip and used your program, but I still don't understand what you want me to check "dts step back". could you give me more description about the error.
I play all the output clips from your command and didn't see anything wrong, I can help you if you can give me more clue.
Thank you for your reply. What I had done was to print out pBS->DecodeTimeStamp and pBS->TimeStamp in CTranscodingPipeline::EncodeOneFrame routine, within sample_multi_transcode example. My expectation was
1- pBS->DecodeTimeStamp should be incrementing monotonically.
2- pBS->TimeStamp should be larger than pBS->DecodeTimeStamp, at all times
Are these not to be expected?
No, it shouldn't be.
Conceptually, there are 2 time stamps; decode time stamp(DTS), presentation time stamp(PTS). DTS doesn't have to be monotonically increment, since decoder will look for PTS to render the frame.
This is why I was playing the output from your scenario and both playback looks normal for me.
You can refer to following post for detail
Let me know if there is a mis-understanding on my side, these concepts are confused sometime.
Indeed. And as noted in the link, DTS always increments monotonically, whereas, PTS can jump around, specifically, in presence of B frames. (Essentially, you need to decoded before you can present. See, http://www.img.lx.it.pt/~fp/cav/Additional_material/MPEG2_overview.pdf for example.)
At any rate, was able to solve this problem by adjusting the frame rate from field rate to half, on the vpp surface.)
I think you are right in the post, DTC should be monotonically increment.
Let's back to your question, I try to reproduce your problem by print out the DTS value at the output but it is confused with the clip you attached, I think the time stamp in your clip was corrupted since I check the other video clips I have, they have no problems with "-dist 4".
Could you show me the log you have?
In theory, the timestamp for media SDK is pass through, we don't touch it during the operation.