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

Hi,

As the first step, I've made correspondent updates for tuner changes [1]
and signal strength [2]. Those about recording and time-shifting are
currently left for follow-up improvements.

Best regards,
Sean

[1] http://w3c.github.io/tvapi/spec/#tvmanager-interface
[2] http://w3c.github.io/tvapi/spec/#tvtuner-interface


Sean Lin
Mozilla Taiwan
selin@mozilla.com


On Thu, Jun 18, 2015 at 3:34 AM, HU, BIN <bh526r@att.com> wrote:

>  Thank you very much Paul.
>
>
>
> Sean,
>
>
>
> Would you take a look and see if ED can be updated with (some of) the
> proposal?
>
>
>
> Thank you
>
> Bin
>
>
>
> *From:* Paul Higgs [mailto:paul.higgs@ericsson.com]
> *Sent:* Wednesday, June 17, 2015 9:24 AM
> *To:* public-tvapi@w3.org
> *Subject:* 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
>
>
>
>
>
>
>
>
>
> [image: 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
>
>
>
> [image: 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
>