RE: MPEG-2 TS metadata cue guidelines

From: Bob Lund [mailto:B.Lund@CableLabs.com]
Sent: Monday, March 24, 2014 9:45 AM
To: Clift, Graham; Brendan Long; public-inbandtracks@w3.org
Subject: Re: MPEG-2 TS metadata cue guidelines



From: <Clift>, Graham <Graham.Clift@am.sony.com<mailto:Graham.Clift@am.sony.com>>
Date: Monday, March 24, 2014 at 10:35 AM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>, Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: RE: MPEG-2 TS metadata cue guidelines



From: Bob Lund [mailto:B.Lund@CableLabs.com]
Sent: Monday, March 24, 2014 9:27 AM
To: Clift, Graham; Brendan Long; public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>
Subject: Re: MPEG-2 TS metadata cue guidelines



From: <Clift>, Graham <Graham.Clift@am.sony.com<mailto:Graham.Clift@am.sony.com>>
Date: Monday, March 24, 2014 at 10:11 AM
To: Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>>, Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: RE: MPEG-2 TS metadata cue guidelines

I have one suggestion. Instead of playing around with arbitrary endtimes  why not set the starttime to the currentTime of playback when the cue is created (making it immediately active when created) and set the endtime to the media resource time

What is 'media resource time'?
[<Graham>] Well that is terminology you use in the mapping spec. It is the time of the metadata with respect to the MPEG-2 TS timeline (eg PTS) clock. The startTime in contrast would be the HTML5 Media Element currentTime when the cue is created in UA, which is equivalent to
                startTime = endTime - (UA decoder buffering time) + UA cue generation processing time

Why not endTime = startTime + 250msec? Seems easier.
[<Graham>]
I explained the reasoning but I will reiterate. 250msec is just some arbitrary number. Rather than an arbitrary number why not just have the startTime before the mediaresource time to allow the application to prepare for the cue onexit event?


(making it inactive after this time). An application can use the onexit event to accurately time the DataCue event and onenter to prepare for this event like fetching a resource for an ad insertion. Of course we will want to specify a minimum endtime-starttime value (which could be zero)

Regards

Graham  Clift

From: Brendan Long [mailto:B.Long@cablelabs.com]
Sent: Monday, March 24, 2014 8:59 AM
To: Bob Lund; public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>
Subject: Re: MPEG-2 TS metadata cue guidelines

Oh never mind. What I suggested doesn't make sense with other metadata cues.

From: Bob Lund <B.Lund@CableLabs.com<mailto:B.Lund@CableLabs.com>>
Date: Monday, March 24, 2014 at 9:38 AM
To: Brendan Long <b.long@cablelabs.com<mailto:b.long@cablelabs.com>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: Re: MPEG-2 TS metadata cue guidelines



From: Brendan Long <B.Long@cablelabs.com<mailto:B.Long@cablelabs.com>>
Date: Monday, March 24, 2014 at 9:10 AM
To: Bob Lund <b.lund@cablelabs.com<mailto:b.lund@cablelabs.com>>, "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: Re: MPEG-2 TS metadata cue guidelines

I'm not sure if it's any better, but another option would be to set it to very large number (infinity if we changed the spec to allow that) and then fix it once we know what the end time is. The advantages would be:
*         track.activeCues[0] should always be the current PMT.
There is no proposal in the submitted HTML5 bugs for PMT track cues, I'm only talking about metadata cues in general. What is the advantage of track.activeCues[0] being the last received cue?
*         The historical data in track.cues will tell you the actual start and end times for previous PMTs, but I'm not sure if that's useful practically.
The disadvantage is that you'd need to mess with cues after creating them.

If there is no advantage for having the last received cue in track.activeCues[0] then my proposal eliminates the UA having to reset times.


From: Bob Lund <B.Lund@CableLabs.com<mailto:B.Lund@CableLabs.com>>
Date: Monday, March 24, 2014 at 8:41 AM
To: "public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>" <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Subject: MPEG-2 TS metadata cue guidelines
Resent-From: <public-inbandtracks@w3.org<mailto:public-inbandtracks@w3.org>>
Resent-Date: Monday, March 24, 2014 at 8:42 AM

CG,

Bug 25005<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25005> is about how to set endTime for MPEG-2 TS metadata text track cues. The issue is that there is no explicit endTime for these cues. I proposed<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25005#c4> setting the endTime to the startTime. The HTML5 editor doesn't think this is a good idea<https://www.w3.org/Bugs/Public/show_bug.cgi?id=25005#c5>.

The reality is that it doesn't really matter since the application understands, and acts on, the cue. So, an alternate proposal is to set the endTime = startTime + minDelta. Where minDelta = the minimum time so that the cue entry and exit handlers will operate properly vis-a-vis the  "time marches on" algorithm. Comments?

Bob