Support working bandwidth estimator in blocking media segment of LL-HLS

[HyowonHwang]

[REQUIRED] Use case description

Currently I use blocking media segment feature by EXT-X-PRELOAD-HINT like below. However, Exoplayer cannot addSample when tranferring segments by below codes. https://github.com/androidx/media/blob/release/libraries/exoplayer/src/main/java/androidx/media3/exoplayer/upstream/DefaultBandwidthMeter.java#L398 Is threre any ways to solve this, please?

#EXTM3U
#EXT-X-VERSION:10
#EXT-X-INDEPENDENT-SEGMENTS
#EXT-X-TARGETDURATION:2
#EXT-X-SERVER-CONTROL:CAN-BLOCK-RELOAD=YES,PART-HOLD-BACK=3.000000
#EXT-X-PART-INF:PART-TARGET=1.000000
#EXT-X-MEDIA-SEQUENCE:3624
#EXT-X-DISCONTINUITY-SEQUENCE:0
#EXT-X-DATERANGE:ID="tt-daterange",START-DATE="2024-07-09T04:54:07.573Z"

#EXT-X-MAP:URI="1080p_0_0_0.m4s?type=hls&filetype=.m4s"
#EXT-X-PROGRAM-DATE-TIME:2024-07-09T06:54:54.573Z
#EXT-X-PART:DURATION=1.000000,URI="1080p_2087764456_1720508094573_7247_0_3624_0.m4v?type=hls&filetype=.m4v",INDEPENDENT=YES
#EXT-X-PART:DURATION=1.000000,URI="1080p_2087764456_1720508094573_7247_0_3624_1.m4v?type=hls&filetype=.m4v",INDEPENDENT=YES
#EXTINF:2.000000,
1080p_2087764456_1720508094573_7247_0_3624.m4v?type=hls&bitrate=1061018&filetype=.m4v
#EXT-X-PROGRAM-DATE-TIME:2024-07-09T06:54:56.573Z
#EXT-X-PART:DURATION=1.000000,URI="1080p_3946427492_1720508096573_7249_0_3625_0.m4v?type=hls&filetype=.m4v",INDEPENDENT=YES
#EXT-X-PART:DURATION=1.000000,URI="1080p_3946427492_1720508096573_7249_0_3625_1.m4v?type=hls&filetype=.m4v",INDEPENDENT=YES
#EXTINF:2.000000,
1080p_3946427492_1720508096573_7249_0_3625.m4v?type=hls&bitrate=1017304&filetype=.m4v
#EXT-X-PROGRAM-DATE-TIME:2024-07-09T06:54:58.573Z
#EXT-X-PART:DURATION=1.000000,URI="1080p_1348917084_1720508098573_7251_0_3626_0.m4v?type=hls&filetype=.m4v",INDEPENDENT=YES
#EXT-X-PART:DURATION=1.000000,URI="1080p_1348917084_1720508098573_7251_0_3626_1.m4v?type=hls&filetype=.m4v",INDEPENDENT=YES
#EXTINF:2.000000,
1080p_1348917084_1720508098573_7251_0_3626.m4v?type=hls&bitrate=1024458&filetype=.m4v
#EXT-X-PART:DURATION=1.000000,URI="1080p_1609383021_1720508100573_7253_0_3627_0.m4v?type=hls&filetype=.m4v",INDEPENDENT=YES
#EXT-X-PRELOAD-HINT:TYPE=PART,URI="1080p_1609383021_1720508100573_7253_0_3627_1.m4v?type=hls&filetype=.m4v"
#EXT-X-RENDITION-REPORT:URI="chunklist_720p.m3u8",LAST-MSN=3627,LAST-PART=0
#EXT-X-RENDITION-REPORT:URI="chunklist_480p.m3u8",LAST-MSN=3627,LAST-PART=0
#EXT-X-RENDITION-REPORT:URI="chunklist_360p.m3u8",LAST-MSN=3627,LAST-PART=0
#EXT-X-RENDITION-REPORT:URI="chunklist_144p.m3u8",LAST-MSN=3627,LAST-PART=0

[tianyif]

Hi @HyowonHwang,

Thanks for filing the issue! Looking at some contexts when we developed the support for LL-HLS, I saw that we marked the preload segment with FLAG_MIGHT_NOT_USE_FULL_NETWORK_SPEED intentionally.

In fact, bandwidth estimation based on transfers is only possible if the transfers happen as fast as possible, that is, the transfer events we receive assume that the underlying network connection is working as fast as possible and thus the resulting estimate can be used for any future data transfer. This assumption may be violated in the case of Low-latency live streaming where the measured bandwidth may also be limited by the speed in which the downloaded content is generated on the server. For example, low-latency live streaming systems that allow fetching unfinished chunks can't be faster than the real-time playback speed.

I'm leaving this open as an enhancement given that I didn't find any previous equivalent issue that tracks this, but this may not be revisited for a better solution in the very near future I'm afraid.