Re: Defining "timeline offset" for various formats

On Tue, May 20, 2014 at 1:57 PM, Brendan Long <B.Long@cablelabs.com> wrote:

>  For normal MPEG-TS, there isn't a descriptor that maps to this, so I'd
> say leave it at NaN.
>
> Interesting. I didn't realize that MPEG-TS didn't map timestamps in the
transport to any sort of wall clock time.


> The DVB version of MPEG-TS has the "Time and Date Table" and "Time Offset
> Table", but those aren't used by North American users and we'd probably
> want input from people who actually use it before adding that to a spec.
>

Sounds reasonable to me.

Aaron


>
>  ------------------------------
> *From:* Aaron Colwell [acolwell@google.com]
> *Sent:* Monday, May 19, 2014 12:37 PM
> *To:* public-inbandtracks@w3.org
> *Subject:* Defining "timeline offset" for various formats
>
>   Hi,
>
>  I was recently trying to implement HTMLMediaElement.getStartDate()<http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#dom-media-getstartdate>in Blink & Chromium and found myself trying to figure out what the "timeline
> offset<http://www.w3.org/html/wg/drafts/html/master/embedded-content.html#timeline-offset>"
> should be for different formats. For now I only have WebM implemented, but
> I thought it might be useful if we all agreed on what this value should be
> for Ogg and ISOBMFF as well. It seems like this could become part of
> the HTMLSourcingInbandTracks spec.
>
>  For WebM/Matroska at least the DateUTC<http://www.matroska.org/technical/specs/index.html#DateUTC>element maps to the "timeline offset" concept, but for now I only expose it
> if Duration is not set and the Segment has an unknown size. This is because
> "timeline offset" seems to only be useful in a live context and no duration
> & unknown segment size is the primary way to detect a live stream in
> WebM/Matroska. I'm assuming that similar hoops have to be jumped through
> for other formats and I think it would be nice to write those down so
> everyone implements them the same way.
>
>
>  Aaron
>