Closed sguinetti closed 11 hours ago
oxyroid
commented
3 weeks ago As far as I know now, we cannot know whether the streaming media is fixed length before it is ready, but whether to use caching needs to be decided before loading it. In addition, for some live streams, even if we specify not to cache dynamic length video streams, the framework will still cache them.
sguinetti
commented
3 weeks ago I have checked on the Apple forum about the differences between the three types that HLS can carry. I quote the bottom line:
- VOD - has EXT-X-PLAYLIST-TYPE:VOD; contains all segments; has an EXT-X-ENDLIST tag
- EVENT - has EXT-X-PLAYLIST-TYPE:EVENT; periodically refetched, each time getting longer; eventually adds an EXT-X-ENDLIST tag
- LIVE - does not have EXT-X-PLAYLIST-TYPE; periodically refetched, with sliding window; NEVER gets an EXT-X-ENDLIST tag.
I believe, I am not an encoding specialist, that if the media player identifies "EXT-X-ENDLIST" in a m3u8 manifest it could perform the caching process by its fixed length. Per example, in tears-of-steel-audio_eng=128002-video_eng=2200000.m3u8 file from m3u8 main file:
#EXTM3U
#EXT-X-VERSION:1
## Created with Unified Streaming Platform (version=1.13.0-29687)
#EXT-X-MEDIA-SEQUENCE:1
#EXT-X-TARGETDURATION:4
#USP-X-TIMESTAMP-MAP:MPEGTS=900000,LOCAL=1970-01-01T00:00:00Z
#EXTINF:4, no desc
tears-of-steel-audio_eng=128002-video_eng=2200000-1.ts
#EXTINF:4, no desc
tears-of-steel-audio_eng=128002-video_eng=2200000-2.ts
[...]
#EXTINF:4, no desc
tears-of-steel-audio_eng=128002-video_eng=2200000-184.ts
#EXT-X-ENDLISTMaybe it's complicated, but that could determine whether one video is live and one is VOD. In case m3u is too complicated to determine, then the app should be set to cache mp4 or similar files and exclude m3u8.
oxyroid
commented
3 days ago The problem is that many playlists don't follow this standard.
Is your feature request related to a problem? Please describe. I have noticed that "cache while playing" is useful for watching movies and series in Xtream (or M3U files that only contain time-lapse videos and not live). So, I am happy that this direction has been taken. However, this feature is complicated for live transmissions because only the first 30 seconds are displayed and activating "cache while playing" ends up making it difficult to view live streaming channels (because the image gets stuck).
Describe the solution you'd like My solution is to have an option to view "cache while playing" in these circumstances:
Describe alternatives you've considered It is a third option instead of activating or deactivating the feature completely.
Additional context The caching issue makes more sense for rewatchable videos than for live channels. Videos need to be cached so they don't reload again and waste bandwidth. On the other context, live channels are always refreshed every moment and also take up unnecessary space, so the cache loses sense in that case.
P.S.: The option to set the cache limit is missed. This option is important for cell phones with limited storage. I would appreciate if it is added in the settings. Like this image from InnerTune:
P.S. 2: Also, because you are using androidx-media3-media3-exoplayer-hls, I have found a HLS Downloader section, which can be written in Kotlin. I think, it is an alternative to the androidx.media3.datasource.cache library cache (which does not affect formats other than m3u/m3u8). This option would help with offline viewing of HLS content and maybe help solve the problem (bug) when the image gets stuck.
More info: https://developer.android.com/reference/kotlin/androidx/media3/exoplayer/hls/offline/HlsDownloader
(edited for new lines)