RE: ACTION-33 and ACTION-35: API additions to remianing requirements

Hi Sean

I put my thoughts in here…

From: Sean Lin [mailto:selin@mozilla.com]
Sent: Friday, July 17, 2015 3:41 AM
To: Paul Higgs; chris.needham@bbc.co.uk
Cc: public-tvapi@w3.org
Subject: Re: ACTION-33 and ACTION-35: API additions to remianing requirements

Hi Paul & Chris,

I just have couple thoughts/questions about recording and time-shifting stated below inline. Please feel free to share your comments.

Sean Lin
Mozilla Taiwan
selin@mozilla.com<mailto:selin@mozilla.com>

On Thu, Jun 18, 2015 at 12:23 AM, Paul Higgs <paul.higgs@ericsson.com<mailto:paul.higgs@ericsson.com>> wrote:
•         recording (summary)

o   There are several factors to take into consideration

1.       How much persistent recording storage is available on the device implementing the TV Control API? This could be determined through attributes such as those in the OIPF DAE DiscInfo<http://www.oipf.tv/web-spec/volume5.html#discinfo-class> class. A total of 0 indicates that recording is not supported.

2.       Not all tuners (especially those “plugged in”) will support recording of programs, (i.e. writing the captured transport stream to a file rather than to an HTMLVideoElement).

•         We can determine if the TVTuner supports recording

3.       It is probably best to have a native implementation of a recording scheduler, however series or linked-program recording may be difficult if that recording scheduler is not provided with (or obtains itself) updated program metadata.
There may be different expectations about how a native recording scheduler handle time conflicts between multiple scheduled requests. Given these requests are for the same channel with overlapped time span and the number of tuners may not able to satisfy all of them, some apps might expect the scheduler to enforce a first-come-first-serve strategy so reject the latter ones. Yet some others might expect the former to be dropped. And some might even expect to auto adjust these time spans to non-overlapped ones, or some more customized strategies to determine which request prevails. And those variations appear already existent across different TV platforms on the market.

Thus I'm thinking to keep the native scheduler relatively simple: reject the new request if it conflicts with some existent ones and no more tuners could satisfy it. If the app prefers different behaviors, it may handle the rejected request with its own implementation, such as explicitly remove the conflicts and re-add the one it plans to conserve.


