Re: [Minutes] Media Sub Team of the Accessibility Task Force - Feb 2., 2011

On Sat, Feb 5, 2011 at 12:44 PM, John Foliot <jfoliot@stanford.edu> wrote:
> Silvia Pfeiffer wrote:
>>
>> Apologies if i seemed off topic, but Eric explained it well.
>>
>> I was just questioning the implicit statement that were made in the
>> teleconference, firstly that SMPTE-TT has widespread support and
>> secondly that it surely will become the specification of choice by the
>> FCC. Since the FCC process has only just started, I was hoping there
>> would be a bit more technical needs analysis and judgement of where
>> things are going. I could, for example, fully understand if the FCC
>> chose both SMPTE-TT and WebVTT as standards for the Internet and the
>> Web respectively. I wouldn't understand if the reasoning that the
>> browser vendors chose to oppose TTML was ignored and SMPTE-TT chosen
>> by default.
>
> Hmmm.... I think that this might be skewed slightly off the mark.
>
> Personally, I don't think the FCC is going to prescribe a specific
> technology solution like this, but rather simply insist that capability
> exists and the entities affected by FCC regulations are mandated to ensure
> that (for example) captioning is made available for X% of all web-based
> video (where X may indeed = 100%, and 'web-based' being broadly defined as
> over the internet network).


That's fine by me. But I don't think that's the intention of this
group, though I might be completely off the mark.


> While the FCC *might* consider feedback from
> browser vendors, theirs will be but one voice of many; others might
> include Ultraviolet (a consortium standardized, cloud-based DRM system)
> and other business interests in the same space, including SMPTEE. If
> SMPTEE says to the FCC, "yes, we agree, and we've looked at this already,
> and we can achieve this with SMPTEE-TT. Our membership is prepared to, and
> in fact is already doing this, using this technology", then I think that
> the FCC will weigh that very heavily.
>
> I think that what we have is a large collection of international
> commercial content providers who will be producing captions in a format
> that they have coalesced around; they (not the FCC) made their choice and
> that format is SMPTEE-TT. If SMPTEE can make the case to the FCC that the
> Time Text format they've agreed upon meets the *user needs* for captioning
> as understood by the FCC, then I really don't see the FCC putting up too
> much of an argument against it.
>
> While the FCC may indeed be the catalyst for deployment here, the FCC's
> reach only extends within the USA. SMPTEE content producers however are
> international in scope, and commercial video producers around the globe
> will all be investing money and resources in a format that they have
> collectively chosen. I honestly don't think they will care if the browsers
> will support that format natively, or whether they will need to stream
> their content to SMPTEE-TT aware/capable <objects> embedded into the web
> browser (as they are already doing today with video content, with Netflix
> being a bit of a poster-child here). I am sure they would be happy if
> SMPTEE-TT support was native in the browsers, but I don't see it as being
> a barrier in their adoption of SMPTEE-TT - they will be less religious
> about the 'native' part of the delivery chain.
>
> Thus, whether or not native support of SMPTEE-TT is in a browser or not
> will then become a business decision of the individual browser vendors, in
> a way very similar to the codec issue we face today. If one or more
> browsers does not support SMPTEE-TT natively, and a company like NBC
> Universal is doing all of their captioning (intended for web delivery) in
> this format, I don't think that they will wring their hands and bemoan the
> fact that Browser X doesn't support it natively - they will simply find
> another solution (with technologies such as Flash and Silverlight standing
> very ready to do just that).
>
> At the risk of being overly controversial, I think that the browser
> vendors need to re-read and reflect on the development goals of HTML5,
> which stated "Users over content producers, producers over implementers,
> and implementers over technical purity". If in-browser, native support of
> video is important to the implementers, then they should be listening
> carefully to the content producers: if the Academy of Motion Picture Arts
> & Sciences, BBC, NHK and other established video content producers* around
> the globe are already using a technology to achieve their mandated goals,
> then the browsers either get on that bus, or leave those business
> interests out of their mix. It's a question of who owns the fiddle, and
> who does the dancing...

At this point it is complete speculation whether SMPTE-TT or WebVTT
wil have more impact on the Web (and I say Web here for a reason -
what people do in their proprietary applications is their own
business). We can argue either side, but only reality will show. We
have in the past seen that community driven formats sometimes find it
easier to have an impact on the Web than corporation-driven formats
and we have also seen it pan out the other way around, in particular
when the formats are kept open. As long as there is no clear market
winner, browsers are going to support first what's simple, but if the
market wins out they would indeed follow. So, I'm not going to even go
down the track of arguing any case. All I am saying is that right now,
if I was the FCC and had to make a decision, I would find going with
the vendors alone as shortsighted and unnecessarily pushing for one
side of the coin.

Cheers,
Silvia.

Received on Saturday, 5 February 2011 04:40:42 UTC