Open joeyparrish opened 3 years ago
@joeyparrish Thanks for bringing it up! Agree that it is better to round to the nearest integer instead of rounding up to the next integer.
I'll consider it an "enhancement" as "rounding up" does not violate HLS specification.
@kqyang Any updates on this? Are you open to a pull request? Whilst it doesn't violate the HLS spec for sure, it's not expected behaviour for an HLS packager.
@JPeMu Definitely. A PR is always welcomed and appreciated.
@joeyparrish I disagree with your interpretation.
By the standard, TARGETDURATION
should be greater or equal. That discards rounding down, and in your examples "5" is actually the correct value.
@Canta is correct. Target Duration must be set to the largest value of any segment and then rounded up.
Let me add some context to my previous comment, as I feel it sounds kinda picky given that common sense dictates that 0.011
seconds shouldn't be an issue for any player, and thus rounding down is not a big deal.
I stumbled into this issue while looking for open issues regarding TARGETDURATION
tag. That's because I'm having trouble with it. Take a look at this:
[root@server ~]# grep TARGETDURATION /path/to/file.m3u8
#EXT-X-TARGETDURATION:11
[root@server ~]# grep EXTINF /path/to/file.m3u8 | sort -u
#EXTINF:3.200,
I expect TARGETDURATION
to be 4
there. Yet, it's 11
, because apparently at some time there was some abnormally large chunk in the playlist, and TARGETDURATION
doesn't seem to refresh from the historical maximum detected. Thing is, I've discovered it because some players in some apps in some devices where crashing because of this.
My problem is different. But my point is: please just do as the spec says. Players can be and actually are a massive PITA for us working on the server side, and strictly respecting the standard is usually our only line of defense when dealing with other parties involved in multimedia operations. If tomorrow Shaka Packager deviates from the standard just for that annoying 0.011
seconds, then I'll most likely have to edit packager's code just for convincing some other party that their player is having an issue. So, please, if possible, just don't deviate from the standard by default, no matter how nonsensical it could look.
Maybe allowing this by command line flag would be a good alternative.
@Canta is correct. Target Duration must be set to the largest value of any segment and then rounded up.
Hmm... the above quoted section (4.3.3.1) in the spec says when rounded to the nearest integer
and not when rounded up to the next integer
. So, IMHO, 4 should be correct in the above example. Of course, 5 is not wrong either and maybe a safer choice, right?
Well... now I'm confused. :P
But there's two values involved here:
EXTINF is the one with the MUST restriction. And that MUST says "less than or equal". So, if we round down EXT-X-TARGETDURATION for whatever reason, and we decide to also round EXTINF, that second rounding should be less or equal than the first one.
In my previous comments I wasn't considering rounding EXTINF. My argument was "targetduration should not be 4 for chunk duration 4.011". But if EXTINF is also rounded to 4 for that chunk, I guess it's OK to also round targetduration. I believe it's still safer to just round up targetduration, and that's it. But it's a valid point.
For a chunk duration of 4.011 its perfectly acceptable (and even desirable) in my experience to use a target duration of 4.0 and remain spec compliant. Apple's HLS validator tool accepts this too.
The spec states rounded to the nearest integer, not rounded up.
Just my 2cents.
On Thu, 10 Jun 2021, 22:41 Daniel Cantarín, @.***> wrote:
Well... now I'm confused. :P
But there's two values involved here:
- EXT-X-TARGETDURATION
- EXTINF
EXTINF is the one with the MUST restriction. And that MUST says "less than or equal". So, if we round down EXT-X-TARGETDURATION for whatever reason, and we decide to also round EXTINF, that second rounding should be less or equal than the first one.
In my previous comments I wasn't considering rounding EXTINF. My argument was "targetduration should not be 4 for chunk duration 4.011". But if EXTINF is also rounded to 4 for that chunk, I guess it's OK to also round targetduration. I believe it's still safer to just round up targetduration, and that's it. But it's a valid point.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/google/shaka-packager/issues/841#issuecomment-859095121, or unsubscribe https://github.com/notifications/unsubscribe-auth/AB34C7FUVDHHTDZ6R5HA65DTSEWP5ANCNFSM4RMEZYPA .
For a chunk duration of 4.011 its perfectly acceptable (and even desirable) in my experience to use a target duration of 4.0 and remain spec compliant. Apple's HLS validator tool accepts this too.
I believe you. And I also share the belief that it's desirable (if I don't get annoying with the spec).
The spec states rounded to the nearest integer, not rounded up.
That goes for EXTINF, not for EXT-X-TARGETDURATION. And, actually, it's not even for EXTINF, at least not in the quote.
The "MUST" clause involves a relationship between the two (different) values. The spec quote mentions the hypothetical case when you round to the nearest integer. The restriction goes like this: "whatever your rounding, EXTINF should never be bigger than EXT-X-TARGETDURATION".
So... what you say should only be ok if you ALSO round EXT-X-TARGETDURATION
, and not JUST EXT-X-TARGETDURATION
.
I've been experiencing this issue as well. According to the spec, there’s a 0.5 second "leeway":
7.7. Media Segments MUST NOT exceed the target duration by more than 0.5 seconds.
Therefore, we should only round up #EXT-X-TARGETDURATION
when #EXTINF > (#EXT-X-TARGETDURATION + 0.5)
.
I'm not entirely sure if this should be >=
or just >
, but currently, we're rounding up even for a fraction of it.
The validator accepts this change if I manually round down the TARGETDURATION.
Additionally, there's another issue related to TARGETDURATION, this time with the iframe playlists.
The options --segment_duration=6 --fragment_duration=2
should result in the video playlists' target duration being 6 and the iframe's target duration being 2.
However, since my audio-only playlists never round to an integer (I would appreciate some help with this), the packager sets the target duration of all playlists (audio, video, iframe) to 7. This causes the validation report to show a -50% diff errors for iframe variants. Manually updating the audio and video target durations to 6 and the iframe's target duration to 2 results in ~0% differences.
System info
Operating System: Ubuntu 20.04 LTS Shaka Packager Version: v2.4.1-c731217-release
Issue and steps to reproduce the problem
Packager Command: I used Shaka Streamer instead of using Packager directly.
Commands generated by Shaka Streamer:
ffmpeg -y -vaapi_device /dev/dri/renderD128 -f image2pipe -framerate 25 -re -thread_queue_size 200 -i /tmp/shaka-live-zzwwvm4u/8a5e7965-6aea-4353-8aef-455a33ecd10d -stream_loop -1 -re -thread_queue_size 200 -i intermediate/audio_loop.mp4 -map 0:v:0 -preset ultrafast -f mpegts -pix_fmt yuv420p -flags +cgop -profile:v high -an -c:v h264 -b:v 2M -keyint_min 100 -g 100 -vf pad=1280:720:20:20,scale=-2:720,setsar=1:1 /tmp/shaka-live-zzwwvm4u/cd3e37c1-5fcc-4a39-8569-9c50c0cad2df -map 0:v:0 -preset ultrafast -f mpegts -pix_fmt yuv420p -flags +cgop -profile:v main -an -c:v h264 -b:v 1M -keyint_min 100 -g 100 -vf pad=1280:720:20:20,scale=-2:480,setsar=1:1 /tmp/shaka-live-zzwwvm4u/e1059f0a-6fa7-47ef-9913-f8f799a261f6 -map 0:v:0 -f webm -dash 1 -row-mt 1 -an -c:v vp9_vaapi -b:v 1M -keyint_min 100 -g 100 -vf pad=1280:720:20:20,format=nv12,hwupload,scale_vaapi=-2:720,setsar=1:1 /tmp/shaka-live-zzwwvm4u/5151fde5-fd61-4087-91a1-26cf4dadfe6a -map 0:v:0 -f webm -dash 1 -row-mt 1 -an -c:v vp9_vaapi -b:v 512k -keyint_min 100 -g 100 -vf pad=1280:720:20:20,format=nv12,hwupload,scale_vaapi=-2:480,setsar=1:1 /tmp/shaka-live-zzwwvm4u/b2d726a4-5bf4-4356-82bf-7c8c4c775307 -map 1:a:0 -vn -ac 2 -c:a aac -b:a 128k -f mpegts /tmp/shaka-live-zzwwvm4u/839235f1-a6b2-4edc-90db-654cc4e5dfd7
packager 'in=/tmp/shaka-live-zzwwvm4u/cd3e37c1-5fcc-4a39-8569-9c50c0cad2df,stream=video,init_segment=tmp/output_files/player-source/video_720p_2M_init.mp4,segment_template=tmp/output_files/player-source/video_720p_2M_$Number$.mp4' 'in=/tmp/shaka-live-zzwwvm4u/e1059f0a-6fa7-47ef-9913-f8f799a261f6,stream=video,init_segment=tmp/output_files/player-source/video_480p_1M_init.mp4,segment_template=tmp/output_files/player-source/video_480p_1M_$Number$.mp4' 'in=/tmp/shaka-live-zzwwvm4u/5151fde5-fd61-4087-91a1-26cf4dadfe6a,stream=video,init_segment=tmp/output_files/player-source/video_720p_1M_init.webm,segment_template=tmp/output_files/player-source/video_720p_1M_$Number$.webm' 'in=/tmp/shaka-live-zzwwvm4u/b2d726a4-5bf4-4356-82bf-7c8c4c775307,stream=video,init_segment=tmp/output_files/player-source/video_480p_512k_init.webm,segment_template=tmp/output_files/player-source/video_480p_512k_$Number$.webm' 'in=/tmp/shaka-live-zzwwvm4u/839235f1-a6b2-4edc-90db-654cc4e5dfd7,stream=audio,init_segment=tmp/output_files/player-source/audio_und_2c_128k_init.mp4,segment_template=tmp/output_files/player-source/audio_und_2c_128k_$Number$.mp4' --segment_duration 4 --time_shift_buffer_depth 1200 --preserved_segments_outside_live_window 3 --suggested_presentation_delay 30 --minimum_update_period 8 --mpd_output tmp/output_files/player-source.mpd --hls_playlist_type LIVE --hls_master_playlist_output tmp/output_files/player-source.m3u8
What is the expected result? Segment durations are all roughly 4s (4.000s for video, 4.011 and 3.989 for audio). So I would expect the EXT-X-TARGET-DURATION to be 4, as well.
What happens instead? The target duration is 5, instead.
The HLS spec section 4.3.3.1 says: