ExoPlayer IMA extension for SSAI DASH Live stream.

[miroslawz81]

According to https://developers.google.com/interactive-media-ads/docs/sdks/android/dai/exoplayer-extension I should be able to do this:

// Build an IMA SSAI media item to prepare the player with.
Uri ssaiLiveUri =
    new ImaServerSideAdInsertionUriBuilder()
        .setAssetKey(SAMPLE_ASSET_KEY)
        .setFormat(CONTENT_TYPE_HLS) // Use CONTENT_TYPE_DASH for dash streams.
        .build();

but with CONTENT_TYPE_DASH instead of CONTENT_TYPE_HLS

When we try the setup as above we get IllegalStateException and upon further investigation we can trace the source of this exception to ImaServerSideAdInsertionUriBuilder.createStreamRequest(...) call.

checkState(
    streamRequest.getFormat() != StreamFormat.DASH
        || TextUtils.isEmpty(streamRequest.getAssetKey()),
    "DASH live streams are not supported yet.");

We're using ExoPlayer version 2.18.2 and wondering when will you support DASH format for Live when using IMA SSAI?

[marcbaechinger]

The comment in the code snippet of developers.google.com is wrong (or true for VOD only) because an asset key implies a live stream. You are right this is incorrect in the context of that code.

Support of live streams with DASH (multi-period) is on the roadmap for Q1/2023. I'll keep this issue open and will report when we made some contributions for this.

[almahirpm]

Hello!
Do we have an ETA for this?
Thanks in advance.

[marcbaechinger]

Sorry, no ETA besides that this is currently in the works.

[miroslawz81]

Is there a chance that this feature will be available in the next official release and what is the ETA for that release?

[marcbaechinger]

Yes. The commit above is from the branch that will be merged into the release branch as 1.1.0-beta01.

This is a process that already started.

[miroslawz81]

Are you commiting this change only to media3 branch or also to exoplayer "2.18.8" branch. We need this change pretty badly and we need to have this ASAP so would like to know if we should start migration from exoplayer to media3 (which we're planning to do anyway but would prefer to wait a little bit longer).
Also is there a more precise of ETA for this change e.g. end of June maybe?

Thanks @marcbaechinger

[icbaker]

Media3 1.1.0 beta01 is scheduled to be released on 7th June and will include the commit Marc linked above.

ExoPlayer 2.19.0 will also include this commit and is scheduled to be released on 5th July (at the same time as Media3 1.1.0 stable) - so you can get the commit in a maven artifact about a month quicker by migrating to Media3.

We're not planning an ExoPlayer 2.18.8 at the moment (that would correspond to Media3 1.0.3 which we're also not planning).

If you need it earlier, you can depend on ExoPlayer locally: https://github.com/google/ExoPlayer#locally

---

Please note that even with the commit above, seeking in DAI DASH live streams is not supported.

[miroslawz81]

Is seeking, in DAI DASH live streams not supported, an ExoPlayer extension limitation or is it Google Ad Manager DAI limitation and what is the path forward to resolving this?

Thanks

[marcbaechinger]

There are some edge-cases that can crash the player when seeking. That's why we declare it unsupported.

The crashes I've seen happen under these conditions (this equally applies to HLS streams by the way):

1. The live stream has ad groups with more than a single ad.
2. The user joins the live stream at a moment/position when an ad group is playing. If that position is at an ad that is not the first ad of the ad group, the extension doesn't get the full ad information of that group. Neither SDK nor the extension have this information that is in the metadata of the media before the playback position that never has been played. The extension then inserts a partial ad group to handle this join-while-ad scenario.
3. If the user now seeks back beyond this partial ad group, the SDK receives the formerly unknown metadata and emits the ad events of the ads. The extension inserts another partial ad group.
4. At the end of the new partial ad group the player crashes.

A similar scenario can happen if the users seeks backwards into an ad group several times. Instead joining a live stream in 2), the seek creates the partial ad groups. This creates the same problem if metadata before the seek position is not available.

The proper fix is to merge these ad groups at point 3 above, which is not really straight-forward. There is a possible easy fix that would simply ignore marking the second partial ad group, but in the context of apps expecting all played ads to be correctly reported this doesn't seem to be a good approach.

If you have a stream that only has ad groups with a single ad, the above scenario can not happen. In this case seeking works as far as I have tested with the test streams available to me.

At the moment I can't say when we get a chance to solve this. We are giving our best to get this into a roadmap as we agree this is an important feature. Sorry for not being able to give you a better answer.

[miroslawz81]

Thanks @marcbaechinger and @icbaker . This is very helpful!