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

FFmpeg trac at avcodec.org
Thu Dec 21 18:23:42 EET 2017


#6915: DASH audio segments duration doesn't match exactly with video segments
duration.
------------------------------------+-------------------------------------
             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:25 beloko]:
 > My notes were for knowledge purposes about HLS playback with common and
 official video players. And used by Apple itself.
 >
 > For sure the #EXT-X-TARGETDURATION cannot be rounded or forced to a
 lower value just to satisfy and dupe the Apple mediastreamvalidator tool
 result. But the #EXTINF value could be rounded to the nearest integer
 value when the duration doesn't exceed few small milliseconds.
 We are not rounding just to satisfy mediastreamvalidator. We are rounding
 because the spec says so.
 I think the problem will be that we will need to define that "small". Then
 implementations will have their own definition of "small"
 >
 > #EXTINF:4.010667 could be rounded to #EXTINF:4.000000.
 > Or #EXTINF:3.989333 could be rounded to #EXTINF:4.000000.
 >
 > Then the #EXT-X-TARGETDURATION can be set to 4 because the #EXTINF
 duration will never exceed 4.000000.
 >
 > The difference in milliseconds between the real segment duration and the
 #EXTINF value setted in the audio playlist doesn't seems to affect HLS
 playback. Probably because the shortest duration of the preceding segment
 is compensated by the following segment. Which has a duration longer than
 4 seconds. And so on until the #EXT-X-ENDLIST.
 That is correct. As long as the difference in duration is within the
 duration one audio frame then all player's should be OK with it, as long
 as the next segment compensates for it and maintains the average segment
 duration to be same as the target duration.
 >
 > Should be interesting to see what's the Apple segmenter can produce for
 HLS audio streams. Perhaps it fakes the real #EXTINF segment duration
 value in the M3U8 playlist. Because I'm not sure it's possible to  force
 the gop size or inject a keyframe to an audio stream.
 There is no concept of gop or keyframe in an aac/mp3 audio stream.
 Technically all the aac/mp3 audio frames are key frames, meaning you could
 start decoding the audio from any frame.
 >
 > Rounding the #EXTINF value to the nearest integer value could be a
 additional parameter in the command line.
 >
 > Ex: -hls_max_segment_duration <int>   E.......... round segments
 duration in HLS playlist if they not exceed few milliseconds
 >
 > Then the -hls_max_segment_duration 2 parameter should be able to fix :
 >
 > #EXTINF:4.010667 into #EXTINF:4.000000.
 > Because 0.010667 seconds is lower than 2 milliseconds
 0.010667 is 10.677 milliseconds, much higher than 2 milliseconds:)
 Theoretically this number could be as high as 128 milliseconds for a 8kHz
 aac audio stream (1024/8000 = 0.128 seconds). And in some other audio
 formats where frame sizes of 2048 and 4096 etc., being used this number
 could go even higher. I think instead of giving that control to the user,
 we should just go by the hls spec and keep things simple.
 Because there were issues in the past with EXTINF being rounded and
 players having difficulty in knowing the exact duration. That is the
 reason when floating point durations were added to the HLS standard. If we
 again round the floating point durations, then it will defeat the whole
 purpose.
 >
 > And #EXTINF:3.989333 into #EXTINF:4.000000
 > Because 4.000000 - 3.989333 = 0.010667 is lower than 2 milliseconds.

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


More information about the FFmpeg-trac mailing list