Open xblabs opened 4 years ago
radiantmediaplayer
commented
4 years ago Hi, thanks for the feedback.
Can you describe a production use-case where there is a need to differiente the load part from the start part? The vast majority of cases I have seen in the online ad industry do not require that differentiation.
Thanks Arnaud
xblabs
commented
4 years ago Hi Arnaud, sure. One being latency, being able to control ad load times, especially being affected by multiple waterfall items accumulating a load latency. Showing other content strategically before a precice and controlled ad play. Load must happen before that or at least possibiity to control needs to be granted. Load and play is super super restrictive. Other reason being is that we are bound to VAST 2 mostly still, so, also being agnostic to other ad server intermediaries, custom ad pods need to be built. Here, again coming back to latency, we need freedom to control when to preload another pod slot, e.g. at 75% VTR of current playing item. I could give more reasons but these are the most striking one. I think you get my point.
loadAds() does too much and should be broken down into loadAds() and startAds() , loadAds() doing what the name suggest - loading the ad, while startAds() starts the ad.
currently there is no way to preload ads without having the player starting the ad. This has several unwanted side effects. There is currently no way to tap into the internal sequence, let's say after the "adtagloaded" event, and prevent the ad from being started. Even if immediately pausing the ad via pause() after the "adstarted" event , it is not clear if the the impression tracking request has already been submitted, and firing the tracking pixel prematurely is not desirable, if the goal is to postpone ad start after it has loaded.