Closed noamtamim closed 6 years ago
The media does not seem to be spec compliant. In particular, I think that:
Fixing these issues should allow the content to play successfully across all players.
thanks @ojw28 we'll check it!
Hi @ojw28 We looked at the standard: http://dashif.org/w/2015/04/DASH-IF-IOP-v3.0.pdf
It says: “In order to make the MPD joining friendly and to remove data that is available in the past, any segments that have fallen out of the time shift buffer may no longer be announced in the MPD. In this case, the Period start may be moved by changing one or both, MPD@availabilityStartTime and Period@start. However, this requires that the @startNumber, @presentationTimeOffset and S values need to be updated such that the Segment Information according to section 4.3.2.2.6 is not modified over an MPD update.”
Please check this again.
Thanks for the reference. I think we might need to discuss this with the DASH-IF authors. I can't think of a good reason for needing to change Period@start, and if there isn't a good reason then I don't see why it should be allowed as an optional thing. It would just be one more thing for clients to have to deal with for no benefit. It's also quite confusing. Note that it's not required to adjust Period@start to remove data or make the MPD joining friendly.
In the meantime, I would still advise changing the way your manifests update to be as I described above. It would be inline with how manifest updates occur in most of the other live streams I've seen, I think, and I suspect it will make your streams compatible with a wider range of clients.
In this case, the Period start may be moved by changing one or both, MPD@availabilityStartTime and Period@start
It appears to me that the first part of the statement directly contradicts DASH 8.4.2 which says:
When the MPD is updated, the value of MPD@availabilityStartTime shall be the same in the original and the updated MPD
While AST does not appear to be relevant in case of the content in question here, it does serve as additional evidence that this part of the guidelines might deserve a review.
DASH-IF question filed here: https://github.com/Dash-Industry-Forum/DASH-IF-IOP/issues/160
note that Period@id is optional in the DASH spec, and so cannot be relied upon to identify that the period is the same
Based on my reading, this attribute is only optional for static manifests, so it could actually be used to determine period identity in case of dynamic manifests.
Here's the relevant snippet from DASH spec:
If the MPD@type is "dynamic", then this attribute shall be present and shall not change in case the MPD is updated.
Ah, thanks, that's good to know!
Marking as wontfix
for now on the assumption that the DASH-IF guidelines will be amended.
DASH IF guidelines v4.2 has been amended to prevent the type of manifest update described here. In 4.4.3.3:
MPD@availabilityStartTime and Period@start shall not be changed over MPD updates.
Closing this. Thanks!
Issue description
A DASH live stream fails to play in ExoPlayer due to what seems like timing issues. The log is shown below.
The first frame is shown, but playback does not continue.
For reference, it also doesn't work in ShakaPlayer, but it does work in bitmovin and dash.js web players.
Reproduction steps
Add the URL to media.exolist.json in ExoPlayer's demo app. No DRM setup is required.
Link to test content
Will be sent in email.
Version of ExoPlayer being used
r2.5.4 (with gradle changes to support Android Studio 3.0.0).
Device(s) and version(s) of Android being used
Nexus 5X, Android 8.0.0.
A full bug report captured from the device
I don't think the full ADB bugreport is relevant, but here's the logcat: