On Tue, Aug 24, 2010 at 8:49 PM, Philip Jägenstedt <span dir="ltr"><<a href="mailto:philipj@opera.com">philipj@opera.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="im">On Tue, 24 Aug 2010 04:32:21 +0200, Silvia Pfeiffer <<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
On Mon, Aug 23, 2010 at 6:55 PM, Philip Jägenstedt <<a href="mailto:philipj@opera.com" target="_blank">philipj@opera.com</a>>wrote:<br>
<br>
</div><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 Aside: WebSRT can't contain binary data, only UTF-8 encoded text.<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
</blockquote>
<br>
<br>
It sure can. Just base-64 encode it. I'm not saying it's a good thing, but<br>
if somebody really has an urge...<br>
<br>
</blockquote>
<br>
Sure, this would be a metadata track. Sites have no reason to offer<br>
download links to it, and if anyone gets hold of such a file it would<br>
quickly be evident that it's useless.<br>
</blockquote>
<br>
<br>
After a user has seen the crap on screen. I'm just saying: it's a legal<br>
WebSRT file and really not compatible with any existing infrastructure for<br>
SRT.<br>
</div></blockquote>
<br>
A fair point. The alternatives I can see are (1) using an incompatible format so that the user sees nothing or (2) adding a header that indicates that the track is metadata.<br>
<br>
In order to tell the user to stop wasting their time with this file, I think (1) is clearly worse. (2) is absolutely an option, but it will only make a difference to software that understands this header and if the header is optional it will likely often be omitted. A dialog saying "this is a metadata track, you can't watch it" is slightly friendlier than a screen full of crap, but they are both pretty effective at getting the message across.</blockquote>

<div><br><br>Yeah, I'm totally for adding a hint as to what format is in the cue. Then, a WebSRT file can be identified as to what it contains.<br><br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div><div></div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 If we define WebSRT in a way that can handle >99% of existing content and<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
degrade gracefully (enough) when using new features in old software, it<br>
seems reasonable to do. If lots of software developers cry foul, then<br>
perhaps we should reconsider. It seems to me, though, that actually<br>
researching and defining a good algorithm for parsing SRT would be of use<br>
to<br>
others than just browsers.<br>
<br>
<br>
</blockquote>
How is that different from moving away from SRT. If everyone has to change<br>
their parsing of SRT to accommodate a new spec, then that is a new format.<br>
<br>
</blockquote>
<br>
Not everyone has to change their parsers immediately, many will continue to<br>
work. However, if someone wants to support SRT in a compatible way, it's<br>
very helpful to have a spec, assuming that WebSRT is actually compatible<br>
enough with existing SRT content.<br>
<br>
This is quite similar to HTML4 vs HTML5. There are lots of mostly<br>
compatible HTML parsers, but HTML5 defines a single parsing algorithm, and<br>
slow convergence towards that is a good thing.<br>
<br>
</blockquote>
<br>
No, no, no! It is not at all similar to HTML4 and HTML5. A Web browser<br>
cannot suddenly stop working for a Web page, just because it has some extra<br>
functionality in it. Thus, the HTML format has been developed such that it<br>
can be extended without breaking existing stuff. We can guarantee that no<br>
browser will break because that is the way in which the format has been<br>
specified.<br>
<br>
No such thing has happened for SRT and there is simply no way to guarantee<br>
that all new WebSRT files will work in all existing SRT software, because<br>
SRT has not been specified as a extensible format and because there is no<br>
agreement between all parties that have implemented SRT support as to how<br>
extensions should be made.<br>
<br>
We can introduce such a thing for WebSRT, but we cannot claim it for SRT.<br>
</blockquote>
<br></div></div>
You are right, existing SRT parsers are probably far less interoperable than HTML parsers were before HTML5.<br>
<br>
Existing content demands that SRT parsers handle at least <i>, <b>, <font> and <u> in some manner, even if it is by ignoring it. Any parsers that treat SRT as plain text don't even work with todays content, so I don't think they should be considered at all. </blockquote>

