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

Hi

During the TV API community group call of 9 June 2015, I took actions 33 [1] and 35 [2] to make an analysis of what additions are needed to the current TV API specification to support the remaining requirements [4] [5]
This is currently a rough analysis which would be probably be better carried out on a wiki page, I just wanted to get them here first for participants to start reading..


·         tuner.signal-strength

o   The OIPF definitions of signal strength [6] seem to capture the required "signal strength". The quality value could be omitted as that is an implementation specific calculation

·         tuner.notifications

§  this is a parent requirement - does not directly require anything

·         tuner.notifications.change

o   Adding an ontunerschange event to the TVManager interface should suffice. We only have one "change" defined (i.e. TUNER_CHANGE) which could be passed to the event handler

interface TVManager {

    Promise<https://w3c.github.io/tvapi/spec/#dfn-promise> getTuners<https://w3c.github.io/tvapi/spec/#widl-TVManager-getTuners-Promise> ();

    attribute EventHandler ontunerschange;

};

o   Upon receiving this event, the application can call getTuners(). Additional arguments could be included into the event handler functions to indicate which TVTuner.id was changed/ added/deleted



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

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.

o   The OIPF DAE has these very well defined in the Recording Scheduler APIs<http://www.oipf.tv/web-spec/volume5.html#scheduled-recording-apis>. We will likely need our own recording scheduler.

·         recording.timed

o   For this we would define something similar to the OIPF DAE recordAt()<http://www.oipf.tv/web-spec/volume5.html#oipfrecordingscheduler-recordat> function.

·         recording.identifier

o   This could be realized with an "record(channel, identifier)" function where the channel is some serialized form of a TVChannel oblect and identifier is the eventId from TVProgram.

o   OIPF DAE has a record(programme)<http://www.oipf.tv/web-spec/volume5.html#oipfrecordingscheduler-record> method, something similar could be added to the Recording Schedule for record( TVProgram program ) - note that some may believe the implementation needs to do some "tricks" if there is a recording resource conflict for the specific program passed to record() to make for a better user experience however this could only be done for an exact match (including parental rating)

·         recording.multiple

o   This would be a consequence of how the recording scheduler grabs tuner resources and/or other implementation dependent functions (i.e. an implementation may not release a tuner {perhaps the only tuner} for recording if it is currently "connected" to a HTMLMediaElement)  -- read this as "watching takes priority over recording"

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

·         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

·         recording.playback

o   Certainly we need to make a list of in-progress or completed recordings available to the webapp so that the URL to the recording can be passed to the HTMLMediaElement

·         recording.delete

o   Depending on how the list of scheduled, in-progress, completed recordings is presented to the webapp, this could be as simple as performing an array splice().

o   OIPF DAE provides the remove(scheduledRecording)<http://www.oipf.tv/web-spec/volume5.html#oipfrecordingscheduler-remove> method to ensure that all the required operations are complete in the implementation.

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



·         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

·         timeshift.pause

o   Essentially the same as { x = playSpeed; setSpeed(0); }

o   Could also add a pause() method to TVTuner

·         timeshift.resume

o   Essentially the same as setspeed(x) - given the current speed is 0 and x is saved according to pause();

o   Could also add a resume() method to TVTuner

·          timeshift.stop

o   Same as setspeed(POSITIVE_INFINITY) or could add something equivalent to OIPF DAE stopTimeShift<http://www.oipf.tv/web-spec/volume5.html#video-broadcast-stoptimeshift>



For later study

·         channel.search

o   The current getChannels() method of TVSource returns an array of TVChannel elements. This should be in the order in which they were found during the last channel scan operation, and should not be changed.

§  Applications can enumerate this list for the channel.search requirement

·         channel.filter

o   The current getChannels() method of TVSource returns an array of TVChannel elements. This should be in the order in which they were found during the last channel scan operation, and should not be changed.

§  Applications can enumerate this list to realize the channel.filter requirement

·         channel.sort

o   The current getChannels() method of TVSource returns an array of TVChannel elements. This should be in the order in which they were found during the last channel scan operation, and should not be changed.

§  I seldom see the channel list being sorted in any other way for use presentation - normally that is a "frowned on" practice.

·         channel.sequential

o   The current getChannels() method of TVSource returns an array of TVChannel elements. This should be in the order in which they were found during the last channel scan operation, and should not be changed.

§  An application can enumerate the channel list and identify the index for the current channel (as defined by the TVSource.currentChannel property). The next "up" channel would be at index+1 and the previous "down" channel would be at index-1 (some wrapping could be applied depending in desired application behavior)

·         channel.tracks

o   This is probably something that can be realized through the tracks associated with the MediaStream produced by the TVTuner

o   We would need to "extend" this MediaStream definition of tracks as a Tuner is likely to produce many (video, main-audio, alternate-audio, clean audio, main language captions, alternte language captions, video signing captions)


·         scan.signal-strength

o   Same properties for the tuner.signal-strength should be sufficient. Don't really know if we need these at channel scan time as we do not have any concept about filtering of which channels discovered during scan get put into the channel list returned by getChannels()



[1] http://www.w3.org/community/tvapi/track/actions/33

[2] http://www.w3.org/community/tvapi/track/actions/35
[3] https://w3c.github.io/tvapi/spec/
[4] https://www.w3.org/community/tvapi/wiki/Main_Page/Technical_Requirement
[5] https://www.w3.org/community/tvapi/wiki/Main_Page/Progress_Measurement
[6] http://www.oipf.tv/web-spec/volume5.html#signalinfo-class




[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
paul.higgs@ericsson.com
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>