[whatwg] Fwd: Timed tracks for <video>

I forgot to send this to the list.

---------- Forwarded message ----------
From: Silvia Pfeiffer <silviapfeiffer1@gmail.com>
Date: Sat, Jul 24, 2010 at 10:00 PM
Subject: Re: [whatwg] Timed tracks for <video>
To: Paul Ellis <paul at ellisfoundation.com>


On Sun, Jul 25, 2010 at 2:04 PM, Paul Ellis <paul at ellisfoundation.com>wrote:

> On Sat, Jul 24, 2010 at 5:49 PM, Silvia Pfeiffer <
> silviapfeiffer1 at gmail.com> wrote:
>
>> On Sun, Jul 25, 2010 at 6:57 AM, Paul Ellis <paul at ellisfoundation.com>wrote:
>>
>>> On Fri, Jul 23, 2010 at 6:54 AM, Henri Sivonen <hsivonen at iki.fi> wrote:
>>>
>>>>  On Jul 23, 2010, at 08:40, Ian Hickson wrote:
>>>> > - Keep implementation costs for standalone players low.
>>>>
>>>> I think this should be a non-goal. It seems to me that trying to cater
>>>> for non-browser user agents or non-Web uses in Web specs leads to bad Web
>>>> specs. I think by optimizing for standalone players WebSRT falls into one of
>>>> the common traps for Web specs. I think we should design for the Web (where
>>>> the rendering is done by browser engines).
>>>>
>>>
>>> I disagree that this should be a non-goal. Making it harder for content
>>> to be portable between the web and the non-web (standalone players, hardware
>>> devices, etc) will definitely stifle the adopting of WebSRT. There is
>>> already a significant ecosystem (players, creation tools, and content)
>>> around SRT that could easily be leveraged to make WebSRT successful.
>>>
>>
>>
>> Everyone I have spoken to in this ecosystem recommended against extending
>> SRT and recommended either picking one of the more capable existing formats
>> (in particular ASS or the new AS6 which is in development) or - if that
>> wasn't possible - recommended creating a proper format for the Web that can
>> then be supported in its own right. I think if we have a mixed set of .srt
>> files out there, some of which are old-style srt files (with line numbers,
>> without WebSRT markup) and some are WebSRT files with all the bells and
>> whistles and with additional external CSS files, we create such a mess for
>> that existing ecosystem that we won't find much love.
>>
>
> My comment was more generally about how we shouldn't completely ignore the
> benefits of adopting/extending existing popular solutions in such a way that
> there is some interoperability with the non-web. Through my work at DivX I
> have had a fair amount of exposure to various subtitle formats and the whole
> ecosystem (creation tools, content, software players, CE, etc) needed for a
> format to be successful. I wouldn't ever argue that SRT is an elegant
> format, but you also can't argue that it doesn't work in the ecosystem
> today. SSA/ASS is is a relatively robust subtitle format and is probably the
> only other format that has comparable support throughout the ecosystem as
> SRT.
>


There is no issue with any of this. SRT is indeed successful. Also, it is
indeed important to look at existing formats. I once held the opinion that
we should support SRT as one of the most basic formats and DFXP as a highly
capable format. I still don't mind about supporting SRT, but it's obviously
not sufficient. Also, for our purposes, DFXP seems not to work. ASS/SSA was
deemed too complex and incompatible with CSS. Thus, the creation of a new
format was pursued.

WebSRT is a suggestion for a new format and one reason for its creation was
that it would keep implementation costs for standalone players low because
it can build on existing SRT infrastructure. I simply doubted whether it
actually meets this goal, while Henri even more fundamentally doubted
whether this is a valid goal. I've heard previously that whenever the W3C
has tried to create a format that is also usable outside the Web, the design
decisions that were made because of trying to make it work outside the Web
have always turned out to be poor decisions. I don't have examples (maybe
somebody else has?), but I can believe that trying to serve two masters is
never a good idea - you might end up not serving either.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100726/5faefe9d/attachment.htm>

Received on Monday, 26 July 2010 09:59:52 UTC