bandwidth parameter is not propagated to HLS EXT-X-STREAM-INF:BANDWIDTH

[synologic]

System info

Operating System: Debian 8.10
Shaka Packager Version: version v2.0.3-ef93a1d-release

Issue and steps to reproduce the problem

Packager Command:
'in=udp://127.0.0.1:10001,stream=video,segment_template=out/video_1920_1080_$Bandwidth$_$Time$.ts,playlist_name=1920_1080.m3u8,bandwidth=4000000'

Extra steps to reproduce the problem?
None

What is the expected result?
#EXT-X-STREAM-INF:BANDWIDTH=4000000,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=19200x1080,AUDIO="audio"

What happens instead?
#EXT-X-STREAM-INF:BANDWIDTH=4150854,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=19200x1080,AUDIO="audio"

$Bandwidth$ however seems fine when generating segments:

video_1920_1080_4000000_68929200.ts

[vaage]

@kqyang What is the use case for giving bandwidth? What benefit is there giving an estimated bandwidth when we can calculate the actual bandwidth?

[synologic]

I can give you at least a corner case there, while i was running some tests with ABR, i ended up having an estimated bandwidth on a 720p stream, higher than the one on an 1080p stream, and the player considered the 720p to be the better stream :)

Since this was done for DASH, i don't see why not have the same thing for HLS as an option

[kqyang]

@vaage There are a few problems with estimated bandwidth:

• It is estimated from actual segments and the segment bitrate varies from segment to segment, thus the estimated bandwidth fluctuates from segment to segment. This may not be desirable sometimes.

• A stable bandwidth is required when using $BANDWDITH$ template for media segments for DASH.

Given that users know the bitrate setting when doing transcoding, which is usually more accurate in long run than our estimates based on current available segments, we allow users to inject BANDWIDTH, which when provided, bandwidth estimation should be disabled.

@synologic For the corner case you given, it sounds more like a bug in the transcoder :) It should never happen that the 720p segments have a higher max bitrate than 1080p segments.

In any case, if BANDWIDTH is injected, bandwidth estimation should be disabled and user provided BANDWIDTH should be used.

[vaage]

@synologic Could you share with us the full command you ran? When we run it on our end it all works.

The bandwidth in #EXT-X-STREAM-INF:BANDWIDTH will be the combined audio and video bandwidths. So if you don't specify the audio bandwidth, it will get estimated and result in a variable bandwidth value for the variant.

The reason you are seeing the correct bandwidth for the video segment, is that the video segment only uses the video bandwidth and not a combined bandwidth.

[synologic]

@kqyang possible a transcoder bug or not, it's ffmpeg which we all know it doesn't play very well with CBR :) however it happened, and I agree with your statement there.

@vaage Indeed by adding the audio bitrate for the audio segments in HLS the bitrates are correctly calculated (using the code compiled 2 days ago from git).

By not adding the audio bandwidth, still the bitrate calculation are off.

Here's the command i run
'in=udp://127.0.0.1:10005,stream=audio,segment_template=out/audio_eng_$Time$.ts,playlist_name=audio_eng.m3u8,hls_group_id=audio,hls_name=ENGLISH,language=eng'
'in=udp://127.0.0.1:10006,stream=audio,segment_template=out/audio_hun_$Time$.ts,playlist_name=audio_hun.m3u8,hls_group_id=audio,hls_name=HUNGARIAN,language=hun'
'in=udp://127.0.0.1:10007,stream=audio,segment_template=out/audio_rum_$Time$.ts,playlist_name=audio_rum.m3u8,hls_group_id=audio,hls_name=ROMANIAN,language=rum'
'in=udp://127.0.0.1:10001,stream=video,segment_template=out/video_1920_1080_$Bandwidth$$Time$.ts,playlist_name=1920_1080.m3u8,iframe_playlist_name=iframe_1920_1080.m3u8,bandwidth=6000000'
'in=udp://127.0.0.1:10002,stream=video,segment_template=out/video_1280_720$Bandwidth$$Time$.ts,playlist_name=1280_720.m3u8,iframe_playlist_name=iframe_1280_720.m3u8,bandwidth=2500000'
'in=udp://127.0.0.1:10003,stream=video,segment_template=out/video_640_360$Bandwidth$$Time$.ts,playlist_name=640_360.m3u8,iframe_playlist_name=iframe_640_360.m3u8,bandwidth=960000'
'in=udp://127.0.0.1:10004,stream=video,segment_template=out/video_384_216$Bandwidth$_$Time$.ts,playlist_name=384_216.m3u8,iframe_playlist_name=iframe_384_216.m3u8,bandwidth=320000'
--segment_duration 2
--hls_playlist_type LIVE
--hls_master_playlist_output out/playlist.m3u8
--default_language "en"
--time_shift_buffer_depth 30

