RE: MediaStream and time-shifted TV playback

Chris,

Great analysis. Let's talk about it on Tuesday.

Thank you and have a good weekend
Bin

-----Original Message-----
From: Chris Needham [mailto:chris.needham@bbc.co.uk] 
Sent: Friday, June 05, 2015 4:32 AM
To: TV Control API Community Group
Subject: MediaStream and time-shifted TV playback

Hi everyone,

Following from my previous email [1], I've done some further investigation into the use of MediaStream as video source for TV Control API, and identified some specific details in the MediaStream specification [2] that would need to be addressed to enable pause/resume for live TV and timeshifted playback, and in particular allowing buffering of the media by the user agent.

The Media Capture and Streams spec is now being finalised [3], so we're unlikely to get any changes made in the short term, but I post this information here for feedback and discussion of next steps.

On to the detail...

# 4.1 Introduction

> All tracks in a MediaStream are intended to be synchronized when rendered..
> This is not a hard requirement, since it might not be possible to synchronize
> tracks from sources that have different clocks. Different MediaStream objects
> do not need to be synchronized.

For a TV (or radio) tuner source, the tracks within the MediaStream must be synchronized.

# 4.3.4 Track Source Types

Add a "tuner" (or similar) value to SourceTypeEnum.

# 6. MediaStreams as Media Elements

> A MediaStream is not preloadable or seekable and represents a simple,
> potentially infinite, linear media timeline.

We want to allow the stream to be seekable.

> The timeline starts at 0 and increments linearly in real time as long as the
> MediaStream is playing. The timeline does not increment when the MediaStream
> is paused.

What is time 0 in the context of a MediaStream obtained from a tuner? Is there a timestamp we can use, obtained from the broadcast stream? How would we specify this for the various broadcast protocols (DVB, ATSC, ISDB, etc)?

I know that HbbTV 2.0 includes a synchronisation protocol for companion screens, so there's work we can look at there.

> The User Agent must not buffer data from a MediaStream. When playing, the User
> Agent must always play the current data from the stream.

Again, we want to allow the stream to be seekable.

# 6.3 Media Element Attributes when Playing a MediaStream

This section contains a table of MediaElement attributes and describes their behaviour when the element is used with a MediaStream.

> readyState: A MediaStream may be created before there is any data
> available, for example when a stream is received from a remote peer.

When the source is a tuner there is no remote peer, so maybe this constraint does not apply in our case.

> currentTime: The value is the current stream position, in seconds. On any
> attempt to set this attribute, the User Agent must throw an InvalidStateError
> exception.

It should be possible to set the currentTime to any time within the seekable time range.

> seeking: A MediaStream is not seekable. Therefore, this attribute must
> always have the value false.

> defaultPlaybackRate (also playbackRate). A MediaStream is not seekable.
> Therefore, this attribute must always have the value 1.0 and any attempt
> to alter it must fail.

> played: A MediaStream's timeline always consists of a single range,
> starting at 0 and extending up to the currentTime.

> seekable: A MediaStream is not seekable.

As we want to allow the stream to be seekable, these attributes should have the usual MediaElement behaviour defined in HTML [4].

> duration: A MediaStream does not have a pre-defined duration.

> loop: Setting the loop attribute has no effect since a MediaStream has no
> defined end and therefore cannot be looped.

These constraints also apply when playing streams from a tuner.

Also, HTMLMediaElement does not have an equivalent to the OIPF stopTimeshift() method, although the same effect could presumably be achieved using:

    element.currentTime = Infinity;

because the current "live" playback position should be the latest time in the seekable range. See [4, section 4.8.14.9].

Chris

[1] https://lists.w3.org/Archives/Public/public-tvapi/2015Mar/0013.html

[2] http://w3c.github.io/mediacapture-main/, draft 23 May 2015
[3] http://www.w3.org/blog/news/archives/4600

[4] http://www.w3.org/html/wg/drafts/html/master/semantics.html


--
Chris Needham
Senior Software Engineer
BBC Research & Development


-----------------------------
http://www.bbc.co.uk

This e-mail (and any attachments) is confidential and 
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in 
error, please delete it from your system.
Do not use, copy or disclose the 
information in any way nor act in reliance on it and notify the sender 
immediately.
Please note that the BBC monitors e-mails 
sent or received.
Further communication will signify your consent to 
this.
-----------------------------

Received on Friday, 5 June 2015 13:57:12 UTC