RE: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS [HOME_NETWORK_TF]

Thanks for the clarification. My concern is with this scenario, what becomes valid if there is both a multiplexed stream and the manifest conveying the same information (one hopes). How can one create a model in HTML5 <video> that can cover both cases. I do not think it is possible.

It is one thing to convey information in the manifest that may apply to different device types with different capabilities and another for conveying the same set of information at different bitrates to be able to take advantage of adaptive streaming. Not sure we can create a universal manifest for all device types. I would have opted to focus on a manifest for conveying information in one codec, mp4 or mpeg2ts, and then explore how does one expose the representation and current period information. With this information it is possible to parse the "manifest" to retrieve the details.

/JanL


________________________________
From: Mark Watson [mailto:watsonm@netflix.com]
Sent: den 20 juni 2011 17:35
To: Jan Lindquist
Cc: Francois Daoust; Giuseppe Pascale; Bob Lund; Web and TV Interest Group WG; Kazuyuki Ashimura
Subject: Re: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS [HOME_NETWORK_TF]


On Jun 20, 2011, at 5:20 PM, Jan Lindquist wrote:

Hello Mark,

I found what you were referring to that the manifest may include information on the available tracks. So does that mean we do not expect information to be conveyed in the stream itself? I thought there might have been an overlap but now I am unsure.

It depends if you're talking about multiple tracks multiplexed into one file, or if the tracks are in separate files.

Clearly, once you have more than one audio language and more than one video bitrate then multiplexing becomes inefficient in terms of storage (you need to store a separate multiplex for each combination).

If everything is completely unmuxed, then it's the manifest which carries the information about the available tracks.

If you have multiplexed streams then the information is available in the manifest and the streams.

This will create for an interesting manifest which depending on periods that may include multiple tracks that change overtime. It adds an additional dimension since in MPEG2-TS it only represents the current time (period).

DASH manifests allow you to specify a sequence of "periods" in time, each of which has entirely separate sets of streams.

For live services, the manifest can be updated over time, with new periods being added (and really old ones being removed).

...Mark


Regards,
JanL

________________________________
From: Mark Watson [mailto:watsonm@netflix.com]
Sent: den 20 juni 2011 16:47
To: Jan Lindquist
Cc: Francois Daoust; Giuseppe Pascale; Bob Lund; Web and TV Interest Group WG; Kazuyuki Ashimura
Subject: Re: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS [HOME_NETWORK_TF]


On Jun 20, 2011, at 4:28 PM, Jan Lindquist wrote:

Comments below.
Regards,
JanL

________________________________
From: Mark Watson [mailto:watsonm@netflix.com]
Sent: den 20 juni 2011 15:31
To: Jan Lindquist
Cc: Francois Daoust; Giuseppe Pascale; Bob Lund; Web and TV Interest Group WG; Kazuyuki Ashimura
Subject: Re: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS [HOME_NETWORK_TF]


On Jun 20, 2011, at 10:57 AM, Jan Lindquist wrote:

Hello Mark,

This is the text I found describing when the event takes place.

Whenever the selected track is changed, the user agent must queue a task<http://dev.w3.org/html5/spec/Overview.html#queue-a-task> to fire a simple event<http://dev.w3.org/html5/spec/Overview.html#fire-a-simple-event> named change at the MultipleTrackList<http://dev.w3.org/html5/spec/Overview.html#multipletracklist> object.

Ah, ok, I missed that.


It implied only on the selected track so not on others.

Actually, what is says is that the event is fired when the selected track changes. It doesn't say there are no other cases where the event fires ;-) One could argue that there is a sentence missing somewhere else that says this event is also fired when the available tracks change.
[JLI>] I like the suggestion from Sylvia Preiffer to make these changes at MediaElement. Since one needs to have an event across the tracklist[ ] so not only 1 track if one creates an event against a single track.


Thank you for sending the e-mail an e-mail on the video thread. It captures the issue very well and from the response it seems like this has to be an event at media level.

The question you raised on adaptive streaming is in my view independent of the video element since it is a seperate aspect of video selection. It is a layer above controlling the selection of a media stream. It mixes the components or tracks associated to a video and the representations that guide the selection of video and associated components if that makes sense.

If you mean that track selection, and availability/unavailability of tracks is a higher layer thing independent of adaptation that might or might not be going on underneath, then I agree.
[JLI>] My concern is that to get track information you need to be actually parsing the stream and extract this information. This will be information in the buffer or in the process of being rendered. The adaptive stream has issues prior to the stream entering the buffer and when rendering. Not sure how one can combine the two requirements on the tracks concept.
I'm not sure I understand the concern. In an adaptive streaming concept the information about the available tracks will likely be in a manifest file, not in the media itself. This is updated periodically (and so can change).

...Mark


...Mark


Regards,
JanL
________________________________
From: Mark Watson [mailto:watsonm@netflix.com]
Sent: den 20 juni 2011 10:31
To: Jan Lindquist
Cc: Francois Daoust; Giuseppe Pascale; Bob Lund; Web and TV Interest Group WG; Kazuyuki Ashimura
Subject: Re: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS [HOME_NETWORK_TF]


On Jun 16, 2011, at 10:14 AM, Jan Lindquist wrote:

Hi Mark,

I have seen there is support for events for changes on the selected track but what if there are changes in the number of tracks and type of tracks? I cannot find anything in the latest tracklist support that hints that it is supported.

The TrackList object has an onchange event: is that what you mean by 'events on the selected track' ? Where does it say that ?

