strict matching of segment boundary#2826
strict matching of segment boundary#2826copybara-service[bot] merged 3 commits intoandroidx:mainfrom
Conversation
|
@marcbaechinger do please let me know if you think this needs further improvement. |
|
Thanks Tamás! Yup, will take that asap. |
1f2e1d0 to
4613ca5
Compare
|
Looks nice, thank you! I'm going to send this for internal review now. You may see some more commits being added as I make changes in response to review feedback. Please refrain from pushing any more substantive changes as it will complicate the internal review - thanks! |
|
Many thanks for the pull. It's merged now. I've added some unit test that actually didn't test your new code, but it was convenient now that the method is visible for testing. I also think the test cases may not happen right now for valid playlist, as the data range need to be within the available playlist time range. However, we consider adding programmatic Interstitial insertion through an API on the ads loader. For such cases, these checks may be useful Thanks again! |
…ing-of-segment-boundary PiperOrigin-RevId: 819743802
This issue is spawned from #2484 (comment)
summary:
at
media/libraries/exoplayer_hls/src/main/java/androidx/media3/exoplayer/hls/HlsInterstitialsAdsLoader.java
Lines 1524 to 1527 in d0e4133
using
mediaPlaylist.targetDurationUscan lead to identifying the wrong index as it's not guranteed that all segments will match the target duration. Especially around interstitial boundaries it's happens often that the actual segment duration is vastly different. This happening a lot of time in a stream can lead to identifying the wrong target segment.The proposed solution instead looks at the actual segment duration to find the best match.
I went with a binary search to try and improve performance for long streams. Our live sliding window streams have more than 1500 segments per playlist.