On Tue, Aug 10, 2010 at 7: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, 10 Aug 2010 01:34:02 +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 Tue, Aug 10, 2010 at 12:04 AM, Philip Jägenstedt <<a href="mailto:philipj@opera.com" target="_blank">philipj@opera.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 Sat, 07 Aug 2010 09:57:39 +0200, Silvia Pfeiffer <<br>
<a href="mailto:silviapfeiffer1@gmail.com" target="_blank">silviapfeiffer1@gmail.com</a>> wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br></div></blockquote><div class="im">
I guess this is in support of Henri's proposal of parsing the cue using the<br>
HTML fragment parser (same as innerHTML)? That would be easy to implement,<br>
but how do we then mark up speakers? Using <span class="narrator"></span><br>
around each cue is very verbose. HTML isn't very good for marking up dialog,<br>
which is quite a limitation when dealing with subtitles...<br>
</div></blockquote><div class="im"><br>
I actually think that the <span @class> mechanism is much more flexible than<br>
what we have in WebSRT right now. If we want multiple speakers to be able to<br>
speak in the same subtitle, then that's not possible in WebSRT. It's a<br>
little more verbose in HTML, but not massively.<br>
<br>
We might be able to add a special markup similar to the <[timestamp]> markup<br>
that Hixie introduced for Karaoke. This is beyond the innerHTML parser and I<br>
am not sure if it breaks it. But if it doesn't, then maybe we can also<br>
introduce a <[voice]> marker to be used similarly?<br>
</div></blockquote>
<br>
An HTML parser parsing <1> or <00:01:30> will produce text nodes "<1>" and "<00:01:30>". Without having read the HTML parsing algorithm I guess that elements need to begin with a letter or similar. So, it's not possible to (ab)use the HTML parser to handle inner timestamps of numerical voices, we'd have to replace those with something else, probably more verbose.</blockquote>
<div><br></div><div><br></div><div>I have checked the parse spec and <a href="http://www.whatwg.org/specs/web-apps/current-work/#tag-open-state">http://www.whatwg.org/specs/web-apps/current-work/#tag-open-state</a> indeed implies that a tag starting with a number is a parse error. Both, the timestamps and the voice markers thus seem problems when going with an innerHTML parser. Is there a way to resolve this? I mean: I'd quite happily drop the voice markers for a <span @class> but I am not sure what to do about the timestamps. We could do what I did in WMML and introduce a <t> element with the timestamp as a @at attribute, but that is again more verbose. We could also introduce an @at attribute in <span> which would then at least end up in the DOM and can be dealt with specially. </div>
<div><br></div><div>Just for those who think it's a fancy karaoke feature and isn't really required: it's actually also a useful feature for captions, in particular when recording live captions that are usually "paint-on". Requirement CC-14 on <a href="http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements">http://www.w3.org/WAI/PF/HTML/wiki/Media_Accessibility_Requirements</a> also refers to this need and 608/708 captions provide this functionality, too.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5"><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>
Similarly, I think that the WebSRT parser should be designed to ignore<br>
things that it doesn't recognize, in particular unknown voices (if we keep<br>
those). Requiring parsers to fail when the version number is increased<br>
</blockquote>
<br>
<br>
oh, you misunderstood me: I am not saying that parser have to fail - it's<br>
good if they don't. But I am saying that if we make a change to the<br>
specification that is not backwards compatible with the previous one and<br>
will thus invariably break parsers, we have to notify parsers somehow such<br>
that if they get parse errors they can e.g. notify the user that this is a<br>
new version of the WebSRT format which their software doesn't support yet.<br>
</blockquote>
<br></div></div>
A browser won't bother their users by saying "hey, there was something in this page I didn't understand", as users won't know what to do to fix it.</blockquote><div><br></div><div><br></div><div>I'm not overly worried about browsers. They will just display the wrong text. They are not normally an authoring or transcoding application. I am more worried about non-browser applications here, in particular those where interpreting the text the wrong way will lead to disaster, such as the wrong data in an archive etc.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">
Think for example about the case where we had a requirement that a double<br>
newline starts a new cue, but now we want to introduce a means where the<br>
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<br>
be hoped that most new features can be introduced without breaking backwards<br>
compatibility and we can write the parsing requirements such that certain<br>
things will be ignored, but in and of itself, WebSRT doesn't provide for<br>
this extensibility. Right now, there is for example extensibility with the<br>
"WebSRT settings parsing" (that's the stuff behind the timestamps) where<br>
further "setting:value" settings can be introduced. But for example the<br>
introduction of new "cue identifiers" (that's the <> marker at the start of<br>
a cue) would be difficult without a version string, since anything that<br>
doesn't match the given list will just be parsed as cue-internal tag and<br>
thus end up as part of the cue text where plain text parsing is used.<br>
</blockquote>
<br></div>
The bug I filed suggested allowing arbitrary voices, to simplify the parser and to make future extensions possible. For a web format I think this is a better approach format than versioning. I haven't done a full review of the parser, but there are probably more places where it could be more forgiving so as to allow future tweaking.</blockquote>
<div><br></div><div><br></div><div>That's a good approach and will reduce the need for breaking backwards-compatibility. In an xml-based format that need is 0, while with a text format where the structure is ad-hoc, that need can never be reduced to 0. That's what I am concerned about and that's why I think we need a version identifier. If we end up never using/changing the version identifier, the better so. But I'd much rather we have it now and can identify what specification a file adheres to than not being able to do so later.</div>
<div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">
On the other hand, keeping the same extension and (unregistered) MIME type<br>
as SRT has plenty of benefits, such as immediately being able to use<br>
existing SRT files in browsers without changing their file extension or MIME<br>
type.<br>
</blockquote>
<br>
<br>
There is no harm for browsers to accept both MIME types if they are sure<br>
they can parse old srt as well as new websrt. But these two formats are<br>
different enough that they should be given a different extension and mime<br>
type. I do not see a single advantage in stealing the MIME type of an<br>
existing format for a new specification.<br>
</blockquote>
<br></div>
But there's no spec for the old SRT, the only thing one could do is parser it with a WebSRT parser.</blockquote><div><br></div><div>I can write that spec in an afternoon and register the mime type with IANA. That really isn't a problem. People have managed to write correct SRT files without having a spec, because it's so trivial. Creating a spec is just a formality. For now, the wikipedia page really is sufficient.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> That would make text/srt and text/websrt synonymous, which is kind of pointless.</blockquote>
<div><br></div><div>No, it's only pointless if you are a browser vendor. For everyone else it is a huge advantage to be able to choose between a guaranteed simple format and a complex format with all the bells and whistles.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> The advantages of taking text/srt is that all existing software to create SRT can be used to create WebSRT</blockquote>
<div><br></div><div>That's not strictly true. If they load a WebSRT file that was created by some other software for further editing and that WebSRT file uses advanced WebSRT functionality, the authoring software will break.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> and servers that already send text/srt don't need to be updated. In either case I think we should support only one mime type.</blockquote>
<div><br></div><div>What's the harm in supporting two mime types but using the same parser to parse them?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;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">
* there is no definition of the "canvas" dimensions that the cues are<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 class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
prepared for (width/height) and expected to work with other than saying<br>
it<br>
is the video dimensions - but these can change and the proportions<br>
should<br>
be<br>
changed with that<br>
<br>
<br>
</blockquote>
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<br>
same<br>
subtitles really don't work at two different resolutions, couldn't we<br>
just<br>
have two files? In what cases would this be needed?<br>
<br>
</blockquote>
<br>
<br>
Most subtitles will be created with a specific width and height in mind.<br>
For<br>
example, the width in characters relies on the video canvas having at<br>
least<br>
that size and the number of lines used usually refers to a lower third of<br>
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<br>
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>
<br>
</blockquote>
<br>
In practice, does this mean scaling font-size by<br>
width_actual/width_intended or similar? Personally, I prefer subtitles to be<br>
something like 20 screen pixels regardless of video size, as that is<br>
readable. Making them bigger hides more of the video, while making them<br>
smaller makes them hard to read. But I guess we could let the CSS media<br>
query min-width and similar be evaluated against the size of the containing<br>
video element, to make it possible anyway.<br>
</blockquote>
<br>
<br>
<br>
Have you ever tried to keep the small font size of subtitles on a 320x240<br>
video when going full-screen? They are almost unusable at that size. YouTube<br>
doesn't do a good job at that, incidentally, so you can go check it out<br>
there - go full-screen and see how tiny the captions become then step back<br>
from your screen to where you'd want to watch the video from and notice how<br>
the captions are basically unreadable.<br>
<br>
When you scale the font-size with the video, you do not hide more of the<br>
video - you hide the exact same part of the video. Video and font get larger<br>
in the same way. And that's exactly the need that we have.<br>
</blockquote>
<br></div></div>
Existing media players have basically two different ways of handling this. The kind you're describing is like MPlayer, where subtitles appear to actually be rendered on to the video frames and then scaled together with the video. The kind I've used more is like Totem, where subtitles are rendered in a separate layer at a fixed size in pixels, regardless of whether or not you're watching in fullscreen. This means that word wrapping will be different depending on screen size.</blockquote>
<div><br></div><div>In the Totem case, does the font size increase with a change in screen size?</div><div><br></div><div>My suggestion is to have them in different layers, but there is knowledge about the intended anchoring, i.e. where is the text supposed to appear on the video screen. The keep that anchoring intact no matter what the video size.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"> I find both MPlayer's and Totem's behavior annoying in some situations, but personally prefer Totem most of the time.<br>
</blockquote><div><br></div><div>Do you find MPlayer's behavior annoying because by rescaling already rendered text, the text loses resolution and becomes less readable? This is definitely not the behaviour I am after.</div>
<div><br></div><div>Cheers,</div><div>Silvia.</div><div><br></div></div>