On Fri, Sep 10, 2010 at 11:00 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 Thu, 09 Sep 2010 15:08:43 +0200, Silvia Pfeiffer<br>
<<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 Wed, Sep 8, 2010 at 9:19 AM, Ian Hickson <<a href="mailto:ian@hixie.ch" target="_blank">ian@hixie.ch</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">
<br>
On Fri, 23 Jul 2010, Philip Jägenstedt wrote:<br>
<br></div><div class="im">
If we must have both kind=subtitles and kind=captions, then I'd suggest<br>
> making the default subtitles, as that is without a doubt the most common<br>
> kind of timed text. Making captions the default only means that most<br>
> timed text will be mislabeled as being appropriate for the HoH when it<br>
> is not.<br>
<br>
Ok, I've changed the default. However, I'm not fighting this battle if it<br>
comes up again, and will just change it back if people don't defend having<br>
this as the default. (And then change it back again if the browsers pick<br>
"subtitles" in their implementations after all, of course.)<br>
<br>
Note that captions aren't just for users that are hard-of-hearing. Most of<br>
the time when I use timed tracks, I want captions, because the reason I<br>
have them enabled is that I have the sound muted.<br>
<br>
</div></blockquote><div class="im">
<br>
Hmm, you both have good points. Maybe we should choose something as the<br>
default that is not visible on screen, such as "descriptions"? That would<br>
avoid the issue and make it explicit for people who provide captions or<br>
subtitles that they have to make a choice.<br>
</div></blockquote>
<br>
If we want people to make an explicit choice, we should make kind a<br>
required attribute and make browsers ignore <track>s without it. (I think<br>
subtitles is a good default though.)</blockquote><div><br><br>I think you misunderstood - my explanation probably wasn't very good. I'm looking at it from the authoring POV.<br><br>What I meant was: if I author a text track that is supposed to be visible on screen as the video plays back and if we choose either @kind=subtitle or @kind=caption as the default, then I don't have to really think through about what I authored as it will be displayed on screen. This invites people to not distinguish between whether they authored subtitles or captions, which is a bad thing, because a deaf user may then get tracks with the wrong label and expectations. If, however, we choose as a default something that is not visible on screen, e.g. @kind=description or @kind=metadata, then the author who wants their text track to be visible on screen has to give it a label, i.e. make an explicit choice between @kind=subtitle and @kind=caption. I believe this will lead to more correctly labeled content. I am therefore strongly against default labeling with either subtitle or caption. We could make @kind a required attribute instead as you are saying.<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">
> - Use existing technologies where appropriate.<br>
> [...]<br>
> > - Try as much as possible to have things Just Work.<br>
><br>
> I think by specifying a standalone cue text parser WebSRT fails on these<br>
> counts compared to reusing the HTML fragment parsing algorithm for<br>
> parsing cue text.<br>
<br>
HTML parsing is a disaster zone that we should avoid at all costs, IMHO. I<br>
certainly don't think it would make any sense to propagate that format<br>
into anywhere where we don't absolutely have to propagate it.<br>
<br>
</blockquote>
<br>
A WebSRT authoring application does not have to create all markup that a<br>
HTML fragment parser supports. It would only use what it sees necessary for<br>
the use cases that it targets.<br>
<br>
Browsers are WebSRT players that will consume the HTML fragments created by<br>
such authoring applications.<br>
In addition, browsers will also be able to consume richer HTML fragments<br>
that were created as time-aligned overlays for video with more fancy<br>
styling by Web developers. Something like<br>
<a href="http://people.mozilla.com/%7Eprouget/demos/vp8/" target="_blank">http://people.mozilla.com/~prouget/demos/vp8/</a> (you need Firefox for it).<br>
Where it says "This movie will eat your planet", you could have fancy timed<br>
text.<br>
<br>
Just as much as there is a need for basic captions and subtitles, there is<br>
also a need for fancy time-aligned HTML fragments. It would be very strange<br>
if, in order to get that working, people would need to use the "metadata"<br>
part of the WebSRT spec.<br>
</blockquote>
<br></div>
Is it likely that HTML in cues alone will be enough to do all the fancy<br>
things that people might want?</blockquote><div><br>I would really want to try and live without script in cues, which means: no canvas. But since we have svg, that should be fine. CSS would be required, too.<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;"> If they need scripts anyway, I'm very happy<br>
to force them to use metadata, as it also makes the browser implementation<br>
simpler (that's my opinion of the suggestions made so far, anyway).</blockquote><div><br>I suppose we can start with having people go that way for now and later when we see that becoming the norm do something about it in a "v2".<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Sun, 25 Jul 2010, Silvia Pfeiffer wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
><br>
> I think if we have a mixed set of .srt files out there, some of which<br>
> are old-style srt files (with line numbers, without WebSRT markup) and<br>
> some are WebSRT files with all the bells and whistles and with<br>
> additional external CSS files, we create such a mess for that existing<br>
> ecosystem that we won't find much love.<br>
<br>
I'm not sure our goal is to find love here, but in general I would agree<br>
that it would be better to have one format than two. I don't see why we<br>
wouldn't just have one format here though. The idea of WebSRT is to be<br>
sufficiently backwards-compatible that that is possible.<br>
<br>
</blockquote>
<br>
With "finding love" I referred to your expressed goals:<br>
- Keep implementation costs for standalone players low.<br>
- Use existing technologies where appropriate.<br>
- Try as much as possible to have things Just Work.<br>
<br>
With WebSRT, we will have one label for two different types of files: the<br>
old-style SRT files and the new WebSRT files. Just putting a single label on<br>
them doesn't mean it is one format, in particular when most old files will<br>
not be conformant to the new label and<br>
</blockquote>
<br></div>
Apart from the encoding, what else about old SRT files wouldn't<br>
be conformant? </blockquote><div><br>
<font> and <u><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;">Does it matter that they aren't conformant if they work<br>
anyway?</blockquote><div> <br>The ones on the wrong charset won't work, at least not without us introducing specific handling for it - which is incidentally specific handling that non-Web applications won't get, so they are still left out in the rain. Think of a new standalone application that was developed just for WebSRT and only deals with UTF-8. It will not deal well with those legacy files.<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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
many new files will not play in the software created for the old spec.<br>
</blockquote>
<br></div>
As long as we don't add a header, the files will play in most existing<br>
software. Apart from parsers that assume that SRT is plain text (and thus<br>
would be unsuitable for much existing SRT content), what kind of breakage<br>
have you found with WebSRT-specific syntax in existing software?<br></blockquote><div><br>I think we need to add a header - and possibly other things in the future. Will we forever have the SRT restrictions hold back the introduction of new features into WebSRT?<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;">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
None is allowed today, but it would be relatively straight-forward to<br>
introduce metadata before the cues (or even in between the cues). For<br>
example, we could add defaults:<br>
<br>
*<br>
DEFAULTS<br>
L:-1 T:50% A:middle<br>
<br>
00:00:20,000 --> 00:00:24,400<br>
Altocumulus clouds occur between six thousand<br>
<br>
00:00:24,600 --> 00:00:27,800<br>
and twenty thousand feet above ground level.<br>
<br>
We could add metadata (here using a different syntax that is similarly<br>
backwards-compatible with what the spec parser does today):<br>
</blockquote>
<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
@charset --> win-1252<br>
@language --> en-US<br>
<br>
00:00:20,000 --> 00:00:24,400<br>
Altocumulus clouds occur between six thousand<br>
<br>
00:00:24,600 --> 00:00:27,800<br>
and twenty thousand feet above ground level.<br>
<br>
<br>
</blockquote>
<br>
When I read the following:<br>
"A WebSRT file body consists of an optional U+FEFF BYTE ORDER MARK (BOM)<br>
character, followed by zero or more WebSRT line<br></div>
terminators<<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator</a>>,<div class="im">
<br>
followed by zero or more WebSRT<br></div>
cues<<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-cue</a>><div class="im">
<br>
separated<br>
from each other by two or more WebSRT line<br></div>
terminators<<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator</a>>,<div class="im">
<br>
followed by zero or more WebSRT line<br></div>
terminators<<a href="http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator" target="_blank">http://www.whatwg.org/specs/web-apps/current-work/multipage/video.html#websrt-line-terminator</a>><div class="im">
<br>
."<br>
then that doesn't imply for me that we can add anything in front of the<br>
WebSRT cues without breaking the spec, or that we can define cues that are<br>
not time ranges around the "-->" sign.<br>
</div></blockquote>
<br>
The parsing algorithm simply skips over things it doesn't recognize,<br>
that's why adding basically any new syntax in between cues wouldn't break<br>
existing WebSRT parsers. </blockquote><div> <br>Legacy SRT parsers are not required to do so and even if they are actually implemented to deal with this situation, it's a dangerous assumption. We may as well write into the syntax description of WebSRT that any line that doesn't match the syntax description has to be ignored, which then has the effect that every single file in the world is a valid WebSRT file.<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;"> Allowing anything as part of the syntax is a bit<br>
dangerous though, as most unrecognized stuff between cues are likely<br>
broken cues. Validators should warn about it, not treat it as a comment.<br></blockquote><div><br>I wasn't aware of the effect of the standardised parsing algorithm for WebSRT allowing "broken cues" to be dealt with. This will effectively mean that a parser will be required to parse all files that it is given from beginning to end and discard all non-conformant lines - even if that file may be a 100GB large movie file. In this case, I would really recommend that we put a magic identifier at the beginning of Web SRT files so we can be sure that the intention of the file was to be a WebSRT file. Let's have the string "WebSRT" at the beginning of the files.<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;">
<br>
Not being convinced we need anything more than simple key-value headers in<br>
a header, I still looked at the options for comments:<br>
<br>
Making any line with a --> in it be a comment would hide a lot of broken<br>
cues from validators, so I think we shouldn't do this.<br>
<br>
; appears at the beginning of lines in 15/10000 files and most don't look<br>
like they're intended as comments.<br>
<br>
# appears at the beginning of lines in 244/10000 files and most don't look<br>
like they're intended as comments.<br>
<br>
/* only appears in 3/10000 files, so CSS-style comments might work, but<br>
does add some complexity<br>
<br>
// appears at the beginning of lines in 5/10000 files and most look like<br>
that *are* intended as comments or are garbage, so it should work.<br>
<br>
(data from OpenSubtitles sample)</blockquote><div class="im"><br>This convinces me only more that we should break with SRT history.<br><br><br>Cheers,<br>Silvia.<br><br></div></div>