search

shaka-project / shaka-packager

A media packaging and development framework for VOD and Live DASH and HLS applications, supporting Common Encryption for Widevine and other DRM Systems.
https://shaka-project.github.io/shaka-packager/
Other
1.98k stars 507 forks source link

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

Closed synologic closed 6 years ago

synologic commented 6 years ago

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_19201080$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 commented 6 years ago

@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 commented 6 years ago

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 commented 6 years ago

@vaage There are a few problems with estimated bandwidth:

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 commented 6 years ago

@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 commented 6 years ago

@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/audioeng$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/audiohun$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/audiorum$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_19201080$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_1280720$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_640360$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_384216$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 commented 6 years ago

@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 commented 6 years ago

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: https://github.com/google/shaka-packager/issues/361. The value should more or less match the bandwidth specified in FFmpeg's -b: option.

kqyang commented 6 years ago

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

synologic commented 6 years ago

Can be closed. Thank you

On Fri, 11 May 2018, 19:21 Kongqun Yang, notifications@github.com 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 https://github.com/google/shaka-packager/issues/389#issuecomment-388429109, or mute the thread https://github.com/notifications/unsubscribe-auth/AKU7m47EsI7nepkq-OV_KhYQVHhUHnxRks5txciWgaJpZM4TrWDM .