On Tue, Aug 10, 2010 at 12:04 AM, 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Sat, 07 Aug 2010 09:57:39 +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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div class="im">
Hi Philip,<br>
<br>
On Sat, Aug 7, 2010 at 1:50 AM, 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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
* there is a possibility to provide script that just affects the<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
time-synchronized text resource<br>
<br>
</blockquote>
<br>
I agree that some metadata would be useful, more on that below. I'm not<br>
sure why we would want to run scripts inside the text document, though, when<br>
that can be accomplished by using the TimedTrack API from the containing<br>
page.<br>
</blockquote>
<br>
<br>
<br>
Scripts inside a timed text document would only be useful for applications<br>
that use the track not in conjunction with a Web page.<br>
</div></blockquote>
<br>
Do you mean that media players could include a JavaScript engine just for supporting scripts in WebSRT? Not to say that it can't happen, but it seems a bit unlikely.</blockquote><div><br><br>Yes, it's indeed an "out there" feature and I am not worried about having it now. I just mentioned it as a simple possibility for 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;"><div class="im"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


2. There is a natural mapping of WebSRT into in-band text tracks.<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Each cue naturally maps into a encoding page (just like a WMML cue does,<br>
too). But in WebSRT, because the setup information is not brought in a<br>
hierarchical element surrounding all cues, it is easier to just chuck<br>
anything that comes before the first cue into an encoding header page. For<br>
WMML, this problem can be solved, but it is less natural.<br>
<br>
</blockquote>
<br>
I really like the idea of letting everything before the first timestamp in<br>
WebSRT be interpreted as the header. I'd want to use it like this:<br>
<br>
# author: Fan Subber<br>
# voices: <1> Boy<br>
#         <2> Girl<br>
<br>
01:23:45.678 --> 01:23:46.789<br>
<1> Hello<br>
<br>
01:23:48.910 --> 01:23:49.101<br>
<2> Hello<br>
<br>
It's not critical that the format of the header be machine-readable, but we<br>
could of course make up a key-value syntax, use JSON, or something else.<br>
</blockquote>
<br>
<br>
<br>
I disagree. I think it's absolutely necessary that the format of the header<br>
be machine-readable. Just like EXIF in images is machine readable or ID3 in<br>
MP3 is machine-readable. It would be counter-productive not to have it<br>
machine-readable, in particular useless to archiving and media management<br>
solutions.<br>
</blockquote>
<br></div>
OK, so maybe key-values?<br>
<br>
Author: Fan Subber<br>
Voice: <1> Boy<br>
Voice: <2> Girl<div class="im"><br>
<br>
01:23:45.678 --> 01:23:46.789<br>
<1> Hello<br>
<br></div>
This looks a bit like HTTP headers. (I'm not sure I'd actually want to allow multiple occurrences of the same key, in practice that seems to result in inconsistencies in how people mark up multiple authors.)</blockquote>

<div><br><br>Yes, anything that can replicate the name-value possibilities of the <meta> element should be fine.<br>Multiple occurrences make sense for some fields and not for others.<br>I wonder if we would need to make a defined list of what should go in here or just define a general mechanism. HTML has a general mechanism (with <meta>) while most subtitle formats have a defined set of fileds, e.g. <a href="http://en.wikipedia.org/wiki/LRC_%28file_format%29">http://en.wikipedia.org/wiki/LRC_%28file_format%29</a> (ID3 tags) or <a href="http://www.matroska.org/technical/specs/subtitles/ssa.html">http://www.matroska.org/technical/specs/subtitles/ssa.html</a> (SSA headers).<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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


I'm not sure of the best solution. I'd quite like the ability to use<br>
arbitrary voices, e.g. to use the names/initials of the speaker rather than<br>
a number, or to use e.g. <shouting> in combination with CSS :before {<br>
content 'Shouting: ' } or similar to adapt the display for different<br>
audiences (accessibility, basically).<br>
</blockquote>
<br>
<br>
<br>
I agree. I think we can go back to using<span> and @class and @id and that<br>
would solve it all.<br>
</blockquote>
<br></div>
I guess this is in support of Henri's proposal of parsing the cue using the HTML fragment parser (same as innerHTML)? That would be easy to implement, but how do we then mark up speakers? Using <span class="narrator"></span> around each cue is very verbose. HTML isn't very good for marking up dialog, which is quite a limitation when dealing with subtitles...</blockquote>

<div><br><br>I actually think that the <span @class> mechanism is much more flexible than what we have in WebSRT right now. If we want multiple speakers to be able to speak in the same subtitle, then that's not possible in WebSRT. It's a little more verbose in HTML, but not massively.<br>

