[FFmpeg-trac] #9028(undetermined:new): mp4 durations include edit list delay

FFmpeg trac at avcodec.org
Wed Dec 23 00:32:10 EET 2020


#9028: mp4 durations include edit list delay
-------------------------------------+-------------------------------------
             Reporter:  j0sh         |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
                                     |  undetermined
              Version:  unspecified  |               Resolution:
             Keywords:               |               Blocked By:
             Blocking:               |  Reproduced by developer:  0
Analyzed by developer:  0            |
-------------------------------------+-------------------------------------

Comment (by j0sh):

 Additional samples for testing this patch -
 https://patchwork.ffmpeg.org/project/ffmpeg/patch/20201219231319.56995-1-martin@martin.st/

 These are 40 second clips with a 600-frame (20 second @ 30fps) GOP, so
 we're creating an edit list mid-GOP:

 Sample 1 (mp4)

 Attached as gop-600.mp4 : Works nicely. Command to generate the sample:

 `ffmpeg -f lavfi -i testsrc=duration=40:size=640x480:rate=30 -an -c:v
 libx264 -g 600 -movflags faststart gop-600.mp4 -y`

 Clip the sample via:

 `ffmpeg -ss 17.316666999999999 -i gop-600.mp4 -t 5 -c copy -movflags
 +faststart -y cut-mp4-600.mp4`

 Inspect the result: `ffprobe cut-mp4-600.mp4` should yield something like:
 ` Duration: 00:00:05.12, start: 0.000000, bitrate: 573 kb/s`. All good.


 Sample 2 (mpegts) - this does not seem to be quite correct.

 As gop-600.ts. Command to generate the sample:

 `ffmpeg -f lavfi -i testsrc=duration=40:size=640x480:rate=30 -an -c:v
 libx264 -g 600 gop-600.ts -y`

 Cut with: `ffmpeg -ss 17.316666999999999 -i gop-600.ts -t 5 -c copy
 -movflags +faststart -y cut-ts-600.mp4`

 The output duration seems okay, but playback starts at the beginning of
 the *next* GOP at the 20-second mark, while the clip should start at 17
 seconds. The difference from the expected value seems to be exactly the
 probed start_time value:

 `ffprobe cut-ts-600.mp4 ` yields `  Duration: 00:00:05.12, start:
 2.683000, bitrate: 79 kb/s`

 Specifically - since playback begins at 20s, and the probed start time is
 2.683, so 20-2.683 = 17.317 which should have been the position of the
 initial cut.

--
Ticket URL: <https://trac.ffmpeg.org/ticket/9028#comment:1>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker


More information about the FFmpeg-trac mailing list