Community
cancel
Showing results for 
Search instead for 
Did you mean: 
NAves
Novice
86 Views

2017R3 Interlace Transcode

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,

0 Kudos
7 Replies
Mark_L_Intel1
Moderator
86 Views

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
Novice
86 Views

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
Moderator
86 Views

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
Novice
86 Views

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
Moderator
86 Views

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

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

Mark

NAves
Novice
86 Views

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
Moderator
86 Views

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

Reply