Repository navigation
Why Exoplayer downloads content manifest before pre-roll manifest? #1358
Description
We are using Exoplayer 2.16.1 in our application. We are seeing video startup time is high with pre-roll ads and we are checking different options to reduce it.
Our application is using custom ads loader but the implementation sequence is similar to IMA Ads loader.
We are doing the CustomAdsLoader.requestAds() before the player.prepare() as recommended in different Exoplayer threads. So we have the ads URL while making the player.prepare() call.
We noticed that once the player.prepare() call is made,
- Exoplayer first makes call to content's master manifest.
- Later it makes call to
AdsLoader.start(AdsMediaSource adsMediaSource, DataSpec adTagDataSpec, Object adsId, AdViewProvider adViewProvider, EventListener eventListener)
The CustomAdsLoader can provide the ad URLs to Exoplayer using the eventListener.onAdPlaybackState(adPlaybackState) only after the AdsLoader.start() call from Exoplayer.
We think this is causing some playback delay.
So my questions are,
- Why content manifest call is made before
AdsLoader.start()whenAdsMediaSourceis used? - Is there anyway we can force pre-roll manifest and segment download calls before content manifest call?
I checked these questions, did not get answer to my questions:
Activity
[-]Why Exoplayer downloads content master manifest before pre-roll manifest?[/-][+]Why Exoplayer downloads content manifest before pre-roll manifest?[/+]tonihei commentedon May 10, 2024
Thanks for your questions!
As far as I see, the content media, ads loader and ad media are all prepared in parallel. Just by the way the code is structured, you probably see the content manifest load being triggered just before the ads loader init, but both are executed in parallel.
Playback can start if the the AdsLoader returned the
AdPlaybackStateand the first media to be played is ready (either content or ad, depending on whether there is a preroll).Overall, this looks like the most efficient way of loading the required data for playback (everything in parallel + start playback as soon as data for first element is available). Does that match your observations too and if not, could you suggest in more detail what you would like to change or where the delay is coming from in your set up?
If you know the ad manifest URL, you can use caching to download the segments in advance. See https://developer.android.com/media/media3/exoplayer/downloading-media for more details (you probably don't need a Service if you trigger downloads ion background while your app has a Activity). On a lower level, you can also use
CacheWriterdirectly to load individual segments or manifests. During playback, you can then access the same cache to play the already downloaded bytes. See https://developer.android.com/media/media3/exoplayer/network-stacks#cachingmayurk2 commentedon May 10, 2024
@tonihei thanks for the explanation.
I understand maybe due to actual code structure the content manifest loading is triggered first.
But looks like they are not fully parallel. For testing purpose I throttled content manifest request heavily. I do not see parallel requests going for Ads manifest even after
AdsLoaderreturned theAdPlaybackState.Is it because same thread is used to load the Ads manifest? In that case, is there any way I can change the order?
Basically with pre-roll I think the Content manifest request is unnecessary before start playing the ads. So in slower network cases, it is delaying or slowing down the ads manifest request and hence increasing the overall startup time.
tonihei commentedon May 10, 2024
I can see both content loading and ads loader preparation happening in parallel. Could you check that your throttling is just done in a
DataSourcefor example to ensure it's on the background loading thread?If you are using IMA, you may also find that the extension itself waits for the content manifest before loading ads data as it needs to know the content start position before the IMA SDK asks to load an ad. Given you use your own ads loader, could you check that it returns an
AdPlaybackStatevery soon after the ads loader is started? When thisAdPlaybackStatecontains ad URLS, these will be prepared immediately, even if the content is not prepared yet.mayurk2 commentedon May 10, 2024
@tonihei I did not understand it fully. I routing the network calls from phone through PC. I am running Charles tool on PC and doing the throttling only to content master manifest URL.
Can you give more info on what do you mean by
ads loader is startedhere?Is it when
AdsLoader.start(AdsMediaSource adsMediaSource, DataSpec adTagDataSpec, Object adsId, AdViewProvider adViewProvider, EventListener eventListener)is called?Yes, we are giving the
AdPlaybackStatein this call or soon after this call. But the problem isAdsLoader.start()itself is called after starting content manifest request.Also, I do not see request for ads manifest till the content manifest is fetched.
tonihei commentedon May 10, 2024
Thanks for explaining this again. I think this part might be the main area for improvement. I was testing with progressive content media before which has no manifest to load, so I didn't notice this part.
I'll see whether we can let the ads source prepare while the main manifest is still loading to speed it up slightly.
One further note: we need to wait for the initial content manifest to generate the right media structure, for example to know when exactly media start playing in live streams.
Use MaskingMediaSource for AdsMediaSource content source
mayurk2 commentedon May 16, 2024
@tonihei Is this issue fixed now?
Just saw the change - d27c36a
Do you think it can be taken to 2.16.1?
tonihei commentedon May 16, 2024
Yes, it should work to load both content and preroll ad in parallel now.
The change will be in Media3 1.4.0. I assume 2.16.1 refers to an old ExoPlayer version? We are no longer updating the ExoPlayer repository with new releases.