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

Thank you Geoff. This was a great analysis/synopsis.

I'll hope for a ping if the scope of the FCC VPAAC changes over time. 
I'm not a subject matter expert on video formats but I'm not convinced 
SMPTE-TT is right for the web especially with ride-along legacy/binary 
formats.

Cheers,
David
(Mozilla accessibility guy)

On 05/02/11 4:38 PM, Geoff Freed wrote:
> Hi, everybody:
>
> John is basically correct, but I'll add a few comments.
>
> The FCC is required to consider existing and emerging technical standards as put forward by recognized standards organizations, so they will most likely look at WebVTT-- though with no real adherents on the committee, I’m not sure who will raise it.  Google, perhaps?  But note that the FCC will not be choosing a technical data format-- instead, the regulated entities will.  Those entities are the content providers who previously captioned their material for broadcast, cable and satellite, and they're mostly the SMPTE crowd.
>
> Here’s some relevant language lifted from the Senate report:
>
> ======
> “One report, to be submitted within six months of the day of the first meeting of the Advisory Committee, will address closed captioning on video programming delivered
> using Internet protocol and shall include an identification of the
> performance requirements for protocols, technical capabilities, and
> technical procedures needed to ensure the delivery of closed captions
> on such programming, to the extent that such programming
> does not include consumer generated media, as well as recommendations
> for technical standards to address the abovementioned performance requirements and for regulations that may be necessary to implement the provisions of this Act.”
> ======
>
> Note that the bill explicitly excludes consumer-generated content.
>
> More language from the bill:
>
> ======
> "Not later than six months after the date on which the Advisory
> Committee submits the first report, the Commission shall take all
> steps necessary to adopt relevant protocols, procedures, standards,
> and other technical requirements needed to facilitate access to
> closed captions for video programming delivered using Internet protocol."
> ======
>
>
> As John and Silvia both say below, this is a market decision.  But the ones who have to make this work won't want to waste a lot of time re-doing their standards work (and thus my belief that SMPTE-TT will be favored by those regulated entities). Next-tier players will have to play along, too, such as the browser manufacturers for computers and mobile devices, as well as software media players. One thing we wouldn’t want to see is a notice on Web sites like Hulu.com, NBC.com or Netflix that says that their content is playable on all platforms/browsers... but if you want to see captions you have to use (for example) IE/Windows or Safari/Mac, or a special app on an iPhone or Android phone. We've discussed this possibility already-- it's a bad idea that doesn't serve deaf audiences at all, but one which could very well occur.  My hope is that even those entities that do not favor TTML/SMPTE-TT will realize this, too.
>
> It all comes down to these three basic provisions-- referring to the FCC VPAAC WG’s report, due by July 13, 2011, with FCC rules in place by Jan. 13, 2012:
>
> ======
> 1. The report shall also include recommendations on performance objectives for protocols, technical capabilities, and technical procedures needed to permit content providers, content distributors, Internet service providers, software developers, and device manufacturers to reliably encode, transport, receive, and render closed captions of IP-based video programming.  (Sec. 201(e)(1)(B))
>
> 2. Additional protocols, technical capabilities, and technical procedures beyond those available as of the date of enactment of the CVAA for the delivery of closed captions of IP-based video programming that are necessary to meet the above performance objectives.  (Sec. 201(e)(1)(C))
>
> 3. Technical standards to address the above performance objectives. (Sec. 201(e)(1)(D))
> ======
>
> The “additional protocols” are those that aren’t ready yet-- WebVTT for example.
>
> Regarding UltraViolet and captions and media distribution:  Google and Apple may not be part of the UltraViolet alliance, but they are teaming with Disney on a competing mechanism called Keychest:
> http://en.wikinoticia.com/Technology/Apple/71133-ultraviolet-against-keychest--the-future-of-home-theater.  I don't know what the state of captions will be in Keychest; my guess is that Keychest will do something similar to UltraViolet and settle on a format for all members to use.
>
> Long-winded, I know.  I hope this clarifies more than it confuses.
>
> Geoff/NCAM
>
> ________________________________________
> From: public-html-a11y-request@w3.org [public-html-a11y-request@w3.org] On Behalf Of Silvia Pfeiffer [silviapfeiffer1@gmail.com]
> Sent: Friday, February 04, 2011 11:39 PM
> To: John Foliot
> Cc: Eric Carlson; Matt May; HTML Accessibility Task Force
> Subject: 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 Tuesday, 15 February 2011 14:50:18 UTC