[FFmpeg-devel] [PATCH] avformat/movenc: Remove dts delay from duration.

Martin Storsjö martin at martin.st
Fri Jan 15 14:59:14 EET 2021


Hi Josh,

On Tue, 22 Dec 2020, Josh Allmann wrote:

> Thank you for taking the time to look into this! Tested with your
> alternative patch and it does seem to be an improvement. I was able to
> find a case where it didn't seem to do the correct thing (described
> below), but this is not a regression; master doesn't do the correct
> thing, and neither does my patch. I haven't looked much at what the
> code is doing beyond running these tests, but could find some time to
> dig in early 2021 if it's not fixed by then.
>
> First, a working sample with pts > 0 . This has a 600-frame GOP (20s @
> 30fps) to show that cutting mid-GOP works correctly.
>
> https://trac.ffmpeg.org/raw-attachment/ticket/9028/gop-600.mp4
>
> Command to generate a clipped sample with edit list. This spans two GOPs.
>
> ffmpeg -ss 17.316666999999999 -i gop-600.mp4 -t 5 -c copy -movflags
> +faststart -y cut-mp4-600.mp4
>
> Things look good with ffprobe, and playback works well with ffplay; it
> starts right around the 17-second mark. The sample is a timecode
> pattern so it is easy to verify.
>
> If the sample is a mpegts (rather than a mp4, all other things
> identical), then things are a bit odd:
>
> https://trac.ffmpeg.org/raw-attachment/ticket/9028/gop-600.ts
>
> Cut the sample with:
>
> ffmpeg -ss 17.316666999999999 -i gop-600.ts -t 5 -c copy -movflags
> +faststart -y cut-ts-600.mp4
>
> Probing gives the correct duration with a start time of 2.683.
> However, playback starts at the 20 second mark. (Same timecode
> pattern, so easy to visually verify.) Incidentally, it seems that 20 -
> 2.683 = 17.316, which is the original cut position.
>
> ffprobe cut-ts-600.mp4 gives "Duration: 00:00:05.12, start: 2.683000"
>
> The trac ticket has a bit more info (including commands for how to
> generate the samples) but this is the gist of it.

I think this issue isn't related to the mov muxer at least, but is more 
related to how stream copy works at the ffmpeg.c level, and/or how the 
seeking is done.

As that's unrelated, and I haven't heard any objections to my version of 
the patch, I think I'll go ahead and land it soon then.

// Martin



More information about the ffmpeg-devel mailing list