incorrect duration when start not zero

[delpeck]

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?

[Cosmin Stejerean]

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

Duration: 00:00:07.35, start: 21.512000

encoded with ffmpeg < 4.4 and -copyts this reports

Duration: 00:00:07.30, start: 21.566016

encoded with ffmpeg 5.0 and -copyts his reports

Duration: 00:00:28.87, start: 21.566016

Digging into the two MP4 files I see that both versions have identical edit lists

    [edts] size=8+40
      [elst] size=12+28
        entry_count = 2
        entry/segment duration = 21566
        entry/media time = -1
        entry/media rate = 1
        entry/segment duration = 7300
        entry/media time = 1024
        entry/media rate = 1

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

[moov]
  [mvhd]
    timescale = 1000
    duration = 7300
    duration(ms) = 7300
  [trak] 
    [tkhd]
      enabled = 1
      id = 1
      duration = 7300
      width = 1920.000000
      height = 1080.000000

whereas newer ffmpeg reports the entire duration with the start time offset of the empty edit.

[moov] 
  [mvhd]
    timescale = 1000
    duration = 28867
    duration(ms) = 28867
  [trak] 
    [tkhd] 
      enabled = 1
      id = 1
      duration = 28867
      width = 1920.000000
      height = 1080.000000

This new duration at the container does seem to be correct in terms of the ISOBMFF spec

Duration is an integer that indicates the duration of this track (in the timescale indicated in the Movie Header Box). The value of this field is equal to the sum of the durations of all of the track's edits. If there is no edit list, then the duration is the sum of the sample durations, converted into the timescale in the Movie Header Box

But the net combination of reported start time and duration seems a bit confusing.

Duration: 00:00:28.87, start: 21.566016

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.

[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?

[James]

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.

[James]

Should be fixed in 836b8001c924deb9263b0f5b7c74ccfaab1f4fdc.

[Balling]

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.