Implement duration change for MPD Validity Expiration events #2304

robertbryer · 2017-11-22T18:46:19Z

Implements the event duration portion of the spec for emsg MPD Validity Expiration events, so the event duration field can be used to set the remaining duration of a live stream. It also allows a stream to be ended at the event time when presentation_time_delta and event_duration are 0.

It does not implement the checking of the message_data field or the presentation_time_delta field to verify that the reloaded manifest has the correct validity

Use the manifestUpdater refresh function

epiclabsDASH · 2017-11-24T12:58:01Z

src/streaming/controllers/EventController.js

@@ -181,7 +205,9 @@ function EventController() {
                            activeEvents[eventId] = curr;
                        }
                        if (curr.eventStream.schemeIdUri == MPD_RELOAD_SCHEME && curr.eventStream.value == MPD_RELOAD_VALUE) {
-                            refreshManifest();
+                            if (event.duration !== 0 || event.presentationTimeDelta !== 0) { //If both are set to zero, it indicates the media is over at this point. Don't reload the manifest.


@robertbryer, I think this should be:
if (curr.duration !== 0 || curr.presentationTimeDelta !== 0)

Yeah, dumb mistake, thanks.

epiclabsDASH · 2017-11-24T13:04:05Z

It also causes a weird effect in ad-insertion/inband example. First period plays just for 5-6 seconds instead of 20 and because duration is updated during playback, seeking bar reacts differently.

robertbryer · 2017-11-24T16:29:39Z

For the ad-insertion inband example, I find this as the event

"{"duration":1,
"presentationTime":5,
"id":1,
 ......,
"presentationTimeDelta":1}"

So the first period should have a duration of 6; at least until the new manifest comes in and says otherwise; so I think there's something about the manifest refresh that's not working here - I'll take a look and see what's going on.

epiclabsDASH · 2017-11-27T11:46:24Z

Ok, looking at the emsg box, event_duration is set to 1. That seems to be wrong and the reason behind not playing the full asset after your changes being applied.

I would say event_duration parameter of emsg box should be 20. @dsilhavy, as the one that added the inband example, what do you think?

epiclabsDASH · 2017-11-29T11:38:49Z

Let's wait for @dsilhavy comments before merging. I think the PR is ready but prefer don't break ad insertion examples, even although seems to be a problem with the content not with this PR.

robertbryer · 2017-11-29T11:58:34Z

Yeah, that seems like a good idea. I think because the event duration is non-zero, this would be allowed, and we should probably not end the stream until the manifest refresh has completed. But, this might be a bit of an edge case to implement, and we might want to just accept it as a limitation until we implement the behaviour of the other fields of the event message.

…hrough an manifest_validity_changed event

epiclabsDASH · 2017-12-07T21:26:21Z

@dsilhavy, do you have any feedback to share?
Thanks!

dsilhavy · 2017-12-11T13:40:39Z

Sorry I just saw this issue, I will try to take a look at it this week. Please feel free to merge your changes if this is a content problem. We will change the content accordingly if it has been created incorrectly.

epiclabsDASH · 2017-12-14T22:59:26Z

Ok. I will wait for your feedback before merging. I prefer don't breaking any of the current samples.

dsilhavy · 2017-12-15T09:08:12Z

Hi guys,
thanks for sharing this issue. I agree that the event duration in the content is wrong. So the spec states:
"The event duration expresses the remaining duration of Media Presentation from the event time. If the event duration is 0, Media Presentation ends at the event time. If 0xFFFF, the media presentation duration is unknown."

In our case this means that the stream stops after 6 seconds.
From my understanding the event duration should be set either set to 15 seconds because we start the new period then, or to 35 seconds, because that is the total media duration. To be save we might set the duration to 0xFFFF.
What are your opinions on that?

Best
Daniel

davemevans · 2017-12-15T09:19:17Z

IIRC, this content also needed the message_data updated to include the relevant MPD@publishTime? (It's been a while since I looked and that may have happened already).

epiclabsDASH · 2017-12-15T09:36:11Z

My understanding is it should be 15 seconds.

In the practice, it would be easier to use 0xFFFF and "inherit" the duration from what is already declared in the manifest. However, I am not sure if "unknown duration" should be interpreted as "use what is declared in the manifest" or "unknown, so continue requesting segments without an end". I guess it is the second option. Probably @bbcrddave or @sandersaares have a more accurate view about this.

sandersaares · 2017-12-15T10:18:27Z

I can try to comment but is there some place I can download this test content you reference as a zip or something like that? Or can you point out the segment containing the message in question?

davemevans · 2017-12-15T10:20:51Z

Since the sample in question is really a contrived example of a live stream with ad insertion, and the DASH event is used to trigger merely an MPD update rather than end of stream, I think the correct value for the event duration in the emsg in the first part of the content (ie before the ad) is either 0xFFFF or 35 seconds.

I believe the presentation_time_delta also needs to be modified to be 15 seconds because that is the remaining duration described by the current MPD. Remember that this particular DASH event schema/value describes MPD validity - and the MPD remains valid until the end of the content in question.

epiclabsDASH · 2017-12-15T10:28:06Z

@sandersaares, content is the one accessed from this sample: http://reference.dashif.org/dash.js/v2.6.4/samples/ad-insertion/inband.html

Url of the mpd has a query string parameter, which is different per user, and that is used to return one mpd content or other depending if it was the first mpd request or the second one.

sandersaares · 2017-12-15T10:48:01Z

Okay, I see it.

I agree with @bbcrddave on all 3 points:

that an 0xFFFF duration is the proper value because this event is not indicating an end to the presentation.
that message_data must contain the PublishTime of the manifest to which the message applies to, instead of the arbitrary (and incomplete) XML blob currently in there.
that presentation_time_delta should be 15 (placing the event at 5+15=20 seconds, end of the first MPD)

dsilhavy · 2017-12-15T10:56:00Z

Thanks,
I agree on the duration and the message_data. One question regarding the presentation_time_delta. By setting this to 15, the event is fired at 20 seconds right? Why cant we do that earlier to give the player enough time to prebuffer segments of the new period? Also if we fire this event exactly at 20 seconds we might run into a scenario in which the player already stopped the playback because the first period has finished?

davemevans · 2017-12-15T11:05:01Z

The problem comes from the fact that MPD validity expiration events are a bit of a hack on the generic event messaging system - the fields don't have the same meaning.

However, like generic event, having the events appear in the stream early does give players the opportunity to acquire the new manifest and, assuming the manifest has a publish time describing the future and the content is available, begin grabbing the content, preparing for the switch etc, or at least be aware that the content is being extended and be prepared for that.

Unfortunately, the current implementation is not capable of achieving this because it does not consider the special case of MPD validity expiration.

dsilhavy · 2017-12-15T11:55:57Z

Ok thanks Dave. I just looked at the example from the DASH spec again, and they also set the presentation_time_delta in a way that the ept of the segment and the value for the ptd match the start time of the new period.
@epiclabsDASH We will change our content as discussed. Unfortunately this might not be possible this year. Not sure if you want to hold back this pull request until the content is changed or if you merge it now.

epiclabsDASH · 2017-12-15T12:02:04Z

Yep, I think makes more sense waiting. There is no issue reported that is blocked because this PR and, although there is an issue in the content, prefer to don't break the sample.

@robertbryer, out of my knowledge, is this PR blocking anything in your side?

robertbryer · 2017-12-15T12:06:20Z

Been using this already in production for a while - nothing I need merged in urgently

epiclabsDASH · 2018-01-15T11:40:36Z

@dsilhavy, any news regarding when the content could be changed?

Many thanks in advance

dsilhavy · 2018-01-16T13:15:46Z

@epiclabsDASH We are on it, should be ready within the next week.

dsilhavy · 2018-01-26T08:32:48Z

@epiclabsDASH We have created new content but I have not had the chance to test it against the changes. I will let you know as soon as I have results

epiclabsDASH · 2018-01-26T08:49:51Z

Great, many thanks

Amend the media duration upon receipt of manifest validity message

f58fbb7

Use the manifestUpdater refresh function

epiclabsDASH added this to the v2.6.4 milestone Nov 22, 2017

epiclabsDASH added the Dash Specification Compliancy label Nov 22, 2017

epiclabsDASH reviewed Nov 24, 2017

View reviewed changes

Fix wrong reference to event

fd3d7de

epiclabsDASH modified the milestones: v2.6.4, v2.6.5 Nov 29, 2017

Make sure the media duration is set too when we change the duration t…

5a3f25e

…hrough an manifest_validity_changed event

epiclabsDASH modified the milestones: v2.6.5, v2.6.6 Dec 15, 2017

epiclabsDASH merged commit e0c1348 into Dash-Industry-Forum:development Jan 22, 2018

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Implement duration change for MPD Validity Expiration events #2304

Implement duration change for MPD Validity Expiration events #2304

robertbryer commented Nov 22, 2017

epiclabsDASH Nov 24, 2017

robertbryer Nov 24, 2017

epiclabsDASH commented Nov 24, 2017

robertbryer commented Nov 24, 2017

epiclabsDASH commented Nov 27, 2017

epiclabsDASH commented Nov 29, 2017

robertbryer commented Nov 29, 2017

epiclabsDASH commented Dec 7, 2017

dsilhavy commented Dec 11, 2017

epiclabsDASH commented Dec 14, 2017

dsilhavy commented Dec 15, 2017

davemevans commented Dec 15, 2017

epiclabsDASH commented Dec 15, 2017

sandersaares commented Dec 15, 2017

davemevans commented Dec 15, 2017 •

edited

Loading

epiclabsDASH commented Dec 15, 2017

sandersaares commented Dec 15, 2017

dsilhavy commented Dec 15, 2017

davemevans commented Dec 15, 2017

dsilhavy commented Dec 15, 2017

epiclabsDASH commented Dec 15, 2017

robertbryer commented Dec 15, 2017

epiclabsDASH commented Jan 15, 2018

dsilhavy commented Jan 16, 2018

dsilhavy commented Jan 26, 2018

epiclabsDASH commented Jan 26, 2018

Implement duration change for MPD Validity Expiration events #2304

Implement duration change for MPD Validity Expiration events #2304

Conversation

robertbryer commented Nov 22, 2017

epiclabsDASH Nov 24, 2017

Choose a reason for hiding this comment

robertbryer Nov 24, 2017

Choose a reason for hiding this comment

epiclabsDASH commented Nov 24, 2017

robertbryer commented Nov 24, 2017

epiclabsDASH commented Nov 27, 2017

epiclabsDASH commented Nov 29, 2017

robertbryer commented Nov 29, 2017

epiclabsDASH commented Dec 7, 2017

dsilhavy commented Dec 11, 2017

epiclabsDASH commented Dec 14, 2017

dsilhavy commented Dec 15, 2017

davemevans commented Dec 15, 2017

epiclabsDASH commented Dec 15, 2017

sandersaares commented Dec 15, 2017

davemevans commented Dec 15, 2017 • edited Loading

epiclabsDASH commented Dec 15, 2017

sandersaares commented Dec 15, 2017

dsilhavy commented Dec 15, 2017

davemevans commented Dec 15, 2017

dsilhavy commented Dec 15, 2017

epiclabsDASH commented Dec 15, 2017

robertbryer commented Dec 15, 2017

epiclabsDASH commented Jan 15, 2018

dsilhavy commented Jan 16, 2018

dsilhavy commented Jan 26, 2018

epiclabsDASH commented Jan 26, 2018

davemevans commented Dec 15, 2017 •

edited

Loading