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

On Thu, Jun 18, 2015 at 12:23 AM, Paul Higgs <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.

 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?

 ·         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?)
* 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.

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


>
> [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
>