[06:56] meeting time-ish [06:56] yo [06:56] --> r2d has joined this channel (n=nico@83-159-93-59.dsl.tiscali.fr). [06:56] xiphmont__: four aussie beers then? I've had two glasses of wine! [06:56] hi r2d [06:57] hi [06:57] no, no... no drunken meetings. And no, the four beers was a joke. [06:57] maikmerten: you awake? [06:58] _Ivo: are you chairing? [06:58] sure [06:58] I'm just an accessory here. [06:58] I'd prefer not to chair this time. [06:58] <_Ivo> I will do it, then [06:58] thanks Ivo [06:59] <_Ivo> I tried to assemble an agenda, http://wiki.xiph.org/index.php/TheoraMeeting20080411 [07:00] <_Ivo> I forgot to add "discuss the MSVC patches" [07:01] <_Ivo> anyway, let's start by the final roadblocks. [07:02] so as of an hour ago we pass 'make check' [07:02] <_Ivo> progress [07:02] I really don't think the new api is ready for freeze [07:02] especially the encode side [07:02] but I suppose we could call it a buggy 1.0 [07:02] no, 1.0 doesn;t have performance to offer, so it better have stability ;-) [07:03] <_Ivo> besides the documentation lack (did anyone start working on that part yet), what is wrong with the API? [07:03] [not here] [07:03] (is the new API actually important for this "legacy 1.0 - it's all about stability" release?) [07:05] maikmerten: derf thought so [07:05] if the new API is considered "unstable" this at least get rid of the "examples used the old API" blocker ;-) [07:05] I don't think the new api is essential [07:06] but the idea is that we should start transitioning people [07:06] <_Ivo> yes [07:06] also, ubuntu is already shipping the new libraries [07:06] so I think we should just say it's subject to change [07:06] maikmerten: and yes, that shouldn't be a blocker [07:07] of course, currently it's only encoder_example that uses the new api... [07:07] --> kfish has joined this channel (n=conrad@60-56-210-121.eonet.ne.jp). [07:08] <_Ivo> rillian, you said the encoding part of the API isn't ready. Might as well report now what isn't working [07:10] well, I think the initialization should be more robust and fill in more missing fields [07:10] but my main concern is that it just hasn't had enough review [07:10] so I don't think it's stable the way the old api is stable, having been in use for years [07:10] As I said, I don't know that that has to hold up the release. [07:11] <_Ivo> ok [07:11] <_Ivo> the beta todo page suggests a solution for the API transition [07:11] does anyone understand teh mmx/selinux bug? [07:11] <_Ivo> "Instead we can provide theora_control() switches for this, and mark the theora_info struct entries as deprecated to encourage transition." [07:12] ah, that [07:13] well, we've decided to provide both apis with libtheoraenc/dec, so I think it's better to just make it a new code/old code thing [07:15] I guess we could apply the patches from 1266 [07:15] and call that beta3 [07:15] <_Ivo> all right. what is the deal with selinux? that's supposed to be a security thingy, why would theora be causing problems with it? [07:16] as I understand it, the old encoder's mmx code uses too many registers [07:16] yep [07:16] which requires the linker to do some more editing than selinux likes [07:16] so selinux is firing a false alarm? [07:17] it is also the case the code should be corrected-- for example it will only build correctly if optimization is enabled. [07:17] Otherwise it uses more registers than is actually available and compile fails completely. [07:17] s/is/are/ [07:17] so we should probably treat it as our bug regardless. [07:18] maikmerten: it's a "false alarm" because the code isn't malicious [07:18] <_Ivo> ok, does the 1266 patch address this, or is it another problems altogether? [07:18] xiphmont__: I don't suppose you'd like to 'just do that' [07:18] <_Ivo> problem* [07:18] rillianbis, 'touche', not sure I'mcapable [07:18] either yourself, or checking the patches on https://trac.xiph.org/ticket/1266 [07:18] yup, so it's more like "their" problem (which of course isn't a viable attitude as it will bit *our* users) [07:19] s/bit/bite [07:19] I could certainly *try* [07:19] maikmerten: yes, especially when some distros have it on by default [07:19] I don;t even have an SSE reference though :-) [07:20] well, it if fixes the bug, doesn't change the output and compiles with -fPIC, that would be enough, no? [07:20] OK, I'll go buy a book. [07:21] s/-fPIC/-fomit-frame-pointer [07:21] -vomit-frame-pointer [07:21] xiphmont__: sure. there are reasonable references on intel's site too [07:21] OK [07:21] I find the inline asm syntax the mysterious part [07:21] inline asm syntax I can do [07:22] Does this hit the VC assembly too? [07:22] I've no idea if they have a similar bug [07:22] the patch is just mmx [07:22] I'm unclear how it's gaining a register, actually [07:23] they seem to just be using di instead of ax [07:24] heh [07:25] Fix attempt is first on the list tomorrow morning [07:25] The problem is just on SELinux, or potentially any other Linux, yeah? Why not leave the VC patch alone, as it's not an issue on Windows. [07:25] <_Ivo> I think the question was IF it was affecting Windows [07:25] yes [07:25] in some way [07:26] <_Ivo> if it isn't, nobody's going to modify what isn't broken [07:26] prolly not [07:26] but you can never tell in open source [07:26] they took off the MANGLE macro, which I assume breaks macos [07:26] <_Ivo> (Vista is weird, but selinux takes the cake on paranoia) [07:27] andrew__: we need to get the MSVC patch in, but it's orthogonal to this issue [07:27] and the release, absent a win32 maintainer [07:28] silvia got a bite fishing for a new directshow person, so hopefully we'll have someone to verify these things in the nearish future [07:28] *sweet* [07:29] sweet indeed [07:29] _Ivo: so, I think we release a new beta after the selinux thing is fixed [07:29] <_Ivo> ETA? [07:29] and if no one notices anything further, we can do 1.0 a few weeks later [07:30] we're blocked on the selinux/frame-pointer thing [07:30] by the way, whenever we mention 1.0... should we stress that 1.0 will be for stability, not for performance and already start talking about 1.1? [07:30] maikmerten: yes [07:30] well, we should stress it's for stability [07:30] <_Ivo> and if you are doing a beta, you might as well add the VS stuff even if we are not yet sure if it's a perfect solution [07:31] and start talking about 1.1 once the thusnelda performance is actually better :) [07:31] Thusnelda is not far off. [07:31] rock [07:31] in the sense that the changes can be merged back soon [07:32] well, no idea (layman here), but thusnelda apparently is rather "ringy" [07:32] but I think quantization wasn't touched yet, so this wouldn't be unexpected [07:32] thusnelda is missing two pieces necessary to make it practical [07:32] _Ivo: sure. I just don't think the VS stuff should block release [07:33] well, anyway, a beta 3 smells like a good idea [07:33] <_Ivo> rillianbis: which is why it should get in beta now instead of waiting for this win32 guy who hasn't even confirmed he will be able to check on theora stuff [07:34] release early, release oftewn [07:34] we need to get back into practice [07:34] <_Ivo> something like that, which reminds me that we need a new ffmpeg2theora out ASAP [07:36] in other news, commandline handbrake now does theora. hopefully the next mac release will too [07:36] thanks to saintdev [07:36] yay [07:36] <_Ivo> progress [07:36] _Ivo: we ready to move on? [07:37] <_Ivo> I suppose. I'm wondering if you could provide an ETA for beta3 [07:37] Is there a verdict on what to do with the VS patch? [07:38] As maikmerten says, if there's going to be a beta3, would be nice to get it in there for some wider testing. Can always be reverted at 1.0 if it doesn't work out, I suppose. [07:39] andrew__: ah, you're Andrew Chew who forwarded the email? [07:39] [I don;t know what the patch is supposed to be, I have no opinion to offer.... but testing is good ;-] [07:39] can you test these things? [07:39] Yes :P [07:39] sorry, took a while to connect [07:39] <_Ivo> xiphmont__: http://lists.xiph.org/pipermail/theora-dev/2007-December/003497.html [07:39] Yes, as soon as it's in, I will migrate to it immediately. [07:39] yes, that's enough to go ahead and put it in mainline [07:40] <_Ivo> andrew__: having a win32 guy able to test these things make the process go much faster [07:40] That's great :) I'll also urge Nils to migrate to beta3 to get another tester on this. [07:41] <_Ivo> rillian, you seem to be looking into older tickets. Could you make a brief assessment of 1328, 1338, and 1336? [07:42] <_Ivo> just to confirm if there's anything worthwile to go into beta3 [07:42] I'll deal with seeing how it affects Thusnelda. [07:42] [the horror of forks] [07:43] andrew__: I'm trying to merge now. the vcproject stuff is out of date, so I'll probably punt on that the rest I'll commit [07:44] That's fine, thanks [07:44] 1328 should be fixed, but isn't important [07:44] Actually, if you merge that, I can try to fix the vcproject stuff and provide a patch. Say, this weekend [07:44] 1338 I don't know about [07:44] derf could do it in half an hour :) [07:45] let me look [07:45] ah, this one [07:45] 1336 should be fixed [07:46] th_encode_dupframe_in()? [07:46] th_encode_dupframe)? [07:46] there's another API request as well, to ask for rate/quality changes on the fly [07:46] adding that to the new API through the control() call is easy enough [07:46] or whatever [07:47] xiphmont__: right. that's more an encoder feature and shouldn't affect api [07:47] ...did it really want a dupre encoded frame or a drop frame? [07:47] xiphmont__: the theory is that if you know you need to insert a duplicate frame, it's nice to be able to tell the encoder you're doing that to save time [07:48] e.g. when you're correcting for clock drift [07:48] much more so if you're doing thomasvs' "simulating variable framerate" thing where most frames are duplicates [07:48] ok, sure [07:48] 'anyway' [07:49] If that's a blocker, you can give it to me. [07:49] in theory the encoder can just turn around and emit a zero-length packet, but if you'd set the "VP3_COMPATIBLE" profile, it should probably emit a non-intra-no-mv packet, which is also cheap [07:50] and of course, if you're at a forced keyframe you have to reencode the previous buffer [07:50] Oh, right. VP3 compat [07:50] sure [07:50] I thought that contract did already expire ;-) [07:50] it's a blocker if a stable theoraenc api is a blocker [07:50] BTW... we might want to officially fuck VP3 compat soon. [07:50] <_Ivo> whatever's needed for improvement [07:50] xiphmont__: I really think you should maintain a compatability mode [07:51] *adding* calls is not 'unstable' [07:51] it can be no better than the current libtheora [07:51] xiphmont__: sure [07:51] rillianbis, there are reasons to throw off VP3 compat, and they're not technical. [07:51] but there's a big installed base that doesn't have the rewritten decoder yet [07:51] xiphmont__: oh? [07:51] unfortunately, it's not a discussion to have here. [07:52] ok, later [07:52] [it was part of conversations that were not public] [07:52] <_Ivo> [I thought they were supposed to be now] [07:52] but visibly breaking the installed VP3 base might have more 'unexpected' benefit than you might think ;-) [07:52] well, it would kill off the alpha installation base [07:53] yes [07:53] <_Ivo> anyway, at some point Theora would have to break compatibility with VP3. [07:53] <-- rillian has left this server (Nick collision from services.). [07:53] *** rillianbis is now known as rillian. [07:53] thusnelda will break it *hard* anyway [07:53] thusnelda already shatters the old decoders. [07:53] --> rillian_ has joined this channel (n=giles@mist.thaumas.net). [07:53] <_Ivo> older versions of the library will be available for those few cases that require VP3 compatibility [07:54] anyway, it may be wise to ask the annodex people about progress on their "Netscape" plugin and their ActiveX thingie [07:54] --> Venus_Mars has joined this channel (n=nithin@203.78.217.176). [07:54] maikmerten, oggplay? [07:54] just so web-authors have a reliable way to embedd Theora content [07:54] <_Ivo> maikmerten: only kfish is here, and he's directly involved [07:54] kfish, ah, hi, sorry, didn't notice you [07:54] <_Ivo> isn't* [07:55] anyway, I think the oggplay plugin can be more robust than Java ever can be [07:55] either the applet is buggy (it is) or the Java plugin is a mess (it is) [07:55] <_Ivo> from personal experience, they both are [07:55] <_Ivo> but oggplay doesn't seem any better right now (AFAIK) [07:56] so if we can cover Firefox/Opera/Konqueror on the one side and Internet Explorer on the other side with non-Java technology that may be better than riding that dead Java applet horse [07:56] _Ivo, if you have bugs to report please do so [07:56] <_Ivo> in time, I will [07:57] the plan for Internet Explorer is a bit vague [07:57] there's a two years old posting about how more information about an ActiveX thingie will be posted later on [07:57] but that's about it [07:57] http://annodex.org/wiki/Committee/Meetings/2008_03_11#6._Update_on_CSIRO.2FFunnelback_communications [07:57] <_Ivo> rillian: I can't find the first part of this message, http://lists.xiph.org/pipermail/theora-dev/2008-January/003520.html Do you still remember what was broken here? [07:58] oooh, thanks [07:59] <_Ivo> kfish: fresh news are good, thanks [07:59] _Ivo: I'm not sure. I think it was a bug in the progress bar. I think it got fixed [08:00] <_Ivo> goodie. Much less bugs than expected [08:01] <_Ivo> All right, moving on to one of the next items in agenda [08:01] <_Ivo> eTheora, I guess [08:01] ribamar is not here [08:01] <_Ivo> anyone played around with it yet? Ribamar has started working on audio part lately [08:02] I haven't looked at it in a while [08:02] hi Venus_Mars [08:02] is he getting any users? [08:03] <_Ivo> I don't know. [08:03] i'd like to encourage that to turn into a high level encode+mux library [08:03] ie. something like liboggplay, but for encoding [08:03] it'd be useful for many things, like some of the other soc projects [08:03] (well, one potential customer for eTheora would be the Darkplaces game engine, which would start recording gameplay videos once eTheora happens to also have sound) [08:04] cool [08:04] <_Ivo> indeed [08:04] (Darkplaces is used in Nexuiz, the all-GPL deathmatch game) [08:04] (awesome) [08:05] <_Ivo> I will email him this part of the log. [08:06] <_Ivo> The logo issue is an item, too. Has there been new developments since the last meeting? [08:07] yes. [08:07] But none worth reporting yet [08:07] In the sense I have had one session with the graphic artist to discuss the logo. [08:08] <_Ivo> cool [08:08] [he is also a redhat employee, one cube down in fact] [08:09] if you want to give him a shock treatment just point him to my home dir on people.xiph.org [08:09] I did something like that already [08:10] <_Ivo> now he cannot unseen what he has seen [08:11] <_Ivo> moving on to ffmpeg2theora [08:11] that's... ungrammatical but scans nicely. [08:11] <_Ivo> j isn't here, so, not really much that we can go over. I'd realy like to help him figure out the last couple of bugs that were reported on Trac, and then get a new release out. [08:13] <_Ivo> since people consider it the only proper Theora encoder, having in top shape would be a priority [08:15] <_Ivo> finally, I have been in contact with Henrik Olsson who's interested in my GSoC proposal to build a qt4 wrapper around the different encoders. I'd say things are looking good here. [08:15] oh, that's nice to hear [08:15] yes, it looked like an interesting project [08:15] I was hoping we could pursuade arkadini to host [08:15] mentor, i mean [08:16] <_Ivo> yes, that is the only issue pending: there's no mentor [08:16] Qt gui, not quicktime [08:16] kfish: no overlap then? [08:16] completely unrelated to quicktime [08:16] I thought silvia suggested it, and assumed she knew what she was talking about [08:17] just a qt gui to select a file and encode it [08:17] ah [08:17] both topics were discussed at the last theora meeting, hence the confusion [08:17] <_Ivo> yeah, and Qt is cross platform [08:17] so we can only half mentor that, unless one of use is hiding some Qt expertise [08:17] <_Ivo> so it would be a nice way to have a GUI encoder for everything Xiph in one place, working across every system [08:17] i think it's a useful project, but too trivial for gsoc [08:17] I'm temped to volunteer, but I don't really have time this summer :( [08:19] <_Ivo> kfish: why would you say it is trivial? getting it right will be a complex task [08:19] and you can do dirac if the theora part works [08:20] can we wrap up soon? [08:20] <_Ivo> yes [08:20] <_Ivo> last item in agenda is the first one: release date. so if everything goes well, 1.0 will be out a few weeks after beta3 [08:20] <_Ivo> but we still don't know when beta3 will be out [08:22] <_Ivo> I guess maybe just share thoughts on how much time will be expected to get it out is enough to cover the topic. [08:22] well, monty said he would try the selinux problem tomorrow [08:22] yes [08:22] <_Ivo> basically, if I got it right, is about committing the VS patches and look into the selinux issue [08:22] <_Ivo> which is a good thing [08:23] I'm merging the VS patch to cpu.c, but if I don't get it done tonight, it will probably be a week [08:23] <_Ivo> all right, we'll say beta3 is out in one week. [08:24] _Ivo: thanks for organizing! [08:24] <_Ivo> thanks. I pulled an all nighter to be here [08:25] <_Ivo> and thanks to everyone else who joined, too. [08:25] yes, thanks everyone [08:25] thanks _Ivo [08:25] cheers [08:25] <_Ivo> I'll be posting the log soon [08:26] 'night all. Thank you Ivo. [08:26] Thanks everyone!