Exoplayer: DASH: Issues playing DVR live streams

[Yonezpt]

I have been trying to make MPD DVR live streams work with Exoplayer 2.1.1, but the behavior is abnormal. When loading the stream with that manifest format, the player shows (on first load) the duration and progress in negative values, then the progress values change to positive values, but the duration remains negative and since the time is negative, the hours mark gets lost as per https://github.com/google/ExoPlayer/blob/release-v2/library/src/main/java/com/google/android/exoplayer2/ui/PlaybackControlView.java#L572. The stream plays only for 5 seconds (equivalent to the length of the segments in the manifest) and then the playback ends, with no way to resume. However, the player is still working and loading the next segments correctly after the playback ended, but since the playback timers are all "broken", the player thinks it reached (or got past) the end and doesn't continue playing or allow resume, at least this is what I assume is happening.

I have also tried with HLS DVR format - the exact same live stream - and it plays perfectly. The timers display correctly, the timeline scrubber stays at the end position, the user can seek back in time and the playback does not halt after the first segment is played. In short, the experience with this format is perfect. The problem is that I think HLS is not compatible with some devices where MPD would be, which is why I would prefer to have both working in case one isn't compatible with the user device, unless I am wrong about this.

I have always been following the manifest structures YouTube uses since I assume their formats are compatible with Exoplayer, they usually standard these things and saves me a lot of time. At first I thought I was building my MPD DVR manifests incorrectly, but when I tested Exoplayer with YouTube's own manifest - untouched - I discovered the exact same problems were present, ruling out the possibility of errors committed on my end during manifest structuring.

I cannot provide the method of doing it via YouTube since it could encourage other users to misuse the YouTube service other than for debugging purposes, so if you need this I can exchange this information privately.

Is this behavior known/expected? Is there a way to fix it on my end or is it a bug with the player? Also, am I wrong in assuming some devices can be incompatible with HLS? I ask this because if any MPD compatible device is also compatible with HLS then finding a fix for this problem becomes low priority.

[AquilesCanta]

Would you kindly provide a stream that reproduces the described issue to dev.[email protected]?

Regarding device compatibility in Exoplayer: it only applies to codecs. e.g: A device might not have decoders for VP9 or support a particular H265 profile, but container formats or streaming protocols are not affected. You can find here useful information about codec compatibility.

In other words, if both your DASH and HLS streams use the same compression formats, all streams _should_ be supported by the same set of devices. Right now, it is advisable to strive for the _technically better_ streaming format. In this context, DASH.

[Yonezpt]

I understand, so having HLS as fallback and DASH as primary will be the ideal scenario if they contain streams with different codecs, in that case solving this takes priority (for me, not for the ExoPlayer team).

I cannot send any stream, they are generated locally (LAN based) and I do not have the authorization for sharing them, but I can do what I mentioned near the end, I can explain (in the email) how to reproduce this problem via YouTube just for this purpose since it will be exactly the same thing for the reasons I explained.

[AquilesCanta]

Yes, the streams don't need to be yours. I just need to reproduce the issue myself.

[Yonezpt]

@AquilesCanta I have sent an email detailing the process for replicating this problem, the subject reads ExoPlayer issue #2422

[Yonezpt]

@AquilesCanta In the email I incorrectly said at the end that the dashmpd manifest url the ExoPlayer behaves correctly , it should be the other way around, the dashmpd is the one that does not work correctly, the hls is the one that does work correctly.

[AquilesCanta]

Thank you for the e-mail. I will have a look as soon as I have some free time. I'll let you know when I have anything interesting to share.

[Yonezpt]

@AquilesCanta Just want to add that I have recently tested this in ExoPlayer r2.2.0 and the same problem persists.

[AquilesCanta]

Just as a heads up: I have been giving it a look, but the streams I've generated so far don't play in other players (vlc, for instance. Oddly, with similar behaviors) and don't pass validation. I'll try to figure out the cause, though.

[Yonezpt]

But the HLS streams do play correctly, right? It's just the MPD streams that are giving problems.

[AquilesCanta]

Honestly, I haven't checked the HLS streams. Will do later.

[Yonezpt]

I don't have urgency on this for now, but are there any news about this?

[AquilesCanta]

The HLS version seems fine, from what I have played around. @ojw28 will probably be able to tell you more about the DASH one. But its certainly broken.

[ojw28]

The YouTube DASH manifests that you're attempting to play are invalid, and are not what YouTube serve to ExoPlayer themselves.

The first version of DASH live that YouTube developed for web (i.e. streams + support in their html5 player) was not spec compliant. In particular, there were some issues with the way the manifests were being generated and updated. This is understandable, since the spec is quite hard to follow and probably wasn't even finalized at the time. YouTube later fixed their manifests, but to avoid breaking existing players that were consuming the invalid manifests generated by their first attempt, they decided to serve both the invalid and fixed versions side by side. I suspect the html5 player has not been updated to move onto the fixed versions, which is why the approach you're using to obtain the streams gets you the invalid ones. The YouTube Android app will be requesting the fixed versions for use with ExoPlayer.

So in conclusion, if you're reverse engineering an API don't expect what you find to be nice and shiny and spec compliant ;). We're not able to provide any details with how you might find the compliant streams, for obvious reasons.

[Yonezpt]

The first version of DASH live that YouTube developed for web (i.e. streams + support in their html5 player) was not spec compliant

So that's why no matter how careful I was when replicating their spec it would never work on ExoPlayer. I assumed in error that they were compliant, I think it was a normal mistake to make when considering which platform we are talking about.
I will then research the correct manifest spec for this very specific case and follow it through from now on. Annoying that the web version is still using only the previous version because, strangely enough, it is way easier for me to reverse a working manifest example than creating one from scratch, but I completely understand why things are the way they are.

Thanks for the helpful detailed explanation, not understanding why it wasn't working correctly was driving me nuts.

[ojw28]

Yeah. More fundamentally, you should consider whether you really want/need to be generating manifests that look anything like the one you were looking at, which appears to be ~2MB. That's going to be fairly horrendous if you're having to re-load it every few seconds. It'll probably gzip very well for transfer over the wire, but that's still a lot of data the player will need to repeatedly process.

It's possible to generate far more concise manifests for VOD, Live and Live-Event use cases if you use SegmentTemplate rather than explicitly listing all of the segments in the manifest.