From: IRC B. <wt...@us...> - 2002-01-16 05:27:49
|
******************************************************************* [03:12] rkarl (~rkarl@12.13.175.27) joined #gstreamer. [03:12] <snax> how will gst clock work? [03:13] <snax> do you stick it in both the audio and video pipes and it feeds it through correctly? [03:17] Company (Company@pD9500527.dip.t-dialin.net) got netsplit. [03:17] rkarl (rkarl@12.13.175.27) got netsplit. [03:17] snax (sn...@12...) got netsplit. [03:17] thomasvs-sleep (th...@ad...) got netsplit. [03:17] chillywilly (da...@d1...) got netsplit. [03:17] rowenc (rowenc@Hong-231-192.PLU.edu) got netsplit. [03:17] ds (ds...@12...) got netsplit. [03:17] wtay-zZz (wi...@ca...) got netsplit. [03:17] rambokid (tj...@hm...) got netsplit. [03:23] rambokid (~tj...@hm...) got lost in the net-split. [03:23] rowenc (~rowenc@Hong-231-192.PLU.edu) got lost in the net-split. [03:23] wtay-zZz (~wi...@ca...) got lost in the net-split. [03:23] ds (~ds...@12...) got lost in the net-split. [03:23] chillywilly (~da...@d1...) got lost in the net-split. [03:23] thomasvs-sleep (~th...@ad...) got lost in the net-split. [03:23] snax (sn...@12...) got lost in the net-split. [03:23] Company (~Company@pD9500527.dip.t-dialin.net) got lost in the net-split. [03:23] rkarl (~rkarl@12.13.175.27) got lost in the net-split. [03:25] rkarl (~rkarl@12.13.175.27) joined #gstreamer. [03:25] snax (sn...@12...) joined #gstreamer. [03:25] thomasvs-sleep (~th...@ad...) joined #gstreamer. [03:25] chillywilly (~da...@d1...) joined #gstreamer. [03:25] rowenc (~rowenc@Hong-231-192.PLU.edu) joined #gstreamer. [03:25] ds (~ds...@12...) joined #gstreamer. [03:25] wtay-zZz (~wi...@ca...) joined #gstreamer. [03:25] rambokid (~tj...@hm...) joined #gstreamer. [03:26] Company (~Company@pD9500527.dip.t-dialin.net) joined #gstreamer. [03:27] <snax> SPEW [03:45] Nick change: leif-class -> leif [04:03] rambaby (~tj...@hm...) joined #gstreamer. [04:03] rambokid (tj...@hm...) left irc: Read error: 54 (Connection reset by peer) [04:07] Action: derek is away: movie [04:13] omega (~om...@om...) joined #gstreamer. [04:14] <omega> taaz: I'm confused, I didn't change the struct definition at all, but a memory dump looks very different in structtest than it does in specialib [04:16] <taaz> haha [04:18] <taaz> maybe some libtool thing [04:22] <omega> nope [04:25] <taaz> what kind of church music do you deal with? [04:25] <omega> um, 'kind' ? [04:25] <Company> uh, that's one nasty bug [04:27] <taaz> i've been going through my whole cd collection, it's taken like 6-8 weeks. so i'm at the bottom of the barrel right now. i found this "spiritual warfare sample" "tearing down strongholds" cd [04:27] <taaz> i have no idea where this came from... so i'm listening to it and my ears are bleeding [04:27] <omega> hmm, it could be just about anything, style-wise [04:28] <taaz> i really don't listen to this relgious stuff at all... there's like 1 gospelish song that has musical value but the rest... [04:28] <omega> it depends heavily on how it's done, there are many ways to do them very badly [04:29] <taaz> i mean really, 50% of the words are Lord, Jesus, Christ, God, Him, or He. that's like just as repetative as the bass in dance music... [04:29] <omega> yeah, there's that too. a lot of the more recent stuff (afaict) is rather simplistic, lyrically [04:30] <taaz> lots of stuff about armies too... i assume that doesnt mean military but i dunno [04:30] <omega> no, nnot military [04:31] <taaz> i mean i could totally twist these words and claim these people are devil worshipers [04:31] <taaz> i was just wondering if there's a better sample of this sort of music, cause this aint it. [04:31] <omega> I'm sure CHW could pick something less annoying [04:33] <taaz> what's the significance of blood from a lamb? [04:34] <taaz> i'm not figuring out this code btw... something weird going on [04:36] <taaz> and i don't quite get what you're trying to do [04:36] <omega> which code? [04:36] <taaz> like everytime you include average.h you'll get a redef of all the C funcs right? [04:37] <omega> yes, for inlining [04:38] <taaz> ok [04:38] <taaz> well... [04:38] <taaz> i don't get that either. what's the overall idea here? [04:39] <omega> sec, sending you what I sent vektor [04:39] <taaz> where do you inline vs switch on func pointers? [04:39] <omega> sent [04:41] <taaz> why don't you just put this stuff in codecs.org cvs and use web page for info? [04:41] <omega> I will as soon as I get around to it [04:41] <taaz> less likely to loss stuff via tar that way ;) [04:42] <omega> well, this isn't going in cvs until it's more structured, which is still a little ways off [04:42] <omega> otherwise stuff moves around all the time, and we know what that does [04:42] Action: taaz thinks omega missing the point [04:43] <taaz> yeah, so i have this theory [04:43] <taaz> software development is hindered by cvs [04:43] <taaz> how many times have you not put stuff under src ctrl because you know you might rename or move it later and dont want to lose file/dir/etc history? [04:43] <taaz> for me the answer is lots [04:44] <omega> yes, cvs needs work [04:44] <taaz> yeah, it's spelled s u b v e r s i o n [04:44] <omega> is it usable? [04:44] <omega> [yet] [04:44] <taaz> or bitkeeper if you can deal with their license [04:45] <taaz> getting there... i tried it close to 2 months ago [04:45] <taaz> basic stuff worked ... i didn't trust it yet though ;) [04:45] <taaz> really a shame bitkeeper isnt GPL [04:45] <omega> well, if it isn't ready, it won't be used [04:45] <taaz> it's got every feature i'd like... [04:45] <omega> as soon as it is, if they can convince people to use it and trust it, I'll switch in a heartbeat [04:46] <omega> problem is getting SF to host it [04:51] <taaz> omega: i've got a gstreamer issue for you to work on: sync [04:51] <omega> heh [04:51] <taaz> i'm serious [04:52] <taaz> dude, we can't call this a multimedia framework if a/v are out of sync [04:52] <omega> yup [04:52] <taaz> and right now they are [04:52] <rkarl> heh [04:53] <taaz> i mean, even some crap hack to add delay one one signal and manual adjustment would be better than nothing [04:55] <omega> ok, so this raises a whole lot of issues that are not at all solved still [04:55] Action: omega hunts for vektor [05:01] <taaz> so anyway, isn't it just easier to recompile libs with various flags and install them so the run time link can find em? [05:01] <taaz> open("i686/mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) [05:01] <taaz> open("i686/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) [05:01] <taaz> open("mmx/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) [05:01] <taaz> open("libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory) [05:01] <taaz> i mean, that's what it does now... [05:01] <omega> eh? [05:01] <taaz> it's not runtime flexable [05:02] <omega> hrm, my system doesn't have that [05:02] <omega> blah [05:02] <taaz> oh? [05:02] <ds> run strace [05:02] <taaz> strace ls and see what happens [05:02] thomasvs-sleep (th...@ad...) left irc: Read error: 60 (Operation timed out) [05:02] <omega> open("/lib/libc.so.6", O_RDONLY) = 3 [05:03] <ds> what are you running? not debian, apparently [05:03] <omega> rh72 [05:03] vektor (reet@HSE-Kitchener-ppp3506571.sympatico.ca) joined #gstreamer. [05:03] <vektor> i can't talk right now. [05:03] <omega> bah [05:03] <vektor> in case you're still talking :) [05:03] <vektor> sorry i just got home [05:03] <vektor> had a big NIS+ experience today :) [05:03] <vektor> i'm wiped out :) [05:03] <omega> ouch [05:03] <vektor> helped setup NIS+ between a solaris server and a debian client and soon a HURD client :( [05:04] <vektor> ugh. [05:04] <ds> omega: btw, the specialib stuff looks good [05:04] <vektor> the netwinder client will be another challenge :) [05:04] <vektor> ds: doesn't it though? [05:04] <vektor> ds: big fan here. [05:04] <ds> I just wanna see the code. So I can write code [05:04] <taaz> so you specialib superfans... you should debug the weird problem omega has now [05:05] Action: taaz pokes omega in the put-it-in-cvs bone [05:05] <omega> taaz: heh [05:05] <ds> I want to go play with my new arc welder [05:06] <taaz> mmmm welding [05:06] <omega> ds: you have time? [05:07] <ds> I suppose [05:07] <omega> ds: building a battlebot? <g> [05:07] <omega> gimme a sec to make sure it builds on my end, then I'll send you a tarbzll [05:07] <ds> I'm fixing my car [05:08] <omega> fixing a car with an arcwelder? hmm [05:08] <taaz> omega: why specialib/sl_preamble.h vs just specialib/preamble.h? [05:08] <omega> no reason atm [05:08] Company (Company@pD9500527.dip.t-dialin.net) left irc: "Client Exiting" [05:09] <omega> ds: on the way [05:10] <omega> ./autogen.sh;make in toplevel and example/ [05:11] thomasvs-sleep (~th...@ad...) joined #gstreamer. [05:14] chillywilly_ (~da...@d1...) joined #gstreamer. [05:14] <omega> test1 in example/tests/ is the program in question, the memory dump does *not* match the _slib_funcptr_def struct defined in example/average/average.h [05:14] <omega> but structtest.c has the exact same structure, and the memory dump there is correct [05:14] chillywilly (da...@d1...) left irc: Killed (NickServ (Ghost: chillywilly_!~da...@d1...)) [05:14] Nick change: chillywilly_ -> chillywilly [05:16] Nick change: wingo-food -> wingo [05:19] <ds> omega: I'm reattaching body panels. I wanted to get a spot welder, but they are pretty specialized, and not very versatile [05:19] rkarl (rkarl@12.13.175.27) left irc: Read error: 60 (Operation timed out) [05:22] <ds> test1.c: [05:22] <ds> undefined reference to __average_U8_U8__x86_mmx [05:26] Nick change: omega -> omega_phone [05:26] <omega_phone> brb [05:28] <ds> taaz: what's the problem? [05:38] royerk (~royerk@ATuileries-106-1-4-125.abo.wanadoo.fr) joined #gstreamer. [05:41] royerk (royerk@ATuileries-106-1-4-125.abo.wanadoo.fr) left irc: "Client Exiting" [05:44] <taaz> did you run test1? [05:45] <ds> I can't even get it to compile with MMX and SSE [05:45] Action: taaz just got new CD, Strings of Fire - The Acoustic Tribute To Guns n' Roses. ;) [05:45] <ds> example/config.h doesn't have SL_COMPILE_X86_MMX or whatever [05:45] <taaz> um... [05:46] <ds> maybe it's supposed to be somewhere else, but it's not getting defined here [05:46] <taaz> for which file? test1? [05:47] <ds> ./configure: SL_CHECK_ARCHITECTURE: command not found [05:47] <taaz> i probably have a different version... too bad we can't sync on cvs code. <g> [05:47] <ds> =} [05:48] <taaz> eh... yeah i have that too.. just ignore it ;) [05:48] <ds> then test1.c doesn't compile [05:49] <wingo> xpath is com-pli-cated [05:50] <taaz> ds: yeah... hmm... i did this last night while close to zzz's, dunno how i got it to work now though. ;) [05:50] <taaz> xslt is complicamated too [05:51] <ds> did you install it? [05:51] <ds> specialib, that is [05:51] <taaz> nope [05:53] <ds> export ACLOCAL_FLAGS="-I ../m4" [05:53] <ds> that worked [05:54] <ds> so the segfault is bad? [05:54] <taaz> yeah [05:54] <taaz> well... [05:55] <taaz> i'm going to blame omeags code [05:55] <taaz> something weird going on.. [05:56] <taaz> mine's still not compiling ;) [05:57] <ds> how does one run gdb on a libtool executable? [05:58] <taaz> libtool gdb test1 [05:59] <ds> blah blah lt-test1 not found [05:59] <ds> .libs/lt-test1 not found [05:59] <taaz> you have latest libtool? [05:59] <ds> 1.4.2-1 [05:59] <ds> from sid [06:00] <ds> gdb .libs/lt-test1 core works [06:00] <wingo> upgrade libtool [06:00] <wingo> -4 is out [06:00] <wingo> it fixes that bug [06:00] <taaz> err. you may need -4 [06:02] <ds> 133 packages upgraded. It must have been about 4 days then [06:07] Action: derek is back (gone 02:00:44) [06:08] Nick change: omega_phone -> omega [06:09] <ds> what is the problem? [06:09] <omega> memory does not match the struct [06:09] <omega> the specialib.c code segfaults [06:09] <omega> but it does match in structtest [06:11] <omega> bah, I had specialib RPMs installed from somewhere, no wonder it builds more easily on my machine [06:12] <leif> anybody feel like fielding an audio filter question ? [06:13] <ds> yeah, you need 'export ACLOCAL_FLAGS="-I ../m4"' in examples/autogen.sh [06:13] <omega> leif: the deafening sound of `gst-launch silence ! osssink` ;-( [06:13] <omega> ds: yeah, added that [06:13] <taaz> ah... forgot about that extra static thing in my version [06:14] <omega> taaz: extra static thing? on the _slib_funcptr_defs ? [06:14] <taaz> yeah [06:14] <leif> omega : yeah ... or maybe `gst-launch afsrc location="crickets.wav" ...` [06:14] <taaz> i rebuilt everything and that .proto thing overwrote it [06:14] <omega> taaz: oh, right [06:15] <omega> once I rewrite the code that generates those .h files it'll get easier [06:15] <omega> taaz: did that email make sense? [06:16] <taaz> i was supposed to read it? [06:16] <omega> um, yeah ;-) [06:16] <omega> understand it too, if you can <g> [06:17] <taaz> just a min.. i like walked home and been sidetracked making food since you sent it ;) [06:17] <ds> omega: The only lead I have right now is that __fpd_average_U8_U8 ends up in the .bss section [06:17] <omega> why would that change the layout of it? [06:18] <ds> it shouldn't. But it means that the data is copied out of some read-only area of the library into that area [06:18] <ds> this happens at library load time [06:18] <omega> it is read-only data though so it shouldn't have to copy it [06:19] <omega> if I need to add stuff to make that clear to the compiler [06:19] <omega> oh wait [06:19] <ds> then you should make it const [06:19] <omega> nevermind, the last element could be changed, to tack another table on the end at run-time [06:19] <omega> bleagh [06:20] Action: leif gapes in wonder at gstbufferpool.c [06:22] <omega> leif: why? [06:23] <ds> Ok, I understand what is happening [06:24] <ds> if you run 'nm --size .libs/test1', you get that the size of __fpd_average_U8_U8 is 4 [06:24] <ds> which is obviously wrong. [06:24] <omega> oh, neet. so why does gcc do it right in structtest? [06:24] <ds> but that explains why only 4 bytes of the ro data is copied [06:24] <omega> ah [06:24] <omega> great [06:25] <omega> so do I have to solve it by making entries a pointer to an external table? there are enough symbols in this thing as it is ;-( [06:25] <leif> omega : trying to figger out when i need to have a filter_parse_caps function, looks like i don't if i use a bufferpool (right ?) [06:26] <omega> bufferpools aren't related to caps at all [06:26] <ds> structtest doesn't reference __fpd_average_U8_U8 [06:26] <omega> uh? [06:26] <ds> well, from the library [06:26] <omega> right [06:27] <ds> So in structtest, the data is defined in the executable [06:27] <omega> right [06:27] <ds> in test1, it's from the library, and only 4 bytes are copied [06:28] <omega> so, __fpd_* are computer-generated, it won't be a problem to rearrange the struct, but I'm also aiming for some efficiency as far as memory, but mostly symbol count [06:30] <omega> I guess it's not too bad, an extra symbol, but annoying [06:30] <ds> I don't you can do it in such a way that _slib_funcptr_def has a size of 4 [06:30] <omega> IMO this is a gcc bug though [06:30] <ds> which is what happend with entries[0] [06:30] <omega> it knows how big it is, and deals with [0] everywhere else.... [06:31] <ds> It probably could be considered a gcc bug [06:31] <omega> have you verified it's listed as 4 bytes? none of the binutils functions understand the ELF symbol-size field [06:31] <ds> uh. [06:31] <ds> nm --size? [06:31] <omega> that doesn't use the size field [06:31] <omega> it sorts them by location and subtracts each neighbor pair [06:32] <omega> that's why you get symbols that are the size of the whole section [06:33] <omega> binutils internal structures have no size field, and the docs state that such information may be carried in a private struct somewhere, but may be completely lost if you restructure the file at all [06:33] <omega> one of the many reasons I dislike binutils [06:34] <ds> right [06:34] <omega> I spent much time tracing all the relevant code, it's really really nasty stuff [06:34] <ds> readelf -s, then [06:34] <omega> needs a ground-up rewrite [06:34] <omega> ah, ok, there it is [06:35] <omega> pff, and readelf comes from binutils [06:35] <omega> you'd think they'd bother to fold the "brand new" ELF format changes into the rest of it [06:36] <omega> oh for infinite time to fix such things [06:36] <ds> but readelf doesn't use libbfd, which is the problem [06:36] <omega> right [06:36] <omega> it's a totally standalone tool [06:36] <ds> it just reads elf files directly [06:37] <ds> I could recompile uClibc's ld.so with debugging on, which will dump size information [06:37] <ds> =) [06:37] <omega> heh [06:37] <omega> now the question is, if I have a _slib_funcptr_entry __fpe_average_U8_U8[] = { ... } [06:37] <omega> is the size going to end up 0 ? [06:38] <omega> I kinda have no choice, because the SL_COMPILE_ARCH_* macros change how big the array is depending on the compiler features, so I can't have the script just count them up [06:39] <omega> I could have a ..._U8_U8[1 [06:39] <omega> #ifdef SL_COMPILE_ARCH_X86_MMX [06:39] <omega> +1 [06:39] <omega> #endif [06:39] <omega> . . . . . [06:39] <omega> ] = { [06:39] <omega> ;-) [06:39] <omega> the cpp run would only take about an hour per file........ [06:40] <ds> put them in a .a? [06:40] <omega> huh? [06:40] <omega> the last element is writable [06:40] <omega> and I'd rather not resort to linker tricks if possible [06:40] <ds> application links with two libraries, one static and one dynamic [06:40] <omega> eew [06:41] <omega> <g> [06:41] <ds> the static one has all the writeable information [06:41] Action: ds chucks ideas [06:41] <omega> oooh, that works [06:42] <omega> ok, the [] array has the correct size [06:42] <omega> so it's definitely a bug in gcc [06:43] <omega> what gcc ver do you have? [06:43] <ds> 2.95.4 [06:43] <omega> anyone have gcc3 handy? [06:43] <ds> I'll check it on gcc-3.0, if you tell me how to pass CC= to autogen.sh [06:44] <omega> should be just CC=gcc ./autogen.sh [06:44] <omega> or just CC=gcc3 make [06:44] <omega> should do the trick [06:44] <ds> yep [06:44] leif (lmj...@rd...) left irc: "BitchX: its magically delicious!" [06:45] <omega> ack, I get huge warnings from the header now though [06:45] <omega> oh, gah [06:45] <omega> .proto strikes again [06:45] <ds> heh [06:45] <ds> deprecated initialization of zero-length array [06:45] <omega> pfff [06:45] <omega> how else are you supposed to *USE* a zero-lenght array?? [06:46] <ds> you're not supposed to use the size of it [06:47] <omega> meaning? [06:48] <ds> besides, zero-length arrays are a gcc-ism [06:48] <ds> maybe in C99, though? [06:48] <omega> right, and there is no other way to do this, short of that nasty +1 trick above [06:49] Action: ds thinks omega should use linked lists [06:49] <omega> very wasteful in this case [06:49] <omega> just sent you a new average.h [06:50] <ds> who cares. A symbol takes up 72 bytes [06:50] <omega> in specialib.h change the entries[] to *entries, the code needs no changes afaict [06:50] <omega> and a symbol has to be relocated at load time [06:50] <omega> imagine having half a dozen implementations of hundreds and hundreds of algos [06:50] <omega> not only a function symbol, but a bookkeeping symbol to go with it [06:51] <omega> it's bad enough with the symbol functions themselves... [06:52] <omega> libcodec has 1083 symbols already, and it just does mcomp and a tiny bit of yuv/idct [06:53] <ds> hmmm... I'm dreaming up an idea [06:53] <ds> it's gonna suck [06:53] <omega> uh oh [06:54] <ds> do the symbol resolution yourself: [06:54] <wingo> yay, gst-xmllaunch works [06:55] <ds> keep a list of symbols _names_ and their architecture info [06:55] <omega> that's what I'm doing here, with the symbolic names [06:55] <omega> much more efficiently, even if it were a linked list [06:55] <ds> then, when you want average_U8_U8, have it constructed using dl_sym() [06:56] <ds> er? aren't you using the symbols themselves? [06:56] <omega> except the function names are fixed, part of the API, it's only the various implementations that have various suffixes [06:56] <omega> no, for each function there's one of these tables, and the various specialized versions are listed with just a symbolic arch ID and the funcptr [06:57] <ds> yes, but if you keep the symbolic arch ID and the name, you can do the funcptr lookup yourself [06:57] <omega> why? [06:58] <ds> you get around the problem of ld.so resolving a bajillion symbols at library load time [06:58] <ds> because you choose when to resolve them [06:58] <omega> ok [06:58] <omega> you sure that is true? [06:58] <ds> ld.so doesn't do lazy relocation for (int *) x = &func; [06:59] <omega> what about the funcptrs in the structs? do they get evaluated before they're used? [06:59] <omega> I guess they have to, cause you can't trampoline them [07:00] <ds> leave the funcptrs NULL, then resolve them when you need them. but do it manually [07:00] <ds> oh, nm [07:00] <ds> yes, any function address data needs to be resolved at load time [07:01] chillywilly_ (~da...@d3...) joined #gstreamer. [07:01] chillywilly (da...@d1...) left irc: Killed (NickServ (Ghost: chillywilly_!~da...@d3...)) [07:01] Nick change: chillywilly_ -> chillywilly [07:02] <omega> does gcc3 have a cow with the new average.h ? [07:04] <ds> uh... cp average.h.proto average.h is kinda bad [07:04] <omega> yeah, I should turn that off until I have code to generate average.h [07:04] <omega> just remove the rule for now [07:06] <ds> kick ass [07:07] Nick change: wingo -> wingo-zzz [07:07] <ds> Internal error: Segmentation fault [07:07] <omega> uh? [07:08] <omega> did you change specialib.h ? [07:08] <ds> er? [07:08] <omega> change entries[] to *entries [07:13] <ds> uh, incompatible pointer type [07:14] <omega> hmm? [07:14] <omega> whuch? [07:14] <ds> average.h:50 [07:15] <omega> oh, you'll also want to remove average.h from the clean rule <g> [07:15] <omega> that's the _average_U8_U8__c ? [07:16] <ds> dude, you need CVS [07:16] Action: derek is away: zZZZZ [07:16] <ds> it's &__fpe_average_U8_U8 [07:17] <omega> yeah, I think I might dump this into cvs as a preview or something [07:17] <omega> so I can restructure it later into cvs final [07:17] <omega> what is specialib.h:22 ? [07:18] <ds> _slib_funcptr_entry *entries [07:18] <snax> will gst ever allow the main program to act as a source or sink so that it can feed its own data into the pipeline and/or examine the results [07:18] <ds> ; [07:18] <omega> snax: possibly, depending on the architecture [07:19] <omega> I'll have to think through the scheduling impacts of that though [07:19] <snax> omega: it would be far easier than working out a communication system between a custom plugin and the parent application [07:19] <omega> yeah [07:21] <omega> ds: ok, I'm gonna clean this up and import it into cvs [07:21] <ds> omega: ok. I'm going to play with my welder. Or at least, watch the instructional video [07:21] <omega> doh [07:22] <omega> ok, I'll let you know when this is in cvs [07:24] <snax> considering how beta gst is, it's amazing how much stuff it can do that actually works right [07:24] <omega> heh [07:31] <snax> sadly, being useful is not yet part of that feature set ;P [07:31] <omega> heh, yeah, for most real uses [07:32] <omega> soon though [07:32] <snax> I managed to get .avi stuff to play (though without any av syncing) as well .mpg (but with screwed up colors) [07:33] <omega> colors screwed up how? [07:33] <snax> Steve Balmer's face was blue [07:33] <snax> which was amusing, but not correct [07:33] rowenc (rowenc@Hong-231-192.PLU.edu) left irc: "Client Exiting" [07:33] <omega> and everything else was screwed up too? [07:33] <snax> it could be mpeg2dec, I'll have to look into it [07:34] <omega> no, more likely something is swapping Cr and Cb [07:34] <omega> what video card? [07:34] chillywilly (da...@d3...) left irc: [07:35] <snax> geforce 2 gts [07:35] <snax> using plain mpeg2dc produces valid colors, so something must be mucking with the colors [07:36] <snax> I'm compiling from CVS atm, I'll test that in a sec [07:37] <omega> ok, can you run gst-register with --gst-mask=-1, and search for where xvideosink prints out the various available image formats according to your X server? [07:37] <snax> yeah, let me make install [07:37] <omega> no, don't [07:37] <omega> if you're building from CVS, you never want to do that [07:38] <omega> read the build FAQ for reasons why [07:38] <snax> ok [07:38] Action: snax makes uninstall [07:41] <snax> where is this faq anyway [07:42] <omega> on the website, click 'download', there should be a link there [07:49] <omega> ok, specialib is in cvs as 'specialib-pre' [07:52] <snax> I didn't find anything on the download page [07:52] <snax> I found a build guide, but it didn't mention building from cvs [07:52] <omega> oh, there's a developers page [07:52] <omega> er, great, it doesn't seem to be linked there either [07:55] <omega> um, blah. there used to be info, but it seems to have been refactored and lost [07:56] <omega> I'll bug ppl about that [07:56] <snax> in any case, how should I install it then? [07:57] <omega> you don't, it's designed to work from the builddir [07:58] <omega> of course, splitting out to multiple modules makes that more annoying ;-( [07:58] <snax> hrm, ok [08:00] <omega> I'll write up something to the list about it [08:06] walken (fo...@12...) joined #gstreamer. [08:06] <walken> hi [08:07] <omega> yo [08:07] <omega> walken: just put a copy of specialib in cvs, maybe you noticed [08:07] <walken> yes, I saw the messages [08:08] <walken> heh [08:08] <walken> I have lots of ideas for libmpeg2 api but I havent started coding anything yet [08:09] <omega> you should write em up, I'll discuss [08:10] <walken> yeah... [08:10] <walken> basically there are two levels [08:11] <walken> lowlevel is functions like mpeg_sequence (state, buf, bufsize), mpeg_sequence_extension (idem), mpeg_gop (idem), mpeg_picture (idem), mpeg_picture_coding_extension (idem) etc... [08:11] <walken> just does some parsing and updates state [08:11] <omega> right [08:11] <walken> and mpeg_slice (dunno exact parameters yet) [08:12] <walken> basically what we have now, without the decode.c [08:12] <omega> have you looked at how my libmpeg works? [08:12] <walken> hmmm [08:12] <walken> not the api at least [08:12] <walken> higher level api is more interesting I think [08:12] Action: omega drools: [08:12] <omega> http://www.samsungelectronics.com/monitor/240t.html [08:13] <walken> so higher level is... [08:14] <walken> state = mpeg_init (flags) [08:14] <walken> while (blah blah) { [08:14] <walken> switch (state->blah) [08:14] <omega> http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/*checkout*/codecs/libmpeg/tests/decode.c?rev=1.2 [08:15] <walken> case BUFFER: size = read (buf, BUFSIZE); mpeg_buffer (buf, size); break; [08:15] <walken> case PICTURE_DISPLAY: [08:15] <vektor> i wish i wasn't going to sleep [08:15] <walken> (state contains pointers to decoded picture) [08:15] <vektor> walken: is the api ready for me to try? [08:15] <omega> I still highly advocate a bitstream interface [08:16] <walken> default: [08:16] <vektor> oh damn no codin g yet :( [08:16] <vektor> ok [08:16] <vektor> night! [08:16] <vektor> :( [08:16] <walken> mpeg_continue (state) [08:16] <walken> basically you pass data and the function gets out either when it wants more data or when it has decoded a frame [08:18] <walken> if you pass some flags on init you can get more control over the process i.e. you can get a callback when there is a new sequence header and at that point you can make it use your own picture buffers instead of having the lib allocate its own (useful for xv without memcpy for example) [08:18] <walken> I mean not a callback but the function exits with some code [08:19] <snax> hrm, wouldn't a realplayer decoder be possible? I seem to remember an XMMS plugin that used the realplayer SDK to do just that [08:19] <omega> yes, it should be possibly, someone just has to get around to it [08:19] <omega> I've had enough experience with Real to stay as far away as humanly possible [08:19] Action: omega moves his computer a little further south [08:20] <snax> is it technically as bad as it looks and sounds? [08:22] <omega> yes [08:22] <omega> I've written a whole system with the Real engine and it's not pretty [08:27] <snax> argh [08:27] <snax> how do I get gstreamer to recognize all the plugins I compiled [08:28] <snax> they are in different source trees since I didn't make install... [08:28] <omega> --gst-plugin-path=/path/to/gst-plugins [08:28] <omega> this is somethig we need to deal with, probably by fixing up gst-all and recommending people use tuat [08:28] <omega> er, that [08:28] <snax> INFO (23838:-1)gst_plugin_load_all:277: loading plugins from ~/gst-plugins [08:28] <snax> and then nothing [08:29] <omega> it can't handle ~, dunno why [08:29] <snax> ah, it doesn't like ~ [08:29] <snax> ok [08:29] <omega> the shell is supposed to expand it [08:29] <omega> but it doesn't seem to want to [08:33] <snax> lt-gst-launch: relocation error: /home/snax/gst-plugins/ext/mpeg2dec/.libs/libgstmpeg2dec.so: undefined symbol: mm_accel [08:33] Action: snax grumbles [08:34] <omega> walken: ? [08:42] <walken> yes ? [08:44] snax (sn...@12...) left irc: Remote closed the connection [08:44] <omega> walken: mm_accel? [08:45] <walken> its flags to say which cpu features or other accelerations are available [08:45] <omega> does the above error indicate an old mpeg2dec? [08:46] <walken> I suppose - doesnt happen with cvs mpeg2dec/libmepg2 at least [08:53] <omega> whee, I'm back into the realm of unexplained segfaults in MMX code [08:59] <omega> psrlq 1, %mm0 segfaults [09:00] <walken> yaaay [09:02] <omega> and the annoying thing is that there's nothing wrong with the code ;-( [09:03] <walken> maybe it thinks 1 is an address not a constant ?????? [09:04] <omega> oh, possibly [09:04] <omega> hrm, guess so [09:04] <omega> neat [09:06] <walken> ok, gotta sleep [09:06] <walken> (very tired these days) [09:06] walken (fo...@12...) left irc: "l8r" [09:09] Shippou (zbl...@ot...) left irc: Read error: 104 (Connection reset by peer) [09:10] Shippou- (zbl...@ot...) joined #gstreamer. [09:10] Nick change: Shippou- -> Shippou [09:15] rambaby (tj...@hm...) left irc: Remote closed the connection [09:15] rambaby (~tj...@hm...) joined #gstreamer. [09:47] wrobell (~wr...@al...) joined #gstreamer. [09:48] <wrobell> hello all [09:48] <wrobell> omega: some questions about plugins [09:48] <omega> ok [09:49] <wrobell> i have taken a look on xmms code and i see that they remove versioning info from plugins [09:49] <wrobell> i mean that when plugins are built then there are no lib<plugin>.so.0.0.0 and similar files [09:50] <omega> ok [09:50] <wrobell> there are only lib<plugin>.so and lib<plugin>.la [09:50] <omega> isn't that what we have? [09:50] <omega> hrm guess not [09:51] <wrobell> we have lib<plugin>.so.* too [09:51] <omega> right [09:51] <wrobell> i know how to change it [09:51] <wrobell> can i commit? [09:51] <omega> we should probably discuss it with a few others, I know taaz has an opinion but I forget what it was [09:52] <wrobell> ok [09:53] <wrobell> btw. ecasound removes versioning info from plugins, too [09:54] <omega> we probably should remove it, since we have gst-specific versions (though we need to make sure those get used at some point) [09:54] <omega> but I want to make sure no one has a specific reason first [09:58] <taaz> there was discussion about actually supporting multiple versions of plugins installed at once [09:59] <taaz> i thought that was silly and would never happen though ;) [09:59] <omega> what good would multiple versions do? [09:59] <taaz> it's not my arguement... [09:59] <omega> I know, but do you remember why? [10:00] <taaz> i really have no idea.... i think we should just punt that whole issue for now [10:00] <omega> hmm [10:00] <omega> you used to make such a big deal about it <g> [10:00] <taaz> it starts to be a problem now that we have seperate plugin package i guess [10:01] <taaz> eh? i said we should just drop the versioning [10:01] <omega> exactly, that's what wrobell's suggesting [10:01] <taaz> cause like we only look at .so's now [10:02] <taaz> and actually looking for proper version is tricky (i think) [10:02] <omega> probably, yeah [10:02] <taaz> whatever... just let me know what to fix debs to handle ;) [10:03] <omega> in the meantime, I think I'm gonna go sleep.... [10:03] <wrobell> so, any decisions? or we should wait? [10:03] <taaz> post to list and ask [10:04] <omega> wrobell: I'd post it to the list [10:05] thomasvs-sleep (th...@ad...) left irc: Read error: 113 (No route to host) [10:05] <omega> l8r all, sleep [10:05] omega (om...@om...) left irc: "zzzzz" [10:13] thomasvs-sleep (~th...@21...) joined #gstreamer. [10:17] Nick change: taaz -> taazzzz [10:25] thomasvs-sleep (th...@21...) left irc: "Client Exiting" [11:24] Shippou (zbl...@ot...) left irc: "Getting off stoned server - dircproxy 1.0.0" [11:24] Shippou (zbl...@ot...) joined #gstreamer. [11:39] Uraeus (~csc...@c2...) joined #gstreamer. [11:47] <thomasvs-train> blergh [11:47] Nick change: thomasvs-train -> thomasvs [11:48] <thomasvs> hi uraeus [11:49] <thomasvs> Uraeus: any gtk knowledge ? [11:55] <wrobell> thomasvs: what's your problem? [11:55] <thomasvs> wrobell: you have gtk knowledge ? [11:55] <thomasvs> I'm trying to do something that is conceptually simple [11:55] <wrobell> thomasvs: not much [11:55] <thomasvs> but everyone tells me it isn't [11:55] <thomasvs> ;) [11:55] <wrobell> shoot [11:55] <thomasvs> I'm trying to set a background image on my toplevel widget using gdk functions [11:56] <thomasvs> which works [11:56] <thomasvs> because someone told me I should connect a signal to the expose-event [11:56] <thomasvs> I did that [11:56] <thomasvs> and now the background image gets drawn [11:56] <thomasvs> but all of the widgets on top of it aren't anymore [11:56] <thomasvs> they tell me it's because I now need to provide the default expose-event handler to all of the children [11:56] <thomasvs> I don't have a clue ;) [11:57] <thomasvs> did I make myself clear ? [11:59] Action: Uraeus has no idea [12:01] <wrobell> i understand the problem but do not see the solution at now [12:01] <thomasvs> hm, me neither [12:02] <wrobell> i have to check sources one of my programs, which sources are in my cvs home... [12:02] <thomasvs> hm, ok [12:05] harpin (~floh@195.3.98.253) joined #gstreamer. [12:31] <harpin> whois taazzzz [12:32] <harpin> i want to know if there is a framebuffer sink in work [12:32] <Uraeus> harpin: his name is David I Lehn [12:32] <Uraeus> harpin: don't think so, there is a svgalib one however [12:34] <harpin> maybe the sdlsink does the job [12:41] <BBB|zZz> sdlvideosink in the current CVS is broken as of yesterday morning, when wtay uploaded the new capsnego. I still need to fix it ;) [12:42] <Uraeus> BBB|zZz: wake up and fix it then :) [12:42] <thomasvs> BBB|zZz: I have a simple gtk question ;) [12:42] <BBB|zZz> thomasvs: ask! [12:42] <BBB|zZz> Uraeus: first need to take a shower :P [12:42] <thomasvs> well ... [12:42] <thomasvs> ... I can now set the background image of a widget thru gdk ... [12:43] <BBB|zZz> ok [12:43] <thomasvs> ... they explained to me how I can connect an expose_event signal to the toplevel widget ... [12:43] <thomasvs> ... which doesn't do anything ... [12:43] <thomasvs> ... preventing the widget to be redrawn in gray [12:43] <thomasvs> you following me up till now ? [12:43] <BBB|zZz> no [12:43] <BBB|zZz> :P [12:43] <thomasvs> ok [12:43] <thomasvs> uhm, how do I explain this ? [12:43] <thomasvs> ok [12:43] <BBB|zZz> expose_event is called when the widget needs a redraw [12:43] <BBB|zZz> afaik [12:43] <thomasvs> exactly [12:43] <BBB|zZz> so it *does* do something, doesn't it? [12:43] <thomasvs> so I clear the gdk window so that the background image gets drawn, and then I see the image [12:44] <thomasvs> but as soon as you do more stuff with it, it gets a redraw, right ? [12:44] <thomasvs> which clears the gdk window again ;( [12:44] <thomasvs> so this is what they tell me : [12:44] <BBB|zZz> not really..... [12:44] <thomasvs> * connect an expose_event signal to the widget [12:44] <thomasvs> * return FALSE in that [12:44] <thomasvs> this way, the background image stays in the toplevel widget [12:44] <thomasvs> so that works [12:44] <thomasvs> only now I cannot put widgets on top of it [12:45] <thomasvs> and they tell me it's because I need to propagate the default expose handler to the children of the toplevel widget [12:45] <thomasvs> so I follow in theory ... [12:45] <BBB|zZz> you need to draw the widget on top of it yourself ;) [12:45] <thomasvs> ... now I need to put it in practice [12:45] <thomasvs> BBB|zZz: how so ? [12:45] <BBB|zZz> well, the widget is drawn first [12:45] <BBB|zZz> then, the signal handlers are being called [12:45] <BBB|zZz> so you draw widget, clear the window, draw the background [12:45] <BBB|zZz> you need to change the signal's order in order to prevent that [12:46] <BBB|zZz> I'd just advise to make your own widget, though ;) [12:48] <thomasvs> BBB|zZz: heh, "make your own widget". I have two days of gtk experience ;) [12:48] <thomasvs> I don't even understand yet how the basic drawing works, in theory ;) [12:48] <BBB|zZz> lol :) [12:49] <BBB|zZz> is there a specific widget that you want to get a background on? [12:49] <thomasvs> I cannot believe no one ever made a simple widget that has a background image [12:49] <thomasvs> yeah, the top-level POPUP_WINDOW one ;) [12:49] <BBB|zZz> *grin* [12:49] <BBB|zZz> the problem is that most widgets have their own GdkWindow [12:49] <BBB|zZz> so this GdkWindow overdraws the toplevel window's one [12:50] <thomasvs> oh [12:50] <thomasvs> so what you're saying is that the table I'm adding to the toplevel ... [12:50] <thomasvs> ... has it's own gdkwindow ? [12:50] <BBB|zZz> tables don't, I think [12:50] <BBB|zZz> hboxes/vboxes don't either [12:51] <thomasvs> ok [12:51] <BBB|zZz> but buttons, for example, do [12:51] <thomasvs> but that's not entirely what I see happening then [12:51] <thomasvs> because as a sample [12:51] <thomasvs> I set the gdkwindow of the top widget to the image [12:51] <thomasvs> and then went into gtk_main ... [12:51] <thomasvs> ... and you could see the image flash up and then be painted back in gray [12:51] <thomasvs> ... [12:51] <thomasvs> but when I connected an expose_event signal [12:51] <Uraeus> thomasvs: tried doing this in Glade and then looked at the generated code? [12:51] <thomasvs> the image stays, it doesn't get redrawn in gray [12:52] <BBB|zZz> could do that too ;) [12:52] <BBB|zZz> send me the source code ;) [12:52] <thomasvs> BBB|zZz: ok, hang on [12:52] <thomasvs> I'll wrap a working version up [12:52] <thomasvs> thanks btw ;) [12:54] Action: BBB|zZz needs to shower, actually [12:54] <BBB|zZz> and fix sdlvideosink/v4lmjpegsink, of course :P [12:55] <Uraeus> hehe [12:55] <Uraeus> BBB|zZz: no need to shower, we can't smell you anyway over IRC :) [12:55] <BBB|zZz> lol :D [13:13] harpin (floh@195.3.98.253) got netsplit. [13:13] Uraeus (csc...@c2...) got netsplit. [13:13] wrobell (wr...@al...) got netsplit. [13:13] vektor (reet@HSE-Kitchener-ppp3506571.sympatico.ca) got netsplit. [13:13] wtay-zZz (wi...@ca...) got netsplit. [13:13] ds (ds...@12...) got netsplit. [13:13] jarl_ (Lor...@pl...) got netsplit. [13:13] wingo-zzz (wi...@rd...) got netsplit. [13:13] BBB|zZz (BB...@uc...) got netsplit. [13:13] <thomasvs> oh man [13:13] <thomasvs> it works ;) [13:13] <thomasvs> great ;) [13:13] harpin (~floh@195.3.98.253) returned to #gstreamer. [13:13] Uraeus (~csc...@c2...) returned to #gstreamer. [13:13] wrobell (~wr...@al...) returned to #gstreamer. [13:13] vektor (reet@HSE-Kitchener-ppp3506571.sympatico.ca) returned to #gstreamer. [13:13] wtay-zZz (~wi...@ca...) returned to #gstreamer. [13:13] ds (~ds...@12...) returned to #gstreamer. [13:13] wingo-zzz (~wi...@rd...) returned to #gstreamer. [13:13] jarl_ (~Lor...@pl...) returned to #gstreamer. [13:13] BBB|zZz (~BB...@uc...) returned to #gstreamer. [13:28] <harpin> i am interested in writing a framebuffer video sink [13:29] <harpin> maybe sdl could do the job already, but this might mean some memory overhead (e.g. for embedded systems) [13:30] <Uraeus> harpin: sounds cool [13:31] <BBB|zZz> hmm..... v4lsrc/v4lmjpegsrc seem back orking [13:31] <harpin> just want to make sure that noone is already working on something i could contribute to. [13:31] <BBB|zZz> now, on to v4lmjpegsink/sdlvideosink [13:31] <BBB|zZz> harpin: afaik, nobody is doing that yet.... [13:32] <BBB|zZz> not for raw video, that is... [13:35] <harpin> that is...? [13:37] <Uraeus> BBB|zZz: is anybody making a framebuffersink for anything atm? :) [13:37] Action: Uraeus me is also a bit sure what you could send to the framebuffer except raw video [13:37] <Uraeus> s/sure/unsure/ [13:39] <BBB|zZz> erm [13:39] <BBB|zZz> well [13:39] <BBB|zZz> you could see the DC10+ as a MJPEG video framebuffer [13:39] <BBB|zZz> v4lmjpegsink handles that already [13:39] <BBB|zZz> harpin: give it a try. if it works, that'd be wonderful! [13:40] Action: BBB|zZz will take a shower now [13:40] <BBB|zZz> and then, on to sdlvideosink and v4lmjpegsink [13:44] <harpin> im a bit confused [13:44] <harpin> what is DC10+ [13:51] <BBB|zZz> DC10+ is a hardware MJPEG encoder/decoder video-capture card [13:51] <harpin> aaah [13:52] <BBB|zZz> with linux drivers, of course ;) [13:58] <BBB|zZz> showertime now [13:58] <BBB|zZz> cya later :) [13:58] <thomasvs> ok, anyone want to test my panel app ? [13:58] <thomasvs> or rather, the demo version of it ;) [13:58] <Uraeus> thomasvs: sure [13:59] <thomasvs> Uraeus: urgent.rug.ac.be/thomas/ddccp-0.0.3.tar.gz [13:59] <thomasvs> needs glib2/gtk2 btw [13:59] <thomasvs> hope it doesn't crash ;) [14:06] <Uraeus> thomasvs: it runs well, if a little limited in current functionality :) [14:06] jarl_ (Lor...@pl...) left irc: Read error: 54 (Connection reset by peer) [14:06] <thomasvs> Uraeus: yeah ;) [14:06] <thomasvs> it's just a demo of the functions so I can see that it works conceptually [14:07] <thomasvs> now the hard part is making that work with an xml config file which is a tree of menus/actions ... [14:07] <thomasvs> ... that is going to suck [14:07] <thomasvs> but if you imagine that panel at the top of your tv, then it looks nice, no ? [14:07] <thomasvs> I think it doesn't look bad for one day of newbie gtk programming ;) [14:08] <Uraeus> hehe, no not at all [14:12] hadess (~ha...@mo...) joined #gstreamer. [14:13] <hadess> heya [14:14] <thomasvs> hi hadess [14:14] <hadess> heya thomasvs [14:15] <hadess> thomasvs: you should go easy on the build reports ;) [14:15] <thomasvs> hadess: meaning ? [14:15] <thomasvs> you want less of them ? ;) [14:15] <hadess> they're just filling up my inbox... but whatever ;) [14:15] <thomasvs> heh, .procmailrc [14:15] <thomasvs> I'm trying to kick you all a conscience when developing ;- [14:15] <hadess> nah, evo filters [14:16] <thomasvs> oh, so you're the man I can ask something too ;) [14:16] <thomasvs> is there some way I can make evolution apply filters for every new message in the inbox ? [14:16] <thomasvs> right now I have to select all on in box then apply filters when I arrive ;) [14:16] <hadess> thomasvs: there's a button to select in the prefs [14:19] <thomasvs> ok this may sound silly ... [14:19] <thomasvs> ... but I haven't found any preference option in the menus ;) [14:19] <hadess> lemme find it [14:21] <hadess> thomasvs: imap inbox ? [14:22] <thomasvs> yep [14:22] <thomasvs> ok, found it ;) thanks [14:22] <hadess> go to mail settings in the tools menu [14:23] <hadess> then edit your imap account [14:23] <hadess> and in the receiving options is what you want [14:26] <Uraeus> hadess: was a guy named jwb in here, said he had made iPod plugins for GStreamer and that he was making a ITunes clone [14:27] <hadess> huh ? really ? [14:27] Action: hadess should be hacking faster [14:27] <hadess> i'm writing a fam wrapper object right now [14:28] <hadess> well, it's not like there are a lot of mail clients out there [14:28] <thomasvs> Uraeus: btw I didn't draw the background ... [14:28] <thomasvs> ... that woman wasn't my idea ;) [14:28] <thomasvs> I tend to agree with the background though ;) [14:29] <Uraeus> hehe [14:30] <hadess> thomasvs: btw, did it work ? the evo change ? [14:32] <thomasvs> hadess: I think so [14:32] <thomasvs> i'm waiting for mail [14:32] <thomasvs> but it'll probably do it, so thanks ;) [14:32] <hadess> hehe [14:34] <BBB|zZz> ddccp (pid:16026): ** ERROR **: file panel.c: line 71 (panel_background_set): assertion failed: (pixmap != NULL) [14:34] <BBB|zZz> aborting... [14:34] <BBB|zZz> Trace/breakpoint trap (core dumped) [14:34] <BBB|zZz> [15 Jan - rbultje@tux src]# [14:34] <thomasvs> bwergh [14:35] <thomasvs> BBB|zZz: are you running it as src/ddccp ? [14:35] <thomasvs> probably not [14:35] <thomasvs> I have the bg image path still hardcoded [14:35] <thomasvs> thank god for asserts ;) [14:35] <thomasvs> run it from the toplevel as src/ddccp [14:35] <BBB|zZz> how do I move it? [14:36] <BBB|zZz> it looks nice :) [14:36] <thomasvs> you can't move it ;) [14:36] <BBB|zZz> ..... [14:36] <thomasvs> it's for dave/dina, it'll be on top [14:36] <BBB|zZz> it looks cool [14:36] <BBB|zZz> :) [14:36] <thomasvs> it won't be window-managed in the traditional sense, it's a key/IR controlled panel [14:36] <thomasvs> BBB|zZz: thanks ;) [14:36] <thomasvs> gtk is cool to work with [14:37] <thomasvs> now I only need to add xml trees of menu's and items and IR input ;( [14:37] <thomasvs> probably the biggest part [14:37] <thomasvs> it's amazing how many windowmanager concepts don't make sense anymore when you take out the mouse ;) [14:38] <BBB|zZz> lol :) [14:38] <BBB|zZz> very true [14:38] <Uraeus> hmm, we are 27th on sourceforge today, maybe we make it back into top 20 again :) [14:38] <thomasvs> ok, going shopping [14:38] <thomasvs> Uraeus: yesterday as well [14:39] <thomasvs> we're getting really high percentages this week, > 99.5 % [14:39] <BBB|zZz> how is activity measured? [14:39] <BBB|zZz> number of commits? [14:39] <Uraeus> still a little unsure how those scores are calculated, but it seems webhits and downloads must be part if it [14:39] <BBB|zZz> size of commits? [14:40] <Uraeus> and commits [14:40] <Uraeus> not sure if mail activity is part of it [15:41] asmod (~stevec@64.5.222.2) joined #gstreamer. [15:41] <Uraeus> hi asmod [15:41] <asmod> hey [15:41] <Uraeus> asmod: got my mail? [15:42] <asmod> yeah. thanks for the feedback [15:42] <Uraeus> asmod: np :) [15:42] <Uraeus> asmod: but the mediaplayer in the screenshots looks much nicer than I ever got mozstreamer looking :) [15:43] <asmod> mozstreamer itself doesn't look like that :) [15:43] <asmod> That's my XUL frontend to the mozstreamer backend :) [15:44] <Uraeus> asmod: will that be publically avaiable for download or is it something you are keeping for the AIO? [15:44] <asmod> I think it will be open sourced [15:45] <Uraeus> asmod: ah, kewl, well let us now if that happens [15:45] <asmod> I certainly will [15:45] <Uraeus> asmod: as you can see we made your new box the channel topic :) [15:45] <asmod> I saw that :) [15:45] <asmod> You must have seen it on slashdot? [15:46] <Uraeus> asmod: actually it was an advertisement on freshmeat I think [15:47] <asmod> Hmm.. I didn't know we had banner ads already. Guess I have to come here to learn what my own company is doing :) [15:47] <Uraeus> hehe [15:48] <Uraeus> asmod: well hope the box becomes a sucess, it looked cool enough [15:49] <asmod> I guess it all depends on if the markets ready for it yet. Internet appliances haven't been working out to well lately. [15:50] <asmod> But we've got a bit of a different approach. We're really building the operating environment and will be licensing it to larger hardware companies that want to get into the IA market quickly (Sony, Panasonic, etc...) [15:51] wingo-zzz (wi...@rd...) left irc: Remote closed the connection [15:51] <Uraeus> asmod: well speaking for myself, your box is the first internet applicance I could have seen myself buying, not for myself but as a gift to my mother or sisters [15:52] <Uraeus> asmod: all others have seemed either to simple or as overpriced PC's [15:53] <thomasvs> where are the shots/specs for it ? [15:53] wingo (~wi...@rd...) joined #gstreamer. [15:54] <Uraeus> thomasvs: look at the oeone.com frontpage, there is a flash demo with lots of screenshots in it [15:54] <Uraeus> hi wingo [15:54] <wingo> howdy [15:54] Nick change: wingo -> wingo-class [15:54] <thomasvs> woah, gratuitious flash usage ;) [15:55] <thomasvs> looks very fancy [15:55] <thomasvs> this thing works already ? what does it cost ? [15:55] <Uraeus> thomasvs: you can buy it yes, but I only think they ship to US and Canada now [15:55] <Uraeus> asmod: ? [15:55] Action: thomasvs is humbled now [15:55] <thomasvs> it's really sweet graphically [15:56] <thomasvs> asmod: how many people worked on this for how long ? [15:56] <asmod> That's right Uraeus. About $799 US I think [15:56] <thomasvs> not too expensive [15:56] <thomasvs> I suppose the mail client is mozilla's ? [15:56] <asmod> There's about 25 total in the company. Less then 2 years. [15:56] <thomasvs> not bad [15:56] <Uraeus> asmod: if we order some can you come to GUADEC and bring them ? :) [15:57] <asmod> It's based on mozilla's mail client, but completely re-skinned and improved. [15:57] Action: derek is back (gone 08:40:40) [15:57] <asmod> Uraeus: Depends on how many you order. I'd be happy to if the boss would let me :) [15:57] <Uraeus> asmod: well you could do a presentation also while there :) [15:58] Action: derek is away: herding 'kids' [15:58] <asmod> Sure, I'll talk about Mozilla as a platform for development rather then just as a browser. [15:59] <Uraeus> asmod: that would be cool [15:59] <thomasvs> the presentation alone must have been expensive ;) [15:59] <asmod> thomasvs: That flash demo? [15:59] <thomasvs> yeah [16:00] <asmod> We did that in house. [16:00] <thomasvs> good idea [16:00] <thomasvs> you'd have paid through your nose for it otherwise ;) [16:00] Action: BBB|zZz thinks he has all plugins back uptodate [16:00] <Uraeus> BBB|zZz: ok, I cvs update and try building again [16:00] <BBB|zZz> not yet [16:00] <BBB|zZz> I'm still to commit it ;) [16:00] <asmod> Yeah, we've got some really good graphics and UI people. Which really comes out in our product. [16:01] <BBB|zZz> I'm currently rebuilding my whole tree from the current CVS with my patches to see whether it actually works [16:02] <thomasvs> how does one get the last element of a GList ? [16:03] <BBB|zZz> g_list_last(GList *list);? [16:03] Company (~Company@pD900413E.dip.t-dialin.net) joined #gstreamer. [16:03] <thomasvs> ok, let me try that ;) [16:03] <thomasvs> i'm so stupid [16:03] <Uraeus> hi Company [16:04] <BBB|zZz> or just g_list_last(list)->data, that gives the void* data :) [16:04] <Company> hi everybody [16:04] <BBB|zZz> hi company [16:07] <Uraeus> asmod: hmm, no Ogg support in the box? just mp3, bad bad bad <g> [16:07] <asmod> Uraeus: Oh ogg will be working before to long. [16:11] <Uraeus> asmod: that abiword version you have, is it a full XUL frontend or just thr gtk+ version somehow embeded? [16:14] <asmod> Uraeus: It's a XUL frontend that uses the abiword library. Not the gtk version embedded. I think. [16:18] <Uraeus> asmod: we had a guy in here yesterday who said he had a set of GStreamer iPod plugins almost ready, so you can soon support iPod users on your machine :) [16:20] <asmod> Really? That would be really cool. [16:20] <Uraeus> Company: if you are hacking on gstplay you should probably mail Arik to avoid duplicating effort [16:20] <Uraeus> asmod: yes, really [16:26] <Company> Uraeus: I did - and I mailed anything useful to -devel anyway [16:29] <Uraeus> Company: ah, cool [16:33] <Uraeus> Company: do you know how far Arik has come on integrating hadess new playlist widget? if he hasn't started yet maybe you could take that on [16:34] <hadess> Uraeus: that's because the playlist component is not finished dudie [16:34] <Uraeus> hadess: have you been slacking again? <g> [16:34] <hadess> Uraeus: not really... it takes time to do this kind of thing you know [16:34] <Company> Uraeus: he was just starting - but I am doing random other stuff atm which is probably only useful for learning the internals of gst [16:36] <BBB|zZz> INFO (25265:-1)gst_plugin_register_func:469: plugin "/home/rbultje/mjpeg/gst-plugins/gst/mpegaudio/.libs/libgstmpegaudio.so" failed to initialise [16:36] <BBB|zZz> INFO (25265:-1)gst_plugin_load_absolute:422: plugin "/home/rbultje/mjpeg/gst-plugins/gst/mpegaudioparse/.libs/libgstmpegaudioparse.so" absolute loading [16:36] <BBB|zZz> ./register-all: line 2: 25265 Segmentation fault /home/rbultje/mjpeg/gstreamer/tools/gst-register --gst-plugin-path=/home/rbultje/mjpeg/gst-plugins [16:36] <BBB|zZz> ? [16:36] Action: BBB|zZz is back (gone 15:55:19) [16:37] Nick change: BBB|zZz -> BBB [16:37] <hadess> BBB: your username is too complicated :P [16:37] Action: hadess runs [16:37] <BBB> <g> [16:46] Action: derek is back (gone 00:48:05) [16:51] Action: BBB thinks SF's CVS is blown up [16:52] <BBB> okay, CVS is uptodate again, all v4l/sdl plugins are fixed [16:52] <Uraeus> ok, I try and download it [16:54] <Company> I'll try it when I get pango to load fonts in gdb :) [16:57] <BBB> now on to the next part.... :) [17:01] Nick change: taazzzz -> taaz [17:01] Action: Company thinks installing GNOME2 is the best way to understand GLib and building in general and it's a booster to self-confidence if it works at the end [17:03] <BBB> GNOME2 doesn't work here ;) [17:03] <BBB> gnome-core refuses to compile with gnome2 :| [17:04] <Company> I'm not that far - gtk is compiling currently but I'll get to that eventually [17:05] Action: BBB has a complete gnome2-ready setup already ;) [17:06] <Company> BBB: try running gtk-demo in gdb plz - mine refuses to load any fonts when run from gdb :( [17:11] <BBB> lemeetry [17:12] <BBB> works fine here [17:13] Nick change: wingo-class -> wingo [17:13] <Company> hm, then it's my X probably - I have to use cvs because of my graphics card... [17:13] <Company> or something very weird [17:14] wrobell (wr...@al...) left irc: "wrobell has no reason" [17:16] hadess (ha...@mo...) left irc: Read error: 113 (No route to host) [17:18] <wingo> so, this is what i'm pleased about: [17:18] <wingo> gst-launch -o test.xml filesrc ! mad ! osssink [17:18] <wingo> gst-xmllaunch test.xml filesrc0.location=/path/to/mp3.mp3 [17:19] <taaz> nice [17:20] <taaz> can you name=filesrcfoo too? [17:20] <taaz> (does the filesrc [fsname] syntax still work? i liked that...) [17:21] <wingo> yes, that should work [17:21] <wingo> that would replace the filesrc0 part [17:22] <taaz> want to do something really 'leet? [17:22] <wingo> to be more explicit, gst-launch -o test.xml filesrc name=foo ! mad ! osssink [17:22] <wingo> gst-xmllaunch test.xml foo.location=/path/to/mp3.mp3 [17:22] <wingo> taaz: yes ;) [17:23] <wingo> i think the proper syntax *should* be (the parser won't allow this now) filesrc[foo] [17:23] <taaz> make gst-xmllaunch accept stdin, then we can do: 'dog http://gstreamer.net/pipelines/mp3player.xml | gst-xmllaunch foo.location=/path/to/mp3.mp3' [17:24] <wingo> that's doable [17:24] <taaz> or maybe a '-' for doing stdin.. whatever ;) [17:24] <wingo> just have to make '-' mean stdin [17:24] <wingo> yes ;) [17:24] <taaz> that's kinda cool though... can run pipelines from over the net ;) [17:24] <wingo> something about great minds... :) [17:25] <taaz> of course that means a default system is needed to auto-select the best audio/video output sink [17:25] <taaz> but for cool examples to stick the man page that would rock. you did write the man page right?? [17:25] <wingo> not yet [17:26] <taaz> heh [17:26] <wingo> i guess i should learn man(1)-speak [17:26] Action: taaz runs off to the pit of dispair^w^w^w^wcampus lab [17:27] <Uraeus> wingo: there is a tool called gmanedit which makes writing man pages very easy [17:27] <thomasvs> heh [17:27] <thomasvs> we could provide default installed xml files for various media types [17:27] <thomasvs> and provide symlinked scripts for that [17:27] <thomasvs> like, mp3play ... [17:28] <thomasvs> would be gst-xmlllaunch mp3.xml (whatever file) [17:28] <thomasvs> is that doable ? [17:28] <wingo> Uraeus: thanks, but i'm doing it on a sparc over an ssh'd connection [17:28] <taaz> sorta... but you really need a way to select default audio output [17:29] <thomasvs> taaz: yeah, from a system-wide default xml file maybe [17:29] <thomasvs> if we extend the xml stuff [17:29] <taaz> eh... that's not the best way to do it [17:29] <thomasvs> Uraeus: do we have someone testing gstreamer on solaris yet ? [17:29] <Uraeus> thomasvs, taaz: I have a bug report to Arik suggesting a GNOME control center caplet for setting audio [17:29] <wingo> thomasvs you would have to have some way of indicating what was the real 'parameter' of the xml file [17:29] <taaz> there's a cooler more complex way [17:29] <thomasvs> wingo: yeah [17:29] <wingo> s/file/file is/ [17:29] <thomasvs> wingo: actually that would be a good idea anyway [17:30] <Uraeus> thomasvs: I have been trying to build it, but not recently and Gman has tried bulding it on sparc [17:30] <thomasvs> I type filesrc=(location) all the time [17:30] <thomasvs> Uraeus: I know someone who has a lot of solaris machines at work [17:30] <thomasvs> recent ones [17:30] <Uraeus> thomasvs: well the more the better [17:30] <thomasvs> wingo: so maybe we should let plugins have a default argument which points to the most used or most likely one [17:30] <wingo> dunno [17:30] <taaz> if autoplugging worked such that it could just pick the sink that has the best metric of some sort that would be ideal. and user could just have a file that says osssink has higher score than alsasink and autoplugger would pick the right thing [17:31] <thomasvs> yes, we really need to start adding scoring [17:31] <taaz> anyway... needs to be thought about more probably [17:31] <thomasvs> Uraeus: maybe something for the 0.4.0 dotplan [17:31] Action: taaz zips off [17:31] <thomasvs> a fixed score set would help tremendously already [17:31] <thomasvs> and it sounds like it's easy to implement too [17:31] <wingo> cya [17:32] <wingo> thomasvs: i'm thinking really in the xml file, that there might be an additional root node called parameter or something [17:33] <thomasvs> wingo: while on xml, is there some easy way to fill a GTree from xml data ? [17:33] <wingo> <gst:parameter element="elementname" property="propname" /> [17:33] <thomasvs> I mean, I suppose people did this before me in other apps ;) [17:33] <wingo> thomasvs: not really [17:33] <thomasvs> so... [truncated message content] |