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

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

From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, 19 Feb 2011 08:18:23 +1100
Message-Id: <F6FB4200-602E-4426-8D64-F1786FABC50B@gmail.com>
Cc: Philip Jägenstedt <philipj@opera.com>, "public-html@w3.org" <public-html@w3.org>
To: Mark Watson <watsonm@netflix.com>

On 19/02/2011, at 3:08 AM, Mark Watson <watsonm@netflix.com> wrote:

> 
> On Feb 18, 2011, at 2:08 AM, Philip Jägenstedt wrote:
> 
>> On Thu, 17 Feb 2011 18:43:49 +0100, Mark Watson <watsonm@netflix.com>  
>> wrote:
>> 
>>> 
>>> On Feb 17, 2011, at 7:17 AM, Philip Jägenstedt wrote:
>>> 
>>>> On Wed, 16 Feb 2011 18:47:22 +0100, Mark Watson <watsonm@netflix.com>
>>>> wrote:
>>>> 
>>>>> 
>>>>> On Feb 16, 2011, at 12:02 AM, Philip Jägenstedt wrote:
>>>>> 
>>>>>> On Wed, 16 Feb 2011 03:31:47 +0100, Silvia Pfeiffer
>>>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>>> 
>>>>>>> On Wed, Feb 16, 2011 at 12:08 PM, Jonas Sicking <jonas@sicking.cc>
>>>>>>> wrote:
>>>>>>>> On Tue, Feb 15, 2011 at 4:19 PM, Silvia Pfeiffer
>>>>>>>> <silviapfeiffer1@gmail.com> wrote:
>>>>>>>>> On Wed, Feb 16, 2011 at 5:36 AM, Mark Watson <watsonm@netflix.com>
>>>>>>>>> wrote:
>>>>>>>>>> Hi Philip,
>>>>>>>>>> 
>>>>>>>>>> Just a quick note that the "alternative" vs "additional"  
>>>>>>>>>> distinction
>>>>>>>>>> is not always completely clear. Video with different camera angles
>>>>>>>>>> (gimmiky or not) could be considered as an alternative, or could  
>>>>>>>>>> be
>>>>>>>>>> rendered as picture-in-picture, or multiple thumbnail videos could
>>>>>>>>>> show beside the main video (some sports sites already do this kind
>>>>>>>>>> of
>>>>>>>>>> thing).
>>>>>> 
>>>>>> Sure, but all of those modes should be achieved by the author making  
>>>>>> it
>>>>>> happen with CSS. At the risk of making a strawman argument, I honestly
>>>>>> can't see browsers allowing the user to change the rendering of the  
>>>>>> page
>>>>>> to achieve PiP or something like that when the author hasn't provided
>>>>>> for
>>>>>> it, messing with the layout like that seems both weird and unlikely to
>>>>>> be
>>>>>> useful. Of course we can have User JavaScript and User CSS to do that
>>>>>> kind
>>>>>> of thing, though.
>>>>> 
>>>>> I was assuming that the "author" of the content - who labels the tracks
>>>>> - might not be the same as the "author" of the webpage that is  
>>>>> rendering
>>>>> the content. So the first author should not assume that (say) multiple
>>>>> views are alternatives, because some webpages might be able to view  
>>>>> them
>>>>> both as PIP.
>>>> 
>>>> Since the tracks are labeled using the attribute of the <track>  
>>>> attribute,
>>>> it will be the page author that has to do the work to support some
>>>> specific video display, be that PiP, overlay or something else.
>>> 
>>> That would be the case for track objects created as a result of <track>  
>>> elements, but what about in-band tracks ? The page author does the work  
>>> for PIP etc., of course, but the media author should not assume that  
>>> such capabilities are or are not available on the pages where their  
>>> media might be used: they should just label the tracks and let the page  
>>> to whatever it is capable of.
>> 
>> I don't think we should spend much time making extra in-band video tracks  
>> work more than barely, if at all, since the extra bandwidth needed to have  
>> multiple in-band video tracks makes it quite unlikely the feature would be  
>> used to any greater extent.
> 
> A track declared within an adaptive streaming manifest (e.g. a DASH manifest or take-your-pick of various proprietary adaptive streaming solutions) would be an in-band track but would only be fetched when actually needed. 
> 
>> 
>> If they should work at all, my position is that the only thing you should  
>> be able to do with in-band video tracks is switch between them, in other  
>> words what I've called alternative tracks. Either having some kind of  
>> layout information in the file itself or having HTML markup to target  
>> individual tracks of the same resource seems like unjustified complexity  
>> and spec/implementation effort not very well spent.
> 
> I think people do imagine that adaptive streaming manifests would declare all the tracks needed for a presentation - including sign language tracks that are additional rather than alternative. Such manifests have to be useful in environments other than HTML and so need to included everything. I don't think we should ask people to re-author them in HTML for use in HTML environments.
> 
> I guess what I am saying is that Option (1) in the wiki write-up should be supported in order to provide support for adaptive streaming. The questions are:
> (1) whether this should be the only way to declare such additional/alternative tracks or whether an HTML markup way is also required (and I think that it is)
> (2) what should that markup be
> (3) how to define the API for discovering and manipulating these tracks in a way that is common for in-band (from a file or from an adaptive streaming manifest) and explicitly marked up tracks.
> 

(4) And what should be the rendering.

Silvia.



> ...Mark
> 
>> 
>> -- 
>> Philip Jägenstedt
>> Core Developer
>> Opera Software
>> 
>> 
> 
> 
Received on Friday, 18 February 2011 21:19:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:17:22 GMT