| 00:25 | <zewt> | Hixie: ENONBLOCK? |
| 00:26 | <zewt> | er, O_NONBLOCK or whatever |
| 01:41 | <Hixie> | zewt: ENONBLOCK is 0? |
| 01:41 | <zewt> | i mean, if it's a nonblocking fd then writing to it might write a partial amount of data (however much fills in the kernel buffer), and it'll return that amount |
| 01:42 | <zewt> | with tcp, anyway, not udp (and i'm not sure since i normally use write, not send) |
| 01:42 | <Hixie> | right, and set errno te EAGAIN or EWOULDBLOCK |
| 01:42 | <Hixie> | but it set it o 0 |
| 02:09 | <zewt> | errno is only set if there's an error, if it partially writes the buffer then there's no error |
| 02:10 | <Hixie> | send()'s documentation says the error is set to EAGAIN or EWOULDBLOCK in the case that the length returned doesn't equal the length provided. |
| 02:10 | <zewt> | if you get -1 and EAGAIN, that means nothing was written (or read) at all, but partial writes return the number of bytes written, which isn't an error (meaning errno is ENOERR) |
| 02:11 | <Hixie> | well clearly you're right, but imho that's not at all clear in the documentation |
| 02:11 | <zewt> | what documentation? |
| 02:12 | <Hixie> | linux man page |
| 02:12 | <zewt> | very loose documentation, that |
| 02:12 | <zewt> | write(2) is much slower to reality, i think |
| 02:13 | <zewt> | wait, i have different OS's in different shells, hold on |
| 02:14 | <zewt> | write(2) in OSX is closer (slower? i blame the weekend): |
| 02:14 | <zewt> | [EAGAIN] The file is marked for non-blocking I/O, and no data could be written immediately. |
| 02:17 | <Hixie> | well in any case this is a pain because i have to rearchitect my code so that i can check for write-readiness in my select loop and the "write" code is in an object that doesn't have access to the select loop's configuration variables. boo. |
| 02:18 | <Hixie> | (not that this is the most serious of problems, it happened once during an overnight run of continuously sending data) |
| 04:27 | <rcombs> | has anyone considered adding inline SVG to WebVTT? |
| 04:27 | <Hixie> | considered and rejected :-) |
| 04:28 | <rcombs> | aww |
| 04:28 | <rcombs> | too complex? |
| 04:28 | <Hixie> | the first T in WebVTT stands for "Text" |
| 04:28 | <shepazu> | thus, no images in HyperText Markup Language |
| 04:28 | <Hixie> | if you want graphics overlayed on your movie... put them in your movie :-) |
| 04:29 | <rcombs> | hmm |
| 04:29 | <Hixie> | shepazu: i didn't name that one, so the same logic doesn't apply :-) |
| 04:29 | <zewt> | technically, couldn't you put images in background-image: url()? heh |
| 04:29 | <rcombs> | it'd be nice to have an ASS-like standard supported in web for more specific timing on overlays |
| 04:30 | <zewt> | (i suspect no non-browser implementation will actually implement anything but simple background colors, though) |
| 04:30 | <Hixie> | rcombs: if what you're looking for is just a generic vector animation system, SVG itself supports that natively |
| 04:31 | <rcombs> | Hixie: can't embed that in a video |
| 04:31 | <Hixie> | rcombs: ? |
| 04:31 | <rcombs> | e.g. screenshot #2 linked here: https://plexapp.lighthouseapp.com/projects/14382/tickets/1414-transcoder-baking-subtitles-results-in-artifacts-quality-degradation-and-incorrect-placement |
| 04:31 | <rcombs> | the actual bug there is in a very unrelated piece of software |
| 04:32 | <rcombs> | and the screenshot shows an incorrect rendering, but demonstrates my purpose well |
| 04:32 | <zewt> | (with one of the most hated seasons of anime of all time) |
| 04:32 | <rcombs> | the text is precisely positioned over the original in-video text, and a shaped box between the new and old text masking the original out |
| 04:33 | <rcombs> | zewt: yep |
| 04:33 | <rcombs> | zewt: I actually watched all 8 |
| 04:33 | <Hixie> | rcombs: this isn't what WebVTT is for. WebVTT is for subtitles. If you're trying to localise a movie, updating graphics, changing text, etc, then subtitles aren't the right technology. |
| 04:33 | <rcombs> | zewt: there were originally only supposed to be about 3, but they were extended when the animators ran out of material when Disappearance was moved to a movie |
| 04:34 | <zewt> | nothing in webvtt is designed for replacing moving text in-frame |
| 04:34 | <rcombs> | Hixie: WebVTT may be the wrong standard, but I think there should be a right one |
| 04:34 | <rcombs> | at the moment, the best thing we've got is ASS |
| 04:34 | <Hixie> | rcombs: well that's fine, i have no objection to people making other standards for stuff :-) |
| 04:34 | <rcombs> | that may just be the standard to support |
| 04:34 | <zewt> | ssa/ass is not a standard, heh |
| 04:34 | <zewt> | it's an ad hoc file format |
| 04:34 | <rcombs> | zewt: therein lies the problem |
| 04:34 | <Hixie> | rcombs: i would have thought Ogg Theora and WebM were pretty good standards for it myself |
| 04:35 | <Hixie> | rcombs: gives you ultimate control over each pixel |
| 04:35 | <rcombs> | Hixie: do those support overlaying text over video in a precise manner that allows you to make paint edits without encoding, storing, and distributing multiple versions of each video? |
| 04:36 | <Hixie> | rcombs: no, the whole point is what you're doing _should_ involve "encoding, storing, and distributing multiple versions of each video" |
| 04:36 | <Hixie> | rcombs: because what you're doing is creating multiple versions of each video |
| 04:36 | <zewt> | Hixie: it absolutely should not |
| 04:36 | <rcombs> | Hixie: disagreeing there |
| 04:36 | <Hixie> | ok well i have no particular horse in this race, just letting you know what i think is the right answer |
| 04:37 | <rcombs> | Hixie: for a change as small as text replacement, which is done (and done well, most of the time) in ASS, there's no good reason for the "correct answer" to involve making a new version of the entire video |
| 04:37 | <Hixie> | when Pixar made a localised version of Monsters, Inc for the non-US market, they didn't just take Monsters, Inc and overlay it with subtitles |
| 04:37 | <Hixie> | they changed entire parts of the video |
| 04:37 | <rcombs> | that's true |
| 04:37 | <rcombs> | and there are plenty of videos where that is necessary |
| 04:37 | <zewt> | which means people who want to see the original version have to buy two copies, making it a poor solution |
| 04:37 | <rcombs> | but also plenty where it's not |
| 04:38 | <Hixie> | ok well as i said, you guys do as you wish :-) |
| 04:39 | <rcombs> | (I'm also saddened by MKV's lack of a feature that lets you skip a portion of a video if a particular audio track is selected, and one that specifies a particular subtitle track to accompany a particular audio track) |
| 04:39 | <zewt> | subtitle tracks and audio tracks are by definition orthogonal |
| 04:39 | <zewt> | caption tracks and audio tracks are related (same language) |
| 04:39 | <rcombs> | (or allow swapping to another audio and subtitle track for a particular scene) |
| 04:40 | <rcombs> | zewt: e.g. associate a non-original audio track with a signs/songs subtitle track, and an original audio track with a full subtitle track |
| 04:41 | <rcombs> | zewt: or, if multiple full subtitle tracks are present, choose the user's preferred language out of them |
| 04:41 | <rcombs> | (current behavior, that last bit) |
| 04:41 | <zewt> | that's an implementation feature, not a file format issue |
| 04:42 | <rcombs> | I'm not sure what a better channel for this is |
| 04:42 | <rcombs> | zewt: the implementation can choose a track, but if you have multiple English tracks, it has no way of knowing which is a signs/songs and which is a full dialogue |
| 04:42 | <zewt> | never seen a case where that even makes sense to have |
| 04:44 | <rcombs> | zewt: e.g. file with 4 sub tracks (S/S english, D english, D French, D German) and 2 audio tracks (Japanese, English). If English user and English audio, show S/S English by default. If German user, show German by default (same with French). If English user and Japanese audio, show English D by default |
| 04:45 | <zewt> | "S/S" and "D" are not meaningful abbreviations :) |
| 04:45 | <rcombs> | zewt: S/S = signs/songs, D = dialogue; sorry |
| 04:46 | <zewt> | real users listening to english audio who speak english don't want to see captions for signs |
| 04:46 | <rcombs> | zewt: example on skipping/swapping: if English audio, but a portion was never dubbed, either skip that scene or revert to Japanese audio and English full subtitles (no need to double-encode the JP audio or English subtitles for the scene) |
| 04:47 | <zewt> | (well, i expect anything with english audio to be a commercial release, with signs actually translated in-band--which isn't really relevant to mkv, since i've never heard of commercial releases of anything in mkv) |
| 04:47 | <rcombs> | zewt: signs here refers to any original-language text present in the video |
| 04:49 | <zewt> | also bear in mind that not every single possible thing you might want to do in localization can be soft-encoded, and a whole lot of nittier things where trying to do it will just complicate everyone's lives and probably not actually work very well |
| 04:49 | <rcombs> | zewt: commercial releases should be able to include both audio tracks _and_ regular subtitles _and_ provide a way to show translated signs (SSA-style) |
| 04:50 | <rcombs> | zewt: what I'm currently suggesting could be done by making a few additions to the MKV spec (with more specific language than mine) and ASS being properly standardized |
| 04:51 | <rcombs> | there's no good reason why commercial releases shouldn't be able to use any of this |
| 04:51 | <zewt> | but it'll never allow changing everything they want to change, and if it doesn't do everything, they'll probably use it for nothing (if they have to pay the cost of reencoding anyway) |
| 04:51 | <rcombs> | side-note: any idea of a better channel for this? |
| 04:52 | <zewt> | well it's pretty irrelevant for commercial releases, since they'll always use whatever the home media standard is (eg. bluray), and that'll never be mkv |
| 04:52 | <rcombs> | This stopped being web-related quite a while back, and I feel like I'm cluttering the channel now |
| 04:52 | <zewt> | (well, commercial-movies-on-a-disc releases--who knows what'll happen with online delivery, of course, which is more potentially relevant for mkv, webvtt, and so on) |
| 04:52 | <rcombs> | zewt: why can't MKV be used commercially as a home media standard? |
| 04:53 | <rcombs> | zewt: online delivery is becoming very popular, and commercial movies on discs are dying slowly |
| 04:53 | <rcombs> | but dying they are |
| 04:54 | <zewt> | the industry will always favor a single, universally-supported standard, and open formats simply haven't yet dented that space |
| 04:54 | <rcombs> | while they haven't at the present time, I see no reason why they can't |
| 04:54 | <zewt> | maybe they will eventually, but I wouldn't put my money on it any time soon :) |
| 04:56 | <zewt> | (and no, I don't know what channels are relevant to this; it's not something I've sought out) |
| 04:56 | <rcombs> | well, that's about all I've got to say about that |
| 04:56 | rcombs | returns to his regularly-scheduled bug report filing about bad ASS rendering in Plex |
| 04:58 | <zewt> | i filed a bug on libass at one point, and his response was along the lines of "people should fix their files, i don't need to make my software work with real data", so I quickly gave up that line of contribution, heh |
| 04:59 | <rcombs> | <_< |
| 04:59 | <rcombs> | >_> |
| 04:59 | <zewt> | http://code.google.com/p/libass/issues/detail?id=67 heh |
| 05:02 | <rcombs> | zewt: well, I can see the guy's point |
| 05:02 | <zewt> | it's an academic point, with no understanding of the file format, that doesn't lead to reliable software |
| 05:03 | <rcombs> | zewt: it's a bit like keeping bugs in software because people have written around them, and fixing the bugs would break other people's stuff |
| 05:04 | <zewt> | except the other way around, since it's vsfilter that everything works with and libass that tries to be "pure" and doesn't work as a result |
| 05:04 | <rcombs> | zewt: I really wish the original web browsers completely stopped, XHTML-style, when presented with an invalid file |
| 05:04 | <zewt> | i prefer a web that works :) |
| 05:04 | <rcombs> | zewt: because then people would write valid files |
| 05:05 | <rcombs> | but it's too late for that now |
| 05:06 | <zewt> | putting aside other issues (it's pretty author-hostile), as soon as a browser has a bug and lets through an authoring error, it breaks down--now everyone else has to let it through, too |
| 05:06 | <zewt> | (just as in this case, vsfilter tolerates the broken section header, since it doesn't even parse them, which means libass needs to, too) |
| 05:07 | <zewt> | (it also doesn't allow for backwards-compatible format extensions, if older software rejects anything it doesn't already know about) |
| 05:08 | <rcombs> | zewt: anyone who cares about people actually being able to play their videos/view their webpages wouldn't write invalid stuff if it only worked in one browser |
| 05:08 | <zewt> | except real-world Joe Authors often only test in a single UA (whether that's a browser or a media player) |
| 05:09 | <rcombs> | zewt: and it'd be trivial to specify, say, for HTML, that unknown tags are allowed and parsed as <div>s |
| 05:09 | <rcombs> | actually, isn't that how it works now? |
| 05:09 | <rcombs> | (just an example) |
| 05:10 | <rcombs> | regardless, it's too late for any of this to actually happen |
| 05:35 | <zewt> | it's a bit more complicated than that; it's not simply "fatal errors or not", it's "what's an error and what's a warning", which is an analog scale |
| 05:38 | <zewt> | that's less important than making the "warning" cases behave predictably (which HTML tries very hard to do, and in the above case, ASS failed at) |
| 06:03 | <Jay2daM> | hello |