| 14:52 | <ubitux> | hi, |
| 14:52 | <ubitux> | how is webvtt supposed to be muxed within webm/mkv? |
| 14:53 | <ubitux> | i'm a bit concerned about the timing line mixed with the payload |
| 14:53 | <ubitux> | timing line mixed with the positionning* sorry |
| 14:54 | <ubitux> | (so what goes in the payload?) |
| 14:56 | <zewt> | not sure what you're asking |
| 14:57 | <zewt> | (not to say I can necessarily answer, but I'll try if I can :) |
| 14:59 | <ubitux> | well, if you take a common srt file muxed in mkv, an event such as "01:02:03.04 --> 05:06:07.08\nfoobar" will be stored in mkv such as [pts_start][duration][payload="foobar"] |
| 14:59 | <ubitux> | what happens now when the position information is stored on the timed line, and not as part of the payload |
| 15:00 | <ubitux> | if you put that information in the payload, how do you differenciate it from the classic text content |
| 15:01 | <zewt> | are you asking as a webm developer? i ask because this is a webm/mkv implementation detail--they can do it however they want, it's not something webvtt would define |
| 15:02 | <zewt> | for static (non-streaming) videos i'd be inclined to put the whole webvtt file (perhaps preprocessed in some way) at the start of the file, not to interleave it across the video--that's a strategy that doesn't make sense with files small enough to trivially load into memory |
| 15:03 | <zewt> | but that's entirely up to the file format; they can preparse and store the file however they like, of course |
| 15:04 | <ubitux> | putting the whole sub content is stupid since the format has capabilities to store subtitles events and an extra header |
| 15:05 | <ubitux> | the thing is, if we want to mux it properly |
| 15:05 | <zewt> | stupid? niiice |
| 15:05 | <ubitux> | it doesn't look like possible |
| 15:05 | <zewt> | "can do" and "should do" are not equivalent :) |
| 15:05 | <ubitux> | except doing the crappy way of dumping the file in it |
| 15:06 | <zewt> | you can dump the whole cue text in it, or preprocess it in some way if you like |
| 15:07 | <zewt> | let's back up a bit |
| 15:07 | <ubitux> | media containers are designed to have the split form (for audio, video or subtitles) |
| 15:07 | <ubitux> | but if we want to split it |
| 15:07 | <ubitux> | how are we supposed to do it? |
| 15:08 | <zewt> | is "start time/duration/payload" the basic format mkv has to work with for subtitles, or is that just how it handles srt? |
| 15:08 | <ubitux> | since if we split the timing line and positionning |
| 15:08 | <ubitux> | the demuxer can't guess if the positionning is part of the text or a positionning info |
| 15:08 | <zewt> | (it doesn't really matter, it just affects how we discuss it) |
| 15:08 | <ubitux> | basis for subtitles |
| 15:08 | <ubitux> | it's used for ASS/SSA too |
| 15:09 | <ubitux> | the start & end are extracted from the dialogue events |
| 15:09 | <zewt> | okay, so start time and duration are straightforward; you'd have to encode the remaining information into the payload |
| 15:09 | <ubitux> | put into the mkv structures, and rest of the dialog line put into the payload |
| 15:10 | <zewt> | for example--not suggesting this is optimal, just a simple quick way--the first byte of "payload" is the "align" setting (0: start, 1: middle, 2: end), the second byte encodes the size, etc., followed by the cue text |
| 15:11 | <zewt> | (not a very robust or extensible encoding, of course, just illustrating) |
| 15:11 | <ubitux> | having an obvious way of muxing it in most of the container would be way better |
| 15:11 | <zewt> | that is, the "payload" is all of the information in the cue block except the timestamps, not just the cue text |
| 15:12 | <zewt> | or put differently, the payload is the whole cue block, with the *exception* of the timestamps (since you encode those as separate fields) |
| 15:14 | <zewt> | my first more serious inclination if I was defining this would be to change the timestamps in the cue to "0.000 --> 0.000", and then just copy the entire cue block into the payload, so the parsing of the payload is defined by webvtt and no WebM format changes are needed to support new WebVTT features |
| 15:14 | <zewt> | (the reason for blanking the timestamp is to make it clearly not redundant with the timestamp/duration encoded in the separate fields, to ensure that nobody accidentally uses them) |
| 15:14 | <zewt> | (but leaving them in so it still parses in the same way) |
| 15:42 | <ubitux> | zewt: about your proposition, it's a pain if a new fields is added |
| 15:42 | <ubitux> | (having 1 byte per prop and stuff) |
| 15:42 | <ubitux> | also if formats implement that differently it will be a pain for demuxers |
| 15:42 | <zewt> | ubitux: like I said, that's not an extensible (or even serious) encoding |
| 15:42 | <ubitux> | since we can't factor code for such trivial thing |
| 15:42 | <zewt> | the latter is rather more probable |
| 15:43 | <zewt> | (muxers don't have to know anything at all about new cue features) |
| 15:43 | <ubitux> | well the good thing i see is cutting just after the timing info |
| 15:43 | <ubitux> | and includes the \n in the payload |
| 15:43 | <zewt> | that's more complex |
| 15:43 | <ubitux> | but it sucks a bit |
| 15:44 | <ubitux> | why? |
| 15:44 | <ubitux> | we can't have some heuristics on the payload to detect if it's align/size, etc |
| 15:44 | <zewt> | because 1: now you have a cue block without a timestamp, meaning you can't just use webvtt's parser, and 2: don't forget about cue identifiers (whether those are often useful or not, better off not dropping them unnecessarily) |
| 15:45 | <ubitux> | demuxers and decoders are different |
| 15:45 | <ubitux> | you use a decoder to parse the payload stuff |
| 15:45 | <ubitux> | basically the markup and stuff |
| 15:45 | <ubitux> | the timing stuff is extracted by the demuxer, splitting the input into chunk |
| 15:45 | <zewt> | yes, that's what i suggested :) |
| 15:46 | <ubitux> | so in case of a standalone webvtt, the demuxer will split the file into chunk, removing the timing stuff and send the payload to the decoder |
| 15:46 | <ubitux> | in case of a muxed file, it's the same, you construct a packet with the timing info from the format |
| 15:46 | <ubitux> | and send the payload to the webvtt decoder |
| 15:46 | <zewt> | yes, that's what i suggested :) |
| 15:46 | <ubitux> | alright |
| 15:47 | <ubitux> | well then that's not answering the question |
| 15:47 | <ubitux> | what happens to the align & size from the timing information? |
| 15:47 | <zewt> | i don't know what the question is |
| 15:47 | <zewt> | they're not part of the timing information, they just happen to be on the same line |
| 15:47 | <zewt> | let me give an example |
| 15:47 | <zewt> | (one sec) |
| 15:49 | <zewt> | http://pastebin.com/CWA5471e |
| 15:49 | <ubitux> | then you have the timing information two times |
| 15:49 | <ubitux> | that sucks. |
| 15:49 | <zewt> | no you don't |
| 15:49 | <ubitux> | well you have a kind of weird signature |
| 15:49 | <zewt> | there's no timestamp in the payload; just "0 --> 0", which is a dummy |
| 15:50 | <ubitux> | (0.000 --> 0.000 is a valid one no?) |
| 15:50 | <zewt> | it's there only to avoid having to change the parser (since then you'd run into other issues, like how to distinguish a cue id) |
| 15:50 | <ubitux> | and btw why this one? |
| 15:50 | <ubitux> | why a so long signature? |
| 15:50 | <zewt> | that's not the timestamp; the timestamp is 00:10.000 --> 00:15.000 |
| 15:50 | <ubitux> | and couldn't that be standardized? |
| 15:51 | <zewt> | it's not a signature, it's just a dummy timestamp so the WebVTT parser can still be used |
| 15:52 | <zewt> | (eg. step 37 in the WebVTT parser) |
| 15:52 | <ubitux> | whatever is decided, it would be *really* important to standardize |
| 15:52 | <ubitux> | or at least a recommendation or something |
| 15:52 | <ubitux> | because this will likely be an issue for various containers |
| 15:54 | <zewt> | not sure it makes sense for webvtt to try to standardize how it's encoded in higher-level formats it knows nothing about, but if the webm/mkv folks want advice on this stuff, they can always come here or post on public-texttracks |
| 15:54 | <ubitux> | well the other way around would be to make obvious how to split that |
| 15:54 | <ubitux> | basically by separating the align/size stuff from the timing line |
| 15:54 | <zewt> | sorry--split what? |
| 15:55 | <zewt> | that's out of webvtt's scope--it doesn't know anything about that (and as I suggested above, I don't even know if that's a good idea) |
| 15:55 | <ubitux> | webvtt will be standardized and massively used |
| 15:55 | <zewt> | webvtt's parser depends heavily on seeing webvtt timestamps to know what it's looking at |
| 15:55 | <ubitux> | it will have the issue of being muxed |
| 15:55 | <ubitux> | so it's something you should consider |
| 15:56 | <ubitux> | zewt: i mean maybe move it do a dedicated line |
| 15:56 | <zewt> | but that would change the format and the parser significantly--the approach I suggested above (dummy timestamps) avoids that complexity |
| 15:57 | <zewt> | (not to say it's the only way of doing it, though nothing else comes to mind and it seems very simple, without all the ways trying to eliminate it might bite you) |
| 16:01 | <ubitux> | just found http://wiki.webmproject.org/webm-metadata/temporal-metadata/webvtt-in-webm |
| 16:01 | <ubitux> | seems like webm has another field that can be used for that information |
| 16:02 | <zewt> | i've seen that page before (it's a bit of a mess, hard to separate actual information from brainstorming) |
| 16:03 | <zewt> | yeah that makes up its own vtt-esque format for storing webvtt, which sort of seems like a bad idea |
| 16:04 | <ubitux> | well if the format isn't good you don't have a choice |
| 16:05 | <zewt> | nothing wrong with the format; i just gave a decent way to do it :) |
| 16:06 | <zewt> | (and if you raise it on texttracks others may well have better ideas--or find issues with mine, for that matter) |
| 16:06 | <zewt> | (though if webm's already made up its mind on how to do it, or if they're not paying attention, it won't help) |
| 16:08 | <ubitux> | meh the specs is missing a lot of examples |
| 16:09 | <zewt> | can file bugs if you have specific examples you want: https://www.w3.org/Bugs/Public/ (product: texttracks) |
| 16:09 | <ubitux> | i would like various timing examples :p |
| 16:10 | <ubitux> | i'll read deeply the text, but not me at first glance it doesn't look obvious if "12:23:45.123" is valid |
| 16:10 | <ubitux> | if "13245.12345" is also |
| 16:10 | <ubitux> | or if "12" is as well |
| 16:12 | <zewt> | see http://dev.w3.org/html5/webvtt/#webvtt-timestamp for the timestamp format (what's "valid") and the parser (http://dev.w3.org/html5/webvtt/#collect-a-webvtt-timestamp) for precisely what happens in a particular case |
| 17:48 | <ubitux> | zewt: thanks :) |
| 17:48 | <ubitux> | (sorry for the delay) |
| 17:48 | <ubitux> | and yes i was refering to that part of the spec |
| 17:48 | <ubitux> | still a list of valid examples would be nice |
| 17:54 | <ubitux> | the spec really isn't obvious IMO |
| 18:09 | <jack_tradez> | zewt: i do not use chrome for number of tasks because a number of quirks are not that developer friendly :P |
| 18:18 | <zewt> | heh, context loss is still an open problem for gpu-accelerated 2d canvas? i don't know why, but i thought that was only a problem with webgl |
| 19:23 | <jack_tradez> | I'm not sure. I like the vi style incremental search but it certainly doesn't work like vi ;) |
| 19:24 | <zewt> | vi starts searching where you are, chrome keeps going to the top of the page |
| 22:14 | <Smylers> | For <base href=http://example.com>; without a trailing slash on the URL, getting the href property returns http://example.com/ with the trailing slash in some browsers. |
| 22:15 | <Smylers> | Reading through http://www.whatwg.org/specs/web-apps/current-work/multipage/semantics.html#dom-base-href I can't spot any step which says to add that trailing slash. |
| 22:15 | <Smylers> | Am I missing it? |
| 22:15 | Hixie | looks |
| 22:16 | <Smylers> | Hixie: Thanks. |
| 22:16 | <Smylers> | This page reports that Firefox, Opera, and Safari add the trailing slash, and IE doesn't: http://notes.minty.org/cgi-bin/wiki.pl?Fixing_Base_Href_Javascript_Document.Location_For_Internet_Explorer |
| 22:16 | <Smylers> | I've only personally checked Firefox, which does add it. |
| 22:16 | <Hixie> | the absolute URL returned by the "Resolve" algorithm always includes that leading slash |
| 22:16 | <Hixie> | ("leading" because it's the first one in the path) |
| 22:17 | <Smylers> | Hixie: Thanks. I'll read it again more carefully. |
| 22:17 | <Hixie> | i'm not sure you'll find it |
| 22:17 | <Hixie> | the "resolve" algorithm is currently pointing at a vague RFC |
| 22:17 | <Hixie> | we hope to write a more detailed spec in due course |
| 22:17 | <Hixie> | (i think anne's the one working on that) |
| 22:20 | <Smylers> | Ah. |
| 22:20 | <Smylers> | I read that RFC before asking here. |
| 22:24 | <Smylers> | I read it as at the Parse step the RFC parses hier-part, picking the path-abempty option, which allows the empty string. So <path> is then set, but empty, and that gets copied across through the rest of the algorithm, still being empty at the end. |