[Bug 25427] Video element playback position and live content

https://www.w3.org/Bugs/Public/show_bug.cgi?id=25427

Philip Jägenstedt <philipj@opera.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |philipj@opera.com

--- Comment #1 from Philip Jägenstedt <philipj@opera.com> ---
(In reply to Jon Piesing (HbbTV) from comment #0)

> 1. The HTML5 specification can be interpreted in two ways regarding where
> playback of live content should begin:
> 
> In one interpretation, the specification reads as requiring the various
> playback positions to always be the earliest possible position. This is not
> what users will expect for live content, although we recognise this can be
> resolved by the application seeking to the live edge if required. 
> 
> In another interpretation, it could be considered that the statement
> “Establish the media timeline for the purposes of the current playback
> position, the earliest possible position, and the initial playback position,
> based on the media data” allows a UA to begin playback at the live edge if
> “media data” indicates that this is most appropriate.  
> 
> Which interpretation is expected (or are both of these incorrect)?  Can the
> specification be clarified specifically for the case of live content?

I think this covers it: "If either the media resource or the address of the
current media resource indicate a particular start time, then set the initial
playback position to that time"

In other words, playback should begin wherever the format defines that it
should begin.

> 2. For live content, the earliest and latest possible positions are
> continually moving. It is unclear how the following statement is to be
> interpreted in these circumstances;
> 
> “When the earliest possible position changes, then: if the current playback
> position is before the earliest possible position, the user agent must seek
> to the earliest possible position; otherwise, if the user agent has not
> fired a timeupdate event at the element in the past 15 to 250ms and is not
> still running event handlers for such an event, then the user agent must
> queue a task to fire a simple event named timeupdate at the element.”
> 
> If the various playPosition properties are set to the earliest possible
> position before playback has started then this language might require the UA
> to continually be seeking as the earliest possible position moves ahead of
> what was the current play position.
> 
> One example of when this could occur is if the HTML page calls the load
> method (but not run) on a piece of live content. What values are assigned to
> the various playback positions under these conditions?
> - None?
> - A static snapshot at the time the method was called?
> - Dynamic updating values? 
> 
> If the UA is continually seeking as described above then it would seem to be
> the last of these however we believe that should be clearly stated in the
> specification.

Per the bit of the spec that you quoted, the UA would continuously be trying to
seek to catch up. Depending on how often the earliest possible position
changes, it could even end up in a situation where no seek is finished before
the next starts, which would cause lots of seeking events to be fired, but no
timeupdate or seeked events. That seems pretty weird, but is there a better
alternative?

> 3. It is unclear whether there is a mechanism for the HTML page to seek to
> the live edge. For seeks before the earliest possible position, it says “If
> the new playback position is less than the earliest possible position, let
> it be that position instead.” However for seeks to the live edge, the
> equivalent language is less clear, “If the new playback position is later
> than the end of the media resource, then let it be the end of the media
> resource instead.”

The position will be clamped to the seekable ranges in a later step: "If the
(possibly now changed) new playback position is not in one of the ranges given
in the seekable attribute, then let it be the position in one of the ranges
given in the seekable attribute that is the nearest to the new playback
position."

Given that, is there still a problem?

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Thursday, 24 April 2014 12:15:15 UTC