[FFmpeg-devel] [PATCH] avformat/movenc: Fix tfdt out of sync

[Martin Storsjö]

Hi,

On Tue, 20 Jul 2021, 胡玮文 wrote:

> After compile and run this code, run this command to inspect the dts (which comes from the out of sync tfdt)
>
> ffprobe -show_packets bug.mp4 | grep dts=
>
> The output is:
>
> dts=0
> dts=1
> dts=2
> dts=2
> dts=3
> dts=4
>
> With this patch applied, the output is:
>
> dts=0
> dts=1
> dts=2
> dts=10
> dts=11
> dts=12

Thanks for the repro case, and sorry for the delay in looking at it.

I do see the issue, but I disagree with your suggested solution. While 
your patch does create the correct, intended value in tfdt, you will 
instead create a file where the dts calculated from adding up previous 
sample durations differ from what's written in tfdt. So depending on 
whether the demuxer just accumulates durations or reads tfdt, it will 
produce a different result.

I guess it can be argued that if a demuxer reads a fragmented file, then 
tfdt should be more authoritative than duration and any other reader is 
buggy, but nevertheless, the code as is is designed to make sure that tfdt 
is consistent with the sum of durations.

It seems it's possible to fix the same issue differently though, by not 
adjusting track_duration and end_pts when autoflushing, if there's no 
samples in the track that are going to be flushed. That way, we retain the 
existing intended logic of the muxer, while avoiding diverging.

The result of your repro example, with my movenc modification, produces 
this dts sequence:

dts=0
dts=1
dts=2
dts=2
dts=11
dts=12

This is, of course less nice than what we had before, but after flushing 
the fragment containing tfdt=2, duration=0, the only consistent choice we 
have is to start the next fragment at tfdt/dts=2.


However, I'm open to add an option to ignore the end of the previous 
fragment and make the new fragment start at the exact desired timestamp.

// Martin