<br>We might be able to add a special markup similar to the <[timestamp]> markup that Hixie introduced for Karaoke. This is beyond the innerHTML parser and I am not sure if it breaks it. But if it doesn't, then maybe we can also introduce a <[voice]> marker to be used similarly?<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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


 * there is no means to identify which parser is required in the cues (is<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
it<br>
"plain text", "minimal markup", or "anything"?) and therefore it is not<br>
possible for an application to know how it should parse the cues.<br>
<br>
</blockquote>
<br>
All the types that are actually for visual rendering are parsed in the same<br>
way, aren't they? Of course there's no way for non-browsers to know that<br>
metadata tracks aren't interesting to look at as subtitles, but I think<br>
showing the user the garbage is a quicker to communicate that the file isn't<br>
for direct viewing than hiding the text or similar.<br>
</blockquote>
<br>
<br>
<br>
The spec says that files of kind "descriptions" and "metadata" are not<br>
displayed. It seems though that the parsing section will try two interfaces:<br>
HTML and plain. I think there is a disconnect there. If we already know that<br>
it's not parsable in HTML, why even try?<br>
</blockquote>
<br></div>
I was confused. The parsing algorithm does the same thing regardless of what kind of text track it is dealing with. I guess what you're saying is that non-browser applications also need to know that something is e.g. chapter markers, so that it can display it appropriately?<br>


<br>
I don't have a strong opinion, but repeating the same information both in the containing document and in the subtitle file means that one of them will be ignored by browsers. People will copy-paste the ignored one and it will end up being wrong a lot of the time.</blockquote>

<div><br>I don't see a problem with repeating this information.There will be files and other file formats that do not have the "kind" inside the file - maybe because the files are always only used for captions/subtitles or only for lyrics/karaoke and thus don't need an extra specification. But for WebSRT files, which provide a platform for time-synchronized text, this is important information to have inside the file - or assume a default of "captions" or so. Thus, for files that do not have a "kind", the specification in HTML is necessary. For those that do, it provides the author with an opportunity to take that hint or even to override it. An authoring application could even alert a Web developer if they are referencing a "chapters" file with a "subtitles" @kind attribute. But obviously what is stated in the HTML page will be what matters.<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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


 * there is no version number on the format, thus it will be difficult to<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
introduce future changes.<br>
<br>
</blockquote>
<br>
I think we shouldn't have a version number, for the same reason that CSS<br>
and HTML don't really have versions. If we evolve the WebSRT spec, it should<br>
be in a backwards-compatible way.<br>
</blockquote>
<br>
<br>
CSS and HTML are structured formats where you ignore things that you cannot<br>
interpret. But the parsing is fixed and extensions play within this parsing<br>
framework. I have my doubts that is possible with WebSRT. Already one<br>
extension that we are discussion here will break parsing: the introduction<br>
of structured headers. Because there is no structured way of extending<br>
WebSRT, I believe the best way to communicate whether it is backwards<br>
compatible is through a version number. We can change the minor versions if<br>
the compatibility is not broken - it communicates though what features are<br>
being used - and we can change the major version of compatibility is broken.<br>
</blockquote>
<br></div>
Similarly, I think that the WebSRT parser should be designed to ignore things that it doesn't recognize, in particular unknown voices (if we keep those). Requiring parsers to fail when the version number is increased </blockquote>

<div><br>oh, you misunderstood me: I am not saying that parser have to fail - it's good if they don't. But I am saying that if we make a change to the specification that is not backwards compatible with the previous one and will thus invariably break parsers, we have to notify parsers somehow such that if they get parse errors they can e.g. notify the user that this is a new version of the WebSRT format which their software doesn't support yet. Think for example about the case where we had a requirement that a double newline starts a new cue, but now we want to introduce a means where the double newline is escaped and can be made part of a cue. <br>

