Session Start: Fri Mar 05 15:11:40 2010 Session Ident: #theora [15:11] * Now talking in #theora [15:11] * Topic is 'Theora and related video codec discussions | http://theora.org/ | development branch at http://svn.xiph.org/experimental/derf/theora-ptalarbvorm/' [15:11] * Set by rillian on Tue Feb 09 00:52:00 [15:12] where can I get the lastest and greatest theora encoder in windows binary form? [18:43] edowaconan: probably http://www.xiph.org/dshow/ [18:43] wouldn't have the latest compile though, I don't think [20:11] edogawaconan: http://v2v.cc/~j/ffmpeg2theora/download.html [20:15] This still has the mainline encoder, I believe. [20:18] oggkoggk: presumably dshow does as well [20:18] so does ffmpeg2theora use ptalarbvorm yet [20:20] bemasc_: "probably". [20:20] Daiz: no, unless you compile it yourself with it. [20:20] meh [20:20] which is much less difficult as you might imagine, the API's the same, so no code changes required. [20:22] Yes, but you have to compile ffmpeg. [20:23] Doh. I'd managed to take this all out of my mind :( [20:23] Though there's a get_ffmpeg.sh script, which gets a specific version, so if you're lucky it might work. [20:25] also, is there any specific reason why xiph couldn't just use mkv for video content and leave ogg alone with vorbis [20:26] even for live streaming purposes it shouldn't be that hard to implement mkv usage since index is optional [20:26] and 90% of all video content on the web is progressive download which mkv handles perfectly fine [20:29] as a result you'd get a container actually planned for general media usage [20:29] which quite many would see as a large improvement over the current audio streaming container extended that ogg pretty much is [20:30] Daiz: How is mkv without an index an improvement over Ogg, for Theora video? [20:30] * bemasc_ is now known as bemasc [20:31] well, the way the whole system is build resembles other container structures a lot more than ogg does, and quite many people who have worked with implementing container support seem to say that working with ogg is quite a nightmare compared to how different (and not better) it does things [20:32] Daiz: Ogg really is a container for all kind of media use. We do audio, video, crazy video (dirac), subtitles (kate), etc. [20:32] Daiz: Basically, you mean the ffmpeg people. [20:32] also, why create a new subtitle format? [20:32] where exactly does kate fall in the line between srt and ass? [20:33] or if it aims to be something similar to either why not just use that? [20:34] oggkate is actually a tremendously general, powerful codec for timed images [20:34] oh, timed images. [20:34] oggkoggk can explain more [20:35] Daiz: but "images" here is a very general concept, including text, vector graphics, bitmaps... and also algebraically described animation. [20:35] so basically it's something like an advanced vobsub? [20:35] really. [20:35] so does anything support more than text? [20:35] Not really. In the case of text, the text is represented as text, and the player is free to display that text however it likes [20:36] and are there are any authoring tools for kate? [20:36] so basically as far as it goes now it's like SRT. [20:36] It's also extremely tightly specified [20:37] IIUC SRT is like AVI... it's become an informal standard, with an endless unruly variety of character encodings and other conventions [20:37] but really, back to matroska - you'd have a working and supported index for when it can be used (progressive downloading aka most of the time) [20:38] Kate requires everything to be UTF-8. [20:38] well, personally I don't really like SRT either. [20:38] ASS is where it's at [20:39] You are free to use any of these with Ogg, of course. They're external files, so the video itself can be stored in any container. [20:39] but if I can't mux them into the container itself it's pretty eh [20:39] I like my subtitles internal [20:39] with font attachments [20:39] Kate runs inside Ogg. This is why I'm saying that Ogg is far from an audio-specific container. It's so general that subtitles are just another kind of codec. [20:40] but ogg did start as an audio-specific container [20:40] and has been extended from that [20:40] It was first used for audio. [20:40] whereas matroska was built from ground-up for general usage [20:40] Matroska's design is terrifying to me. [20:41] how so? [20:41] Do you know why it's called Matroska? [20:41] because its sort of an analogue for a container with content inside? [20:41] It's a transliteration of Matryoshka, the nested Russian dolls. [20:41] I know. [20:41] ok [20:42] Matroska is a meta-container. It defines mappings from a bunch of other containers into it. [20:42] www.matroska.org seems to be dead, so I can't get the spec. [20:43] but if you have a .avi, .mov, .mpg, etc. there's a defined mapping into mkv [20:43] http://209.85.129.132/search?q=cache:85uWQ4wlyewJ:www.matroska.org/technical/specs/index.html+http://www.matroska.org/technical/specs/index.html&cd=1&hl=en&ct=clnk&client=firefox-a [20:43] bemasc: actually, vector graphics (SVG) aren't in any released version (unless you count the 'hand drawing' motions ?). Though if I add it, it will not break the bitstream. There are pros and cons to ASS/SSA, and yes, it is rather different indeed. [20:44] bemasc: what do you exactly mean by mapping [20:44] Daiz: This means that a single codec (e.g. mpeg-2) could have five different incompatible mappings in Matroska. [20:44] Daiz: Some people have a funny idea that you can just take media and "put it in a container". [20:44] Matroska maps *containers* into itself ? [20:45] where is this stated in the spec [20:45] Daiz: In order to put a media file into a container (any media file, any container) you need to define a mapping. [20:45] I can't read the spec [20:45] does the cached version not work for you or what [20:45] The google cache won't load for me either. [20:46] google http://www.matroska.org/technical/specs/index.html and click cached [20:46] ok, text-only version worked. [20:47] Daiz: It's not in the core spec. That page just defines mkv, not any of the mappings. [20:48] http://209.85.129.132/search?q=cache:Z7t9wu0kNMQJ:www.matroska.org/technical/specs/codecid/index.html+matroska+mapping&cd=5&hl=en&ct=clnk&client=firefox-a do you mean this [20:48] I don't see anything about other containers in here [20:48] and why the hell are you talking about "putting container into a container" anyway [20:48] that makes no sense [20:48] That's what OGM is, apparently... [20:49] "but ogg did start as an audio-specific container" No, from the beginning it had Vorbis and Tarkin in it. [20:49] (or so I heard). [20:49] the hell is tarkin? [20:49] Tarkin! \o/ [20:49] Tarkin was our first video codec. It was not successful. [20:49] there were two implementations, they might even still be in SVN. [20:50] It used 3d wavelets and the artifacts were.... really special. [20:50] but anyway, bemasc, there's obviously codec mappings [20:50] Daiz: V_QUICKTIME, V_MS/VFW/FOURCC [20:51] I can't really understand that page due to whatever problem their webserver is having [20:51] http://svn.xiph.org/trunk/tarkin/ [20:52] http://svn.xiph.org/trunk/w3d/ [20:52] there they are. [20:52] Daiz: Clearly they do define a lot of codec mappings. My point is that they define multiple redundant mappings [20:52] and how exactly is ogg's mapping any better than matroska's? [20:52] who said it was? [20:52] "Our is in a hundred million web browsers" [20:53] But I don't understand the MKV baiting. [20:53] xiphmont: Try not to feed the troll. [20:53] and matroska in a multiple hundreds of millions of media players [20:53] matroska is in* [20:53] -a [20:53] Fine, so go use it instead. [20:53] I'm a little lost as to the issue. [20:54] but by any account it seems like a better choice for general-purpose compared to ogg [20:54] and it's equally FOSS [20:54] we don't base decisions on 'seems like'. [20:54] okay then, it is. [20:54] but yes, it's equally FOSS AFAACT. [20:54] we disagree. [20:55] then how is ogg better than matroska? [20:55] How is it not? [20:56] got anything specific that isn't hearsay? [20:56] It's true we don't paint racing stripes on ogg. [20:57] lack of proper index, even more clusterfuck of a mapping, completely different from basically every other container for no real benefit [20:57] I think you were already pointed ot the index docs. [20:57] 'clusterfuck' is not a technical rebuttal. [20:57] The following is a draft. It is at best incomplete and at worst completely broken. In any case, it is not an "official" Xiph spec/codec, so use with care. [20:57] in the linked ogg index page. [20:58] It *predates* all the other precious containers you mention, so they're the ones that are different. Except NUT, which is pretty much Ogg with built in metadata. [20:58] so let's change that to lack of working index if you wish [20:58] Daiz: so your complaint is that something does not say "IM GREAT AND PERFECT USE MEEE!" ? :o [20:58] also, theora was created back in 2004 [20:58] It's a draft in final review. You don't want to use it quite yet without coordinating. [20:58] theora has nothign to do witht he Ogg container. Stay focused. [20:59] Daiz: Ogg was (and still is) designed for use cases where the index isn't applicable. Truncate an mkv (e.g. from saving part of an infinite stream) and you can't seek in it. [20:59] no, but at that point you guys started to take video seriously in xiph again [20:59] all Oggs are seekable, period. [20:59] and at that point, matroska was already out [20:59] as well as every other container [20:59] no, early matroska was. it has changed and been extended since. [20:59] For everything _except_ seeking over a high latency network, the lack of an index in an asset, not a weakness, because it means that all the files are seekable. [20:59] Nut was not. [20:59] Daiz: Please do not tell us what our history is. [20:59] You are wrong. [21:00] "Ogg was (and still is) designed for use cases where the index isn't applicable." << aka actual streaming [21:00] WHICH 90% OF INTERNET VIDEO IS NOT [21:00] now you're making shit up. [21:00] really now. [21:00] Go talk to Mozilla eh. or even google. [21:00] basically all video on the internet is progressive download [21:00] it's just called "streaming" for the sake of convenience [21:01] even though it has nothing to do with actual streaming [21:01] progressive download is streaming faster than realtime. [21:01] progressive download can seek and play immediately. [21:01] ==streaming. [21:01] Seeking works fine over the internet without one, even given the bugs in firefox network layer regarding doing it sanely. It doesn't work fine from australia. [21:04] are you seriously saying that lack of index is a good thing in this day and age [21:04] not *requriring* an index is a good thing in this day and age. [21:05] "demux: Can't see in raw AVI. Try -idx." [21:05] matroska doesn't require an index either [21:05] it's optional [21:05] wait... are you seriously saying that lack of index is a good thing in this day and age? [21:06] no, I just said that matroska fits your criteria for a container for that part then [21:06] right. Where did I say I didn't like Matroska? [21:06] well, you said you like ogg more [21:07] Black, meet white. [21:07] then you say it's because of something that's true for matroska as well [21:07] Overall, for most uses, yes I do. Specifically, the uses we're most concerned with. If you want to 'back up' a DVD, you're going to be happier with Matroska is my bet. [21:07] Daiz: what tool can seek in a mkv without an index without being told to read the whole file and build one, if it's optional? [21:08] the ZOMG TOORRENT crowd uses matroska for a reason. You don't see me in their channels telling them they're idiots. [21:08] T'aint nothing wrong with MKV. It's just something that does some differen't things than Ogg. [21:09] btw... why is the main Matroska site down? Is it coming back? [21:09] gmaxwell, I don't know, let me look into that if there's anything [21:09] but is there a tool that can read ogg indexes? [21:10] Daiz: Only patches to stuff currently. But without being able to read them you can still seek. And you can seek without reading the entire file. [21:10] Daiz: OggIndex does, if you're interested in hacking on them. [21:10] An Ogg index has one use really: seeking where roundtrips are an issue, eg, an Apache without an ogg-aware module serving media. [21:10] ffmpeg2theora also writes them. [21:11] (The index stuff is only a few months old, and was specifically created because seeking was somewhat slow across high latency networks) [21:11] could be that there aren't any matroska implementations that have cared about no-index scenarios since no-one has deemed it necessary so far [21:11] On a local filesystem? You have sample/frame accurate seeking under 50ms for up to about 50TB. [21:11] Daiz: same can be said of Ogg. [21:12] Indexes are such an incredible fatally missing feature that no one has cared enough to write them. Now that we're scrubbing using raw HTTP ranges and seek times are up to about 300ms, people have seen fit to implement an optional index. [21:12] Daiz: Mplayer can be told to build one. But then the tool has to read the whole file. [21:13] hm [21:14] let's see [21:14] I'll do some tests with indexless matroska files [21:14] This is a _design difference_ it doesn't make one format bad and one good. It's just a difference. It means that Ogg does a couple of things a little better, and the consessions needed to achieve that make ogg do some other things somewhat worse. [21:15] And honesly, gawd, the mkv/nut/mp4 fanbois are just as bad as ours. [21:15] At the end of the day, it's just a container. They're all 99.9% the same. (Except AVI, that one blows). [21:15] LOL! [21:16] hm [21:16] How many people in the Slashdot comments managed to essentially recreate AVI yesterday? 3? [21:16] It was a few. [21:16] well, my short test with indexless matroska shows that 1) file opens instantly, so I doubt it scans the entire file to create an index 2) seeking is miniscularly slower than normally [21:16] I mean really, if you've got nothing better to do than to worry about the internal details of ogg vs whatever. You need a life even more than _I_ do. :) [21:17] Daiz: strace it. it reads the whole file. [21:17] (or test on a file bigger than your ram by a good multiple) [21:17] gmaxwell: I recommend having kids as a way of never getting anything done ever again. [21:17] okay then, just a moment [21:17] as I slap some encodes together [21:21] also, anything similar to strace for windows? [21:21] Yes... but I don't know what its called! Sorry. :( [21:22] hold on, let me fire up a VM... [21:22] KVM really needs a better virtual disk system. [21:22] 5.91 GB file large enough? [21:22] I have 4GB of RAM [21:23] I suspect strace is the right way to answer the question, but... [21:23] the wrong but amusing way would be NFS :-) [21:23] Or just reading the source code. [21:23] hm [21:23] Which I'd offer to do and point out the behavior, but I've got to run. [21:24] Cygwin has strace... not sure if that actually helps you. [21:24] guess I'll just follow the memory usage :\ [21:24] Hm, I'd have thought it would just scan it. [21:25] the 'bigger than memory' is not because it's loading it all into mem, it's because it would be sitting in buffercache making scanning the whole thing seem instant. [21:25] ...what are you testing specifically? mplayer? [21:25] Right. I'm not expecting it to load it all into memory. [21:25] MPC-HC [21:25] well, if it's a freshly muxed mkv [21:26] I doubt it'd be sitting ready in buffer [21:26] I'm expecting it to read through the whole file without loading it into memory. Which would produce a lot of disk IO or network IO unless it were in your disk cache. [21:26] Daiz: if its freshly written then it should be in your disk cache for sure! :) [21:26] well, luckily I can trace that [21:26] Surely it's more likely to be in buffer if it was just created... [21:26] disk I/O that is [21:27] Only if your tracing tool covers cached writes. (Iostat in linux does not, only ones that actually hit the media) [21:28] * gmaxwell bbl [21:28] Corrupt the data at 50%, then load, play, and seek at 80% ? [21:28] Not that it really matters anyway. [21:28] guess I could try that too [21:28] or... put that bad boy up somewhere and try to stream it :-) [21:29] "progressive download" it :) [21:29] Progressive download, xiphmont. [21:29] [anyway, I fear I will have to leave you witht hat task too... insufficient Win experience to help] [21:29] How would I go about doing a numerological comparison of Ogg and Matroska? [21:29] Also, xiphmont, please send me a plaster cast of your skull. [21:29] Wumboot: Checksums on source code! [21:29] grep 666 [21:30] Ell, Ogg is ascii 79 103 103, add them together... [21:30] OK, I'm going to shut downt he Windows VM before it gets rooted. [21:30] I'd really like a system based in prime factors. [21:30] I like prime factors, for some reason. [21:31] I like ice cream. [21:31] I like the prime factors of ice cream. [21:31] Screw prime factors. Chinese Remainder Theorem. [21:31] BUT HATE OOG! NNGGGHHH! [21:31] Would it be alright if we just put Ogg into Matroska ? [21:31] Then it'd seek with an index, [21:31] Like how it's put into AVI? [21:31] oggkoggk: Only if you mean OGM. [21:32] I was kinda wondering how they were getthing Vorbis and Theora in in the typical case actually. [21:32] Hey, we could put Ogg into AVI into OGM into MKV. [21:32] oooh, I can't type. [21:32] If we then put Ogg-in-Matroska into AVI, then we gain automatic compatibility with every tool around! [21:32] OK, a little less mocking and a little more working. [21:32] But the mocking is the fun part. [21:32] hm [21:32] Speaking of AVI... why is it acceptable for that to be the default format for mplayer? Aren't mplayer team condemning us all to burn in hell by making us use it? [21:32] interesting [21:32] For a short while. [21:32] the first time I seeked in the file with no index [21:33] Wumboot: Historical reasons. [21:33] it took like 10 seconds or longer to buffer [21:33] after that any further seeking is fast [21:33] so it built the index on demand. [21:33] apparently. [21:33] (like mplayer does) [21:33] (but only with -idx) [21:33] (whereas with Ogg you don't have to build an index at all) [21:33] yes, yes, we already drove that point home. [21:34] (but you can if you really want, I suppose) [21:34] The problem with Matroska is that I can't find an RFC for it, so I can't figure out when its birthday is. [21:34] though when it comes to live streaming [21:34] Like I said, the OggIndex is not for local storage. [21:34] there's no reason why you couldn't just in on the stream without building an index, no? [21:34] It's for scrubbing streams over links with latency. [21:34] just jump in* [21:34] Sounds odd to build on demand if you're not going to save it. You pay the linear scan anyway, and if you're on a slow link (like HTTP in .au), you pay through the nose anyway. [21:34] Wumboot: The important thing to remember is that despite how much the mplayer folks complain about other people's technical design, their software is still terrible. [21:34] Daiz: for Ogg, yes in fact [21:35] I highly doubt it would be any more complex than that for matroska [21:35] Daiz: Sure. The interesting thing about Ogg is that you can save that live stream directly to disk, and when you're done you have a 100% functional local file. [21:35] MPC-HC probably builds an index on demand because I'm playing local files [21:35] and that's what it expects [21:35] Daiz: part of the whole index craze is to get very fast *precise* seeking, although precise seeking is almost never needed. You can capture an Ogg stream at any point. [21:35] well, surely you could the same to a matroska stream? [21:35] in fact I see no reason why you couldn't [21:36] then afterwards you'd also have a perfectly working matroska file. [21:36] with no index, and taking 10 seconds to scan [21:36] for the first seek [21:36] derf: "terrible" is a hopeless attempt at describing it. Have you ever looked at their AVI code? [21:36] well, try chopping chunks out and see what happens. [21:36] Wumboot: Fortunately, no. [21:36] and it'd be instantaneous as in my earlier test for files that are not 6 GB in size [21:36] Daiz: If your disk is that fast, you don't need an index. [21:37] (and everyone's disk is that fast) [21:37] or nearly instataneous for the first seek anyway [21:37] Well, before you do so you should probably spend a lot of time learning a lot of different natural languages in the hope that you'll eventually have the verbal capacity to express your horror more adequately. [21:37] instantaneous* [21:37] you're arguing past each other again. [21:37] well, it's still nicer to have an index, if even for that first seek [21:37] Wumboot: I figure I'd be better off just stabbing myself in the face a few times. [21:37] I'm pretty sure English falls well short. I think any other one language would too. You're going to have to make some kind of hybrid word out of lots of languages. [21:37] but well, test result is, indexless matroska files work and seek just fine [21:37] and you could stream, jump in, and save stream just fine as well [21:38] and if you want to add a permanent index to the saved file, just remux it [21:38] Great, use it then :) [21:38] Daiz: you're not describing an improvement. You're describing a workaround. [21:38] I have to admit. I did do a shitty job of the ogg handler that we use here. I was constrained to using less than 64kB of memory, though. [21:39] how is it a workaround? [21:39] matroska files work without index just like ogg files do [21:39] (less tahn 14kB, in fact -- but at 64kB everything would have flowed very easily) [21:39] Ogg doesn't have that 10s first seek. And it doesn't have to remux to avoid it. [21:39] Daiz: you just said it was creating an index by itself... [21:39] Wumboot: One thing that came up reviewing the new Java decoders... if you do MC into the correct place in the destination frame (instead of into a local stack buffer), then if the DCT residual happens to be zero, you can skip the adding step entirely. [21:40] And a player that doesn't implement indexes is scrod. [21:40] well, that's more of the splitter/whatever behavior [21:40] Nevertheless, not an improvement over what we already have. [21:40] Odd muscle memory effect. I felt a typo and started cursoring back to correct it, but I had lag of something approaching a minute, and by the time I could see what I'd typed I'd forgotten why I had been cursoring back. [21:40] but does the ogg offering in this aspect really beat it? [21:40] beat what? [21:41] Parse error. [21:41] beat what for what use case? and why is this a competition? [21:41] well, my test was rather just about the no-index usage of matroska and how it works [21:41] In this case, yes the Ogg offering just beat it. [21:42] also do note that this 10sec first seek was again on a 6GB file [21:42] Specifically, current Ogg implementations beat current Matroska implementations [21:42] Wumboot: May not help your 4x DCT case much, but it would certainly help libtheora. [21:42] I don't have a single Ogg file with an index here and they all seek instantly. [21:42] Daiz: Both Ogg and Matroska players could presumably be updated to gain each other's behavior if they so desired. [21:42] And I wrote the muxing, so I know it's not scanning the whole file. [21:42] derf: Is residual often zero? [21:43] how big are the biggest files? [21:43] Wumboot: Depending on the bitrate, quite often. [21:43] So Ogg players could scan the file to produce an index if anyone cared, and MKV players could probably implement the binary search if someone figured out how to do it. [21:43] 20-sh GB. and a few near-raw files much larger. [21:43] bemasc: not on all containers. Not all containers can capture. [21:43] also, there's also the factor that I used H.264 as the video codec [21:43] Theora doesn't have a way to encode "apply MC, but no residual" other than explicitly coding a zero residual. [21:43] Daiz: and? [21:43] And many that can 'capture', the capture is heuristic. [21:43] I wonder how this test would change if I had a 6GB Theora&Vorbis in MKV... [21:44] or if it would change at all [21:44] I can hardly imagine why it would be different. [21:44] Wumboot: Which is fairly cheap, so not that big a deal, but not being taken advantage of by the decoder. [21:44] I can, but I don't know. [21:44] Daiz: take a step back: either you pay whatever size the index is, or you pay whatever amount of time a player spends building the index in memory. That can't be an improvement, can it ? Either way, you pay. With Ogg, you only have to pay the index size if you're going to serve over a slow roundtrip link. [21:44] well obviously decoding speeds also affect seeking speeds? [21:44] And I don't really care. I still haven't seen a practical benefit demonstrated to abandoning our entire sourcebase. [21:45] Daiz: no. [21:45] I guess it'll be highlighted by an EOB run in the DC list. [21:45] Daiz: you seek to a keyframe. Period, done. [21:45] Wumboot: Not necessarily. DC prediction can screw that up. [21:45] how about I seek into a b-frame? [21:45] nothing decodes anything until that process is finished. [21:45] Daiz: can you? [21:46] Most systems won't actually let you do that. [21:46] well with "jump to frame" in MPC-HC I can definitely land on a b-frame if I wish so [21:46] [though the ogg ones do, and our own frameworks seek to the preceeding keyframe then decode forward. That's unusual.] [21:47] unusual? really? most proper software players do that as well with anything [21:47] do you actually get the b-frame or the preceeding/following I-frame (don't know, not an MPC user. I wouldn't be shocked if they implemented the feature.) [21:47] or well, with H.264 MKVs anyway [21:47] I get the actual b-frame [21:48] ok, good. So just seek to a keyframe to test the seek time :-) [21:48] okay then, that changes my test methology of "click around in the seekbar" a bit [21:49] well, if it's instant for small files and really long for big files, that's still a result. [21:49] It struck me, the other day, that the continuation bit might have been a good way to signal non-keyframes; since it's possible to make it fail to match the end of the previous page. It doesn't really represent a loss of information because it's still true that you can't use the data in that page without information from earlier pages anyway. [21:49] heh, you think there's wailing and gnashing of teeth now? :-) [21:50] But that actually violates Ogg design spec. [21:50] Oh, I'll violate anything, I will. [21:50] uhhh huh. [21:50] Too late to change it anyway, but out of curoosity, what would have been the violation? [21:51] there are specirfic things in the design that the mux layer is allowed to ask the codec; if it's a discontinuous stream and how to parse granpos. [21:51] At the time the decision would have mattered, I think it would simply have been a matter of changing an existing definition in a way that didn't affect anything that had used it in the past. [21:52] there's not actually any intuitedinformation, it's all explicit. [21:52] Even if I add whitespace, I can't make much sense of the word intuitedinformation. [21:53] well looks like it'll build the index no matter what [21:53] in MPC-HC [21:53] even if there's already an index? [21:53] well no [21:53] only on non-indexed files [21:53] ok [21:53] on indexed files it's instant [21:53] seeking to a keyframe, that is [21:54] Wumboot: Oh, retconning is possible. But a retcon would be needed. [21:54] hm [21:54] though I highly doubt this would be the only way to deal with non-indexed matroskas [21:55] guess I'll need some help if I want to test no-index-creating seeking on a no-index matroska [21:55] but... you'd be blurring the line between codec and mux to do it another way! ;-) [21:55] what [21:55] I'm being silly. [21:55] A different argument, unrelated tot he one you're making. [21:55] "in joke" [21:55] I might have changed my mind. If a page ends with a frame that is a multiple of 255 bytes, could it be forced into a position of having to bump the trailing 0 into the next page, but the continuation bit obviates that zero? [21:56] yes [21:56] --no-clusters-in-meta-seek [21:56] Tells mkvmerge(1) not to create a meta seek element at the end of the file containing all clusters. [21:56] er [21:56] hmmm [21:56] I misinterpreted 'obviates' [21:56] I wonder if this has anything to the subject [21:56] time to test! [21:58] By clearing the 'this is extends the previous packet' bit, it removes the necessity to terminate that packet with a zero. [21:58] Or is that false? [21:58] Wumboot: from spec: Note that a packet can span an arbitrary number of pages; the above spanning process is repeated for each spanned page boundary. Also a 'zero termination' on a packet size that is an even multiple of 255 must appear even if the lacing value appears in the next page as a zero-length continuation of the current packet. The header flag should be set to 0x01 to indicate that the packet spanned, even though the span [21:58] is a nil case as far as data is concerned." [21:59] Ahh. [22:00] by definition could you say that a single page contains X ms of video/audio/whatever data or am I misunderstanding the definition of a page in ogg completely? [22:01] no. the pages don't really 'contain' packets; they're more like mileposts driven into the ground at the side of the road. [22:01]