Re: Action-219: Draft Response to MSE on Bug 23661

On Mon, 16 Dec 2013 22:39:20 +0100, Silvia Pfeiffer  
<silviapfeiffer1@gmail.com> wrote:

> Charles,
>
> Why not try to fix it in the HTML spec first and thus imply the MSE
> and all other such specs?

Because I am under the impression that MSE aims to have a Recommendation  
around the time that HTML5 is expecting to return to Last Call.

So anything implied by HTML that isn't already supported by MSE is  
essentially only implied in the land of spec wonks (which is not quite the  
same as reality).

> It makes sense to me to fix this problem at
> the root, not start with the leaves.
>
> Is there a bug on the HTML spec for this yet?

No. You could clone 23661, but it seems to me that the HTML Bug should  
learn from the ongoing discussion with MSE. I am pretty sure we haven't  
figured out how to do this exactly right yet, although I hope we can close  
in on it pretty quickly.

(Since apparently nobody is pushing hard for a formal requirement I think  
we will be able to collaborate thoughtfully and get something we are all  
happy with. It's not as exciting as making a big fuss about an important  
principle, but it might be more productive :) ).

In the next couple of days I expect to fulfill my action item and raise a  
bug, if there isn't one.

cheers

> Regards,
> Silvia.
>
>
> On Tue, Dec 17, 2013 at 3:16 AM, Charles McCathie Nevile
> <chaals@yandex-team.ru> wrote:
>> On Thu, 12 Dec 2013 20:50:33 +0100, Steven Robertson <strobe@google.com>
>> wrote:
>>
>>
>>> YouTube intends to use MSE to improve accessibility by offering the  
>>> user
>>> the ability to switch content streams on the fly. Currently we do  
>>> *not* plan
>>> to implement this using AudioTracks/VideoTracks but rather by  
>>> switching the
>>> streams that get appended using JS. We are doing this so that the  
>>> feature
>>> can work reliably across all devices, including those which lack the
>>> technical capability to support A/VTracks.
>>
>>
>> Right, this is one valid implementation strategy. Note that it requires  
>> you
>> to hold and mix on the server-side all the necessary pieces, which goes
>> beyond providing the simple adaptations typically required to make MSE  
>> worth
>> using.
>>
>> Note that signing video being developed by LaTrobe University (which
>> currently has the largest deaf student population in Australia  
>> according to
>> their own statements) to support hearing-impaired students is designed  
>> to
>> meet the use case of allowing the student to reposition the two video  
>> tracks
>> relative to each other, for example swapping video-in-video display for
>> either video to be the "container", as well as moving the smaller video
>> around on screen to cater for shifts in the visually important areas at  
>> any
>> time. It seems the YouTube proposal would be unable to support these
>> requirements efficiently, requiring a large amount of re-encoding to  
>> support
>> a relatively small but mission-critical (for the University) audience.
>>
>>
>>> This supports Aaron's objection;
>>
>>
>> I don't think so.
>>
>>
>>> conflating the user-facing goal of improving accessibility by having
>>> the ability to select more appropriate content and one technical
>>> implementation of that goal will limit the adoption of other
>>> strategies
>>
>>
>> It may well do so, and I agree that it would be a mistake to make such a
>> conflation. For example by assuming that the approach taken by YouTube  
>> is
>> available to and appropriate for everyone else - or by assuming that  
>> signed
>> captioning can only be done with a second independent video track.
>>
>> (A third obvious technique is to use avatars, and transmit something  
>> that is
>> not video at all over the wire - but while this has been considered a  
>> great
>> idea for at least two decades, it's still in the "nice demo, but not  
>> really
>> generally usable" stage as far as I know).
>>
>>> which have broader support.
>>
>>
>> That's a judgement call that relies on a number of assumptions. Tto be  
>> fair,
>> so is the word "typically" in the proposed resolution of the TF, and on
>> reflection it seems that it should be easy to remove any bias toward  
>> one or
>> other assumption in a result acceptable to all.
>>
>> But even if it turns out that we can prove one solution has and will  
>> have
>> broader support, failing to adequately support legitimate alternative
>> implementation strategies should be justified on some technical  
>> grounds. As
>> you note above, assuming that a solution which works for many cases is  
>> the
>> right one for everyone else too is a path to making specifications that
>> unfairly distort perceptions about use cases that are appropriate to
>> support.
>>
>> Please note that I am not accusing you of actually making that  
>> assumption,
>> but it seems to me that upholding your objection would lead people to  
>> think
>> in that direction.
>>
>>
>> cheers
>>
>> Chaals
>>
>> --
>> Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
>>         chaals@yandex-team.ru         Find more at http://yandex.com
>>


-- 
Charles McCathie Nevile - Consultant (web standards) CTO Office, Yandex
       chaals@yandex-team.ru         Find more at http://yandex.com

Received on Tuesday, 17 December 2013 00:13:18 UTC