<div><br>You've just defined what SRT is. I would actually define SRT as the plain text format and the <i>, <b>, <font> and <u> markup as extensions.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

The question, then, is if parsers that handle the mentioned markup also ignore <1>, <ruby> and <rt>. I haven't tested it, but I assume that some will ignore it and some won't. How many percent of the media player market would have to handle this correctly for these extensions to be OK, in your opinion?</blockquote>

<div><br>If a single one breaks, it would be bad IMO because the expectations of the users of that software will be broken even if it may just be a small percentage of users and we have no influence on the upgrade path of that software - in particular if it is proprietary.<br>

<br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
If the SRT ecosystem is so fragile that it cannot tolerate any extension<br>
whatsoever, then we should stay far away from it. It just seems that's not<br>
the case.<br>
</blockquote>
<br>
<br>
How do we know that everyone that uses SRT now really wants to use WebSRT<br>
instead and wants to take part in the new ecosystem that we are introducing?<br>
We make some pretty big assumptions about what everyone who is not a Web<br>
browser vendor wants to do with SRT. That doesn't make the existing SRT<br>
ecosystem fragile - but it makes it an existing environment that needs to be<br>
respected.<br>
</blockquote>
<br></div>
At this point, what is your recommendation? The following ideas have been on the table:<br>
<br>
* Change the file extension to something other than .srt.<br>
<br>
I don't have an opinion, browsers ignore the file extension anyway.<br></blockquote><div><br>Yes, I think we should definitely have a new file extension.<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


* Change the MIME type to something other than text/srt.<br>
<br>
I doubt it makes any difference, as most software that deal with SRT today have no concept of MIME types. No matter what I'd want exactly 1 MIME type or alternatively make browsers ignore the MIME type completely.<br>

</blockquote><div><br>You're right in that existing SRT software probably doesn't deal much with a SRT mime type. Right now text/x-srt or text/srt is sometimes used for SRT files, but often text/plain is also in use and more likely from a Web server. Since this is the space where Web browsers play, I am not overly fussed, though I think logically text/websrt makes more sense with a .wsrt extension. Then, also SRT files can be served as text/websrt to allow them to take part in the WebSRT infrastructure if indeed they will continue to be valid WebSRT files.<br>

<br>Incidentally, it is a problem if WebSRT files are served as text/plain, i.e. will the browser not identify them as subtitle files?<br><br> </div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


* Add a header to WebSRT to make it uniquely identifiable.<br>
<br>
The header would have to be mandatory and browsers would have to reject files that don't have it. Such files would be compatible with some existing software and break some, depending on how they sniff. We could also put metadata in such a header.<br>

</blockquote><div><br>Yes, I think we need to introduce a header. Maybe we can hide all the structure in what SRT recognizes as comments (i.e. start the lines as ";". But I believe we need some hints like the @profile to identify the type of the cues and the <link> to link to a style sheet, and we need metadata like the <meta> element of HTML headers.<br>

 <br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* Make something deliberately incompatible with SRT.<br>
<br>
It doesn't make a big difference to browsers implementing the format. We'd be replacing something that mostly works in existing players with something that never works.<br></blockquote><div><br>That was the idea of WMML and I took that path because I thought it would be advantageous for other Web applications, such as built on libxml2, expat, php's SimpleXML, pyexpat for python, Nokogiri for ruby etc. But I really like the idea of WebSRT to allow arbitrary metadata in the cues without having to put it into CDATA sections.<br>

<br>I don't mind creating a format that is still somewhat compatible with SRT. We don't have to force incompatibility - but we should also not have it restrict us. In either case, it is a new format.<br><br> </div>

<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Here's the SRT research I promised: <a href="http://blog.foolip.org/2010/08/20/srt-research/" target="_blank">http://blog.foolip.org/2010/08/20/srt-research/</a></blockquote><div><br>That is awesome work. I knew that most SRT files didn't use UTF-8, but I didn't know that we would make such a large percentage of files that are currently parsed by SRT software be incompatible. It is good data to have.<br>

<br>Cheers,<br>Silvia.<br></div></div>