I couldn't find any detailed description on this TrackList::onchange event, so I assumed it fires when the contents of the TrackList object changes i.e. the set of available tracks, or their properties, changes.

There was a question raised by Ian Hickson titled "Re: [whatwg] Video feedback" (2011-06-03) touching exactly on this point. The response basically highlights this issue. I have refrained from starting a Bugzilla report since I presume this would be addressed by the <video> author.

That was talking about text tracks, where there is indeed no way to detect changes.

I wouldn't presume that things just get addressed ;-) I just replied to that thread.

...Mark


Best regards,
JanL

________________________________
From: Mark Watson [mailto:watsonm@netflix.com]
Sent: den 16 juni 2011 00:19
To: Jan Lindquist
Cc: Francois Daoust; Giuseppe Pascale; Bob Lund; Web and TV Interest Group WG; Kazuyuki Ashimura
Subject: Re: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS [HOME_NETWORK_TF]


On Jun 7, 2011, at 5:41 AM, Jan Lindquist wrote:

Hello Francois,

I realize the timing is not good. There will be things that we definitely cannot get addressed in the short term so the use case can be adapted to look at a longer term.

There is one issue which I see as relatively minor and should be possible to address in the short term. The change in available video/audio tracks and not necessarily the one being presented. Is your suggestion to use Bugzilla to highlight this issue?

What do you think is missing ? The TrackList object (http://dev.w3.org/html5/spec/Overview.html#tracklist) has an onchange event. Although it is not very well-described, I would assume that it fires when something in the TrackList changes, for example if the available video and audio tracks change.

...Mark


Regards,
JanL

-----Original Message-----
From: Francois Daoust [mailto:fd@w3.org]
Sent: den 6 juni 2011 11:54
To: Giuseppe Pascale
Cc: Bob Lund; Web and TV Interest Group WG; Jan Lindquist; Kazuyuki Ashimura
Subject: Re: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS [HOME_NETWORK_TF]

On 06/03/2011 05:24 PM, Giuseppe Pascale wrote:
Hi Jan,

On Wed, 01 Jun 2011 09:54:45 +0200, Jan Lindquist <jan.lindquist@ericsson.com<mailto:jan.lindquist@ericsson.com>> wrote:

My only be concern is with timing. To delay discussing the use case until a new TF is created may affect discussions with HTML5 WG. I understand there are pressures to complete HTML5 video tag as soon as possible. I would request if we can discuss the use case and eventually move it to a new TF once it is created.

Note that the fact that HTML5 is in last call NOW make it quiet
unlikely that any extension will be ready in time to go into this version of the spec, if we are talking about a major addition that still need to be discussed, defined, presented to the HTML Wg etc.

This doesn't mean that this cannot be discussed and worked on by this
group first and by a WG later on and included in the next version of HTML (6?) when is mature I think the HTML groups is also collecting a list of "new features" for next releases, so our input could be provided to them.

Kaz and Francois (CCed) should be able to confirm/clarify a bit what I just said about the W3C procedures and deadlines and maybe even give us more details.

I confirm: the group is very unlikely to add any new feature to the HTML5 specification at this time, and will begin to discuss new features for next version.

Last Call Comments need to be sent by 3 August 2011. The Web and TV IG may send such comments to the HTML working group (and anyone can send comments on his own, of course). The HTML Working Group will follow the same decision policy as before, documented here:
 http://dev.w3.org/html5/decision-policy/decision-policy.html

In particular, a Bugzilla bug needs to be created with a description of the problem and a concrete proposed solution:
 http://dev.w3.org/html5/decision-policy/decision-policy.html#bugzilla-bug

See also the HTML5 Last Call FAQ at:
 http://www.w3.org/2011/05/html5lc-faq.html

The IG has more time to suggest new features for next version. There is no deadline for that as of today.

Francois.



/g

Best Regards,
JanL

-----Original Message-----
From: public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org>
[mailto:public-web-and-tv-request@w3.org] On Behalf Of Bob Lund
Sent: den 31 maj 2011 17:45
To: Web and TV Interest Group WG
Subject: RE: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS
[HOME_NETWORK_TF]

While there may be <video> tag requirements imposed by MPEG-2 TS, it doesn't seem to fit within the scope of the HNTF, which is addressing how home network services get discovered and used by Web content.

There has been some discussion about starting a new TF to address how adaptive bit-rate delivery should be accommodated in HTML5. This would seem to be the place to also examine the MPEG-2 TS issue raised.

Thanks,
Bob Lund

-----Original Message-----
From: public-web-and-tv-request@w3.org<mailto:public-web-and-tv-request@w3.org> [mailto:public-web-and-tv-
request@w3.org] On Behalf Of Web and TV Interest Group Issue Tracker
Sent: Monday, May 30, 2011 2:27 AM
To: public-web-and-tv@w3.org<mailto:public-web-and-tv@w3.org>
Subject: webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS
[HOME_NETWORK_TF]


webtv-ISSUE-18 (JanL): Video tag support of MPEG2-TS
[HOME_NETWORK_TF]

http://www.w3.org/2011/webtv/track/issues/18

Raised by: Jan Lindquist
On product: HOME_NETWORK_TF

The support of MPEG2-Transport Stream is fundamental to viewing
content in the home (ex. TV). Applications require an API to have
control and access of MPEG2-TS components.

This use case puts explicit requirements of what the the application
may requires support from the video tag (HTML5). While video tag
support many of the indicated implementation requirements not all are supported.
This use case may not explicitly indicate the missing portions but
highlights the full set of implementation requirements.