W3C home > Mailing lists > Public > public-html-media@w3.org > July 2012

Re: [MSE] Establishing the Presentation Start Timestamp

From: Aaron Colwell <acolwell@google.com>
Date: Wed, 18 Jul 2012 10:00:57 -0700
Message-ID: <CAA0c1bCiaTPCeWqM=q8rNbbES6eo7L8KSctj98jLwS9-pPH27w@mail.gmail.com>
To: Kevin Streeter <kstreete@adobe.com>
Cc: "<public-html-media@w3.org>" <public-html-media@w3.org>
 Kevin,

If I understand you correctly, you are proposing that a "preroll" state be
added that prevents a transition to HAVE_METADATA, but allows media
segments to be appended. Once the web application determines that it has
appended enough segments for the start time to be determined, it would call
a method to transition out of the "preroll" state and then the MediaSource
could determine the start time and allow the HTMLMediaElement.readyState to
transition to HAVE_METADATA. Is this correct?

I believe it should be relatively easy to modify the MediaSource object to
do this. If people are ok with this idea I can draft up some IDL and text
to give people a feel for what this could look like.

Aaron




On Thu, Jul 12, 2012 at 11:06 AM, Kevin Streeter <kstreete@adobe.com> wrote:

> Aaron,****
>
> ** **
>
>   This is a tricky one, we encountered a similar situation dealing with
> unmixed content in Flash.  The problem is really that at startup time,
> before you have anything in the playback buffer, you have an ambiguous
> situation when you push the first segment (for the first track).  Will
> there be another track?  More segments for that single track?  There is no
> way for the UA to know unless the application tells it.****
>
> ** **
>
>   One possible way to deal with this is to have a pre-roll state where you
> can push segments without playback starting.  You would resolve the time
> issues only after playback actually started.  This would allow the
> application to initialize all tracks.****
>
> ** **
>
>   Another way would be to assume that all **initialized** tracks have at
> least some data.  So if you create a track programmatically, or push in an
> initialization segment, the UA will wait to start playback until at least
> some content for that track arrives.****
>
> ** **
>
>   The first mechanism is more explicit (which IMO is generally better),
> but would also probably mean changes in the playback state machine.****
>
> ** **
>
> -K****
>
> ** **
>
> ** **
>
> *From:* Aaron Colwell [mailto:acolwell@google.com]
> *Sent:* Thursday, July 12, 2012 10:28 AM
> *To:* <public-html-media@w3.org>
> *Subject:* [MSE] Establishing the Presentation Start Timestamp****
>
> ** **
>
> Hi,****
>
> ** **
>
> While doing some testing with demultiplexed content that uses separate
> SourceBuffers for the audio & video streams, we ran into some issues around
> establishing the presentation start timestamp that I don't think are
> covered well in the existing spec text.****
>
> ** **
>
> Section 6.1.3<http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#webm-start-timestamp> for
> WebM states :****
>
> The timestamp in the first block of the first media segment appended
> establishes the starting timestamp for the presentation timeline. All media
> segments appended after this first segment are expected to have timestamps
> greater than or equal to this timestamp.****
>
> ** **
>
> Section 6.2.3<http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#iso-start-timestamp> has
> similar text for ISO.****
>
> ** **
>
> This language is pretty straightforward if we are only dealing with a
> single SourceBuffer. When more than one SourceBuffer is involved things get
> a little more tricky when the first media segment for each SourceBuffer
> don't start with the same timestamp.****
>
> ** **
>
> Say I have an audio stream that starts at timestamp 0, and the video
> stream starts at 30 milliseconds. If I follow the existing language very
> strictly, then whichever stream appends a media segment first establishes
> the presentation start time. This means that I can either have a start time
> of 0 or 30 miliseconds. This raises several questions that I think need to
> be discussed.****
>
> ** **
>
> 1. Should we expect the web application to be aware of this situation and
> always ensure that the earliest segment gets appended first?****
>
> ** **
>
> 2. Should we wait until the first media segments are appended to all
> SourceBuffers in MediaSource.activeSourceBuffers before determining the
> start time and then simply take the earliest timestamp?****
>
> ** **
>
> 3. If a media segment is appended that starts before the established
> presentation start time and continues past it, how should we handle that?
>  ****
>
>   - Should this trigger an error?****
>
>   - Should it be treated like an end overlap<http://dvcs.w3.org/hg/html-media/raw-file/tip/media-source/media-source.html#source-buffer-overlap-end> where
> the presentation start time acts like the end of a range already in the
> buffer? This would essentially keep everything after the first random
> access point that has a timestamp >= the presentation start timestamp.****
>
> ** **
>
> 4. How close do the starting timestamps on the first media segments from
> each SourceBuffer need to be? ****
>
>   - In this example I've shown them to be only 30 milliseconds apart, but
> would 0.5 seconds be acceptable? Would 2 seconds? ****
>
>   - How much time do we allow here before we consider there to be missing
> data and playback can't start? ****
>
>   - What happens if the gap is too large?****
>
> ** **
>
> Any insights or suggestions would be greatly appreciated.****
>
> ** **
>
> Aaron****
>
> ** **
>
Received on Wednesday, 18 July 2012 17:01:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 15:48:24 UTC