W3C home > Mailing lists > Public > public-html@w3.org > March 2011

RE: Tech Discussions on the Multitrack Media (issue-152)

From: Bob Lund <B.Lund@CableLabs.com>
Date: Thu, 3 Mar 2011 14:50:15 -0700
To: Mark Watson <watsonm@netflix.com>, Silvia Pfeiffer <silviapfeiffer1@gmail.com>
CC: Philip Jägenstedt <philipj@opera.com>, "public-html@w3.org" <public-html@w3.org>
Message-ID: <114DAD31379DFA438C0A2E39B3B8AF5D017C2BB937@srvxchg>
We've contemplated this problem with respect to in-band metadata tracks in live streams over MPEG-2 TS. We'd like to see a descriptive label that identifies the type of metadata (and can be learned by the user agent from the in-band track). Can the DASH manifest and ISO file carry such a label? 

Thanks,
Bob Lund

-----Original Message-----
From: public-html-request@w3.org [mailto:public-html-request@w3.org] On Behalf Of Mark Watson
Sent: Thursday, March 03, 2011 2:38 PM
To: Silvia Pfeiffer
Cc: Philip Jägenstedt; public-html@w3.org
Subject: Re: Tech Discussions on the Multitrack Media (issue-152)

>From a DASH manifest you do. And from an ISO file there is a track id. Don't know about Matroska.

But in any case, in the absence of a track id from the container the browser could just create numeric track ids and you would be no worse off than your original proposal.

It is the more complex things like adaptive streaming presentations were the tracks can change. If you have a simple file I expect they don't change during playout.

....Mark

On Mar 3, 2011, at 12:38 PM, Silvia Pfeiffer wrote:

> My only concern with addressing by id rather than position is the availability of an id from on-band. Do we get such an identifier for tracks from all containers?
> 
> Silvia.
> 
> Sent from my iPhone
> 
> On 04/03/2011, at 4:51 AM, Mark Watson <watsonm@netflix.com> wrote:
> 
>> 
>> On Mar 2, 2011, at 4:38 PM, Silvia Pfeiffer wrote:
>> 
>>> On Thu, Mar 3, 2011 at 3:40 AM, Mark Watson <watsonm@netflix.com> wrote:
>>>> 
>>>> 
>>>> I have another question related to an earlier discussion on this thread: do I understand correctly that in order to apply CSS styling there needs to be an HTML markup element to apply the styling to ? i.e. that you couldn't apply styling to control the rendering of an in-band track that appears only as a MediaTrack object and not as a <track> element (with associated HTMLTrackElement object) ?
>>>> 
>>>> In that case it seems we need to be able to refer to an in-band track in the main resource from a <track> element in order to apply styling. For example the MediaTrack API could expose an "id" attribute (at least for in-band tracks) which could be used to refer to this track from a <track> element.
>>> 
>>> 
>>> I didn't want to let this one go unnoticed. In the current spec for 
>>> <track> we address the cues inside the <track> - independent of 
>>> whether they come from in-band or from an external file - through a 
>>> ::cue CSS pseudo-selector.
>>> 
>>> Maybe something like this can be introduced for the tracks, too? 
>>> This could then avoid having a HTML markup element for tracks and 
>>> allow us to style them similar to how we style cues. Can this work:
>>> ::track(number) where number is the position in the IDL tracks list 
>>> in the HTMLMediaElement? Some kind of default rendering would need 
>>> to be described, too.
>>> 
>> 
>> I don't have a strong opinion on the solution, just that it should be possible to control the rendering of in-band tracks as well as those which are explicitly declared in the markup.
>> 
>> Do I understand correctly that to style WebVTT with CSS you attach a styles to the HTMLMediaElement containing the :cue pseudo-selector and these apply to both in-band and explicitly defined timed text tracks ?
>> 
>> To apply the same to other tracks, then it still might be better to require some kind track id and then the pseudo-selector would be :track(id). I say this because I expect that in-band tracks might be added or removed during playback and so the numbering will change. For example, accessibility tracks may be available for the main content but not for adverts. Or in a long-lived live stream things will change from show to show.
>> 
>> I expect we will need an event to indicate when the in-band tracks change.
>> 
>> ...Mark
>> 
>> ...Mark
>> 
>> 
>>> Cheers,
>>> Silvia.
>>> 
>> 
> 
Received on Thursday, 3 March 2011 21:52:11 UTC

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:23 UTC