#9775 closed defect (fixed)
incorrect duration when start not zero
Reported by: | delpeck | Owned by: | |
---|---|---|---|
Priority: | normal | Component: | avformat |
Version: | git-master | Keywords: | mov duration |
Cc: | Blocked By: | ||
Blocking: | Reproduced by developer: | no | |
Analyzed by developer: | no |
Description (last modified by )
Hello-
I am having a problem with the duration field when I am encoding segments of a HLS - ffmpeg versions greater than 4.3.3 seem to be writing an erroneous duration (the start + real duration). Try the following:
ffprobe attached segment-3.ts results:
Input #0, mpegts, from 'segment-3.ts':
Duration: 00:00:07.35, start: 21.512000, bitrate: 1651 kb/s
encode segment-3.ts
ffmpeg -i segment-3.ts -copyts -map 0:v -c:v libx264 bbb-seg-enc.mp4
/ffprobe the results:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bbb-seg-enc.mp4':
Duration: 00:00:28.87, start: 21.566016, bitrate: 345 kb/s
encode segment-3.ts without the -copyts
ffmpeg -i segment-3.ts -map 0:v -c:v libx264 bbb-seg-enc2.mp4
ffprobe results (notice the duration is correct, but start is zero'd out)
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from 'bbb-seg-enc.mp4':
Duration: 00:00:07.30, start: 0.000000, bitrate: 1367 kb/s
ffmpeg version 4.3.3 and lower write the correct duration and preserve the start time, is there anyway to write the correct duration and preserve the start time with ffmpeg 5.0.1?
Attachments (1)
Change History (9)
by , 2 years ago
Attachment: | segment-3.ts added |
---|
comment:2 by , 2 years ago
Description: | modified (diff) |
---|
comment:3 by , 2 years ago
Description: | modified (diff) |
---|
follow-up: 5 comment:4 by , 2 years ago
Status: | new → open |
---|
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220815231442.1976-1-jamrial@gmail.com/
Will this also fix the remainder of gapless playback, finally? I.e., it will apply media duration from editlist?
comment:5 by , 2 years ago
Replying to Balling:
https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220815231442.1976-1-jamrial@gmail.com/
Will this also fix the remainder of gapless playback, finally? I.e., it will apply media duration from editlist?
I can't tell without a sample. Open a ticket if it doesn't.
comment:6 by , 2 years ago
Resolution: | → fixed |
---|---|
Status: | open → closed |
Should be fixed in 836b8001c924deb9263b0f5b7c74ccfaab1f4fdc.
comment:7 by , 2 years ago
Component: | undetermined → avformat |
---|---|
Keywords: | mov duration added |
Version: | unspecified → git-master |
comment:8 by , 2 years ago
So, no, it does not fix remainder. Two bugs are opened about it: #9140, #7828. Someone needs to fix this thing, fixed by Chromium. And BTW, 102400samples_qt-lc-aac.m4a is also not correctly handled: iTunSMPB says how much samples should be deleted in the start (those are deleted correctly) and how much in the end, ffmpeg does not delete those (Apple style remainder). Duration is 0x19000 samples from 4th actual subfield of iTunSMPB, so 102400 samples. Those remove ALL silence in the end. See https://imgur.com/a/GWbIxjA
2.342993 duration is absolutely wrong, it is 2.321973 or 2.321972.
The actual values in the ticket don't match the attached segment (which is segment-3.ts instead of segment-5.ts) but I can reproduce the same problem. Here's the data on the attached segment
encoded with ffmpeg < 4.4 and -copyts this reports
encoded with ffmpeg 5.0 and -copyts his reports
Digging into the two MP4 files I see that both versions have identical edit lists
we see the empty edit which represents the start time. However the duration reported in the container, in mvhd and tkhd is different. Older ffmpeg reported only the media duration without the empty edit
whereas newer ffmpeg reports the entire duration with the start time offset of the empty edit.
This new duration at the container does seem to be correct in terms of the ISOBMFF spec
But the net combination of reported start time and duration seems a bit confusing.
I'd expect the final timestamp is going to be start time + duration, and the reported values don't add up. Furthermore we essentially have a TS file and an MP4 file that represent the same slice of a longer video with preserved timestamps and they report different values for start time and duration, which seems confusing.