PH> A “first-come-first-served” scheduler would probably suffice as long as we defined it that way. Some recorders are a little smart in that if you overlap record on the same channel, only one tuner is occupied yet two recording files are made. It is also possible to schedule numerous recordings for different channels at the same time, if there are insufficient tuners available when it comes to perform the actual recording, some will not be preformed and an error state such as “no tuning resource available” should be indicated against the scheduled recording (“ERROR_REC_RESOURCE_LIMITATION<http://www.oipf.tv/web-spec/volume5.html#ERROR_REC_RESOURCE_LIMITATION>” in OIPF DAE)
This could certainly be the case as this API supports tuner addition/removal

4.       Access permissions should be considered. You would not want “just any” application being able to access (and modify) your lists of recording schedules or completed recordings.

•         recording.series

o   For this the recording scheduler needs to be configured with a EPG source. The easy way is for the implementation vendor to provide this information as a “browser data service”, alternatively we could permit the implementation to be provided with necessary URLs for a TV-Anytime implementation.
The problem is that so far there doesn't seem any field in EPG which could be reliably used for identifying a series of programs. TVProgram doesn't have relevant attributes, neither do some underlying broadcasting EIT examples I've found. (Please feel free to point out those which have such fields if you happen to have some.) So I'm afraid the implementation vendor may not have a common and reliable way to identify a TV series from EPG, before actually covering this requirement.

Besides, if there are some mechanisms that the web content can figure out / analyze the schedule of a TV series (for example, a page with the schedule of a specific series, or an app has specific protocols or pattern analysis to come out each series for some channels), would it be better to let this done by the web content by generating multiple recording requests?

PH> Series information could be carried in several ways

1.       In an extended_event_descriptor descriptor of an EIT-sched (DVB SI) – with some suitable definition for the values name (i.e. seriesID)

2.       In TV-Anytime metadata which is referenced via a TVA_id_descriptor within an EIT-sched

3.       Other methods for ATSC, ISDB…

•         recording.data

o   The requirement is not clear about what “data” should be saved along with the recorded program. This should certainly include any program metadata known to the TVProgram object
I'm also not clear about what data are expected here. And under some circumstances the recording time span may not be bound to a single program. What is it supposed to do?

•         recording.parental

o   I do not seem how or why the API would enforce parental rating control when scheduling a recording – expecially if it is done only on channel/start/duration basis (that recording could span multiple rating levels)

o   The playback of a recording with parental ratings should not differ to the parental rating requirements.

o   see also the note in recording.identifier.
The parental control looks channel-based. But here are some derived questions:

* Is it allowed to record a parental protected channel, or a program in that channel, when parental control is on? If so, then we only need to check parental control when trying to play the recorded data. (Should this restriction get applied to the recorded channel content which had been done before the channel is set to parental protected?)
PH> I believe it is OK to record a parental controlled program as long as the parental control rating information is retained in the recording and is used during playback. That said, if the recording file is not “secured” to the player (and could be copied from the recorder) and played on a player that did not honour parental ratings, then it should not be possible (i.e. most TV’s and STB’s will not allow an network connected computer to FTP/copy off the recording files)

* But if it's not allowed, then we may need to reject the scheduling request under this situation. But what if the recording is on for the channel while it's set to parental protected?

Maybe we need to readdress and clarify this requirement while working on parental control.
PH> yes, lets ensure we are in agreement regarding the actual requirements!

•         timeshift (summary)

o   Depending on the desired implementation characteristics, we could specify either a fixed or dynamic timeshift buffer mechanism for each tuner (note that each tuner should have its own buffer, as we may do “PiP” and need timeshifting on both.

1.       In a fixed timeshift buffer model, the TVTuner would have a readonly attribute Integer tsBufferSize; which would either depict 0 indicating TS is not available on that tuner or a some >0 value indicating a “size”. Its not possible to say what this size means.

2.       If TS is available on a TVTuner then some additional attributes and methods are needed

•         readonly firstTStimestamp – the timestamp of the oldest

•         readonly pctEmpty – the percentage of the TS buffer that is currently empty so that an on-screen display can show meaningful information to the user

•         setspeed( float speed) – manipulates the HTMLVideoElement playout from the TS buffer

o   speed = NEGATIVE_INFINITY: set the TS buffer playout position to the first frame in the TS buffer then sets the playback speed to 1

o   speed = POSITIVE_INFINITY: set the TS buffer playout position to the last frame in the TS buffer then sets the playback speed to 1 (equivalent to stopTimeShift<http://www.oipf.tv/web-spec/volume5.html#video-broadcast-stoptimeshift> in OIPF DAE)

o   speed = negative number: reverse playback at the specified speed (new frames go into the TS buffer) until the beginning of buffer is reached, then set playback speed to 1 and resume forward

o   speed = positive number: playforward at the specified speed. If the end of the TS buffer is reached and speed>1, set speed = 1.

o   speed = 0 : same as pause

•         readonly playSpeed

o   could also set this as writable and merge the “setspeed()” rules into the setter for this attribute

•         setposition(???) – jump to the designated position (likely a percentage or number of seconds) in the TS buffer and continue playout at playSpeed from there

3.       if TS buffer is not available, attributes would return “undefined” and methods would throw an error (or return some NO_TIMESHIFT_BUFFER errorcode to the resolvers reject algorithm
As suggested in [1], I'm planning to have a TVBufferedMediaStream interface extending MediaStream API for recording and time-shifting use cases. So it can be easily assigned to HTML video tag which can play/pause the stream and set the playback rate.

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



[Ericsson]<http://www.ericsson.com/>
PAUL HIGGS
Technical Solutions Manager
Ericsson Inc

Ericsson
6 Concourse Parkway, suite 400
Atlanta, GA 30328, United States of America
Phone +1 (650) 580-1731<tel:%2B1%20%28650%29%20580-1731>
paul.higgs@ericsson.com<mailto:paul.higgs@ericsson.com>
www.ericsson.com<http://www.ericsson.com>


[http://www.ericsson.com/current_campaign]<http://www.ericsson.com/current_campaign>

Legal entity: Ericsson AB, registered office in Kista, Sweden. This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer<http://www.ericsson.com/email_disclaimer>