[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