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.
  *   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.

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