2017R3 Interlace Transcode

[NAves]

Hi

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.

Cheers,

[Mark_L_Intel1]

Hi Nastooh,

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?

Mark

[NAves]

Hi  

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?

Cheers,

[Mark_L_Intel1]

Thanks Nastooh,

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.

Mark

[NAves]

Hi

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?

Cheers,

[Mark_L_Intel1]

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

https://stackoverflow.com/questions/6044330/ffmpeg-c-what-are-pts-and-dts-what-does-this-code-block-do-in-ffmpeg-c

Let me know if there is a mis-understanding on my side, these concepts are confused sometime.

Mark

[NAves]

Hi

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.)

Cheers,

[Mark_L_Intel1]

Hi Nastooh,

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.

Mark