Here be some log of flamefest discussion wrt mkv vs ogg

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 | | development branch at'
[15:11] * Set by rillian on Tue Feb 09 00:52:00
[15:12] <edogawaconan> where can I get the lastest and greatest theora encoder in windows binary form?
[18:43] <nessy> edowaconan: probably
[18:43] <nessy> wouldn't have the latest compile though, I don't think
[20:11] <bemasc_> edogawaconan:
[20:15] <oggkoggk> This still has the mainline encoder, I believe.
[20:18] <bemasc_> oggkoggk: presumably dshow does as well
[20:18] <Daiz> so does ffmpeg2theora use ptalarbvorm yet
[20:20] <oggkoggk> bemasc_: "probably".
[20:20] <oggkoggk> Daiz: no, unless you compile it yourself with it.
[20:20] <Daiz> meh
[20:20] <oggkoggk> which is much less difficult as you might imagine, the API's the same, so no code changes required.
[20:22] <derf> Yes, but you have to compile ffmpeg.
[20:23] <oggkoggk> Doh. I'd managed to take this all out of my mind :(
[20:23] <oggkoggk> Though there's a script, which gets a specific version, so if you're lucky it might work.
[20:25] <Daiz> also, is there any specific reason why xiph couldn't just use mkv for video content and leave ogg alone with vorbis
[20:26] <Daiz> even for live streaming purposes it shouldn't be that hard to implement mkv usage since index is optional
[20:26] <Daiz> and 90% of all video content on the web is progressive download which mkv handles perfectly fine
[20:29] <Daiz> as a result you'd get a container actually planned for general media usage
[20:29] <Daiz> which quite many would see as a large improvement over the current audio streaming container extended that ogg pretty much is
[20:30] <bemasc_> Daiz: How is mkv without an index an improvement over Ogg, for Theora video?
[20:30] * bemasc_ is now known as bemasc
[20:31] <Daiz> 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] <bemasc> Daiz: Ogg really is a container for all kind of media use.  We do audio, video, crazy video (dirac), subtitles (kate), etc.
[20:32] <bemasc> Daiz: Basically, you mean the ffmpeg people.
[20:32] <Daiz> also, why create a new subtitle format?
[20:32] <Daiz> where exactly does kate fall in the line between srt and ass?
[20:33] <Daiz> or if it aims to be something similar to either why not just use that?
[20:34] <bemasc> oggkate is actually a tremendously general, powerful codec for timed images
[20:34] <Daiz> oh, timed images.
[20:34] <bemasc> oggkoggk can explain more
[20:35] <bemasc> Daiz: but "images" here is a very general concept, including text, vector graphics, bitmaps... and also algebraically described animation.
[20:35] <Daiz> so basically it's something like an advanced vobsub?
[20:35] <Daiz> really.
[20:35] <Daiz> so does anything support more than text?
[20:35] <bemasc> 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] <Daiz> and are there are any authoring tools for kate?
[20:36] <Daiz> so basically as far as it goes now it's like SRT.
[20:36] <bemasc> It's also extremely tightly specified
[20:37] <bemasc> IIUC SRT is like AVI... it's become an informal standard, with an endless unruly variety of character encodings and other conventions
[20:37] <Daiz> 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] <bemasc> Kate requires everything to be UTF-8.
[20:38] <Daiz> well, personally I don't really like SRT either.
[20:38] <Daiz> ASS is where it's at
[20:39] <bemasc> 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] <Daiz> but if I can't mux them into the container itself it's pretty eh
[20:39] <Daiz> I like my subtitles internal
[20:39] <Daiz> with font attachments
[20:39] <bemasc> 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] <Daiz> but ogg did start as an audio-specific container
[20:40] <Daiz> and has been extended from that
[20:40] <bemasc> It was first used for audio.
[20:40] <Daiz> whereas matroska was built from ground-up for general usage
[20:40] <bemasc> Matroska's design is terrifying to me.
[20:41] <Daiz> how so?
[20:41] <bemasc> Do you know why it's called Matroska?
[20:41] <Daiz> because its sort of an analogue for a container with content inside?
[20:41] <bemasc> It's a transliteration of Matryoshka, the nested Russian dolls.
[20:41] <Daiz> I know.
[20:41] <bemasc> ok
[20:42] <bemasc> Matroska is a meta-container.  It defines mappings from a bunch of other containers into it.
[20:42] <bemasc> seems to be dead, so I can't get the spec.
[20:43] <bemasc> but if you have a .avi, .mov, .mpg, etc. there's a defined mapping into mkv
[20:43] <Daiz>
[20:43] <oggkoggk> 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] <Daiz> bemasc: what do you exactly mean by mapping
[20:44] <bemasc> Daiz: This means that a single codec (e.g. mpeg-2) could have five different incompatible mappings in Matroska.
[20:44] <bemasc> Daiz: Some people have a funny idea that you can just take media and "put it in a container".
[20:44] <oggkoggk> Matroska maps *containers* into itself ?
[20:45] <Daiz> where is this stated in the spec
[20:45] <bemasc> Daiz: In order to put a media file into a container (any media file, any container) you need to define a mapping.
[20:45] <bemasc> I can't read the spec
[20:45] <Daiz> does the cached version not work for you or what
[20:45] <bemasc> The google cache won't load for me either.
[20:46] <Daiz> google and click cached
[20:46] <bemasc> ok, text-only version worked.
[20:47] <bemasc> Daiz: It's not in the core spec.  That page just defines mkv, not any of the mappings.
[20:48] <Daiz> do you mean this
[20:48] <Daiz> I don't see anything about other containers in here
[20:48] <Daiz> and why the hell are you talking about "putting container into a container" anyway
[20:48] <Daiz> that makes no sense
[20:48] <oggkoggk> That's what OGM is, apparently...
[20:49] <xiphmont> "but ogg did start as an audio-specific container"  No, from the beginning it had Vorbis and Tarkin in it.
[20:49] <oggkoggk> (or so I heard).
[20:49] <Daiz> the hell is tarkin?
[20:49] <oggkoggk> Tarkin! \o/
[20:49] <xiphmont> Tarkin was our first video codec.  It was not successful.
[20:49] <xiphmont> there were two implementations, they might even still be in SVN.
[20:50] <xiphmont> It used 3d wavelets and the artifacts were.... really special.
[20:50] <Daiz> but anyway, bemasc, there's obviously codec mappings
[20:50] <bemasc> Daiz: V_QUICKTIME, V_MS/VFW/FOURCC
[20:51] <bemasc> I can't really understand that page due to whatever problem their webserver is having
[20:51] <xiphmont>
[20:52] <xiphmont>
[20:52] <xiphmont> there they are.
[20:52] <bemasc> Daiz: Clearly they do define a lot of codec mappings.  My point is that they define multiple redundant mappings
[20:52] <Daiz> and how exactly is ogg's mapping any better than matroska's?
[20:52] <xiphmont> who said it was?
[20:52] <xiphmont> "Our is in a hundred million web browsers"
[20:53] <xiphmont> But I don't understand the MKV baiting.
[20:53] <derf> xiphmont: Try not to feed the troll.
[20:53] <Daiz> and matroska in a multiple hundreds of millions of media players
[20:53] <Daiz> matroska is in*
[20:53] <Daiz> -a
[20:53] <xiphmont> Fine, so go use it instead. 
[20:53] <xiphmont> I'm a little lost as to the issue.
[20:54] <Daiz> but by any account it seems like a better choice for general-purpose compared to ogg
[20:54] <Daiz> and it's equally FOSS
[20:54] <xiphmont> we don't base decisions on 'seems like'.
[20:54] <Daiz> okay then, it is.
[20:54] <xiphmont> but yes, it's equally FOSS AFAACT.
[20:54] <xiphmont> we disagree.
[20:55] <Daiz> then how is ogg better than matroska?
[20:55] <xiphmont> How is it not?
[20:56] <xiphmont> got anything specific that isn't hearsay?
[20:56] <xiphmont> It's true we don't paint racing stripes on ogg.
[20:57] <Daiz> lack of proper index, even more clusterfuck of a mapping, completely different from basically every other container for no real benefit
[20:57] <xiphmont> I think you were already pointed ot the index docs.
[20:57] <xiphmont> 'clusterfuck' is not a technical rebuttal.
[20:57] <Daiz> 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] <Daiz> in the linked ogg index page.
[20:58] <xiphmont> 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] <Daiz> so let's change that to lack of working index if you wish
[20:58] <oggkoggk> Daiz: so your complaint is that something does not say "IM GREAT AND PERFECT USE MEEE!" ? :o
[20:58] <Daiz> also, theora was created back in 2004
[20:58] <xiphmont> It's a draft in final review.  You don't want to use it quite yet without coordinating.
[20:58] <xiphmont> theora has nothign to do witht he Ogg container.  Stay focused.
[20:59] <gmaxwell> 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] <Daiz> no, but at that point you guys started to take video seriously in xiph again
[20:59] <xiphmont> all Oggs are seekable, period.
[20:59] <Daiz> and at that point, matroska was already out
[20:59] <Daiz> as well as every other container
[20:59] <xiphmont> no, early matroska was.  it has changed and been extended since.
[20:59] <gmaxwell> 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] <xiphmont> Nut was not.
[20:59] <derf> Daiz: Please do not tell us what our history is.
[20:59] <derf> You are wrong.
[21:00] <Daiz> "Ogg was (and still is) designed for use cases where the index isn't applicable." << aka actual streaming
[21:00] <xiphmont> now you're making shit up.
[21:00] <Daiz> really now.
[21:00] <xiphmont> Go talk to Mozilla eh.  or even google.
[21:00] <Daiz> basically all video on the internet is progressive download
[21:00] <Daiz> it's just called "streaming" for the sake of convenience
[21:01] <Daiz> even though it has nothing to do with actual streaming
[21:01] <xiphmont> progressive download is streaming faster than realtime.
[21:01] <xiphmont> progressive download can seek and play immediately.
[21:01] <xiphmont> ==streaming.
[21:01] <gmaxwell> 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] <Daiz> are you seriously saying that lack of index is a good thing in this day and age
[21:04] <xiphmont> not *requriring* an index is a good thing in this day and age.
[21:05] <xiphmont> "demux: Can't see in raw AVI.  Try -idx."
[21:05] <Daiz> matroska doesn't require an index either
[21:05] <Daiz> it's optional
[21:05] <xiphmont> wait... are you seriously saying that lack of index is a good thing in this day and age?
[21:06] <Daiz> no, I just said that matroska fits your criteria for a container for that part then
[21:06] <xiphmont> right.  Where did I say I didn't like Matroska?
[21:06] <Daiz> well, you said you like ogg more
[21:07] <oggkoggk> Black, meet white.
[21:07] <Daiz> then you say it's because of something that's true for matroska as well
[21:07] <xiphmont> 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] <gmaxwell> 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] <xiphmont> the ZOMG TOORRENT crowd uses matroska for a reason.  You don't see me in their channels telling them they're idiots.
[21:08] <gmaxwell> T'aint nothing wrong with MKV. It's just something that does some differen't things than Ogg. 
[21:09] <xiphmont> btw... why is the main Matroska site down?  Is it coming back?
[21:09] <Daiz> gmaxwell, I don't know, let me look into that if there's anything
[21:09] <Daiz> but is there a tool that can read ogg indexes?
[21:10] <gmaxwell> 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] <oggkoggk> Daiz: OggIndex does, if you're interested in hacking on them.
[21:10] <xiphmont> 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] <oggkoggk> ffmpeg2theora also writes them.
[21:11] <gmaxwell> (The index stuff is only a few months old, and was specifically created because seeking was somewhat slow across high latency networks) 
[21:11] <Daiz> 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] <xiphmont> On a local filesystem?  You have sample/frame accurate seeking under 50ms for up to about 50TB.
[21:11] <xiphmont> Daiz: same can be said of Ogg.
[21:12] <xiphmont> 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] <gmaxwell> Daiz: Mplayer can be told to build one. But then the tool has to read the whole file. 
[21:13] <Daiz> hm
[21:14] <Daiz> let's see
[21:14] <Daiz> I'll do some tests with indexless matroska files
[21:14] <gmaxwell> 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] <xiphmont> And honesly, gawd, the mkv/nut/mp4 fanbois are just as bad as ours.
[21:15] <gmaxwell> 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] <xiphmont> LOL!
[21:16] <Daiz> hm
[21:16] <xiphmont> How many people in the Slashdot comments managed to essentially recreate AVI yesterday?  3?
[21:16] <xiphmont> It was a few.
[21:16] <Daiz> 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] <gmaxwell> 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] <gmaxwell> Daiz: strace it. it reads the whole file. 
[21:17] <gmaxwell> (or test on a file bigger than your ram by a good multiple)
[21:17] <xiphmont> gmaxwell: I recommend having kids as a way of never getting anything done ever again.
[21:17] <Daiz> okay then, just a moment
[21:17] <Daiz> as I slap some encodes together
[21:21] <Daiz> also, anything similar to strace for windows?
[21:21] <gmaxwell> Yes... but I don't know what its called! Sorry. :(
[21:22] <xiphmont> hold on, let me fire up a VM...
[21:22] <xiphmont> KVM really needs a better virtual disk system.
[21:22] <Daiz> 5.91 GB file large enough?
[21:22] <Daiz> I have 4GB of RAM
[21:23] <xiphmont> I suspect strace is the right way to answer the question, but...
[21:23] <xiphmont> the wrong but amusing way would be NFS :-)
[21:23] <gmaxwell> Or just reading the source code. 
[21:23] <Daiz> hm
[21:23] <gmaxwell> Which I'd offer to do and point out the behavior, but I've got to run. 
[21:24] <xiphmont> Cygwin has strace... not sure if that actually helps you.
[21:24] <Daiz> guess I'll just follow the memory usage :\
[21:24] <xiphmont> Hm, I'd have thought it would just scan it.
[21:25] <xiphmont> 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] <xiphmont> ...what are you testing specifically?  mplayer?
[21:25] <gmaxwell> Right. I'm not expecting it to load it all into memory. 
[21:25] <Daiz> MPC-HC
[21:25] <Daiz> well, if it's a freshly muxed mkv
[21:26] <Daiz> I doubt it'd be sitting ready in buffer
[21:26] <gmaxwell> 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] <gmaxwell> Daiz: if its freshly written then it should be in your disk cache for sure! :)
[21:26] <Daiz> well, luckily I can trace that
[21:26] <oggkoggk> Surely it's more likely to be in buffer if it was just created...
[21:26] <Daiz> disk I/O that is
[21:27] <gmaxwell> 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] <oggkoggk> Corrupt the data at 50%, then load, play, and seek at 80% ?
[21:28] <oggkoggk> Not that it really matters anyway.
[21:28] <Daiz> guess I could try that too
[21:28] <xiphmont> or... put that bad boy up somewhere and try to stream it :-)
[21:29] <bemasc> "progressive download" it :)
[21:29] <oggkoggk> Progressive download, xiphmont.
[21:29] <xiphmont> [anyway, I fear I will have to leave you witht hat task too... insufficient Win experience to help]
[21:29] <Wumboot> How would I go about doing a numerological comparison of Ogg and Matroska?
[21:29] <Wumboot> Also, xiphmont, please send me a plaster cast of your skull.
[21:29] <derf> Wumboot: Checksums on source code!
[21:29] <oggkoggk> grep 666
[21:30] <xiphmont> Ell, Ogg is ascii 79 103 103, add them together...
[21:30] <xiphmont> OK, I'm going to shut downt he Windows VM before it gets rooted.
[21:30] <Wumboot> I'd really like a system based in prime factors.
[21:30] <Wumboot> I like prime factors, for some reason.
[21:31] <xiphmont> I like ice cream.
[21:31] <Wumboot> I like the prime factors of ice cream.
[21:31] <derf> Screw prime factors. Chinese Remainder Theorem.
[21:31] <xiphmont> BUT HATE OOG!  NNGGGHHH!
[21:31] <oggkoggk> Would it be alright if we just put Ogg into Matroska ?
[21:31] <oggkoggk> Then it'd seek with an index,
[21:31] <Wumboot> Like how it's put into AVI?
[21:31] <derf> oggkoggk: Only if you mean OGM.
[21:32] <xiphmont> I was kinda wondering how they were getthing Vorbis and Theora in in the typical case actually.
[21:32] <derf> Hey, we could put Ogg into AVI into OGM into MKV.
[21:32] <xiphmont> oooh, I can't type.
[21:32] <oggkoggk> If we then put Ogg-in-Matroska into AVI, then we gain automatic compatibility with every tool around!
[21:32] <xiphmont> OK, a little less mocking and a little more working.
[21:32] <derf> But the mocking is the fun part.
[21:32] <Daiz> hm
[21:32] <Wumboot> 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] <Daiz> interesting
[21:32] <oggkoggk> For a short while.
[21:32] <Daiz> the first time I seeked in the file with no index
[21:33] <derf> Wumboot: Historical reasons.
[21:33] <Daiz> it took like 10 seconds or longer to buffer
[21:33] <Daiz> after that any further seeking is fast 
[21:33] <xiphmont> so it built the index on demand.
[21:33] <Daiz> apparently.
[21:33] <xiphmont> (like mplayer does)
[21:33] <xiphmont> (but only with -idx)
[21:33] <bemasc> (whereas with Ogg you don't have to build an index at all)
[21:33] <xiphmont> yes, yes, we already drove that point home.
[21:34] <bemasc> (but you can if you really want, I suppose)
[21:34] <Wumboot> 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] <Daiz> though when it comes to live streaming
[21:34] <xiphmont> Like I said, the OggIndex is not for local storage.
[21:34] <Daiz> there's no reason why you couldn't just in on the stream without building an index, no?
[21:34] <xiphmont> It's for scrubbing streams over links with latency.
[21:34] <Daiz> just jump in*
[21:34] <oggkoggk> 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] <derf> 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] <xiphmont> Daiz: for Ogg, yes in fact
[21:35] <Daiz> I highly doubt it would be any more complex than that for matroska
[21:35] <bemasc> 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] <Daiz> MPC-HC probably builds an index on demand because I'm playing local files
[21:35] <Daiz> and that's what it expects
[21:35] <xiphmont> 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] <Daiz> well, surely you could the same to a matroska stream?
[21:35] <Daiz> in fact I see no reason why you couldn't
[21:36] <Daiz> then afterwards you'd also have a perfectly working matroska file.
[21:36] <bemasc> with no index, and taking 10 seconds to scan
[21:36] <Daiz> for the first seek
[21:36] <Wumboot> derf: "terrible" is a hopeless attempt at describing it.  Have you ever looked at their AVI code?
[21:36] <xiphmont> well, try chopping chunks out and see what happens.
[21:36] <derf> Wumboot: Fortunately, no.
[21:36] <Daiz> and it'd be instantaneous as in my earlier test for files that are not 6 GB in size
[21:36] <bemasc> Daiz: If your disk is that fast, you don't need an index.
[21:37] <bemasc> (and everyone's disk is that fast)
[21:37] <Daiz> or nearly instataneous for the first seek anyway
[21:37] <Wumboot> 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] <Daiz> instantaneous*
[21:37] <xiphmont> you're arguing past each other again.
[21:37] <Daiz> well, it's still nicer to have an index, if even for that first seek
[21:37] <derf> Wumboot: I figure I'd be better off just stabbing myself in the face a few times.
[21:37] <Wumboot> 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] <Daiz> but well, test result is, indexless matroska files work and seek just fine
[21:37] <Daiz> and you could stream, jump in, and save stream just fine as well
[21:38] <Daiz> and if you want to add a permanent index to the saved file, just remux it
[21:38] <oggkoggk> Great, use it then :)
[21:38] <xiphmont> Daiz: you're not describing an improvement.  You're describing a workaround.
[21:38] <Wumboot> 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] <Daiz> how is it a workaround?
[21:39] <Daiz> matroska files work without index just like ogg files do
[21:39] <Wumboot> (less tahn 14kB, in fact -- but at 64kB everything would have flowed very easily)
[21:39] <xiphmont> Ogg doesn't have that 10s first seek.  And it doesn't have to remux to avoid it.
[21:39] <oggkoggk> Daiz: you just said it was creating an index by itself...
[21:39] <derf> 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] <xiphmont> And a player that doesn't implement indexes is scrod.
[21:40] <Daiz> well, that's more of the splitter/whatever behavior
[21:40] <xiphmont> Nevertheless, not an improvement over what we already have.
[21:40] <Wumboot> 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] <Daiz> but does the ogg offering in this aspect really beat it?
[21:40] <bemasc> beat what?
[21:41] <oggkoggk> Parse error.
[21:41] <bemasc> beat what for what use case? and why is this a competition?
[21:41] <Daiz> well, my test was rather just about the no-index usage of matroska and how it works
[21:41] <xiphmont> In this case, yes the Ogg offering just beat it.
[21:42] <Daiz> also do note that this 10sec first seek was again on a 6GB file
[21:42] <bemasc> Specifically, current Ogg implementations beat current Matroska implementations
[21:42] <derf> Wumboot: May not help your 4x DCT case much, but it would certainly help libtheora.
[21:42] <xiphmont> I don't have a single Ogg file with an index here and they all seek instantly.  
[21:42] <bemasc> Daiz: Both Ogg and Matroska players could presumably be updated to gain each other's behavior if they so desired.
[21:42] <xiphmont> And I wrote the muxing, so I know it's not scanning the whole file.
[21:42] <Wumboot> derf: Is residual often zero?
[21:43] <Daiz> how big are the biggest files?
[21:43] <derf> Wumboot: Depending on the bitrate, quite often.
[21:43] <bemasc> 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] <xiphmont> 20-sh GB.  and a few near-raw files much larger.
[21:43] <xiphmont> bemasc: not on all containers.  Not all containers can capture.
[21:43] <Daiz> also, there's also the factor that I used H.264 as the video codec
[21:43] <derf> Theora doesn't have a way to encode "apply MC, but no residual" other than explicitly coding a zero residual.
[21:43] <bemasc> Daiz: and?
[21:43] <xiphmont> And many that can 'capture', the capture is heuristic.
[21:43] <Daiz> I wonder how this test would change if I had a 6GB Theora&Vorbis in MKV...
[21:44] <Daiz> or if it would change at all
[21:44] <bemasc> I can hardly imagine why it would be different.
[21:44] <derf> Wumboot: Which is fairly cheap, so not that big a deal, but not being taken advantage of by the decoder.
[21:44] <xiphmont> I can, but I don't know.
[21:44] <oggkoggk> 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] <Daiz> well obviously decoding speeds also affect seeking speeds?
[21:44] <xiphmont> And I don't really care.  I still haven't seen a practical benefit demonstrated to abandoning our entire sourcebase.
[21:45] <xiphmont> Daiz: no.
[21:45] <Wumboot> I guess it'll be highlighted by an EOB run in the DC list.
[21:45] <xiphmont> Daiz: you seek to a keyframe.  Period, done.
[21:45] <derf> Wumboot: Not necessarily. DC prediction can screw that up.
[21:45] <Daiz> how about I seek into a b-frame?
[21:45] <xiphmont> nothing decodes anything until that process is finished.
[21:45] <xiphmont> Daiz: can you?
[21:46] <xiphmont> Most systems won't actually let you do that.
[21:46] <Daiz> well with "jump to frame" in MPC-HC I can definitely land on a b-frame if I wish so
[21:46] <xiphmont> [though the ogg ones do, and our own frameworks seek to the preceeding keyframe then decode forward.  That's unusual.]
[21:47] <Daiz> unusual? really? most proper software players do that as well with anything
[21:47] <xiphmont> 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] <Daiz> or well, with H.264 MKVs anyway
[21:47] <Daiz> I get the actual b-frame
[21:48] <xiphmont> ok, good.  So just seek to a keyframe to test the seek time :-)
[21:48] <Daiz> okay then, that changes my test methology of "click around in the seekbar" a bit
[21:49] <xiphmont> well, if it's instant for small files and really long for big files, that's still a result.
[21:49] <Wumboot> 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] <xiphmont> heh, you think there's wailing and gnashing of teeth now? :-)
[21:50] <xiphmont> But that actually violates Ogg design spec.
[21:50] <Wumboot> Oh, I'll violate anything, I will.
[21:50] <xiphmont> uhhh huh.
[21:50] <Wumboot> Too late to change it anyway, but out of curoosity, what would have been the violation?
[21:51] <xiphmont> 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] <Wumboot> 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] <xiphmont> there's not actually any intuitedinformation, it's all explicit.
[21:52] <Wumboot> Even if I add whitespace, I can't make much sense of the word intuitedinformation.
[21:53] <Daiz> well looks like it'll build the index no matter what
[21:53] <Daiz> in MPC-HC
[21:53] <bemasc> even if there's already an index?
[21:53] <Daiz> well no
[21:53] <Daiz> only on non-indexed files
[21:53] <bemasc> ok
[21:53] <Daiz> on indexed files it's instant
[21:53] <Daiz> seeking to a keyframe, that is
[21:54] <xiphmont> Wumboot: Oh, retconning is possible.  But a retcon would be needed.
[21:54] <Daiz> hm
[21:54] <Daiz> though I highly doubt this would be the only way to deal with non-indexed matroskas
[21:55] <Daiz> guess I'll need some help if I want to test no-index-creating seeking on a no-index matroska
[21:55] <xiphmont> but... you'd be blurring the line between codec and mux to do it another way! ;-)
[21:55] <Daiz> what
[21:55] <xiphmont> I'm being silly.
[21:55] <xiphmont> A different argument, unrelated tot he one you're making.
[21:55] <xiphmont> "in joke"
[21:55] <Wumboot> 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] <xiphmont> yes
[21:56] <Daiz> --no-clusters-in-meta-seek
[21:56] <Daiz>     Tells mkvmerge(1) not to create a meta seek element at the end of the file containing all clusters.
[21:56] <xiphmont> er
[21:56] <Daiz> hmmm
[21:56] <xiphmont> I misinterpreted 'obviates'
[21:56] <Daiz> I wonder if this has anything to the subject
[21:56] <Daiz> time to test!
[21:58] <Wumboot> By clearing the 'this is extends the previous packet' bit, it removes the necessity to terminate that packet with a zero.
[21:58] <Wumboot> Or is that false?
[21:58] <xiphmont> 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] <xiphmont> is a nil case as far as data is concerned."
[21:59] <Wumboot> Ahh.
[22:00] <Daiz> 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] <xiphmont> 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] <xiphmont> you can space them by timing or just by distance.
[22:01] <Daiz> what's the default?
[22:01] <xiphmont> but they're a max of a little under 64kB apart.
[22:01] <xiphmont> default in the Xiph tools is to just space them about 4kB apart.
[22:02] <xiphmont> For a long time I've meant to add a timing-based mode to libogg.
[22:02] <Daiz> what would that 4kB translate to for timing?
[22:02] <xiphmont> [doesn't affect the format, just changes the behavior of the muxer]
[22:02] <Daiz> in general
[22:02] <xiphmont> Daiz: depends entirely on your media.
[22:03] <Daiz> well, for example... 2Mbps video stream, 192kbps audio stream
[22:03] <Daiz> would the codecs matter
[22:03] <xiphmont> codecs don't matter, just rate
[22:03] <Daiz> stream formats*
[22:04] <xiphmont> 15ish ms for the audio, less than a single frame of video at those rates.
[22:04] <Daiz> okay.
[22:04] <gmaxwell> (back for a bit)
[22:05] <gmaxwell> Another fun excercise is to try playing a truncated tail-index mp4 file. :)
[22:06] <gmaxwell> The 4k limit makes sense for audio... it keeps memory usage low for low memory devices. 
[22:06] <xiphmont> and low rate video
[22:06] <gmaxwell> But moderate or higher rate Video could benefit from some larger pages.
[22:07] <Wumboot> An embedded device can only make use of that if it's prepared to fail when the pages turn out to be larger than 4kB.
[22:07] <xiphmont> sorry, I'm wrong--- 150ms-ish audio.
[22:07] <xiphmont> Wumboot: you're not required to hold pages in memory.
[22:07] <xiphmont> or even to parse them.
[22:07] <Wumboot> Yeah, you just write more complicated code.  That's what I did.
[22:07] <xiphmont> libogg2 pulled in pieces of pages 256 bytes at a time.
[22:08] <Wumboot> But since you have to write the complicated code, the 4kB thing means nothing.
[22:08] <xiphmont> except to overhead.
[22:08] <gmaxwell> Wumboot: keeping the average size down is still nice. 
[22:08] <xiphmont> [yeah, it means nothing to demux]
[22:08] <gmaxwell> It also limits the distance you must scan to capture, not the worst case on the worst file... but on such files.
[22:09] <Wumboot> I've been meaning to rewrite our ogg handler to pull in 64kB chunks at a time to de-uglify that code.
[22:09] <gmaxwell> Imagine the opposite case. Say libogg maximally pagenated by default... everyone would complain about the enormous latency. :)
[22:09] <Wumboot> Well, that but rounded up so as to ensure that every read is 512-byte aligned.
[22:13] <Wumboot> I don't think many people would notice the latency, to be honest.
[22:14] <gmaxwell> I dunno, people do complain about vorbis in icecast pretty much every time it gets used for something live. (page size is by far not the only source of latency there...) I don't think that adding two and a half seconds would help! :)
[22:16] <Wumboot> Nobody streams media.  That would imply that you'd want some kind of streamable container format, which is a patently ridiculous idea.
[22:16] <Wumboot> It's clealy impossible.
[22:23] <Wumboot> Also, a 64kB page size would let me use my SIMD-accelerated CRC code.
[22:24] <Wumboot> SIMD doesn't like short CRC runs.  The recombination is too expensive.
[22:38] <bemasc> gmaxwell: Maybe a theora testcase is in order?
[22:39] * Wumboot realises Cantonese is being spoken behind him.
[22:40] <Wumboot> It's so full of technical words it sounded pretty much like English.
[22:43] <gmaxwell> bemasc: be my guest. I think just s/4096/32768/ in libogg would be pretty much sufficient. (plus use an encoder that doesn't force pages)
[22:46] <bemasc> gmaxwell: not 65536?
[22:46] <gmaxwell> You can't actually put 65536 payload bytes in a page.
[22:46] <oggkoggk> I think a page has to be slightly less than that.
[22:47] <gmaxwell> (you're limited to 255 segments)
[22:47] <gmaxwell> I wasn't sure if there were boundary cases that need to be handled at the absolute maximum which aren't...
[22:48] <gmaxwell> The maximum packet that can be fully completed on a single page is 65024 bytes. 
[22:49] <gmaxwell> (Unless I've mathfailed)
[22:49] <gmaxwell> 254 full segments (size 255) plus one segment of size 254. 
[22:50] <bemasc> Right, but why does it need to be completed?
[22:50] <bemasc> I was thinking to just make libogg produce the largest possible pages.  "Maximum efficiency mode".
[22:52] <gmaxwell> spanning pages doesn't increase the efficiency though. But sure.
[22:54] <gmaxwell> Could run CELT at 50mbit/sec as a test case. ;)
[22:56] <gmaxwell> In terms of making a test file, beyond big pages we should create a file that hits the corner cases of the fragment lenghts being [...,255,255][0,...] while at the maximum size. 
[22:57] <gmaxwell> would also be amusing to make a file with only 1 byte of payload per page.
[22:58] <gmaxwell> Hm. actually, we can't do that.
[22:59] <bemasc> No?
[22:59] <bemasc> you might need to define a new codec
[23:00] <bemasc> You could get close with empty theora frames.
[23:00] <gmaxwell> Right. That could be done, but not general packets.
[23:00] <gmaxwell> because segments less than 255 are terminal.
[23:01] <Wumboot> PCM, perhaps?
[23:02] <bemasc> gmaxwell: spanning pages doesn't increase efficiency?
[23:02] <Wumboot> It can gain you one whole byte over the example stated.
[23:03] <xiphmont> uh...
[23:04] <xiphmont> website is being wonky.
[23:10] <derf> gmaxwell: No, the more sensible behavior for libogg is to default to 4k pages, but go larger if individual packets are larger.
[23:11] <derf> And also to make it stop doing things like [...,255,255][0,...] when it doesn't _have_ to (currently, it does that all the time for no good reason).
[23:13] <derf> Oh, xiphmont, did you see and my suggested yesterday?
[23:15] <xiphmont> I hadn't although I actually already knew about that bug from the code review I was in the middle of doing when my 'work priorities' were 'adjusted' to 'embrace change'.
[23:15] <derf> :)
[23:16] <xiphmont> Yeah, that looks fine to me.  I'll suck it into SVN shortly.
[23:16] <xiphmont> The... ahem... truth is there are a couple more of those Mozilla just hasn't found yet :-|
[23:16] <bemasc> gmaxwell: If you have lots of 48 KB packets, surely spanning them all will save 25% on page headers?
[23:16] <derf> I don't doubt it.
Session Time: Sat Mar 06 00:00:01 2010
[01:04] * gantim_ is now known as gantim
[02:55] <blizzard> MikeS-tp: ping
[02:55] <blizzard> actually, anyone can answer this
[02:55] <blizzard> when you're listening to an ogg stream using songbird
[02:56] <blizzard> it will update the song name based on what's playing
[02:56] <blizzard> is that just a new skel track that shows up in the stream?
[02:56] <blizzard> wondering where those updates come from
[02:56] <MikeS> blizzard: no skeleton or anything.
[02:57] <asadotzler> it's just metadata on the audio stream
[02:57] <asadotzler> we could add that for our air mozilla broadcasts pretty easily.
[02:57] <asadotzler> I think.
[02:57] <MikeS> blizzard: it's just a new ogg 'chain' - basically a new vorbis stream, with a new set of vorbis comments in the metadata packet
[02:57] <MikeS> asadotzler: I thought firefox didn't support chained ogg though?
[02:57] <asadotzler> but we don't chain anything in air mozilla.
[02:57] <MikeS> blizzard: this is completely different to how it works for mp3 streams, FWIW
[02:57] <asadotzler> it's just one show :-)
[02:58] <MikeS> asadotzler: right, so you can't have metadata updates.
[02:58] <asadotzler> but we can have metadata. we don't right now.
[02:58] <derf> blizzard: You can't start new streams in Ogg without starting a new chain.
[02:59] <MikeS> asadotzler: you could have metadata at the start of the stream. You couldn't change it mid-stream without starting a new chain, and hence running into the problem that firefox can't cope with that IIRC
[02:59] <blizzard> MikeS: ok, so we won't be able to do that until we support chained oggs?
[02:59] <MikeS> blizzard: Yeah
[02:59] <blizzard> yay new backend
[03:00] <MikeS> this is, in practice, the main use-case for chained oggs - internet radio style applications
[03:00] <blizzard> MikeS: yeah, I was just wondering if we wanted to expose song information like that through an HTML5 event
[03:00] <blizzard> DOM event, anyway
[03:00] <MikeS> blizzard: I dunno. It seems like it'd be a good idea to do it somehow?
[03:01] <derf> You certainly would want to expose playing across chain boundaries.
[03:01] <blizzard> you could simulate that by doing it out of band
[03:01] <blizzard> but it would be messy without good information about how much we have buffered
[03:01] <blizzard> which we also don't expose
[03:13] <gmaxwell> I also think you want to expose chaining boundaries stuff.
[03:14] <gmaxwell> Perhaps a call to get a list of currently playing serial numbers.
[03:15] <derf> I'm not sure you'd want to make the interface that Ogg-specific.
[03:15] <derf> But I don't really know what your DOM API is like now.
[03:41] <blizzard> derf: it's super-simple
[03:41] <blizzard> derf: and the part that we actually impl is even more simple :)
[03:42] <blizzard> derf: basically load, play, stop, volume, events for position, "got enough to play"
[03:42] <blizzard> derf: and some other random stuff
[03:46] <derf> Well, I assume with nessy's work you're going to need some kind of interface to ask it what kind of streams are available.
[03:50] <gmaxwell> haha... sequential /. headlines caused me to read
[03:51] <gmaxwell> " Microsoft Spends $9 Billion On Internet Explorer 6 Funeral"
[03:57] <mattl> by injecting a copy of IE6 into the eyes of every child in the US.
[04:18] <xiphmont> nnnnnnnnggggg
[04:19] <gmaxwell> xiphmont: nice hat!
[04:24] <xiphmont> I have a hat?
[04:24] <xiphmont> oh, on my ass.  Thanks!
[04:26] <gmaxwell> <@  it's like a wide brimmed dunce cap.
[04:26] <xiphmont> I have to admit I really have no idea what you're talking about.
[04:27] <gmaxwell> 16:24 <@xiphmont> I have to admit I really have no idea what you're  talking about.
[04:27] <gmaxwell> Sometimes you wear a cape... now you've got a hat!
[04:27] <xiphmont> Oh.
[04:28] <xiphmont> aw.
[04:29] <xiphmont> *someone* has to wear the asshat.
[04:29] <mattl> isn't that why i'm here?
[04:35] <gmaxwell> mattl: No. You _are_ the asshat.  Fine distinction.
[04:37] <mattl> True, true.
[04:41] <ds> anyone know of a good motherboard database?
[04:42] <lantizia> Hey, converting from 23 to 25fps... bad idea... converting down from 30fps (well ok 29.997 NTSC) down to 25fps... a perfectly fine idea?
[04:43] <bemasc> still a bad idea
[04:43] <bemasc> possibly marginally less bad
[04:43] <derf> It depends on the source.
[04:43] <lantizia> would I exist jitter just as I would upping fps... even going down by the number of fps
[04:44] <bemasc> yep, you get judder either way
[04:44] <derf> If the "29.970 fps" is really created from 24 fps source material that's gone through 3:2 pulldown, then you could convert to 24 fps and resample the audio to get it to 25 fps.
[04:44] <bemasc> If you have to convert, then convert, but if you can avoid it, avoid it.
[04:44] <derf> But in any other situation it's a bad idea.
[04:49] <lantizia> I wouldn't have thought going from 30 to 25 would be that bad... I mean you'd still have 25 fps evenly spaced in a second!?
[04:49] <derf> No, you wouldn't.
[04:49] <bemasc> lantizia: you can try it.  You will have 5 discontinuities a second.
[04:50] <lantizia> but... why? :D
[04:50] <derf> Because gcd(25,30)=5.
[04:51] <lantizia> gap frame frame frame frame frame gap frame frame frame frame frame gap frame frame frame frame frame gap frame frame frame frame frame gap
[04:51] <lantizia> is that the reason? :D
[04:51] <bemasc> lantizia: more or less, but "gap" is not what you will see
[04:51] <lantizia> well thats not sending it down to 25fps 
[04:52] <lantizia> it's leaving it at 30fps and removing the content of 5 frames every second
[04:52] <bemasc> what you will see is 1 2 3 4 5 7 8 9 10 11 13 14 15 16 17 19 ...
[04:52] <bemasc> if your video has very little motion then it probably doesn't matter
[04:53] <lantizia> ok I think I understand the reason now
[04:53] <derf> If it has a smooth pan in it, it will look like shit.
[04:53] <bemasc> but the rule is always: do as little processing as necessary
[04:53] <derf> Because the pan will no longer be smooth.
[04:54] <lantizia> damn no more smooth omelettes then
[04:54] <derf> Better switch to bacon.
[04:56] <lantizia> ok lets say I --need-- to go from 30fps to 25fps... whats the most painless way? is there way to smooth the pan as well as convert to 25fps?
[04:56] <bemasc> lantizia: you can play with yuvmotionfps
[04:56] <lantizia> like detect frames that barely change and cut back on them to allow for those that move alot
[04:56] <lantizia> if that makes sense
[04:57] <bemasc> lantizia:
[04:57] <derf> It does. It's called content-adpative resampling.
[04:57] <derf> I don't know of anything that implements it for video.
[04:57] <lantizia> derf, when you say "it" are we on about ffmpeg2theora here?
[04:57] <lantizia> thats what I use to make my theora files
[04:57] <bemasc> lantizia: I don't know that yuvmotionfps works well, but you can try it.
[04:58] <bemasc> lantizia: you can also try the simpler , which just blends frames together.
[04:59] <lantizia> I'm not sure how to use any of this in my scripts
[05:00] <lantizia> what I do at the moment is use mplayer to strip the audio from the original file, then pipe it into an ogg vorbis encoder
[05:00] <lantizia> then use ffmpeg to just convert the video to theora
[05:00] <lantizia> then oggz-merge
[05:03] <lantizia> so how does it fit in with all that?
[05:04] <bemasc> lantizia: here's a random python script someone wrote. It might delete your children, though.
[05:05] <bemasc>
[05:05] <bemasc> You can probably substitute in ffmpeg2theora for the encoding step, if you speak python
[05:06] <bemasc> lantizia: basically, you need to take your input video, decode it to uncompressed raw yuv, push that through yuvmotionfps, then encode it with ffmpeg2theora
[05:06] <lantizia> right
[05:06] <bemasc> lantizia: The reason this is so hard is that people who care about quality don't normally resample video framerate... and the ones who do are usually using Final Cut Pro, which presumably has this stuff built in.
[05:07] <lantizia> tell me... since I push my audio to WAV then into OGG ... but my vid goes direct from say xvid to theora... would also pushing the vid to RAW then to theora - help to eliminate sync issues?
[05:07] <bemasc> I have no idea.
[05:08] * lantizia wonders if mplayer can handle converting anything to yuv raw
[05:37] <basilgohar> bemasc: Way-to-go getting mentioned on CNet.
[07:16] * drac6671 giggles on how the cnet article (Is H.264 a legal minefield for video pros?) has baptised Fraunhofer Institute - *Frauenhofer*
[07:16] <Diablo-D3> subtle.
[07:17] <derf> You'll have to explain why that's giggle-worthy to us non-Germans.
[07:17] <blizzard> yeah....
[07:17] <drac6671> Frauen - women
[07:17] <blizzard> hah
[07:17] <blizzard> right
[07:17] <drac6671> or womenkind...
[07:17] <Diablo-D3> drac6671: cnet is not without a pool noodle of wit.
[07:18] <drac6671> Frauenhofer gave us mp3! :)
[07:18] <Diablo-D3> doesnt that make mp3 a std?
[07:25] <blizzard> laughing aside it's a good article
[07:25] <blizzard> nice to see quotes from the mpeg-la people
[07:25] <blizzard> I love the arrow to "Free Television"
[07:28] <ds> rather sad that the answer was "We can't be bothered to make the license clear"
[07:28] <blizzard> it's more like "we want as much leverage as possible"
[07:33] <bemasc> blizzard: the diagram is straight from the mpeg-la
[07:34] <bemasc> yeah, the article isn't quite cynical enough to be right, but it's pretty good
[07:37] <blizzard> bemasc: he's not usually cynical
[07:37] <blizzard> except when it comes to firefox :)
[07:44] <bemasc> blizzard: y'all should benchmark your competitors' browsers in your nightly whatever
[07:45] <blizzard> bemasc: hmm?
[07:45] <blizzard> bemasc: we're generally aware :)
[07:45] <bemasc> blizzard: I mean, should have other people's alphas and nightlies
[07:45] <blizzard> oh
[07:46] <blizzard> see privmsg :)
[08:04] <mattl> wait, we got mp3 now?
[08:05] <derf> Just five more years?
[08:05] <derf> Or 8?
[08:05] <derf> Somewhere in there.
[10:27] <basilgohar> I've heard mention of rolling-intra....
[10:28] <basilgohar> Does that mean intra blocks are spread across multiple frames, rather than all in one keyframe?
[10:38] <MikeS-tp> basilgohar: yes
[10:42] <basilgohar> Ah, okay.  Well then.
[10:42] <basilgohar> And this is something the Theora spec can support?
[10:43] <MikeS-tp> You can easily do it in theora, but there's no way to signal that you're doing it.
[10:43] <MikeS-tp> So a decoder doesn't currently have any way to know when it's safe to start displaying, or where to seek to, etc. Those could probably be done as backwards-compatible extensions though?
[10:43] <basilgohar> MikeS-tp: So, does that mean decoders must have support for it before it can be rolled out?
[10:43] <basilgohar> Oh, I see...
[11:00] <basilgohar> Boy....FN seems to be dead tonight...
[11:01] <MikeS-tp> basilgohar: nah, we're just all ignoring you :-)
[11:10] <basilgohar> Figures...
[11:47] <gmaxwell> basilgohar: there is a simple way of signaling it which abuses the spec a little, thats the backwards compatible way.
[11:47] <gmaxwell> The resulting files play in everything.  They seek correctly in firefox.   They'd seek correctly in gstreamer with a ~1 line change.
[11:47] <gmaxwell> VLC seeks like crap, but it does on normal files.
[11:47] <basilgohar> VLC cuts off the beginnings of files, so it shouldn't be the standard anyway.
[11:48] <gmaxwell>
[11:48] <gmaxwell>
[11:49] <gmaxwell> Those are just silly examples to test the client, they are hideously inefficient files.
[11:50] <gmaxwell> (they don't use motion prediction)
[12:07] <basilgohar> gmaxwell: What would it take to get that into libtheora and how much benefit could we potentially glean from that?
[12:09] <MikeS-tp> you really only want it for super-low-bitrate buffer-constrained encoding - it's a pretty niche use case
[12:10] <MikeS-tp> s/low-bitrate/low-latency/ sorry
[12:10] <MikeS-tp> it's not useful for non-live usage
[12:10] <basilgohar> MikeS-tp: So, there's no advantage to having it in, say, a quality-based stream?
[12:10] <MikeS-tp> basilgohar: no.
[12:11] <basilgohar> I was under the impression that it could make playback quality a bit smoother because you wouldn't perceive such a difference as when a keyframe is decoded.
[12:12] <gmaxwell> The encoder controls the quality given to a keyframe.  It's a seperate issue, except in a buffer constrained stream
[12:12] <MikeS-tp> not really - it's more like part of every frame is keyframe-like
[12:12] <gmaxwell> (where the encoder may not be able to give the keyframes the desired quality)
[12:13] <basilgohar> I see...
[12:14] <gmaxwell> There is also an obnoxious disadvantage of rolling intra: the encoder can't generate motion vectors pointing to the old side of the sweep.
[12:15] <gmaxwell> (I couldn't be bothered to actually code the MV referencing restriction, though it wouldn't be hard to do,  which is why my files don't use motion prediction at all)
[12:27] <blizzard> I wonder how I closed this channel
[12:28] <Diablo-D3> by magic.
[12:32] <gmaxwell> oggkoggk: Charge!
[12:37] <blizzard> oh hey
[12:37] <blizzard> who runs
[12:57] <blizzard>
[12:57] <blizzard> heh
[12:57] <blizzard> the error
[13:02] <MikeS-tp> blizzard: mostly nobody as far as I can tell! It's pretty crappy
[13:05] <blizzard> heh
[13:05] <blizzard> ok
[13:06] <blizzard> MikeS-tp: so who maintains the list in songbird?
[13:17] <MikeS-tp> blizzard: the shoutcast thing? It's pulled directly from shoutcast, I assume. I dunno, I've never even used that
[13:17] <blizzard> ahh
[13:17] <blizzard> I use it all the time
[13:18] <MikeS-tp> I don't really listen to internet radio any more
[13:19] <MikeS-tp> except sometimes an internet stream from a 'real' radio station or two.
[13:19] <MikeS-tp> but not even that very often
[15:20] <basilgohar> So, okay...I know this isn't the most appropriate place to ask this, but regarding H.264 licensing...
[15:21] <basilgohar> If I buy an HD camcorder that uses the AVCHD codec...
[15:21] <basilgohar> And I record with that same camcorder *something*...
[15:21] <basilgohar> And I then want to provide that resulting video, in a different format (e.g., Ogg Theora) online or on disk, for a fee...
[15:21] <basilgohar> Would I owe anything to the MPEGLA?
[15:22] <basilgohar> So, H.264 only played the role of being the master recording...
[15:22] <ds> no
[15:23] <Diablo-D3> basilgohar: no
[15:23] <Diablo-D3> due to the fact you could sue them for even knowing
[15:24] <basilgohar> <quote>But the wedding videographer might need to take an AVC/H.264 license--though payments will hardly be a big burden even if they're sending out 100 DVDs of somebody's nuptuals.</quote>
[15:24] <basilgohar>
[15:36] <basilgohar> In the case cited, H.264 was only part of the production chain....
[15:37] <basilgohar> The final format was a DVD.
[15:37] <Diablo-D3> the license was already paid for
[15:37] <Diablo-D3> by the manuf of the camcorder
[15:39] <kinetik> basilgohar: i assumed it was just imprecise, and that the videographer was distributing H.264 videos on "media"
[15:39] <Diablo-D3> kinetik: I doubt it
[15:39] <Diablo-D3> he probably was making actual DVDs
[15:39] <kinetik> besides which, there's an MPEG-2 patent pool, which might have similar terms
[15:39] <basilgohar> kinetik: It's this kind of ambiguity that permeates everything about the licensing of H.264 that unnerves me...
[15:39] <Diablo-D3> kinetik: yes, but theres the problem
[15:40] <Diablo-D3> the article implies it was for a h264 license
[15:40] <Diablo-D3> not a mpeg2 license
[15:40] <Diablo-D3> not only that, most likely the license was already paid for
[15:40] <basilgohar> Diablo-D3: That's only a license for encoding (the camcorder comp)
[15:41] <kinetik> Diablo-D3: not a distribution license, which is what's probably being implied here
[15:41] <basilgohar> It doesn't include decoding and distribution...
[15:41] <basilgohar> Both of which are separate licenses.
[15:41] <Diablo-D3> basilgohar: except thats not HIS problem
[15:41] <Diablo-D3> there was no distribution
[15:41] <Diablo-D3> and hes not required to snoop on whoever wrote the decoder
[15:41] <basilgohar> Diablo-D3: It is if he distributes the DVDs!
[15:41] <kinetik> Diablo-D3: the 100 DVDs is distribution of a product to end users
[15:42] <Diablo-D3> BUT THE DVDS DONT USE h264!
[15:42] <kinetik> s/is/are/
[15:42] <Diablo-D3> THEY USE MPEG2!
[15:42] <basilgohar> H.264 was part of the production chain.
[15:42] <Diablo-D3> basilgohar: but they cant prove that!
[15:42] <basilgohar> That would constitute non-commercial use.
[15:42] <Diablo-D3> at no point was h264 used in any commercial use
[15:42] <basilgohar> That's irrelevant to the point.
[15:42] <Diablo-D3> Actually it is
[15:42] <ds> blueray uses h.264
[15:43] <Diablo-D3> otherwise I can sue you, right now, for just existing
[15:43] <kinetik> anyway, if you're deriving legal advice from a CNET article you probably have bigger problems
[15:43] <Diablo-D3> somewhere, along the line
[15:43] <Diablo-D3> someone you met
[15:43] <Diablo-D3> met someone else
[15:43] <Diablo-D3> who shared a room in college with someone
[15:43] <Diablo-D3> who slept with someone
[15:43] <Diablo-D3> who violated a license thats mine
[15:43] <Diablo-D3> so pay up right now
[15:43] <Diablo-D3> see how stupid your argument is?
[15:43] <basilgohar> kinetik: It's the only semi-legit source with an inkling of what real-life licensing issus H.264 will have.
[15:43] <Diablo-D3> such licensing cannot be enforced
[15:44] <Diablo-D3> its illegal
[15:44] <Diablo-D3> the only thing they can attempt to grab him for is mpeg2 licenses
[15:44] <Diablo-D3> and I bet someone already paid for those somewhere
[15:44] <basilgohar> Diablo-D3: Itf they even know the camera you used to record, it could be proof.
[15:44] <Diablo-D3> basilgohar: nope, to record it was already paid for
[15:45] <Diablo-D3> to decode it isnt paid for by the viewer, its paid by the manuf.
[15:45] <basilgohar> Diablo-D3: There are three aspects....encoding, decoding, & distribution.
[15:46] <Diablo-D3> encoding was paid for
[15:46] <basilgohar> MPEG-LA claims the authority to license all three.
[15:46] <Diablo-D3> decoding was, presumably, paid for
[15:46] <Diablo-D3> and distribution never happened.
[15:46] <Diablo-D3> ergo, there is no issue.
[15:46] <basilgohar> Encoding & decoding are paid for, but not for commercial purposes.
[15:46] <Diablo-D3> basilgohar: ahh, but therein lies the problem
[15:46] <basilgohar> This is the crux.
[15:47] <Diablo-D3> at no point has he distributed a work of h264.
[15:47] <basilgohar> I am having this argument with literally one hand....I
[15:47] <basilgohar> m holding my on in the other...
[15:47] <Diablo-D3> Such a license cant even be written to paper, let alone be enforced
[15:47] <basilgohar> Diablo-D3: You're arguing that they cannot prove its source, right?
[15:48] <Diablo-D3> basilgohar: no, Im arguing the source is irrelevant
[15:48] <Diablo-D3> he neither manufactured the camcorder, the decoder, or did any transporting
[15:48] <basilgohar> only takes one legal precident to get around the point you're making.
[15:49] <Diablo-D3> except this is embedded in law older than the US.
[15:49] <Diablo-D3> mpegla is simply three or four centuries too late on this.
[15:49] <basilgohar> And, besides, this is a very lossy conversation, because half of what I am saying appears to not be making it to you...;)
[15:49] <basilgohar> Diablo-D3: RIAA has shown us how little relevance there is to embedded law.
[15:50] <Diablo-D3> the RIAA has lost, legally
[15:50] <Diablo-D3> so Im not sure why you brought them up
[15:50] <basilgohar> Heck, 2000 - 2008 has show us how little power the US constitution has when tested.
[15:51] <Diablo-D3> thats because the people of this great country were not awake
[15:51] <Diablo-D3> the RIAA made the mistake of waking us up.
[15:51] <Diablo-D3> their mistake will not be repeated.
[15:52] <basilgohar> Meanwhile, countless people have already been sued by the RIAA and had to settle, they've all but destroyed the traditional concept of fair use, and ACTA is being passed right under our noses.
[15:52] <Diablo-D3> actually, ACTA is basically dead
[15:52] <Diablo-D3> not enough countries are going to pass it
[15:52] <Diablo-D3> since it basically amounts to foreign rule
[15:52] <basilgohar> I think you over-estimate the zeal of the average person for freedom, and under estimate the zeal for control of business-minded people.
[15:53] * basilgohar is executing a strategic withdrawal...
[15:55] <Diablo-D3> Heh.
[16:53] <rom_> hi
[16:55] <rom_> In your opinion, does something in missing for decoding : I have the impression there is no deblocking
[17:20] <rom_> the same image in x264 :
[17:26] <kinetik> is giving me the default apache setup page
[17:26] <kinetik> shouldn't it be redirecting to or something?
[18:31] <nessy> try
[18:41] <kinetik> yes, i'm just pointing out that is broken
[18:41] <kinetik> it's owned by xiph, so presumably it should be showing something more useful than "It works!"
[18:41] <kinetik> indicates that it used to redirect to, so it must've broken recentlyish
[18:41] <Diablo-D3> its better than it saying ARGH ITS BROKE
[18:42] * Diablo-D3 changes his apache default page to that now.
[18:42] <Diablo-D3> wait, I'd have to install apache
[18:42] <Diablo-D3> screw it
[18:42] <Diablo-D3> cherokee forever!
[21:04] <xiphmont_> hi
[21:06] <xiphmont_> back to working on my Ogg doc.
[21:07] <nessy> to reply to the big article ? cool!
[21:08] <xiphmont_> yeah
[21:08] <xiphmont_> spent all of yesterday on it.
[21:08] <xiphmont_> Trying to get it to the point of 'collaborative input welcome/needed' today.
[21:08] <nessy> can you turn it into technical documentation, too ;-)
[21:08] <xiphmont_> but it's the weekend and thus faily time, so probably not.
[21:08] <derf> What a waste.
[21:09] <xiphmont_> derf: I agree, but this has been a consistent distraction for a while now.
[21:09] <nessy> prolly necessary, actually
[21:09] <xiphmont_> Better me than you.
[21:09] <xiphmont_> One of us has to be the charming drunk.
[21:09] <Diablo-D3> xiphmont_: you're glorifying that pile of bs with a response?
[21:10] <xiphmont_> no.  I'm not addressing the trolls.
[21:10] <nessy> btw: I am trying to invite Diego to the open video conf as probably planned again for end of June
[21:10] <xiphmont_> I'm being the reasonable adult and addressing the other reasonable adults who will be unwittingly swayed.
[21:10] <xiphmont_> nessy: a good idea.
[21:11] <nessy> having a beer together might help a lot of things ;)
[21:11] <xiphmont_> btw, what open video conf?  OVC?
[21:11] <xiphmont_> yes, it will establish what he's really like.
[21:11] <nessy> yeah - isn't public yet, but will prolly happen again end of June
[21:11] <Diablo-D3> xiphmont_: that implies reasonable adults can be trolled
[21:11] <xiphmont_> Diablo-D3: sure they can.
[21:11] <nessy> and FOMS prolly during the 2 days ahead of OVC
[21:11] <nessy> we'll see how planning pans out
[21:12] <Diablo-D3> I question the reasonable part of the qualifying statement.
[21:12] <nessy> I'm talking with the guys
[21:12] <xiphmont_> nessy: that would be so fucking cool.  NTC again, or...?
[21:12] <xiphmont_> er
[21:12] <xiphmont_> NYC
[21:12] <nessy> yup, NYC
[21:12] <nessy> we've been talking about having FOMS in the northern hemisphere for a while and I wanted some change for the next foms
[21:12] <xiphmont_> YES!
[21:13] <nessy> prolly won't make January next year anyway in AU cause I'll be in Europe
[21:13] <xiphmont_> I'm so there.
[21:13] <nessy> awesome!
[21:13] <nessy> tentatively keep 23-27 June free
[21:13] <nessy> anyway - gotta grab some sleep
[21:13] <nessy> nn
[21:14] <nessy> good luck with the writing!
[21:14] <nessy> oh - and with talking to the lawyers ;)
[21:47] <CIA-8> robin * r16951 /branches/theorarm-merge-branch/: Create a branch of experimental/derf/theora-ptalarbvorm to use to merge the theorarm changes back in
[21:55] <bemasc> Robin_Watts: the CIA has outed you.
[21:56] <Robin_Watts> bemasc: Indeed :)
[21:58] <edrz> FOMS in NYC?
[21:58] <derf> That seems to be the current plan.
[22:24] <Robin_Watts> Does not have viewvc or something ?
[22:25] <derf> There's
[22:25] <Robin_Watts> Ahaha, thanks.
Session Time: Sun Mar 07 00:00:01 2010
[00:32] <Robin_Watts> gmaxwell: derf: You about ?
[00:32] <derf> Robin_Watts: Yes.
[00:33] <Robin_Watts> derf: I'm starting to look into this merging lark now.
[00:34] <Robin_Watts> The ARM code stuff is straightforward enough, I guess, with the wrinkle that I decide what ARM options are available at compile time, rather than runtime.
[00:34] <Robin_Watts> The variety of C changes are less obvious though.
[00:35] <derf> In what sense?
[00:35] <Robin_Watts> For instance, oc_sb_quad_top_left_frag - you have that as a static function, I have it as a macro, because lots of compilers I've used fail to inline static stuff.
[00:36] <Robin_Watts> I *could* just put it in as a macro for everything. I can't think of a platform on which that would hurt, but it's the kind of change that I ought to run past people before just doing it.
[00:37] <derf> I mean, that function is only ever used in initialization code.
[00:37] <Robin_Watts> Ah, then I'll silently drop that.
[00:37] <Robin_Watts> in fact, I have changed all the statics in that function to be STATIC, where I have #define STATIC static at the top of the file, with a comment.
[00:38] <Robin_Watts> The point of that being, for profiling, I change that to be #define STATIC to allow me to see where time is spent.
[00:38] <Robin_Watts> How do you feel about stuff like that being carried over?
[00:39] <derf> I'd prefer not to add too much macro crap without a good reason.
[00:39] <derf> Your compiler doesn't have a -fno-inline-functions?
[00:40] <Robin_Watts> probably it does, actually.
[00:40] <Robin_Watts> fair enough, I can drop that easily enough too.
[00:43] <Robin_Watts> OK. Motion vector stuff...
[00:44] <Robin_Watts> You do lots of memset(last_mv, 0, sizeof(last_mv)); and stuff like that.
[00:45] <Robin_Watts> and memcpy(frag_mvs[fragi],lbmvs[bi],sizeof(lbmvs[br])); etc
[00:45] <Robin_Watts> Various compilers I've used aren't smart enough to do those in sensible ways.
[00:46] <Robin_Watts> So I've defined oc_mv_u to be a union of a short and a oc_mv;
[00:47] <Robin_Watts> and oc_mv_u2 to be a union of short[2] and an oc_mv[2] and an i;
[00:47] <Robin_Watts> and oc_mv_u4 etc.
[00:49] <Robin_Watts> Then these memset/memcpy's can be rewritten as last_mv.i = 0; or other simple assignments.
[00:50] <Robin_Watts> frag_mvs[fragi].s=cbmvs.s[mapi&3] for example
[00:50] <derf> This seems to be making all kinds of assumptions I'd rather not.
[00:51] <Robin_Watts> Such as ?
[00:51] <derf> Like that a short is exactly the same size as two unsigned chars.
[00:51] <Robin_Watts> I've checked the alignment issues, and they are all fine.
[00:51] <xiphmont_> right, not true on many platforms
[00:51] <Robin_Watts> (Yes, instead of a short, I should be using an uint16_t)
[00:52] <Robin_Watts> (This is part of what I need to tidy up as I merge back)
[00:53] <Robin_Watts> But yes, the key thing is to make the assumption that we can have part of the union match the size of the other bit of the union.
[00:54] <Robin_Watts> It allows you to trade procedure calls for much simpler copies of elements that are generally nicely sized on all architectures.
[00:55] <Robin_Watts> Would you object to this if we swapped to using uint8_t's instead of unsigned chars, and uint16_t's instead of shorts etc?
[00:56] <derf> Yes.
[00:56] <derf> uint8_t's don't exist on many compilers.
[00:56] <derf> Specifically, Windows does not have stdint.h.
[00:56] <Robin_Watts> And on those compilers it's easy enough to fix that with a header and some #definery.
[00:57] <derf> See, this is the kind of stuff that creates maintenance headaches.
[00:57] <Robin_Watts> Using memcpy and memset will never be fast on all compilers.
[00:57] <sirlemonhead1> someone has made a stdint.h for visual studio - would it not be ok to just point visual studio users towards that in the documentation?
[00:57] <derf> True, but it will always work.
[00:58] <Robin_Watts> right, but unless the compiler is prepared to make all sorts of (to my mind unacceptable assumptions about what memset and memcpy do) it'll never work fast.
[00:58] <Robin_Watts> bah, misplaced ).
[00:59] <Robin_Watts> I'm sure I remember seeing ogg_uint8_t etc somewhere in this source...
[01:00] <Robin_Watts> which means that somewhere, you're already going through that maintenance pain.
[01:00] <derf> I'm sure you're wrong.
[01:01] <Robin_Watts> tremor has ogg_int16_t in it.
[01:02] <sirlemonhead1> os_types.h in the libogg source
[01:02] <derf> And what those guarantee is that the type is "at least 16 bits".
[01:02] <derf> It doesn't not guarantee an absolute size.
[01:02] <derf> *does not
[01:02] <derf> And there isn't one for 8 bits, anyway.
[01:03] <derf> But aside from the fact that your proposals make the code unreadable, and will silently fail on some platforms, or fail to compile on others...
[01:03] <derf> ...there has to be a better way to go about this.
[01:03] * gantim_ is now known as gantim
[01:04] <Robin_Watts> We could do it using macros?
[01:04] <Robin_Watts> COPY_MV(dst,src);
[01:04] <derf> Copying could at least be solved by making oc_mv a struct.
[01:04] <derf> Then *&mv1=*&mv2 works fine.
[01:05] <Robin_Watts> OK.
[01:10] <Robin_Watts> We could solve the memset one with a 'ZERO_MV(mv)' macro that would default to memset, and could be overridden on specific platforms?
[01:10] <Robin_Watts> and ZERO_MV(mv) should be suitably readable ?
[01:12] <Robin_Watts> (Sorry if this sounds like I'm beating on something you're really not keen on. I believe this matters on ARM, and I'm trying to find a way to get the benefits while addressing your concerns.)
[01:13] <Robin_Watts> Clearly you have to be happy that this isn't going to cause readability or reliability or portability or otherility problems going forwards.
[01:22] <derf> Actually, gcc does a pretty shitty job of optimizing the structure assignment.
[01:23] <derf> (it still copies byte by byte)
[01:23] <Robin_Watts> gcc does a pretty shitty job of *everything* on ARM.
[01:23] <derf> It does, however, properly translate *&mv1=*&MV_ZERO to avoid the global reference.
[01:24] <derf> E.g., with a static const oc_mv MV_ZERO={0,0};
[01:24] <Robin_Watts> yeah, I followed the idea.
[01:24] <derf> Unfortunatey, I need to run.
[01:25] <Robin_Watts> I'll think about it some more and try and come up with something that works well, and you're happy with.
[01:27] <derf> Okay. I appreciate you actually trying to have the conversation rather than just sending me a patch with these things in it.
[01:27] <Robin_Watts> derf: A lot of theorarm was done "just make it work" style.
[01:27] <Robin_Watts> and even "just make it work on ARM".
[01:27] <Robin_Watts> Clearly when rolling back to the trunk, a higher standard needs to apply.
[01:36] <xiphmont_> "The gods are pleased with what you've done."
[01:36] <xiphmont_> "Are they going to help?"
[01:36] <xiphmont_> "Ha!  No."
[01:37] <xiphmont_> "Then tell them to stay out of the way."
[01:38] * Robin_Watts can't place the quote, but feels like he should be able to...
[01:38] <xiphmont_> oh yeah.
[01:38] <xiphmont_> [Conan]
[01:38] <Robin_Watts> ah, right.
[02:13] <basilgohar> encoder_example has the '--soft-target' option...
[02:14] <basilgohar> Is there a way to do the same through gstreamer?
[02:20] <basilgohar> derf: I know I'm going to sound like a broken record, but there's still some posterization/banding/what you want to call it on some smooth sky backgrounds....
[02:20] <basilgohar> Dark skies show it too...
[02:21] <basilgohar> I'll prep some samples & sources...
[04:39] <Guiri> I used mencoder -oac copy -ovc copy input.vob -o input.avi to convert a vob to an avi. But it seemss to be skipping frames every now and then. Is this a bad idea? Should I use some type of hard sync command?
[04:40] <ds> I don't think this is the appropriate place to ask a question like that and expect an answer
[04:41] <Guiri> Well the idea is to convert the vob to avi so I can test out Firefogg
[04:41] <Guiri> But perhaps I'll ask in #mplayer
[04:43] <blizzard> probably a good idea
[04:43] <blizzard> although I wouldn't havwe been as gruff as ds :)
[04:43] <blizzard> ...and he's gone
[04:44] <ds> yeah
[04:44] <ds> well
[04:45] <ds> it's not the first time he's asked completely off-topic questions
[04:47] <blizzard> ahh
[06:49] <xiphmont_> anyone got a URL that describes OGM in detail?
[06:51] <xiphmont_> I can't tell if it's a container in Ogg or just using AVI-style metadata and nonstandard codec mappings.
[06:55] <mattl> OGM was just a hack to have Vorbis in AVI, i thought?
[06:58] <bemasc> reverse
[06:59] <bemasc> wikipedia says "a hack on Ogg that allowed embedding of video from the Microsoft DirectShow framework into an Ogg-based wrapper" without a source.
[06:59] <bemasc> website people: wtf:
[07:04] <kfish> hmm, that page lacks the proper template
[07:04] <kfish> that, or pictures of kittens; not sure which way it should go
[07:04] <xiphmont_> bemasc: that was an Emmett thing
[07:05] <xiphmont_> I thought I'd killed all those old unlinked paged
[07:05] <bemasc> xiphmont_: that wikipedia entry links to that page
[07:06] <kfish> perhaps we should just copy the contents to then take out the ranting
[07:06] <xiphmont_> Emmett took an oddly confrontational tone about OGM that I didn't really challenge at the time
[07:06] <MikeS-tp> xiphmont: I'm fairly sure it's AVI _headers_, then just the codec data in ogg packets. Not full-blown AVI-in-ogg
[07:07] <xiphmont_> ok
[07:07] <bemasc> I don't see ranting on ogm.html.  It's just out of date, now.
[07:07] <bemasc> that, and broken.
[07:07] <xiphmont_> there are still rant pages in various scattered places
[07:07] <MikeS-tp> xiphmont: plus some ogm-specific prefix to the actual avi header
[07:07] <xiphmont_> I've been trying to get rid of them all, but I keep missing some.
[07:08] <xiphmont_> MikeS-tp: was that also true of Vorbis and Theora in OGM?
[07:08] <MikeS-tp> xiphmont: e.g. see gstreamer's code here for ogm:
[07:09] <MikeS-tp> xiphmont: no, vorbis in ogm was a pure, perfectly normal, vorbis stream in ogg.
[07:09] <MikeS-tp> xiphmont: since the point of ogm was that people wanted vorbis, and they had been using avi, which didn't work with vorbis... I never saw theora in ogm. 
[07:12] <xiphmont_> how did video codecs go into OGM?  AVI header + raw codec packets?  And an OGM metaheader that was the equivalent of a Skeleton header?
[07:14] <Diablo-D3> yeah
[07:14] <kfish> sounds about right; probably with avi timestamps in the granulepos etc.
[07:14] <Diablo-D3> ogm was a horrid hackup
[07:14] <Diablo-D3> except I thought it used asf instead of avi for the encapsulation
[07:14] <MikeS-tp> xiphmont: OGM file had two streams: vorbis, and some video. The video had an avi-like header (with an ogm-specific prefix), and then avi codec data packets with an ogm prefix
[07:14] <bemasc> ogmparse is in -base!?
[07:14] <MikeS-tp> xiphmont: this is half what I remember, and half reading the gstreamer code I pointed at above.
[07:15] <kfish> i was going to point to , from about line 851 also
[07:15] <MikeS-tp> xiphmont: there was no separate metaheader.
[07:16] <xiphmont_> OK
[07:19] <gmaxwell> xiphmont_: I don't think emmett's position was oddly hostile... software that encourages people to shove random encumbered codecs in Ogg is a serious branding problem.   Right now if someone wants to adopt only free formats they can specify "ogg" and have a fighting chance. Had OGM become and stayed popular people would be stuck doing carful codec analysis all the time which simply doesn't work. 
[07:21] <ds> also, OGM allowed people to shove random crap into Ogg the same way they shoved random crap into AVI, which made AVI a cesspool
[07:22] <gmaxwell> You can do that to ogg without OGM, but ogm instutionalized the practice.
[07:22] <ds> matroska has mappings defined for everything, which makes this a non-issue
[07:24] <ds> gmaxwell: sure, but if you want to put h.264 into ogg, you'd have to write a mapping first.  And then convince a bunch of projects to support your mapping with no blessing from Xiph
[07:24] <gmaxwell> institutionalized and automated
[07:25] <MikeS-tp> ds: but doesn't help with the branding issue that gmaxwell notes. mkv is great in most ways, as far as I can tell - but doesn't make that clear distinction in practical use between "could contain anything" and "free codecs yay!"
[07:27] <gmaxwell> Also, since a fair amount of the logic needed with ogg is codec specific you can't say that a bunch of people running h264 in it would at least encourage non-broken ogg (de)muxers. 
[07:27] <ds> I don't understand the place for matroska.  If I want to use h.264 and aac, I'll use mp4 because it's supported everywhere.  If I'm using a xiph codec (or dirac), I'll use Ogg.
[07:27] <ds> Perhaps if I want to mix h.264 and vorbis, but that seems silly
[07:28] <bemasc> MikeS-tp: DS made this point (from the opposite side, of course) in a recent reddit post.
[07:29] <gmaxwell> the sometimes accusation that ogg is only for xiph codecs can be answered with dirac (or pointing out that flac and speex were both xiph-"acquisitions") 
[07:29] <gmaxwell> (well, and theora too)
[07:29] <bemasc> gmaxwell: Ogg is only for Xiph-approved codecs.
[07:29] <bemasc> This is good if you support the Xiph mission and bad if you don't.
[07:30] <gmaxwell> I think monty has taken the position that it's not "just xiph approved" but ..well, we don't approve of the not xiph approved stuff. It's an open container, do what you like.
[07:30] <ds> We should add an mpeg-1 mapping when it becomes free
[07:31] <MikeS-tp> when is that, anyway? 
[07:31] <xiphmont> right, which is why I wanted to be sure of OGM.  It's a branding issue and a forking issue.
[07:31] <ds> and perhaps a JPEG mapping
[07:31] <gmaxwell> ds: There is also the question of what happens when mp3 becomes free.  (whenever that is, people spread a lot of clearly wrong numbers)
[07:32] <gmaxwell> xiphmont_: I think OGM is mostly a non-issue now because it's mostly dead and gone.
[07:32] <xiphmont> gmaxwell: I agree on that point.
[07:33] <gmaxwell> For full disclosure... I ran a little private campaign about a year ago asking people to take down pages instructing people to use ogm...
[07:33] <gmaxwell> This might be contributing to your difficulty in finding details on it. :)
[07:35] <bemasc> ds: we could do jpeg now, no?
[07:35] <ds> afaik
[07:35] <bemasc> ds: I can't say I see a lot of value in it.
[07:36] * bemasc tries to formulate an opinion on the importance of being able to remux odd things into Ogg.
[07:36] <gmaxwell> I think I reasoned out that the important MP3 expirations wouldn't be later than 2016. (rough conservative numbers based on the latest submarine patents could have surfaced) 
[07:37] <gmaxwell> bemasc: it's only interesting because the things people do instead of using Ogg are worse. 
[07:37] <gmaxwell> e.g. randomly concatinating data.. perhaps with some silly length header.. with the result only working in one application.
[07:38] <bemasc> mp3 already has a widely supported container
[07:38] <ds> gmaxwell: encoding or decoding?
[07:39] <bemasc> mjpeg I guess tends to come in avi or mov
[07:39] <gmaxwell> ds: Decoding, and some encoding, but not all encoders obviously for all I know people are still churning out mp3 encoding relevant patents today.
[07:48] <xiphmont_> the mp3 is only for mp3 I thought.  It's not an MPEG transport is it?
[07:50] <MikeS-tp> xiphmont: nope, mp3 is just an elementary stream. No container at all. Plus then tag formats (id3, ape, id3v2) wrapped around it often
[07:51] <xiphmont_> right, with internal framing
[07:51] <MikeS-tp> usually. 
[07:52] <MikeS-tp> there's also "free format" mp3, which almost nothing supports, where you have to parse the entire bitstream from end to end to figure out the frame length. And there's no external container.
[07:52] <MikeS-tp> so nobody bothers.
[07:53] <MikeS-tp> for normal mp3, the internal framing is a short syncword (11 bits? Something like that), then a few bytes of header that give you the frame length and various other bits of info
[07:53] <Robin_Watts> MikeS-tp: As I remember it, every frame can be a different size in free format.
[07:54] <Robin_Watts> but the header still tells the truth about each frame ?
[07:54] <MikeS-tp> Robin_Watts: no, that's normal VBR.
[07:54] <MikeS-tp> free format the length is NOT specified by the header, but I _think_ every frame has to be the same size
[07:55] <Robin_Watts> Hmm.
[07:55] * Robin_Watts checks AMPlayer sources.
[07:56] <MikeS-tp> (I'm not certain about free format. I _am_ certain that what you described is just normal VBR mp3)
[07:57] <Robin_Watts> MikeS-tp: Right. Free format has the bitrate bits in the header listed as 0.
[07:58] <Robin_Watts> yeah, so presumably you need to do it by hunting for frame markers.
[08:00] <Robin_Watts> You're absolutely right about VBR though.
[08:01] <Robin_Watts> Ages since I looked at any of this stuff.
[08:43] <basilgohar> I can see mapping mp3 into Ogg for using MP3 along with some video.
[08:43] <basilgohar> But only because you don't want to transcode...
[08:43] <basilgohar> And originals are not there.
[08:43] <basilgohar> JPEG would be nice because a lot of webcams (mine, for instance) output MJPEG natively.
[08:44] <nessy> as soon as MP3 patents run out ;-)
[08:44] <basilgohar> Not to mention DV as well.
[08:44] <basilgohar> nessy: That's a given.
[08:44] <nessy> not yet, but yes, they will
[08:44] <basilgohar> I'm just adding some perspective to the point bemasc brought up.
[08:44] <basilgohar> I meant, it's a given not to do it until such a time.
[08:45] <nessy> ah, I see, the discussion has already been had
[08:45] <basilgohar> Having JPEG in Ogg is very useful because then I can stream my webcam "losslessly
[08:45] <basilgohar> " (since it's originally MJPEG).
[08:46] <basilgohar> Logitech Quickcam Pro 5000
[08:46] <basilgohar> What else uses JPEG for video?
[08:47] <basilgohar> Ah, my Canon PowerShot A550 captures video in MJPEG encapsulated n regular AVI
[08:47] <Diablo-D3> lol mjpeg
[08:48] <Diablo-D3> streaming "losslessly" may not be the best idea
[08:48] <Diablo-D3> mjpeg sucks at compression
[08:48] <Diablo-D3> you probably can get theora to recompress it at half the size with no quality loss
[09:06] <basilgohar> Diablo-D3: It may not appear to be the best idea for you, but streaming can be for other purposes.
[09:06] <basilgohar> Ogg can just act as a transport stream for audio + video locally, on the same computer.
[09:07] <basilgohar> I, for one, would appreciate being able to transport the a/v from my webcam losslessly without having to reencode it.
[09:07] <basilgohar> Rather than encapsulating that inside of, say, AVI, which is really less than ideal for streaming.
[09:11] <basilgohar> I see when I can type with two hands, Diablo-D3 cannot respond...
[09:26] <Diablo-D3> sorry, I went to discover food
[09:26] <Diablo-D3> basilgohar: well yeah, streaming audio and video in the same container is nice
[09:27] <Diablo-D3> but if you're only doing it locally, why bother with ogg?
[09:27] <Diablo-D3> if you're really doing it over the internet, you _really_ need to have a singular standard here
[09:38] <gmaxwell> Diablo-D3: there is a big difference between "600 bazillion people" and a smaller set of people that you can ask to install a particular package yet whom are still not local.
[09:39] <Diablo-D3> gmaxwell: yes, there is a difference between people who dont wish to fuck with it, and those who do.
[09:44] <basilgohar> Can some give me a quick summary of what theora-exp is/was?
Session Close: Sun Mar 07 21:48:03 2010