[FFmpeg-trac] #3724(undetermined:new): Computed HLS duration is incorrect with short segment durations

[FFmpeg]

#3724: Computed HLS duration is incorrect with short segment durations
-------------------------------------+-------------------------------------
             Reporter:  fthiery      |                    Owner:
                 Type:  defect       |                   Status:  new
             Priority:  normal       |                Component:
              Version:  git-master   |  undetermined
             Keywords:  hls          |               Resolution:
             Blocking:               |               Blocked By:
Analyzed by developer:  0            |  Reproduced by developer:  0
-------------------------------------+-------------------------------------

Comment (by fthiery):

 I am indeed failing to reproduce it using a clean, generated test file.

 {{{
 ffmpeg -f lavfi -i testsrc -t 1800 -r 30 -g 30 -codec:v libx264 -pix_fmt
 yuv420p -b:v 1M -filter_complex "aevalsrc=sin(440*2*PI*t)" -t 1800 -c:a
 libfaac -b:a 128k test.mp4
 }}}

 Duration is quite precisely 1800s (30 min):
 {{{
 ffprobe test.mp4
 [...]
   Duration: 00:30:00.02, start: 0.023220, bitrate: 313 kb/s
 }}}

 Then i segment:
 {{{
 mkdir ts
 ffmpeg -i test.mp4 -flags -global_header -f segment -segment_time 1
 -segment_list ts/playlist.m3u8 -segment_list_type m3u8 -segment_format
 mpegts -map 0 -bsf h264_mp4toannexb -vcodec copy -acodec copy -y
 ts/media%05d.ts
 }}}

 Duration is then correct
 {{{
 ffprobe ts/playlist.m3u
 [...]
   Duration: 00:30:00.09, start: 0.043422, bitrate: 0 kb/s
 }}}

 The difference is that my content is the concatenation of two mkv files
 using mkvtoolnix's mkvmerge between a 5 seconds long "intro" and the
 actual video. Analyzing the gopsize using ffprobe shows that gops get
 "offset" after the intro video, where the file generated with ffmpeg has a
 perfect gop of 30 all the time.

 Gopsize (i.e. timecode_s is the iframe timecode, gopsize is the number of
 consecutive frames + 1 until the next keyframe):

 ||timecode_s||gopsize||
 ||0.0||30||
 ||1.0||30||
 ||2.0||30||
 ||3.0||30||
 ||4.0||30||
 ||5.0||7||
 ||5.233||30||
 ||6.233||30||
 ||...||...||
 ||94.233||30||
 ||95.233||2||
 ||95.3||28||
 ||96.233||30||
 ||...||...||
 ||220.833||30||
 ||221.833||1||
 ||221.866||29||
 ||686.833||30||
 ||687.833||1||
 ||687.866||29||
 ||688.833||30||
 ||...||...||

 While i am suspecting that this merging is the origin of the problem, is
 there a different way of generating a test video using ffmpeg so that it
 triggers scene changes and shorter gops (as gops of 1 or 2, then 28 in the
 real video) ?

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