[whatwg] Fwd: Discussing WebSRT and alternatives/improvements

[Silvia Pfeiffer]

On Wed, Aug 11, 2010 at 7:31 PM, Anne van Kesteren <annevk at opera.com> wrote:

> On Wed, 11 Aug 2010 10:30:23 +0200, Silvia Pfeiffer <
> silviapfeiffer1 at gmail.com> wrote:
>
>> On Wed, Aug 11, 2010 at 5:04 PM, Anne van Kesteren <annevk at opera.com>
>> wrote:
>>
>
>  Also, I can see that structured formats with a
>> clear path for how extensions would be included may not need such a
>> version
>> attribute. WebSRT is not such a structured format, which is what makes all
>> the difference. For example, you simply cannot put a new element outside the
>> root element in XML, but you can easily put a new element anywhere in WebSRT
>> - which might actually make a lot of sense if you think e.g. about adding
>> SVG and CSS inline in future.
>>
>
> There is all kinds of ways we could address this. For instance, we could
> add a feature that makes a line ignored and use that in the future for new
> features.


That goes down the path that Philip suggested. It's a bit artificial and
trying to introduce structure in a basically unstructured document.




> While players are transitioning to WebSRT they will ensure that they do not
> break with future versions of the format.


That's impossible, since we do not know what future versions will look like
and what features we may need.



> There might be enough extensibility in the current WebSRT parsing rules for
> this, I have not checked.


Maybe. I guess we can think hard about all the potential things that we
might want the format to be extended with in the future and then introduce
spaceholders for this. Then we may be ok. But we will never really know
until the future tells us.



>
>  But it is not complex at all and everyone else supports most of the
>>> extensions the WebSRT format has.
>>>
>>
>> All of the WebSRT extensions that do not exist in {basic SRT , <b> , <i>}
>> are not supported by anyone yet.
>> Existing SRT authoring tools, media players, transcoding tools, etc. do
>> not
>> support the cue settings (see
>>
>> http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue-settings
>> ),
>> or parsing of random text in the cues, or the voice markers. So, I
>> disagree with "everyone else supports most of the extensions of the WebSRT
>> format".
>>
>
> Do they throw an error or do they just ignore the settings? If the latter
> it does not seem like a problem. If the former authors will probably not use
> these features for a while until they are better supported.



I'm pretty sure that several will break. We cannot just test a handful of
available applications and if they don't break assume none will. In fact,
all existing applications that get loaded with a WebSRT file with extended
features will display text with stuff that is not expected - in particular
if the "metadata" case is used. And wrong rendering is bad, e.g. if it's
part of a production process, burnt onto the video, and shipped to
hearing-impaired customers. Or stored in an archive.




>
>  Also, what I man with the word "complex" is actually a good thing: a
>> format that supports lots of requirements that go beyond the basic ones.
>> Thus, it's actually a good thing to have a simple format (i.e. SRT) and a
>> "complex"
>> (maybe rather: rich? capable?) format (i.e. WebSRT).
>>
>
> I don't think so. It just makes things more complex for authors (learn two
> formats,


I see that as an advantage: I can learn the simple format and be off to a
running start immediately. Then, when I find out that I need more features,
I can build on top of already existing knowledge for the richer format and
can convert my old files through a simple renaming of the resources.



> have to convert formats (i.e. change mime) in order to use new features
> (which could be as simple as a <ruby> fragment for some Japanese track)


If I know from the start that I need these features, I will immediately
learn WebSRT.



> , more complex for implementors (need two separate implementations as to
> not encourage authors to use features of the more complex one in the less
> complex one), more complex for conformance checkers (need more code), etc.
> Seems highly suboptimal to me.


That's already part of Ian's proposal: it already supports multiple
different approaches of parsing cues. No extra complexity here.

My theory is: we only implement support for WebSRT in the browser - that it
happens to also support SRT is a positive side effect. It works for the Web
- and it works for the existing SRT communities and platforms. They know
they have to move to WebSRT in the long run, but right now they can get away
with simple SRT support and still deliver for the Web. And they have a
growth path into a new file format that provides richer features.

Cheers,
Silvia.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100811/09cbf821/attachment-0002.htm>