<br>Other formats keep track of their version, such as MS Word files. It is to be hoped that most new features can be introduced without breaking backwards compatibility and we can write the parsing requirements such that certain things will be ignored, but in and of itself, WebSRT doesn't provide for this extensibility. Right now, there is for example extensibility with the "WebSRT settings parsing" (that's the stuff behind the timestamps) where further "setting:value" settings can be introduced. But for example the introduction of new "cue identifiers" (that's the <> marker at the start of a cue) would be difficult without a version string, since anything that doesn't match the given list will just be parsed as cue-internal tag and thus end up as part of the cue text where plain text parsing is used.<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;">makes it harder to introduce changes to the format, because you'll have to either break all existing implementations or provide one subtitle file for each version. (Having a version number but letting parsers ignore it is just weird, quite like in HTML.)<br>


<br>
I filed a bug suggesting that voice is allowed to be an arbitrary string: <<a href="http://www.w3.org/Bugs/Public/show_bug.cgi?id=10320" target="_blank">http://www.w3.org/Bugs/Public/show_bug.cgi?id=10320</a>> (>From the point of view of the parser, it still wouldn't be valid syntax.)</blockquote>

<div><br><br>As it stands, the voice marker is more of a "WebSRT setting" for the complete cue and should probably be moved up with the other "WebSRT settings", since it's not markup inside the cue like the others and should not end up as a token during parsing.<br>

<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 class="im"><br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


 2. Break the SRT link.<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<br>
</blockquote>
<br>
 * the mime type of WebSRT resources should be a different mime type to SRT<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
files, since they are so fundamentally different; e.g. text/websrt<br>
<br>
* the file extension of WebSRT resources should be different from SRT<br>
files,<br>
e.g. wsrt<br>
<br>
</blockquote>
<br>
I'm not sure if either of these would make a difference.<br>
</blockquote>
<br>
<br>
Really? How do you propose that a media player identifies that it cannot<br>
parse a WebSRT file that has random metadata in it when it is called .srt<br>
and provided under the same mime type as SRT files? Or a transcoding<br>
pipeline that relies on srt files just being plain old simple SRT. It breaks<br>
expectations with users, with developers and with software.<br>
</blockquote>
<br></div>
I think it's unlikely that people will offer download links to SRT files that aren't useful outside of the page, so random metadata isn't likely to reach end users or applications by accident. Also, most media frameworks rely mainly on sniffing, so even a file that uses lots of WebSRT-only features is quite likely going to be detected as SRT anyway. At least in GStreamer, the file extension is given quite little weight in guessing the type and MIME isn't used at all (because the sniffing code doesn't know anything about HTTP). Finally, seeing random metadata displayed on screen is about as good an indication that the file is "broken" as the application failing to recognize the file completely.<br>

</blockquote><div><br>But very poor user experience and a "WTF: I thought this application supported SRT and now it doesn't". Transcoding pipelines will break in existing productions that expect the simplest SRT without much tolerance for extra characters and they will have the extra markup of voice and ruby etc in plain sight, since they are not built as WebSRT parsers. It will lead to many many headaches. We're even against serving a WebM resource as a .mkv video with <code>video/x-matroska</code> MIME type when WebM is really completely compatible with Matroska. So, why do it with WebSRT and SRT?<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;">
<br>
On the other hand, keeping the same extension and (unregistered) MIME type as SRT has plenty of benefits, such as immediately being able to use existing SRT files in browsers without changing their file extension or MIME type.</blockquote>

<div><br>There is no harm for browsers to accept both MIME types if they are sure they can parse old srt as well as new websrt. But these two formats are different enough that they should be given a different extension and mime type. I do not see a single advantage in stealing the MIME type of an existing format for a new specification.<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: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">


 * there is no definition of the "canvas" dimensions that the cues are<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
prepared for (width/height) and expected to work with other than saying it<br>
is the video dimensions - but these can change and the proportions should<br>
be<br>
changed with that<br>
<br>
</blockquote>
<br>
I'm not sure what you're saying here. Should the subtitle file be<br>
hard-coded to a particular size? In the quite peculiar case where the same<br>
subtitles really don't work at two different resolutions, couldn't we just<br>
have two files? In what cases would this be needed?<br>
</blockquote>
<br>
<br>
Most subtitles will be created with a specific width and height in mind. For<br>
example, the width in characters relies on the video canvas having at least<br>
that size and the number of lines used usually refers to a lower third of a<br>
video - where that is too small, it might cover the whole video. So, my<br>
proposal is not the hard-code the subtitles to a particular size, but to put<br>
the minimum width and height that are being used for the creation of the<br>
subtitles into the file. Then, the file can be scaled below or above this<br>
size to adjust to the actual available space.<br>
</blockquote>
<br></div>
In practice, does this mean scaling font-size by width_actual/width_intended or similar? Personally, I prefer subtitles to be something like 20 screen pixels regardless of video size, as that is readable. Making them bigger hides more of the video, while making them smaller makes them hard to read. But I guess we could let the CSS media query min-width and similar be evaluated against the size of the containing video element, to make it possible anyway.</blockquote>

</div><br><br>Have you ever tried to keep the small font size of subtitles on a 320x240 video when going full-screen? They are almost unusable at that size. YouTube doesn't do a good job at that, incidentally, so you can go check it out there - go full-screen and see how tiny the captions become then step back from your screen to where you'd want to watch the video from and notice how the captions are basically unreadable.<br>

<br>When you scale the font-size with the video, you do not hide more of the video - you hide the exact same part of the video. Video and font get larger in the same way. And that's exactly the need that we have.<br>
<br>
<br>Cheers,<br>Silvia.<br>