[FFmpeg-trac] #6915(avformat:open): DASH audio segments duration doesn't match exactly with video segments duration.

FFmpeg trac at avcodec.org
Sat Dec 23 12:57:20 EET 2017

#6915: DASH audio segments duration doesn't match exactly with video segments
             Reporter:  beloko      |                    Owner:  stevenliu
                 Type:  defect      |                   Status:  open
             Priority:  normal      |                Component:  avformat
              Version:  git-master  |               Resolution:
             Keywords:              |               Blocked By:
             Blocking:              |  Reproduced by developer:  0
Analyzed by developer:  0           |

Comment (by j_karthic):

 Replying to [comment:52 beloko]:
 > However segments duration for chunk-stream1-00002.m4s, chunk-
 stream1-00004.m4s and chunk-stream1-00006.m4s exceed the
 #EXT-X-TARGETDURATION limit in the audio playlist.
 Why is that an issue? Are you observing any players/validators complaining
 about it? It is perfectly fine as per the spec. That is what last
 discussion was all about. EXT-X-TARGETDURATION can be lesser than EXTINF
 duration, as long as the round(EXTINF duration)<= EXT-X-TARGETDURATION.
 > I think #EXTINF values could be rounded like this :
 > {{{
 > #include <stdio.h>
 > #include <math.h>
 > int main(int argc, char *argv[])
 > {
 >     double targetduration = 4.000000;
 >     double extinf = 4.010667;
 >     if(extinf > targetduration)
 >     { extinf = round(extinf * 10.0) / 10.0; }
 >     fprintf(stdout, "value #EXTINF: %f\n", extinf);
 >     return 0;
 > }
 > }}}
 > This is what Apple does to produce HLS streams with variant audio
 playlists to cover the RFC 8216's requirements.
 > Also I tested with 1 second segments and 10 seconds segments. And the
 difference between "extinf" and "targetduration" never exceed 0.100000
 > . If -min_seg_duration 1000000 in FFMPEG's command line
 > then targetduraion = 1.000000 and max(extinf[]) = 1.002667.
 > . If -min_seg_duration 10000000 in FFMPEG's command line
 > then targetduraion = 10.000000 and max(extinf[]) = 10.005333.
 > Result is safe and comply with "The EXT-X-TARGETDURATION tag specifies
 the maximum Media Segment duration.  The EXTINF duration of each Media
 Segment in the Playlist file, when rounded to the nearest integer, MUST be
 less than or equal to the target duration; longer segments can trigger
 playback stalls or other errors."
 > It said the #EXTINF can be rounded. But it must be less than or equal to
 That was the definition for EXT-X-TARGETDURATION. It says round(EXTINF
 duration)<= EXT-X-TARGETDURATION. It doesn't say that rounded EXTINF
 duration must be specified in the playlist. Here is the definition for
 EXTINF duration.

 {{{  EXTINF

    The EXTINF tag specifies the duration of a Media Segment.  It applies
    only to the next Media Segment.  This tag is REQUIRED for each Media
    Segment.  Its format is:


    where duration is a decimal-floating-point or decimal-integer number
    (as described in Section 4.2) that specifies the duration of the
    Media Segment in seconds.  Generally, durations SHOULD be decimal-
    floating-point, with enough accuracy to avoid perceptible error when
    segment durations are accumulated.  If the compatibility version
    number is less than 3, durations MUST be integers.  Durations that
    are reported as integers SHOULD be rounded to the nearest integer.
    The remainder of the line following the comma is an optional human-
    readable informative title of the Media Segment expressed as raw
    UTF-8 text.

 It suggests providing enough accuracy to EXTINF duration. If you really
 want those durations to be same, we can round it off to the nearest
 integers and specify it as an integer instead of floating point, to be in
 line with the spec. Maybe we can add an option for round_durations similar
 to the one available in hlsenc.
 But I think the current floating point duration is still legal, and most
 popular players should be fine with it.

Ticket URL: <https://trac.ffmpeg.org/ticket/6915#comment:54>
FFmpeg <https://ffmpeg.org>
FFmpeg issue tracker

More information about the FFmpeg-trac mailing list