[Bug 25427] New: Video element playback position and live content

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

            Bug ID: 25427
           Summary: Video element playback position and live content
           Product: HTML WG
           Version: unspecified
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P3
         Component: HTML5 spec
          Assignee: dave.null@w3.org
          Reporter: hbbtvjon@gmail.com
        QA Contact: public-html-bugzilla@w3.org
                CC: mike@w3.org, public-html-admin@w3.org,
                    public-html-wg-issue-tracking@w3.org

This issue is raised on behalf of HbbTV - see http://www.hbbtv.org, an
organisation specifying the use of web technologies in television receivers.
HbbTV is in the process of adding the HTML5 video element to its specification.
The current HbbTV specification uses the <object> element for presenting video
in an HTML page.

We are looking at the use of the HTML5 video element to playback live content
delivered via IP. This could be adaptive using MPEG DASH (in our case a native
DASH player as part of the UA, not a JavaScript DASH player as part of the web
page). Alternatively this could be non-adaptive using HTTP chunked transfer
coding as defined by section 3.6.1 of RFC 2616.

It seems to us that the specification for the video element only partly
considers live content. In particular, the description of the seekable property
considers it but other places do not. For example, the following note from the
description of seekable shows that live content has been considered to some
extent:

"The range might be continuously changing, e.g. if the user agent is buffering
a sliding window on an infinite stream. This is the behavior seen with DVRs
viewing live TV, for instance."

With live content, typically the server in the network will only buffer a
certain period behind the live edge. Using the terminology of this note, there
would essentially be two sliding windows, one in the UA of tens of seconds and
one in the network which might be (say) 10 minutes behind the live edge. In the
case of MPEG DASH, the UA may know the size of the buffer in the network from
the optional timeShiftBufferDepth attribute in the DASH MPD.

Typically, we would expect users to want to join live content at the live edge
and not at the earliest time available in the network. In practice this would
be achieved by the UA (media player) starting to read a small distance behind
the live edge in order to fill the necessary buffers and start playing as
quickly as possible.

Points concerning live content that we believe are ambiguous or not fully
considered are the following:

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?

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.

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

If the live edge would be considered the end of media in then we believe that
needs to be clearly stated. In general, we might expect the latest seekable
position to be a few seconds before the current ‘end of the media resource’ for
a live stream since the UA will typically require some amount of buffering.  Do
you agree?

Perhaps the concept of a latest seekable position could be introduced
explicitly to mirror the current definition of ‘earliest possible position’. It
would correspond to the end time of the last range in the seekable attribute’s
TimeRanges object, if any, or the current playback position otherwise.  This
could be further clarified as typically being the end of the media resource for
on-demand but the live edge for live content, taking into account any buffering
requirements that the UA may have. If this was introduced then the following
text;
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.

could be re-written as;

If the new playback position is later than the latest seekable position, then
let it be the end of the latest seekable positioninstead.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

Received on Wednesday, 23 April 2014 12:11:03 UTC