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

[FFmpeg]

#3724: Computed HLS duration is sometimes 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 saste):

 Replying to [ticket:3724 fthiery]:
 [...]
 > ffprobe reports some duration on the m3u8 resource (in my case,
 1957.493063s) where the actual duration is 1935.033333s (obtained by
 ffprob'ing the original mp4 file or using the last frame timestamp + frame
 duration by analyzing the m3u8 resource with ffprobe). One of the issues
 is that the duration difference is large enough (~40s for one hour of
 content) for most players to seek to an unappropriate location (e.g. 10
 seconds too late).
 >
 > Btw original mp4 file has an average gop size of 30 (video is 30 fps),
 and the goal here is to have 1 second segments for precise seeking.

 I think this is due to the way the segment muxer computes the duration of
 each segment.
 We have this code to compute the ending time (libavformat/segment.c):
 {{{
         seg->cur_entry.end_time =
             FFMAX(seg->cur_entry.end_time, (double)(pkt->pts +
 pkt->duration) * av_q2d(st->time_base));
 }}}

 The adopted semantics is: total segment duration = maximum ending time of
 contained packets minus initial time of the segment. If you have several
 streams it might be that the sum of the segments durations will be greater
 to the real global duration (for a single stream or for an A/V stream
 where A/V durations are aligned this shouldn't be an issue, so you won't
 be able to reproduce the issue with a synthetic {{{testsrc}}} stream).

 Note that when computing the HLS duration (libavformat/hls.c) is simply
 performing the sum of the duration of each segment as read from the EXTINF
 tag.

 A possible solution would be to compute the duration only considering the
 reference stream packets. Not sure if this is consistent with the specs
 though.

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