Audio only does not save data in live streams using HLS

[cyanescent]

Checklist

• [X] I am able to reproduce the bug with the latest version given here: CLICK THIS LINK.
• [X] I made sure that there are no existing issues - open or closed - which I could contribute my information to.
• [X] I have read the FAQ and my problem isn't listed.
• [X] I have taken the time to fill in all the required details. I understand that the bug report will be dismissed otherwise.
• [X] This issue contains only one bug.
• [X] I have read and understood the contribution guidelines.

Affected version

0.27.2

Steps to reproduce the bug

1. Show network speed indicator in the top bar to measure the download speed.
2. Open a live stream in NewPipe with audio only: ~200-300 kB/s.
3. Close NewPipe and switch to the same Youtube live through a browser (Brave).
4. Choose the minimum resolution (144p): ~40 kB/s.

Expected behavior

The step 2 should show a data usage <40 kB/s and actually save data compared to a video live stream.

Actual behavior

The data usage remains high in NewPipe with audio only, even after 1 min.

Affected Android/Custom ROM version

Android 13 /e/OS 2.5

Affected device model

Fairphone 3+

[opusforlife2]

From #7349, this is the reason:

Note that livestreams will still fetch the video stream (because streams we are getting right now are not demuxed (this will probably change soon) and there is an ExoPlayer bug which still fetches video even if it has been disabled with the track selector for HLS contents (the delivery method we can only use for livestreams right now) (a low priority has been given by the ExoPlayer team to this bug)).

@AudricV Has the situation changed here? Maybe media3 doesn't have this problem?

[AudricV]

No, nothing has changed sadly in Media3.

DASH manifests can be prioritized as a workaround, but in order to use the DASH manifests of YouTube livestreams (version 5 up to 7), we need to fix them, as ExoPlayer starts them from the beginning of the live window (only the period?) (i.e. the earliest point with which you can rewind). For other services that use HLS for livestreams only, nothing will change.

I don't know right now what causes the start position issue (it doesn't seem to be a NewPipe bug this time). For some reason, the availabilityStartTime property in DASH manifests of YouTube causes issues in ExoPlayer. Setting this value to "1970-01-01T00:00:00Z" like in this sample makes the library handle things like expected.