CMAF and live delay optimization question

[Gian84]

I see that Exoplayer supports CMAF.
I would like to know if you have planned to implement the live delay optimization concerning the “sub chunk”.
I mean to process the single chunk before the get request is completed.
For example to process 200ms in a chunk having a duration of 2s.

Thank you

[ojw28]

We already do that.

[ojw28]

By "that", I mean that we start consuming data as soon as we receive it, rather than waiting for the whole chunk request to complete. I doubt this makes much of a difference to live delay though.

[Gian84]

Thanks so much for the explanation ojw28.
I had this doubt about Exoplayer optimizations because I was comparing Exoplayer with DASH IF Reference Client on the web (http://reference.dashif.org/dash.js/v2.9.0/samples/dash-if-reference-player/index.html) and if you try a live (Dynamic MPD for example) Low Latency content you can see a difference of 8 seconds more or less.
I already have set Exoplayer live delay (DEFAULT_LIVE_PRESENTATION_DELAY_MS in DashMediaSource) to 0 seconds.
I'm using Exoplayer 2.9.0.

Could I change some other parameters in Exoplayer to get the same latency of the web player DASH IF?

Thanks,
Gian

[linhai326]

did you set suggestedPresentationDelay tag in your manifest file? If not, Exoplayer will use a default 30 seconds for delay.

[ojw28]

The good news is it's possible to get the latency down (see below). The bad news is that ExoPlayer just isn't designed with this in mind currently, so there are quite a few things that need doing (details to follow).

[ojw28]

Test media: https://vm2.dashif.org/livesim-chunked/chunkdur_1/ato_7/testpic4_8s/Manifest300.mpd

Note on the media: It lacks a UtcTiming element, which I think it really should have, particularly if it's going for low latency. In it's current form I think it relies on the client having a synchronized clock.

Notes on ExoPlayer: There are a whole bunch of things that ExoPlayer does that are not friendly to this type of content:

1. We do not parse or use availabilityTimeOffset, which is 7 seconds in this manifest.
2. DashMediaSource only updates which segments are available every 5 seconds for this type of media, here, where-as a much faster rate is required.
3. DashMediaSource will attempt to snap the playback start position back to a segment boundary. This moves playback further behind the live edge, although the benefit is playback can start immediately because it's not necessary to decode and discard up to the non-snapped starting position (i.e. it's a trade-off between starting more quickly, but further behind, or waiting longer to start, but closer to the live edge when you do). I got good results just by disabling snapping.
4. There are some configuration changes you need to make to the player. In particular turning the presentation delay down and minimum buffered duration parameters down to 0 (or some small value).

A patch that gets the latency down to comparable with the reference client can be found here: 36f5c0c

Note that the availabilityTimeOffset value is hardcoded for the particular piece of media, so it's definitely not safe just to take and use ;).

[ojw28]

Spun out #4904 to track making this better.

[Gian84]

It works perfectly! :)
Thanks so much for the clear patch.

Gian