and the result i get

#EXT-X-MEDIA:TYPE=AUDIO,URI="audio_hun.m3u8",GROUP-ID="audio",LANGUAGE="hu",NAME="HUNGARIAN",AUTOSELECT=YES,CHANNELS="2"
#EXT-X-MEDIA:TYPE=AUDIO,URI="audio_eng.m3u8",GROUP-ID="audio",LANGUAGE="en",NAME="ENGLISH",DEFAULT=YES,AUTOSELECT=YES,CHANNELS="2"
#EXT-X-MEDIA:TYPE=AUDIO,URI="audio_rum.m3u8",GROUP-ID="audio",LANGUAGE="ro",NAME="ROMANIAN",AUTOSELECT=YES,CHANNELS="2"

#EXT-X-STREAM-INF:BANDWIDTH=2653750,CODECS="avc1.64001f,mp4a.40.2",RESOLUTION=1280x720,AUDIO="audio"
1280_720.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=6153750,CODECS="avc1.640028,mp4a.40.2",RESOLUTION=1920x1080,AUDIO="audio"
1920_1080.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=473750,CODECS="avc1.42c01f,mp4a.40.2",RESOLUTION=384x216,AUDIO="audio"
384_216.m3u8
#EXT-X-STREAM-INF:BANDWIDTH=1113750,CODECS="avc1.4d401f,mp4a.40.2",RESOLUTION=640x360,AUDIO="audio"
640_360.m3u8

#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=2500000,CODECS="avc1.64001f",RESOLUTION=1280x720,URI="iframe_1280_720.m3u8"
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=6000000,CODECS="avc1.640028",RESOLUTION=1920x1080,URI="iframe_1920_1080.m3u8"
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=320000,CODECS="avc1.42c01f",RESOLUTION=384x216,URI="iframe_384_216.m3u8"
#EXT-X-I-FRAME-STREAM-INF:BANDWIDTH=960000,CODECS="avc1.4d401f",RESOLUTION=640x360,URI="iframe_640_360.m3u8"

somehow it estimates ~153k for audio where i asked ffmpeg to encode at 96k the audio tracks.

Still it's no deal breaker since it can be corrected by specifying bandwidth for both video and audio tracks.

Thanks for all the help

[vaage]

@synologic So it looks like setting the bandwidth tag is correct, so the part in question is the bandwidth estimation for streams. In our code it appears we use the max segment bitrate to determine the bitrate of the media playlist. @kqyang Do you remember why we chose to do it this way?

[kqyang]

That is required by HLS specification: https://tools.ietf.org/html/draft-pantos-http-live-streaming-23#section-4.3.4.2.

@synologic I assume you specified bitrate using -b: option in FFmpeg. That specifies the target bit rate, i.e. average bit rate for the encoder. You could also control maximum bitrate using -maxrate option in FFmpeg.

We also have a feature request to support AVERAGE-BANDWIDTH: #361. The value should more or less match the bandwidth specified in FFmpeg's -b: option.

[kqyang]

@synologic Do you have more questions? If not, we will close this issue.

[synologic]

Can be closed. Thank you

…

On Fri, 11 May 2018, 19:21 Kongqun Yang, ***@***.***> wrote: @synologic <https://github.com/synologic> Do you have more questions? If not, we will close this issue. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#389 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKU7m47EsI7nepkq-OV_KhYQVHhUHnxRks5txciWgaJpZM4TrWDM> .