[gst-devel] Daily IRC logs

[wim.taymans at chello.be]

[06:41] Nick change: aj_uni -> ajmitch
[07:04] Nick change: ajmitch -> aj_food
[07:38] Nick change: aj_food -> ajmitch
[08:21] Nick change: taaz -> taazzzz
[08:21] Action: omega_ is writing gdb macros now
[08:21] <ajmitch> ;)
[08:21] <ajmitch> surely it doesn't crash that often? ;)
[08:21] <omega_> no, but when it needs debugging, following the gtk objects is very non-trivial
[08:22] <omega_> so I'm writing a macro that prints out names, pads, pads' peers, etc.
[08:24] hashao (hashao at pcd222106.netvigator.com) joined #gstreamer.
[08:24] <omega_> yo
[08:24] hashao (hashao at pcd222106.netvigator.com) left #gstreamer.
[08:24] <omega_> hmm
[08:40] Nick change: ajmitch -> ajLUG
[09:34] walken (foobar at c1583255-a.smateo1.sfba.home.com) joined #gstreamer.
[09:42] <omega_> yo
[09:42] <omega_> vmware let you go home?
[09:43] <walken> yeah :)
[09:43] <walken> got cable installed wednesday
[09:43] <omega_> that helps
[09:43] <walken> configured firewalling today
[09:43] <walken> whats up ?
[09:43] <omega_> just the usual hacking
[09:43] <omega_> latest project is some gdb macros to make debugging suck less
[09:45] <walken> heh
[09:45] <omega_> prev was a bash commandline completion helper app
[09:46] <omega_> and fixing up gst scheduling is the main task
[09:46] <omega_> learning more about gdb than I really ever wanted to know, right now
[09:47] <omega_> it's not as complete as it could be ;-(
[09:49] <walken> heh
[09:49] <walken> I've been thinking about trying the vtune stuff
[09:49] <walken> see if it finds interesting things about mpeg2dec
[09:49] <omega_> yeah, could be useful
[09:49] <walken> yeah
[09:49] <omega_> but the trick is that I dunno if it'll work on cygwin binaries as well
[09:49] <walken> dont know how well it will work with gcc-compiled code though
[09:49] <walken> yes
[09:50] <omega_> it works?
[09:50] <walken> gotta try :)
[09:50] <omega_> right
[09:50] <omega_> at the core it's just machine instructions...
[09:50] <omega_> but the higher-level structures might matter too
[09:50] <omega_> esp for runtime profiling
[09:50] <walken> the problem would be for the different debug formats
[09:51] <omega_> yeah, depending on what you attempt
[09:51] <omega_> if you just do static anaylsis you probably won't have any problems
[09:53] <omega_> btw, one of the mjpeg guys, author of mpeg2enc, is very interested in libcodec
[09:54] <omega_> he's gonna be closing out mpeg2enc at 1.4, then working with the sampeg guys
[09:55] <walken> who ?
[09:55] <omega_> um, searching
[09:56] <omega_> mailto:andrew.stevens at philips.com
[09:56] steveb (chatzilla at 212186169160.chello.com) joined #gstreamer.
[09:56] <omega_> yo
[09:57] <steveb> hi
[09:57] <steveb> I almost finished my DynamicParams wiki page a week ago - just waiting for a chance to polish it off
[09:58] <omega_> cool, I'll have to read it
[09:58] <walken> ok
[09:58] <walken> I had talked with him before :)
[09:58] <omega_> re: what?
[09:59] <walken> hmmm about mpeg2dec stuff
[09:59] <omega_> optimization?
[09:59] <walken> like he made me add the fifo output
[09:59] <omega_> ah
[10:00] <omega_> so, now that you've got a cable modem, you're going to cease being AWOL? ;-)
[10:01] <walken> yeah, I plan to get active again
[10:01] <omega_> good
[10:01] <walken> I still have to actually do it
[10:01] <omega_> do what?
[10:01] <walken> and I wont have as much time as before
[10:01] <omega_> yeah
[10:02] <walken> but I should be able to do stuff still
[10:02] <omega_> cool
[10:02] <omega_> what I'd love to see would be sampeg built up, but they're going to be doig things in C++ ;-(
[10:02] <omega_> I can't seem to convince Andrew that a core library should not be written in C++, esp a decoder
[10:02] <walken> huh
[10:03] <omega_> but he's very excited about the libcodec stuff
[10:03] <walken> I'm glad libmpeg2 wasnt in c++ when aaron wrote it
[10:03] <omega_> hehehe
[10:03] <walken> I have a problem with c++ :)
[10:03] <omega_> so do I
[10:03] <omega_> esp in a codec
[10:04] <omega_> where no matter what code you write, it has to be performant
[10:04] <omega_> and accessible from anything, which means C by definition
[10:05] <walken> :)
[10:05] <walken> we have a g3 at work
[10:05] <omega_> oooh, but a g4 is better
[10:05] <walken> I'm tempted to try writing an idct on it
[10:05] <omega_> g4 means altivec
[10:05] <walken> hmmm
[10:05] <omega_> I've got some code, even
[10:05] <walken> well it may be a g4
[10:05] <walken> its a mac whatever
[10:06] <walken> I dont know mac models very well
[10:06] <omega_> hadess gave me a tarball that has ppc and altivec optimizations to mpeg2dec
[10:06] <omega_> I figured you might be interested ;-)
[10:06] <walken> no way
[10:06] <walken> you actually have it ?
[10:06] <omega_> searching
[10:06] <walken> someone told me monthes ago that he had such a thing
[10:06] <omega_> walken at ... ?
[10:06] <walken> and never sent it to me despite me asking him
[10:06] <walken> wondered if it was real :)
[10:06] <omega_> it is
[10:07] <walken> @zoy.org
[10:07] <walken> or @vmware.com works too
[10:07] <omega_> ah, I have you in my addrbook anyway ;-)
[10:07] <omega_> sent
[10:07] <walken> have you tried it ?
[10:07] <omega_> no ppc
[10:07] <walken> ok
[10:07] <walken> will look :)
[10:08] <walken> damn why dont people send me the good patches
[10:08] <walken> am I such a bitch ?
[10:08] <omega_> I sent you sse patches 1+yrs ago and you didn't integrate them... <g>
[10:08] <walken> oops :)
[10:09] <omega_> but the mmxext stuff seems to cover most of it, afaict
[10:09] <omega_> I've been thinking about mcomp a bit recently, from wtay's comments
[10:09] <walken> I'm quite happy about my mmx/mmxext routines
[10:09] <omega_> he said he implemented avgsum mcomp routines, and got a significant win
[10:09] <walken> they are 15/20% faster than intel's reference code
[10:09] <omega_> hmmm
[10:10] <walken> hmmm
[10:10] <omega_> how did you measure intel's code?
[10:10] <walken> dont we have that in mpeg2dec-current already ?
[10:10] <walken> didnt, just looked at their numbers
[10:10] <omega_> which?
[10:10] <walken> errr, appnote 922
[10:10] <omega_> no, which in -current?>
[10:11] <walken> pavgb_r2r
[10:11] <omega_> btw, my notes from a while ago on colorspace conversion are at:
[10:11] <omega_> http://codecs.org/wiki/MMXOptimizedYUV2RGB
[10:11] <walken> in motion_comp_mmx.c
[10:12] <omega_> yeah, that's the mmxext stuff
[10:12] <omega_> hrm, the problem I'm running into is dealing with intersections of instruction sets
[10:13] <omega_> and naming thereof
[10:13] <walken> hmmmm
[10:13] <omega_> x86, MMX, MMXext, 3dnow, sse, sse2/kni
[10:13] <omega_> etc.
[10:13] <walken> well here's what I did
[10:13] <walken> mmx - you know what it is
[10:14] <walken> mmxext - its the extensions AMD introduced
[10:14] <omega_> 3dnow
[10:14] <walken> sse - its mmxext plus floating point extensions. but the integer instructions in mmxext are exactly the same as mmxext
[10:14] <omega_> ok
[10:14] <walken> 3dnow is a different branch altogether
[10:14] <omega_> sse2/kni is the wider version of that
[10:15] <omega_> oh? 3dnow is mmxext + stuff ?
[10:15] <walken> no
[10:15] <walken> 3dnow is mmx+stuff
[10:15] <omega_> hmmm
[10:15] <walken> most of the interesting instructions in 3dnow are in mmxext too, but with different opcodes :-/
[10:15] <omega_> ok, I'm writing up a table for the wiki, lemme flesh it out, then you can comment in a sec
[10:15] <walken> like pavgb (mmxext) versus pavgusb (3dnow)
[10:16] <walken> they do the same thing
[10:16] <walken> which is why I deal with these using a #define
[10:16] <omega_> hmm, ok
[10:16] <omega_> http://codecs.org/cgi-bin/wiki/moin.cgi/SIMD
[10:17] <omega_> I'll do a preliminary fill-in
[10:19] <omega_> ok, check that
[10:19] <walken> basically if you dont care about floating point stuff you only want to know about mmx mmxext and 3dnow
[10:19] <omega_> right
[10:19] <walken> (actually sse2 too for the 128bit stuff)
[10:20] <omega_> right, though the P4 has many reasons to suck
[10:21] <walken> if you use sse (floating point) or sse2 (either integer or fp) you'll need some kernel support to save the register on a context switch. I'm not sure yet how to detect if the kernel you run on supports this.
[10:21] <omega_> yeah, good point
[10:21] <walken> xine got burned by that
[10:21] <omega_> I know I'm being pessimistic in that table, there are some holes in it
[10:21] <omega_> I'll have to make sure I get good detection routines (none so far) into libcodec
[10:21] <walken> why would you need such a table anyway
[10:22] <omega_> for reference
[10:22] <walken> I'm happy with my detection code :)
[10:22] <omega_> I'm still fuzzy on some aspects, mostly of the AMD line
[10:22] <walken> did it straight from the books
[10:22] <omega_> you know how to update the wiki?
[10:23] <walken> and 3dnow is not an amd thing
[10:23] <walken> well not only them at least
[10:23] <omega_> eh?
[10:23] <omega_> it's their name
[10:23] <walken> oh ?
[10:23] <omega_> afaik
[10:23] <omega_> not cyrix's
[10:23] <omega_> cyrix is out of the game anyway
[10:23] <walken> I think it was designed together by all the non-intel guys of the time
[10:23] <walken> yeah they're dead
[10:24] <omega_> hmm, maybe
[10:24] <omega_> are you editting the wiki page?
[10:25] <walken> wait
[10:25] <walken> just refreshed
[10:25] <walken> but actually I'm not sure about stuff
[10:26] <walken> pentium II doesnt have mmxext
[10:26] <omega_> ok
[10:26] <omega_> you want to update it?
[10:26] <walken> intel pretends mmxext never existed and they invented these instructions in sse
[10:26] <omega_> of course
[10:27] <walken> I actually had to compare all the instructions & opcodes to convince myself it was actually the same thing
[10:28] <omega_> heh
[10:28] <omega_> opcodes are identical?
[10:28] <walken> yes
[10:28] <walken> there is also 3dnowext
[10:28] <omega_> uh oh
[10:28] <walken> I havent looked at what it does :)
[10:28] <omega_> that's the k7 stuff
[10:28] <omega_> ?
[10:29] <walken> it didnt have interesting instructions for me :)
[10:30] <walken> hmmmm
[10:34] <walken> also K6 didnt have 3dnow
[10:34] <omega_> ok
[10:34] <walken> (just looked up the docs)
[10:34] <omega_> a -2 think?
[10:34] <walken> (fixed)
[10:34] <walken> -2 and -3 had 3dnow but no mmxext
[10:35] <omega_> the athlon has sse afaict
[10:37] <walken> no
[10:37] <omega_> uh?
[10:37] <walken> athlon has mmxext and 3dnow+3dnowext
[10:38] <walken> but no sse
[10:38] <omega_> hmm, ok
[10:38] <omega_> but 3dnowext overlaps with sse ?
[10:38] <walken> dont know :)
[10:38] <omega_> hmm, ok, this is something I want to document in the wiki eventually
[10:39] <walken> but you should rip off my detection routines
[10:39] <walken> they work
[10:39] <omega_> ok, will do
[10:39] <omega_> how much work do you have to do on mpeg2dec before you can start helping me with libcodec? ;-)
[10:39] <walken> heh
[10:40] <walken> I have work to do on ac3dec too :)
[10:40] <omega_> yeah, that can use libcodec too
[10:41] <walken> hmmm
[10:41] <walken> have you implemented all these ideas in the color conversion routines ?
[10:41] <omega_> btw, is mmxext an offical name of any kind?
[10:41] <walken> no...
[10:41] <omega_> that wiki doc?
[10:41] <walken> amd calls this "amd mmx extensions"
[10:41] <walken> yes
[10:42] <omega_> yeah, that's on the code I have, though it doesn't match it perfectly any more
[10:42] <walken> I just nicknamed it mmxext
[10:42] <omega_> for instance, I don't use intel's pmadd tricks for rgb555 packing anymore
[10:42] <omega_> ok, it makes sense though ;-)
[10:42] <walken> your stuff is faster than intel's stuff ?
[10:42] <omega_> I dunno, but I think it is
[10:43] <omega_> I don't have intel's code timed, but I'm getting about 10cycles/pixel without too much high-level optimizaton
[10:43] <omega_> ~50Mpel/sec on a 500MHz 
[10:43] <omega_> I can do better, depending on circumstances
[10:43] <walken> for the color conversion ?
[10:43] <omega_> yup
[10:43] <omega_> and no cache-thrashing either
[10:43] <omega_> no tables
[10:44] <omega_> intel uses 'big' tables
[10:44] <omega_> my code's in libcodec cvs now, btw
[10:44] <walken> yummy
[10:44] <omega_> any idea what the timings are on the code you've got now?
[10:45] <walken> and you got all rgb modes in there ?
[10:45] <omega_> nope, not yet
[10:45] <omega_> there are a few things to be decided before that
[10:45] <omega_> API and suc
[10:45] <omega_> such
[10:45] <walken> no, but its not scheduled at all. I wouldnt surprised if it was twice slower
[10:45] <omega_> my code isn't scheduled either
[10:45] <walken> oh ?
[10:45] <omega_> I've made some rudimentary attempts in a few places, but nothing sophisticated
[10:45] <walken> I thought it was computer-scheduled
[10:46] <omega_> only bits
[10:46] <omega_> as I mentioned, the timing part takes waaay too long
[10:46] <omega_> if you can think of a good way to *quickly* build and time the generated codesegments, we can get the whole thing optimized as a unit
[10:46] <walken> how long have you had the altivec tarball ?
[10:46] <omega_> a week maybe
[10:47] <walken> i.e. do you know what version of mpeg2dec I should match it against
[10:47] <omega_> no clue
[10:47] <omega_> ask hadezZz, see if he knows
[10:47] <omega_> when he 'wakes up', that is
[10:47] <omega_> (it's 11am there)
[10:47] <omega_> er, 10am
[10:49] thomas (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[10:49] <omega_> yo
[10:49] <omega_> speaking of 11am....
[10:49] <thomas> hey omega_
[10:49] <thomas> you still up ?
[10:49] <omega_> not for long <g>
[10:49] <thomas> I finally got the tv out working on the box ;)
[10:49] <omega_> oooh, which card?
[10:49] <thomas> started up raine with chase hq full screen
[10:49] <thomas> ati rage fury pro 128
[10:49] <omega_> neat, what about input?
[10:49] <thomas> had a hell of a time doing it too
[10:49] <thomas> not yet there
[10:50] <thomas> I want the out first ;)
[10:50] <walken> hmmm his version is pre 0.2.0
[10:50] <thomas> I had to go back and use vesa fb device for X
[10:50] <thomas> was stupid enough to put BOTH vesa fb and ati fb in the kernel
[10:50] <thomas> they conflicted all the time and I didn't even notice...
[10:50] <thomas> ... since I don't know how tv/out and vga out combined are supposed to work anyway
[10:50] <thomas> anyway, how do I use the gst-complete ?
[10:52] omega_ (omega at omegacs.net) left irc: Ping timeout for omega_[omegacs.net]
[10:54] <walken> hmmmm
[10:54] <walken> altivec is though to read
[10:56] <walken> wow
[10:56] <walken> c support for altivec is nice though
[10:58] thomas (thomas at 212-100-172-175.adsl.easynet.be) left irc: Ping timeout for thomas[212-100-172-175.adsl.easynet.be]
[11:12] steveb (chatzilla at 212186169160.chello.com) left irc: ChatZilla 0.8 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010323]
[11:56] <walken> blah
[12:18] walken (foobar at c1583255-a.smateo1.sfba.home.com) left irc: l8r
[12:42] thomas (thomas at 212.100.172.175) joined #gstreamer.
[12:59] Nick change: ajLUG -> ajmitch
[13:06] thomas (thomas at 212.100.172.175) left irc: Ping timeout for thomas[212.100.172.175]
[13:06] thomas (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[13:08] Nick change: maYam -> maYam_away
[14:23] <thomas>  
[14:24] <ajmitch> ;)
[15:23] Nick change: ajmitch -> ajzzzz
[16:08] thomas (thomas at 212-100-172-175.adsl.easynet.be) left irc: Ping timeout for thomas[212-100-172-175.adsl.easynet.be]
[16:09] thomas (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[16:45] paddler (paddler at adsl-64-168-101-122.dsl.scrm01.pacbell.net) joined #gstreamer.
[16:52] matth (matth at qwest.dsplinux.net) joined #gstreamer.
[16:52] Nick change: matth -> matth-email
[17:14] thomas (thomas at 212-100-172-175.adsl.easynet.be) left irc: [x]chat
[17:23] dobey (dobey at 141.154.95.104) joined #gstreamer.
[17:39] Nick change: taazzzz -> taaz
[18:12] steveb (steveb at node1ee05.a2000.nl) joined #gstreamer.
[18:34] Zeenix (programmer at host-119.netzone.net.pk) joined #gstreamer.
[18:35] <Zeenix> gstreamer isnt that straight
[18:36] <steveb> what do you mean?
[18:36] <Zeenix> it depends on libs, that doesnt yet really exist
[18:36] <steveb> like?
[18:36] <Zeenix> go to gstreamer.net/releases/0.1.1/support
[18:37] <Zeenix> it has broken links
[18:37] <Zeenix> & also watch out what it says about L.A.M.E
[18:39] <steveb> the version in CVS is a different story
[18:39] <steveb> although nothing is complete and no-one is pretending that it is
[18:41] <Zeenix> but it was so bad, i have been searching for that libs,
[18:41] <Zeenix> i think they should tell at the dowload page about the dependencies
[18:44] <Zeenix> i had got those gstreamer rpms & when i ran 'rpm ...' it told that ugly dependency prob.
[18:46] <Zeenix> i cant explain what my feelings were at that time
[18:48] <Zeenix> because internet is very expensive, slow for me & i dont have it at my home PC so i take what i download on an fd
[18:48] Nick change: hadezZz -> hadess
[18:48] <steveb> you could always build from the source - if you don't have those other libraries then those plugins won't be built
[18:48] <steveb> hadess: yo
[18:49] <hadess> heya steveb
[18:49] <dobey> hadess!!!!!!!!!!!
[18:49] <dobey> hadess: where can i get 2.2.19 source for ppc?
[18:50] <hadess> dobey: there is no 2.2.19 for ppc, it's 2.2.19 from linus, it includes all the ppc patches
[18:50] <dobey> hadess: oh, ok
[18:51] <Zeenix> can i do a much without those plugins
[18:51] <hadess> Zeenix: no
[18:51] <steveb> Zeenix: that depends what you want to do :)
[18:51] <Zeenix> i have got the LAME offcourse
[18:52] <Zeenix> i need gstreamer just to compress & uncompress sampled sound in realtime( at the moment )
[18:54] <hadess> you'd better get the sources in any case
[18:55] <Zeenix> is mp3 a better choice ?
[18:55] <Zeenix> is it fast enough ?
[18:56] <hadess> depends on the computer, the quality of the sound you want...
[19:01] <Zeenix> i want the lowest quality, 1 channel
[19:01] <Zeenix> i want it 5KB/s, thats the lowest one can have
[19:06] Zeenix (programmer at host-119.netzone.net.pk) left irc: Ping timeout for Zeenix[host-119.netzone.net.pk]
[19:08] Zeenix (programmer at host-119.netzone.net.pk) joined #gstreamer.
[19:08] <hadess> Zeenix: mp3 should be alright then
[19:09] <Zeenix> what about mpeg layer 2
[19:10] <hadess> why would you want to use mpeg layer 2 ?
[19:10] <dobey> use ogg/vorbis
[19:10] <hadess> and beware that 5kbps is really low quality
[19:11] <Zeenix> i want it fast
[19:11] <Zeenix> i just need the understandable voice
[19:11] <hadess> what is it for ?
[19:11] <dobey> Zeenix: ogg/vorbis has better compression
[19:11] <hadess> there's the gsm library...
[19:12] <Zeenix> no music, just communication
[19:12] <Zeenix> internet Chat
[19:12] <Zeenix> how much does it compress
[19:12] <Zeenix> what % of the original
[19:13] <hadess> dunno, try it out...
[19:13] <dobey> Zeenix: talk to bjack on irc.gimp.org
[19:15] <Zeenix> i want 1KB out of 5KB
[19:15] <Zeenix> which cannel
[19:15] <Zeenix> i meant which channel
[19:15] <hadess> #gnome
[19:16] <dobey> Zeenix: he's not on right now, he's writing a netmeeting clone for gnome though
[19:16] <dobey> Zeenix: and uses gsm
[19:17] <hadess> dobey: i didn't know that...
[19:17] <dobey> hadess: i think he's gonna release something next month
[19:17] <dobey> now i need a kernel.org ftp that i can get into and into the 2.2 directory...
[19:18] Zeenix (programmer at host-119.netzone.net.pk) left irc: Ping timeout for Zeenix[host-119.netzone.net.pk]
[19:30] Nick change: wtay-zZz -> wtay
[19:30] <wtay> ho
[19:44] <wtay> hmm, IP phone with mp3... my intuition says this is bad...
[19:45] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[19:45] <Uraeus> hi
[19:45] <wtay> hello Uraeus
[19:46] <hadess> hey dude
[19:46] <Uraeus> hi people
[19:46] <wtay> Uraeus: just read your summary, nice work :)
[19:47] <Uraeus> thnx
[19:51] <hadess> Uraeus: yeah, it's really cool stuff =)
[19:52] <Uraeus> you are talking about my GUADEC summary right? cause the GNOME weekly summary this week is by george steve :)
[19:54] <hadess> oh, sorry then
[19:54] Action: hadess goes to talk to george
[19:54] <hadess> :P
[19:54] matth-email (matth at qwest.dsplinux.net) left irc: Ping timeout for matth-email[qwest.dsplinux.net]
[19:55] <wtay> I was talking about the GNOME summary <g>
[19:55] <wtay> s/GNOME/GUADEC
[19:56] <Uraeus> hehe
[19:57] <Uraeus> ok I will mail my first (early) GStreamer 0.2.0 roadmap document to the list now for suggestions and feedback, it might be slightly innaccurate already since I think you guys broke a lot more after I got my CVS version to test stuff
[19:58] <wtay> Uraeus: very cool!
[20:12] Action: Uraeus realises that he is missing the core element in batchelor dinner cooking, pasta
[20:12] Action: Uraeus runs to the store
[20:12] <wtay> doh!
[20:41] Action: Uraeus is back with pizza :)
[20:44] Action: wtay is replying to Uraeus's email..
[20:45] <Uraeus> oh-oh
[20:53] <hadess> "trouble coming"
[20:53] <hadess> i'm wondering if omega has received his ov511 webcam...
[20:56] omega_ (omega at omegacs.net) joined #gstreamer.
[20:56] <Uraeus> hi omega_
[20:56] <wtay> yo
[20:56] <hadess> hey omega_
[20:57] Action: Uraeus is waiting nervously for wtay's email
[20:57] <wtay> Uraeus: it's a long one :)
[20:57] Action: Uraeus turns white
[20:57] Action: hadess helps wtay cut'n'paste his figlet generated DIE DIE DIE
[20:58] Nick change: omega_ -> omega_breakfast
[21:02] <omega_breakfast> a RidgeRun employee died this weekend in a raftig accident
[21:02] <omega_breakfast> er, rafting
[21:03] <Uraeus> your going rafting? that is so cool, I love rafting
[21:04] <omega_breakfast> no, I'm not going rafting, after this
[21:05] <Uraeus> huh, did someone really die?
[21:05] <omega_breakfast> yes
[21:05] <Uraeus> oops, sorry ,thought you very trying to be funny in advance of a rafting trip next weeked :(
[21:05] <omega_breakfast> nope
[21:07] <Uraeus> so who was it, anyone who has been in here?
[21:07] <omega_breakfast> no, a compression guy, though he wanted to finish up that and work on gstreamer
[21:08] <Uraeus> well, my condolences 
[21:10] <omega_breakfast> Uraeus: your categorization of the element is a bit strange
[21:10] <omega_breakfast> xmms-ish
[21:10] <hadess> omega_breakfast: suckage :/
[21:11] <wtay> mail sent...
[21:11] <Uraeus> gulp
[21:11] <wtay> don't fear.. 
[21:11] <wtay> I have it under control :-)
[21:11] <wtay> not..
[21:12] <wtay> uhm..
[21:12] <Uraeus> something wrong with your outgoing mail?
[21:13] Nick change: omega_breakfast -> omega_
[21:14] <taaz> omega_: that releases/0.1.1/debs idea is no good, need to have version indep location since don't want to force people to update apt sources.list location just cause version went from 0.1.1 to 0.2.0.  
[21:14] <omega_> hmm, ok
[21:14] <omega_> releases/debs/ then, maybe make those symlinks to the real ones in 0.1.1/debs/
[21:17] <Uraeus> wtay: sure the au source works?
[21:17] matth (matth at qwest.dsplinux.net) joined #gstreamer.
[21:17] Nick change: matth -> matth_
[21:17] <omega_> hello
[21:17] <matth_> howdy... what's up?
[21:18] <omega_> not much yet
[21:18] <Uraeus> hi matth_, sorry to hear of your loss
[21:18] <matth_> thx... very sad...
[21:18] <steveb> wtay: are you saying that sinesrc should be a plugin?
[21:20] <wtay> yes, my condolences too.. who said sports was healthy..
[21:21] <wtay> steveb: maybe I am...
[21:22] <Uraeus> wtay: sure the au source works? I tried it while writing my roadmap and it snuffed out
[21:22] <wtay> omega_: should put that .gbdinit script is cvs too
[21:22] <omega_> yeah, but where?
[21:23] <wtay> Uraeus: Zaheer depnds on it heavily and the code looks good and up to date
[21:24] <Uraeus> hmm, maybe it is just gstmediaplay who can't use it then
[21:24] <wtay> Uraeus: -launch disksrc location=some.au ! parseau !osssink?
[21:24] <omega_> re: build system, we need to identify which dependencies are critical, such as Hermes, and fail the configure if they aren't there
[21:24] <wtay> Uraeus: probably
[21:24] <steveb> wtay: in that case i couldn't agree more
[21:24] <omega_> and print much larger messages listing the plugins and features that go away when you don't have a dep
[21:25] <Uraeus> wtay: can't test much now, since I migratet to XFS I also got devfs as part of the package and I have been unable to get sound working properly
[21:25] <omega_> doh
[21:25] <Uraeus> devfs is really cool, but for me it sucks
[21:25] <wtay> oops
[21:25] <wtay> omega_: yup, the configure stuff should be more verbose...
[21:26] <wtay> is a directory reorganisation planned for 0.2.0?
[21:26] <omega_> post? yeah, I think it should be done
[21:26] <omega_> can be done kinda in parallel with the glibification
[21:27] <omega_> since it only affects the plugins/ dir
[21:27] <omega_> and the nice thing about that is that each plugin dir is independent of everything but the build stuff, so we're not gonna screw things up
[21:30] <hadess> Uraeus: did you install devfsd ?
[21:30] <Uraeus> hadess: yes, but it doesn't set up my OSS drivers, seem to be some ALSA stuff in there but ALSA 0.5.9 didn't even compile for me
[21:31] <wtay> brb
[21:31] <hadess> Uraeus: i have yet to find out the devfsd voodoo as well
[21:32] <Uraeus> hadess: it worked so well for my cdrom I thought it must be hardware setup nirvana, but my problems both with the commercial NVIDIA driver and the OSS driver shot it down, think I will try and mail the author for some pointers
[21:33] greg_ (greg at home.sente.pl) joined #gstreamer.
[21:33] <omega_> yo
[21:37] <ajzzzz> hmm, uni time... will comment on roadmap later ;)
[21:37] Nick change: ajzzzz -> aj_uni
[21:37] dobey (dobey at 141.154.95.104) left irc: eh
[21:39] Action: omega_ is making many comments to wtay's list
[21:40] Action: taaz made comment to omega_s gdbfu
[21:40] <omega_> taaz: good point, that may be best, as I'm having a really hard time figuring out if a pointer is, say, a Bin
[21:41] <omega_> and actually, it's `call gst_element_info(element)`
[21:42] <taaz> p works too
[21:42] <omega_> it does?
[21:42] <taaz> well, i didn't know about 'call' till just now ;)  i've been using p
[21:43] <taaz> call makes more sense 
[21:43] <omega_> ah
[21:52] stux (jedi at aus-141-81.static.satnet.com.au) joined #gstreamer.
[21:52] <omega_> yo
[21:52] <stux> lo :)
[21:53] <stux> saw you had a little chat with shitowax :)
[21:53] <omega_> yup
[21:53] <stux> <-- 3ivx lead guy ;)
[21:53] <omega_> cool
[21:53] <stux> anywho, glad someone decided to clean up the media architechture mess on linux :)
[21:53] <omega_> heh
[21:54] <stux> i was actually wondering how you are/plan to handle timing/sync in the architechture?
[21:54] <omega_> timing is handled with timestamps on all buffers
[21:55] <omega_> sync is dealt with by a clocking system which is currently very immature
[21:55] <stux> :)
[21:55] <omega_> each sink plugin has the job of coordinating with the clock, or even *providing* the clock in the case of the audiosink
[21:55] <omega_> even the stuff we have right now works better than OMS's... just ask taaz
[21:56] <stux> an idea might be to take a leaf from QT's book... clock's are sources in their own right, 'clock' being a completely separate data stream
[21:56] <omega_> hmmm
[21:56] <stux> essentially the clock beat is the trigger...
[21:56] <taaz> of course it works better than oms... oms doesn't do jack for syncing
[21:56] <omega_> except the gstreamer architecture doesn't allow that to work the same way
[21:56] <stux> and that trigger ripples through the entire frame work... from the movie layer through the track layer to the media layer and then the samples
[21:57] <stux> <shrug> :)
[21:57] <omega_> the clocking system is going to get a major overhaul soon, to make it more robust and accurate
[21:57] <stux> i've gotten good at detecting 1/25th of a second sync problems ;)
[21:57] <omega_> and we need to go through all the plugins that don't do timestamping and make them do timestamping ;-)
[21:57] <stux> anywho, before you overhaul it, go and check out the Clock chapter in Inside Mac: QuickTime
[21:57] <omega_> ok
[21:57] <stux> yeah, timestamps are good
[21:58] <omega_> btw, are you on gst-devel ?
[21:58] <stux> in fact, the 3ivx codec for qt runs on timestamps ;)
[21:58] <stux> nope
[21:58] <stux> maybe I should be... how heavy is the email volume?
[21:58] <omega_> there's some extensive roadmap stuff going up now, if you're interested
[21:58] <omega_> not very heavvy
[21:58] <stux> k
[21:58] <stux> I already get 2-300 per day ;)
[21:58] <omega_> two nightly reports, plus a few a day at most, except for today <g>
[21:58] <stux> hehe, I won't even notice :)
[21:59] <Uraeus> hehe
[21:59] <hadess> stux: heya
[21:59] <stux> lo :)
[21:59] <hadess> stux: i'm the one whining about lack of ppc support :)
[21:59] <stux> in which OS :)
[21:59] <hadess> linux
[21:59] <stux> we do support 12 at last count ;')
[22:00] <stux> LinuxPPC then?
[22:00] <hadess> debian ppc if you ask
[22:00] <stux> hehe, well, I'll be trying to setup a bunch of build machines ... probably in under a week
[22:00] <stux> okay, we have 3ivxXA running on LinuxPPC... the redhat clone
[22:00] <stux> might have to get dual boot setup :)
[22:01] <stux> another interesting thing in a media architecthure which is worth thinking about early is ... internal pipe buffers
[22:01] <omega_> such as?
[22:02] <stux> I'm not sure... but at the moment a sync can pull or a source can push right... and stuff just goes along synchronously right?
[22:02] <omega_> within a single thread, yes
[22:02] <stux> what about something like a buffer component ;)
[22:02] <omega_> pthreads are explicit in the pipeline structure though, so you can place thread boundaries and buffering queues wherever you need
[22:02] <stux> space for say... 10 samples.. be that frames or whatnot
[22:02] <omega_> yup
[22:02] <stux> k
[22:03] <omega_> see http://gstreamer.net/gsteditor.shtml
[22:03] <stux> this helps with glass smooth playback when doing complex decoding
[22:03] <omega_> yup
[22:03] <stux> heeh, GST is the Goods + Services Tax here ;)
[22:04] <omega_> doh
[22:05] <omega_> the dvd player graph shows 4 queues, one before and after each decoder
[22:06] <hadess> omega_: you'll be replacing fdsrc soon ?
[22:06] <omega_> why?
[22:06] <stux> cool, so you have buffers on the threadboundaries?
[22:06] <omega_> yup
[22:07] <stux> cool
[22:07] <hadess> omega_: huh, disksrc even
[22:07] <stux> one of the big problems we had on lesser OS's was starvation...
[22:07] <omega_> they are either fixed size or unbounded, and eventually will have signals at low&high watermarks, etc.
[22:07] <stux> the decode thread could starve the disk read thread!
[22:07] <stux> stupid os
[22:07] <omega_> heh
[22:07] <stux> the other problem we've had was overstressing memory subsystems and hiliting faulty ram sticks ;)
[22:07] <omega_> the thread element will eventualy have the ability to set its priority, as the OS allows
[22:07] <stux> "your code crashes"
[22:08] <omega_> doh
[22:08] <stux> "no it doesn't. Buy new ram"
[22:08] <stux> was about to say :)
[22:08] Action: omega_ has a memtest-2.5 floppy handy
[22:08] <taaz> someone should look into some refactoring that makes disk* subclasses of fd*.
[22:08] <stux> another important thing :)
[22:08] <stux> how direct is GST :)
[22:08] <omega_> taaz: nope, disksrc mmap()'s, fdsrc can't
[22:09] <omega_> direct?
[22:09] <stux> ie, can a codec go direct into an overlay? providing no effects etc are in the way?
[22:09] <omega_> yup
[22:09] <stux> GREAT!
[22:09] <omega_> an overlay can provide bufferpools, which pull backwards, and you can fill them in directly
[22:09] <stux> this is the largest problem with the other feeble ones :)
[22:09] <stux> nice
[22:09] <taaz> omega_: they have so much similar code though... would be nice to see it just in one spot.
[22:09] <omega_> the new filesink I'm gonna write will do this as well, creating buffers that *are* the mmap()'d region
[22:09] <stux> and... how fast can a filter graph be updated?
[22:09] <omega_> taaz: no, the have basically no similar code
[22:09] <hadess> omega_: which one is it i should base gnomevfs src on ?
[22:10] <stux> ie inter frame?
[22:10] <omega_> hadess: probably fdsrc
[22:11] <omega_> incsched allows the graph to be modified at just about any time, as long as you don't do something stupid <g>
[22:11] <stux> :)
[22:11] <omega_> for instance, the typefind example...
[22:11] steveb (steveb at node1ee05.a2000.nl) left irc: [x]chat
[22:11] <stux> no rebuild time or anything :)
[22:11] <omega_> it connects a disksrc to a typefind, runs the pipeline in an infinite loop
[22:12] <hadess> omega_: i'm sorry i didn't have time to work on it yet, i'll do it during the week...
[22:12] <omega_> when the typefind figures out what the stream is, it fires a signal, which causes the app to disconnect the typefind and attach the correct decoder/sink, and reset a cache
[22:12] <hadess> bye all
[22:12] <omega_> the cache runs out of data post-reset, and the app removes it mid-stream
[22:12] <omega_> hadess: l8r
[22:12] hadess (hadess at pc121-gui14.cable.ntl.com) left irc: mooooh!
[22:12] <stux> leads me to another question... I presume you have an internal video data format... ie RGB or YUV etc... or is that completley irrelevant?
[22:12] <omega_> no data is lost
[22:13] <omega_> it's entirely up to the elements
[22:13] <omega_> the caps system is based on mime/type and arbitary tag/value properties
[22:13] <stux> but can codecs (filters) support multiple output formats?
[22:13] <omega_> so video/raw, fourcc = YUY2, stride = 720, etc.
[22:13] <omega_> yes
[22:13] <omega_> when elements are attached, they go through negotiation to settle on a format
[22:14] <omega_> the elements can then internally optimize for those formats
[22:14] <stux> how are priorities determined?
[22:14] <omega_> priorities of which?
[22:14] <stux> ie, we prefer YUV anything to RGB, but us handling RGB is better than someone else doing a YUV to RGB :)
[22:14] Action: wtay is distracted by the snooker final..
[22:14] <omega_> that's a bit tricky right now, but wtay is the man to answer that one ;-)
[22:15] Action: omega_ un-distracts wtay
[22:15] <stux> that's why I'm asking ;)
[22:15] <stux> in the benefits of hoping to stimulate some design questions while its still 'easy' ;)
[22:15] <omega_> heh
[22:15] <stux> these are all problems with the way its done on other *serious* systems
[22:15] <omega_> yup
[22:15] <stux> namely directshow and bemedia (which is pathetic) and quicktime
[22:15] <omega_> heh
[22:16] <omega_> are you very familiar with each of those?
[22:16] <stux> reasonably :)
[22:16] <stux> very very familiar with QT
[22:16] <omega_> how does gstreamer compare, from what you know so far?
[22:17] <stux> i oversee the DMO, Be, Xanim, QT4L codecs etc
[22:17] <stux> so  understand how they all work
[22:17] <stux> gstreamer compares very well :)
[22:17] <omega_> good ;-)
[22:17] <stux> I'd say you need to check out the crazy shit the qt boys have in there ;)
[22:17] thomas (thomas at adsl-65523.turboline.skynet.be) joined #gstreamer.
[22:17] <omega_> stux: specifically?
[22:18] <stux> you know, QTVR, Flash, and all that type of stuff which doesn't fit into traditional AV :)
[22:18] <omega_> heh
[22:18] <stux> ie...
[22:18] <stux> how would you handle a 3D object...
[22:18] <omega_> does a 3d object really *stream* ?
[22:18] <stux> just a 3D object, set of OpenGL instructions, to produce and object which is rotated etc, rather than 'played'
[22:18] <stux> yes, it does ;)
[22:18] <omega_> hmm, ok
[22:19] <omega_> um, I know basically nothing about GL, so I dunno
[22:19] <stux> QT embeds VRML more or less
[22:19] Action: wtay reads the IRC log..
[22:19] <omega_> ok, that's what I thought
[22:19] <stux> (as a matter of fact, so does MPEG4 ;) )
[22:19] <stux> well, GL is like logo... but in 3D ;)
[22:19] <omega_> yeah, but /me has a fundamental disagreement with some of mpeg4's design, at the system level
[22:19] <omega_> heheeh
[22:19] <stux> well, MPEG4 is a funny thing :)
[22:20] <stux> understanding that I know it very well ;)
[22:20] <omega_> I think mpeg4 is overdesigned, and thus has excess overhead even for the natural-video case
[22:20] <stux> (i'm on the commitee ;))
[22:20] <omega_> you are?
[22:20] <stux> 3ivx.com are
[22:20] <stux> not the secretary or anything
[22:20] <stux> but yeah, we go to the meetings, keep up with the goss ;)
[22:20] <omega_> hmmm, ok
[22:21] <omega_> any news from the LA front?
[22:21] <stux> not really, they're essentially concentrating on studio profiles and digital cinema these days
[22:22] <omega_> and ignoring patent license fee structures?
[22:22] <stux> yeah :)
[22:22] <omega_> uh, ok
[22:22] <stux> MPEG likes to pretend patents don't exist ;)
[22:22] <stux> they leave that to the lawyers...
[22:22] <omega_> MPEG2-LA disproves that ;-(
[22:22] <stux> they're completely different to the 350 odd people who get to gether and make up this stuff :)
[22:22] <omega_> MPEG has their head stuck up you know where in pretending patents don't exist
[22:23] <stux> yep
[22:23] <omega_> which is why in the long run MPEG is gonna be replaced
[22:23] <stux> well, MS did piss them off with their glorious MS-MPEG4.3 debacle
[22:23] <omega_> with an Ogg-style codec
[22:23] <omega_> yeah, well, MS pisses lots of people off
[22:23] <omega_> they seem to have cornered that market as well ;-)
[22:24] <stux> i find it hard to believe ogg is really going to be able to match mpeg when it comes to video... without stepping on patents... their are soooooo many here, and they're sooo generalised, but good luck to them
[22:24] <omega_> yeah, that's the problem
[22:24] <stux> I mean, audio is simple really compared to video ;)
[22:24] <stux> its 1D vs 2D :)
[22:24] <stux> (well 2D vs 3D)
[22:24] <omega_> but then they're free to look at different approaches without legacy specs
[22:25] <omega_> and different target hardware, etc.
[22:25] <stux> anyhwho
[22:25] <stux> gotta run
[22:25] <stux> ciao ;)
[22:25] <omega_> MPEG has always targetted silicon
[22:25] <omega_> l8r
[22:25] stux (jedi at aus-141-81.static.satnet.com.au) left irc: 
[22:28] <thomas> hi all
[22:28] Action: wtay is somewhat back
[22:28] <omega_> wtay needs to get over his snooker addiction <g>
[22:30] <wtay> hmmm
[22:31] <Uraeus> wtay: there is a GNOME snooker game you know, maybe you should try switvhing to that :)
[22:31] <omega_> hehehehe
[22:32] <wtay> Uraeus: there is?
[22:33] Action: wtay apt-get frantically..
[22:33] <wtay> hmmm where?
[22:33] <omega_> Uraeus: not smart...
[22:33] <Uraeus> wtay: http://www.suse.cz/gtulpas/
[22:34] Action: omega_ thwacks Uraeus
[22:34] <Uraeus> i remembered wrong it was pool not snooker :)
[22:34] <wtay> hmm, it does say something about snooker too
[22:34] <Uraeus> oh, and there is a snooker screenshot, it must support both
[22:34] <wtay> now, don't we all have an addiction? :-)
[22:36] Action: omega_ hates gcc-2.96
[22:37] <Uraeus> omega_: hate is bad, forgivness is divine :)
[22:38] <omega_> g++ can't convert const char[9] to char *
[22:38] <omega_> i order to compile a stupid little program
[22:38] Action: omega_ hates C++
[22:38] Action: omega_ removes -pedantic -werror -wall
[22:39] <omega_> anyone dumb enough to include those on a g++ commandline, well, ...
[22:39] <omega_> didn't help, either
[22:43] <thomas> omega_: how is the gstreamer-complete supposed to work ?
[22:43] <omega_> you mean how do you use it?
[22:43] Nick change: aj_uni -> ajmitch
[22:43] <ajmitch> greetings, people
[22:44] <omega_> greetings, earthling
[22:44] <ajmitch> i saw my name mentioned in the roadmap, how could this be? ;)
[22:45] <omega_> you didn't know? you've been nominated as release coordinator ;-)
[22:45] <Uraeus> ajmitch: yes, I decided that you had volunteered to take responsibility for extending the gstmediaplay for gstreamer 0.2.0
[22:45] <omega_> ajmitch and arik
[22:45] <ajmitch> yes, i thought arik was as well
[22:46] <Uraeus> omega_: arik volunteered to take on gstmediaplay?
[22:46] <ajmitch> Uraeus: and arik will probably have much more time/skills than me :(
[22:46] <omega_> yeah, instead of write his own media player
[22:46] <omega_> great.  even g++ 3.0 can't compile this code
[22:46] <ajmitch> he volunteered to be maintainer of gstmediaplay
[22:47] <Uraeus> ajmitch: well, the more the merrier :), two people can accomplish more than one person
[22:47] <Uraeus> ajmitch: but I guess that means you are our new editor maintainer!!
[22:47] Action: Uraeus sings and dances
[22:47] <ajmitch> gah
[22:47] <thomas> omega_: I mean, when I run it it segfaults; maybe it isn't meant to be run from the command line ? I have no clue how external bash completion is supposed to work
[22:48] <omega_> oh
[22:48] Action: ajmitch loads editor to se what a sorry state it is on
[22:48] <omega_> you have to run gstreamer-compprep first
[22:48] <omega_> and make sure it has write access to /etc/gstreamer/compreg.xml
[22:48] <thomas> ah ok, trying that tomorrow
[22:48] <thomas> btw I'm setting up a website for the box
[22:48] <omega_> cool
[22:48] <ajmitch> hmm, i'm not even sure how to use the editor properly ;)
[22:48] <omega_> *on* the box? ;-)
[22:48] <thomas> omega_: heh
[22:49] <thomas> I think I've got the structure nailed down the way I want it to ..
[22:49] <Uraeus> ajmitch: so being the maintainer will be a real learning experience then?
[22:49] <thomas> ... in such way as to make it an open-source project for all to contribute
[22:49] <ajmitch> heh, i should see if i can get gstreamer to compile on GNU/Hurd
[22:49] <ajmitch> Uraeus: you could say that ;)
[22:49] <thomas> omega_: hardest part was the name of course
[22:49] <thomas> ;)
[22:49] <omega_> oh?
[22:49] <Uraeus> ajmitch: well, you need the asm stuff if you want it on GNU\Heard
[22:49] <thomas> well you need a name you think is cool ...
[22:49] <thomas> ... and hope others will follow...
[22:50] <thomas> ... I mean, how the hell did someone end up making a company with a name like Microsoft ???
[22:50] <thomas> and it even sells too
[22:50] <ajmitch> Uraeus: what asm stuff? ;)
[22:50] <Uraeus> ajmitch: forget it, it is processor not OS dependant
[22:51] <Uraeus> my bad
[22:51] <ajmitch> i got GNU/Hurd cds yesterday, want to try and see how well stuff breaks ;)
[22:51] <omega_> ajmitch: that's the spirit!
[22:51] <ajmitch> hey, the more platforms the merrier ;)
[22:53] <Uraeus> omega_: ok, so when is the PA-Risc asm code going in? think we might get jacob to do the rest of the porting if we have that in :)
[22:53] <omega_> uh, I can look into that
[22:53] Action: omega_ is considering merging the gsti386, gstppc, gstalpha, etc. files into gstarch.h
[22:55] Action: thomas is starting to really like phpnuke
[22:56] <ajmitch> so is an editor rewrite needed?
[22:56] <omega_> the graph system, yes
[22:56] <ajmitch> i see that it requires a good knowledge of gstreamer core
[22:56] <omega_> sorta
[22:58] <ajmitch> hmm, i dunno if i want to be volunteered as editor hacker ;)
[22:59] <ajmitch> i wonder how well linux handles me turning off the swap and then editing the partition table on a running system?
[23:00] <ajmitch> only one way to find out ;)
[23:00] <omega_> thomas: don't forget to make use of the wiki
[23:01] <omega_> wtay: ?
[23:01] <thomas> omega_: I'll add it as soon as the site looks halfway decent and has some basic content
[23:01] <omega_> ok
[23:01] <Uraeus> ajmitch: ok, I put you up for taking the DVD code in mplayer and fixing up our DVD support instead then
[23:01] <thomas> I'm currently describing how to get  the vesa framebuffer to work
[23:02] <Uraeus> ajmitch: and while your at it take their .asf code too
[23:02] <omega_> thomas: you realize that the vesa frame buffer doesn't do colorspace conversion?
[23:02] <ajmitch> Uraeus: you enjoy volunteering others, don't you? ;)
[23:03] <Uraeus> ajmitch: yes, remember I have a degree in management ;)
[23:03] <wtay> uh?
[23:03] <Uraeus> management==volunteer others :)
[23:04] <omega_> so, what is left before we merge incsched?
[23:04] <wtay> omega_: there still is an issue with the INCSCHED gstplay there is now
[23:04] <omega_> yeah
[23:05] <wtay> It currently uses two thread, one for disksrc, another for thz autoplugged element
[23:05] <wtay> they all sit inside a pipeline so it should work
[23:05] <thomas> omega_: what do you mean, no colorspace conversion ? I mean, I'm not quite sure what that is yet.
[23:05] <thomas> Currently, the vesafb is the only way I can get the graphics to show on the tv screen
[23:05] <omega_> thomas: video's native format is YUV
[23:05] <omega_> all the video codecs operate in that colorspace
[23:05] <thomas> btw right now I use 800x600 in 16 bit, I suppose 640x480 would look better ?
[23:06] <Uraeus> ajmitch: so when will the plugin be in?
[23:06] <omega_> if you capture and/or display in RGB, you have to do a software converson
[23:06] <omega_> thomas: yup
[23:06] <thomas> omega_: is there a way to display native yuv under linux then ?
[23:06] <thomas> and does it look better ?
[23:06] Action: omega_ notes that hadess still has 256MB of RAM
[23:06] <omega_> thomas: yeah, either XFree Xv extension, or some of the others that are card-specific, like mga_vid
[23:07] <ajmitch> Uraeus: umm...
[23:07] <omega_> wtay: I'm gonna make another pass as figuring out the mixer livelock
[23:07] <thomas> omega_: ok, I'll check that later.  Right now I'm happy I got raine working under X on the TV ;)
[23:07] <thomas> it looks good too with chase hq
[23:07] <omega_> heh
[23:07] <thomas> I'll put up screenshots as well as I progress
[23:08] <thomas> btw I'm also working with version numbering for the "states" of the box, so right now I'll leave the vesa fb setup in...
[23:08] <thomas> ... as a first possible way of getting tv/out to work.
[23:08] <wtay> omega_: ok
[23:08] <thomas> then a next version of the os config would entail Xv and YUV and stuff
[23:08] <omega_> wtay: any more thoughts on dynamic autoplug?
[23:08] <thomas> ok, I'm off to bed.
[23:08] <thomas> night all
[23:08] <wtay> omega_: not yet...
[23:08] <omega_> thomas: ok. check out mplayer's doc on output
[23:09] <omega_> they list the hardware specific caps
[23:09] <thomas> mplayer is a media player ? is it on freshmeat ?
[23:09] <wtay> omega_: we need to suickly find a compatible element somehow..
[23:09] <omega_> wtay: that's gonna be the big killer for incsched, is getting the static autoplugger to cooperate
[23:09] <omega_> thomas: yeah. yes.
[23:09] <thomas> ok, will check tomorrow
[23:09] <thomas> bye
[23:09] <wtay> cya
[23:09] thomas (thomas at adsl-65523.turboline.skynet.be) left irc: Client Exiting
[23:10] <omega_> wtay: btw, if we can precompute the compatibility graph, we can use that to aid in -launch completion
[23:10] <wtay> omega_: yup
[23:10] <wtay> omega_: I've been thinking about that
[23:10] <wtay> omega_: the compatibility graph can only be done on the padtemplates though
[23:10] <omega_> right
[23:11] <omega_> well, we can instantiate the element as in -inspect
[23:11] <omega_> and record those as well.  I do that in compprep
[23:11] <wtay> omega_: real caps are set at PLAYING time..
[23:11] <omega_> yes
[23:13] <omega_> btw, where should I put the gdb command script in cvs, and what should I call it?
[23:13] <omega_> we can assume that someone will create a .gdbinit with `source /path/to/gst-gdbinit`
[23:19] <wtay> hmm
[23:20] <wtay> I think you can, yes
[23:20] <wtay> install dir
[23:20] <omega_> I mean where in cvs, filename, and installdir ?
[23:21] <wtay> actually, I like taaz's solution better...
[23:21] <omega_> yes, but we still need a gdbinit file
[23:21] <wtay> in cvs: /gst-gdbinit is fine
[23:21] <omega_> since that gives us command completion, even if it's just a wrapper around call gst_....
[23:22] <wtay> ok
[23:22] <wtay> filename .gst-gdbinit
[23:22] <wtay> installdir...
[23:22] Action: omega_ still waits for UPS to devliver camera and 100bt switch
[23:22] <omega_> do we really want it a dotfile?
[23:23] <wtay> not needed
[23:23] <omega_> hrm, this is strange
[23:23] <wtay>  /usr/local/share/gst/gst-gdb/gst-gdbinit?
[23:24] <omega_> ick
[23:24] <wtay> yeah
[23:24] <wtay>  /usr/local/share/gst/gst-gdbinit?
[23:24] <omega_> somehow disksrc is getting a pullfunc proxy, and getting stuck in it
[23:24] <omega_> that works
[23:24] <wtay> pullfunc?
[23:25] <omega_> yeah
[23:25] <wtay> oops
[23:26] <wtay> btw, snooker is over now for a few months :-)
[23:26] <omega_> good
[23:28] <omega_> ah, I see what's wrong
[23:28] <omega_> it thinks it's switching to disksrc, but in actuality it's switching to volenv, which is driving the loop
[23:28] <omega_> but how it got into that state I have no idea
[23:31] <Uraeus> night
[23:31] Uraeus (cschalle at c224s9h5.upc.chello.no) left #gstreamer.
[23:31] <omega_> l8r
[23:32] <wtay> omega_: this is with the WITH_BUG define?
[23:32] <omega_> afaik, dblchecking
[23:33] <omega_> yes
[23:33] <omega_> lemme commit the latest cvs stuff, sec.
[23:33] <omega_> er, nevermind, CVS will do it
[23:34] <wtay> ok, so something is not cleared properly when removing the bin from the autoplug pipeline
[23:37] <omega_> so it seems
[23:38] <wtay> ok, got something even smaller to show the lock
[23:38] <omega_> which?
[23:38] <wtay>   {
[23:38] <wtay>     GstElement *pipeline;
[23:38] <wtay>     pipeline = gst_pipeline_new ("autoplug_pipeline");
[23:38] <wtay>     gst_bin_add (GST_BIN (pipeline), channel->pipe);
[23:38] <wtay>     gst_element_set_state (pipeline, GST_STATE_PLAYING);
[23:38] <wtay>     gst_element_set_state (pipeline, GST_STATE_NULL);
[23:38] <wtay>     gst_bin_remove (GST_BIN (pipeline), channel->pipe);
[23:38] <wtay>   }
[23:38] <omega_> which lock?
[23:38] <wtay> right after creating the channel->pipe bin
[23:39] <wtay> as seen with the WITH_BUG define...
[23:39] <omega_> er, huh?
[23:40] <wtay> er, are we talking about the same thing?
[23:40] ajmitch (ajmitch at p10-max7.dun.ihug.co.nz) left irc: Ping timeout for ajmitch[p10-max7.dun.ihug.co.nz]
[23:40] <wtay> I'm talking about the lock in mixer.c when you define WITH_BUG in the source
[23:43] <omega_> you mean the livelock?
[23:44] <omega_> can you commit that somehow?
[23:44] <wtay> yup, sec. I'm rebuilding
[23:44] <wtay> I didn't have your latest changes
[23:44] <omega_> ok
[23:45] Action: omega_ has his camera and 100bt switch
[23:45] <wtay> what kind of camera?
[23:46] <omega_> ov511
[23:46] <wtay> a webcam?
[23:46] <omega_> yup
[23:47] <wtay> commited a new mixer.c
[23:47] <wtay> uncomment WITH_BUG2
[23:50] <wtay> autoplugtest works
[23:57] Action: omega_ goes to install his switch
[00:00] --- Tue May  8 2001
[00:01] <omega_> LAD is basically ignoring gstreamer
[00:01] <wtay> LAD?
[00:01] <omega_> linux-audio-dev
[00:01] <wtay> oh
[00:01] <wtay> why?
[00:02] <wtay> I mean, why do you think so?
[00:02] <omega_> I think they're in their own little world
[00:02] <wtay> just doing theor own stuff..
[00:02] <omega_> yup
[00:02] <wtay> recreate a gstreamer or just ignoring it?
[00:03] <omega_> recreate a part of it, yeah
[00:03] ajmitch (ajmitch at p33-max10.dun.ihug.co.nz) joined #gstreamer.
[00:03] <wtay> great..
[00:04] <wtay> I got an idea..
[00:05] <omega_> lad or mixer?
[00:05] <omega_> mixer faults much more immediately now
[00:05] <wtay> we need a DTD for properties and gstreamer-verify to check them against our standards
[00:05] <omega_> good idea, though that should be part of the general verifier
[00:06] <wtay> yup
[00:06] <omega_> which would check for conformance with all the various requirements, and detail what's wrong and even how to fix some of them (like the NO_ENTRY) flag
[00:06] <wtay> maybe we could use an XML schema to describe the standard caps etc..
[00:06] <omega_> could be
[00:06] <omega_> not a schema, just an xml file
[00:07] <wtay> well, a schema is XML,if we can use it, why not
[00:07] <omega_> one big point that is being made on lad right now is that they don't want to do datatype negotiation, just stick with float32
[00:07] <wtay> do a caps to XML export and then verify it
[00:07] <omega_> schame describes xml
[00:07] <omega_> erm
[00:07] <omega_> not sure an xml verifier is the right approach
[00:08] <omega_> I'd rather just do it directly, since we do have a finite set of props
[00:08] <wtay> could be done too of course
[00:08] <omega_> but for pro-audio, we'll want to make sure that we make it very easy to write stuff with float32
[00:09] <omega_> since that's the standard they've settled on
[00:09] <wtay> no prob for us
[00:09] <wtay> a problem for them if they are going to meet the real world
[00:09] <omega_> yup
[00:09] <omega_> well, that's where the conversion elements come in ;-)
[00:10] <omega_> and I'd be tempted to set up the alsasrc/sink to do some conversions internally just to speed those cases up
[00:10] <wtay> if needed, yes
[00:11] <omega_> ** CRITICAL **: file gstelement.c: line 736 (gst_element_set_state): assertion `element->sched != NULL' failed
[00:12] <wtay> looks like stux is impressed
[00:12] <omega_> quite ;-)
[00:12] <wtay> aha
[00:13] <wtay> also not that in the mixer case, the livelock doesn't happen when there is no state transition...
[00:13] <wtay> s/not/note
[00:13] <omega_> oh?
[00:13] <wtay> add/remove works
[00:13] <wtay> add/PLAYING/NULL/remove doesn't
[00:14] <omega_> don't need to go to NULL
[00:14] <omega_> should only go to PAUSED
[00:14] <omega_> see autoplugtet
[00:14] <omega_> er, autoplugtest
[00:14] <wtay> but it should work, no?
[00:14] <omega_> not necessarily
[00:14] <omega_> it should work, yes
[00:14] <wtay> in this case
[00:19] <wtay> 0x8084b10: !disksrc1 <<--- what does the '!' mean?
[00:19] <omega_> where?
[00:19] <omega_> oh, sched_show?
[00:19] <omega_> it means it's disabled
[00:19] <omega_> ~= !PLAYING
[00:20] <wtay> ok, makes sense
[00:21] <omega_> I'm gonna write up the mixer to look like autoplugtest
[00:24] <omega_> could I create a disksrc, give it caps, create some filter with a small range of caps, then autoplug_to_caps between those?
[00:26] <wtay> I think you can, yes
[00:26] <wtay> I have to sleep now...
[00:26] <wtay> cya
[00:26] Nick change: wtay -> wtay-sleeping
[00:26] Action: wtay-sleeping has been living on 6hours sleep for the past 3 weeks..
[00:26] <omega_> ok, I'll give it a try
[00:26] <omega_> sleep
[00:26] <ajmitch> sleep?
[00:27] <ajmitch> 6 hours os more than enough
[00:27] <omega_> ajmitch: um
[00:27] <ajmitch> hmm, this could be fun trying to install GNU/Hurd with no floppy drive to boot the system - might have to install grub under linux and play that way ;)
[00:28] <ajmitch> omega_: yes? ;)
[00:28] <ajmitch> me runs apt-get install grub
[00:28] <omega_> um, yeah
[00:28] <omega_> no bootable cd?
[00:28] <ajmitch> doh
[00:29] <ajmitch> yeah, but no bootloader installed after base system is installed
[00:29] <omega_> uh???
[00:29] <omega_> that's stupid
[00:30] <ajmitch> yeah, well, it's a hacked up debian install system
[00:31] <ajmitch> done by one of my friends in the LUG
[00:31] Nick change: matth_ -> matth-distracted
[00:32] <ajmitch> ah, crap, nearly time to go to lectures, gstreamer hacking will have to wait until later (if i can find something to work on)
[00:32] <ajmitch> omega_: what needs work done that a newbie like me can help with? ;)
[00:32] <omega_> ah
[00:33] <omega_> plugin cleanup
[00:35] <ajmitch> ok
[00:35] <ajmitch> will take a look this afternoon then
[00:35] <omega_> cool
[00:35] <ajmitch> i've got the email to the list about what plugins are on need of some luvin'
[00:35] <omega_> ;-)
[00:39] <ajmitch> bbl
[00:39] Nick change: ajmitch -> aj_uni
[00:56] <taaz> heh... you see post from pbd about parameter negotiation?
[00:58] <omega_> which one?
[00:58] <omega_> that's been the focus of the thread for a while now
[01:11] <taaz> the recent one where he's laughing
[01:13] <omega_> yeah, he's got a point, and he's assuming other limitations like 'frame size'
[01:13] <omega_> we'll probably have a frame_size property for pro-audio filters, just so they can optimize on it, but that's not gonna be a big deal
[01:14] <taaz> heh... you should post that ;)  trivialize the whole discussion
[01:14] <omega_> erm, don't want to make him into an enemy
[01:15] <omega_> do need to find a good place to insert gstreamer again
[01:15] <omega_> maybe you should try it
[01:15] <taaz> yup, better to make it work first then point out how cool it is
[01:16] <taaz> have everyone here just sort of pop in with a comment about gstreamer?  no one will notice...
[01:16] <omega_> no, just people like you who already follow the discussion
[01:17] <taaz> i don't have much to say.  i would rather get hard numbers on gst latency and overhead or whatever and compare with whatever they have.  i'm really not enough of an expert to just speculate on this stuff.
[01:18] <omega_> latency and overhead are nothing compared to the fundamental design limitations they're assuming
[01:18] <omega_> heck, don't even mention gstreamer, just challenge their assumptions
[01:19] <taaz> after following this stuff for a while i tend to get the impression that they don't need much more than what they have.  hard to argue against that.  i like lots of flexability but perhaps it's just not needed in some cases
[01:20] <omega_> yes, but they're going to waste their time producing yet another system that's incompatible with everything else
[01:21] <omega_> they may need only that much, but what reason is that to implement something new if the other choices do it with insignificant overhead anyway?
[01:21] <taaz> well, you can have the last laugh when there is a gstreamer plugin for all these different plugins and it all becomes compatible and fast and good
[01:21] <omega_> and btw, in a synchronous system, overhead == latency
[01:21] <omega_> or they decide not to waste their time with another system
[01:22] <taaz> picky picky...
[01:23] <taaz> perhaps the ladspa plugin should be fixed up so we do real comparisons with other ladspa systems.  
[01:23] <omega_> yeah, I should just finish that
[01:23] <omega_> there was one problem I can't remember...
[01:24] <taaz> you must have a large todo list with items that actually need to be done... mine are mostly dreams ;)
[01:24] <omega_> caps nego is trick, since they tend to assume mono as well
[01:24] <omega_> let's just say that I have to have an MMU just to handling paging of my todo list
[01:25] <omega_> er, handle the paging
[02:46] greg_ (greg at home.sente.pl) left irc: Ping timeout for greg_[home.sente.pl]
[02:51] paddler (paddler at adsl-64-168-101-122.dsl.scrm01.pacbell.net) left irc: Ping timeout for paddler[adsl-64-168-101-122.dsl.scrm01.pacbell.net]
[02:51] paddler (paddler at adsl-64-168-101-122.dsl.scrm01.pacbell.net) joined #gstreamer.
[02:53] sienap (synap at ipc379c27e.dial.wxs.nl) joined #gstreamer.
[02:53] <sienap> hmm
[02:54] sienap (synap at ipc379c27e.dial.wxs.nl) left irc: sienap has no reason
[02:57] Nick change: aj_uni -> ajmitch
[02:57] Action: omega_ is building the first compound element
[02:58] Action: ajmitch is back
[03:01] <omega_> there are some issues to worry about...
[04:21] <taaz> compound elements?
[05:41] <omega_> subclass of a Bin that does neat stuff by way of child elements
[06:03] <taaz> bins arnt enough?
[06:05] <omega_> nope
[06:14] walken (foobar at c1583255-a.smateo1.sfba.home.com) joined #gstreamer.
[06:14] <omega_> yo
[06:14] <walken> yop
[06:15] <walken> whats up ?
[06:15] <omega_> doing some cleanup in libgst.la
[06:15] <omega_> grep warning MAKE.OUT
[06:15] <taaz> hey walken 
[06:15] <walken> hi david
[06:16] <taaz> omega_: why not just use -Werror?
[06:16] <omega_> tempting
[06:16] <walken> -Werror is quite useful
[06:16] <walken> for me
[06:17] <walken> david. do you use the gcc 3.0 debian package ?
[06:18] <taaz> um... let me check ;)
[06:18] <taaz> nope
[06:18] <walken> hmmm
[06:19] <walken> I'd like to try it, but I'd like to know first if it'll overwrite my perfectly working 2.95.4
[06:19] <taaz> where is it? experimental?
[06:19] <walken> in testing
[06:19] <walken> been there for a few weeks
[06:19] <walken> gcc3.0
[06:20] <walken> gcc-3.0 even
[06:21] <taaz> its not like you cant undo it
[06:22] <walken> /usr/bin/gcc-3.0
[06:22] <walken> looks ok
[06:23] <taaz> does it have mmx/sse/etc intrinsics?
[06:23] <walken> no idea
[06:23] Action: taaz ventures off to gcc homepage
[06:25] <omega_> I heard something about Intel releasing their compiler on Linux soon, for free no less (no source)
[06:25] <walken> yes there is a beta program
[06:25] <taaz> why would they do that?  its in their best interest for code gen to suck so epople have to buy faster processors ;)
[06:26] <walken> it was supposed to start last december, but now its supposed to be real soon now :)
[06:26] <walken> OTOH its their best interest for code gen to be better than on amd processors
[06:26] <omega_> yup. and take advantage of the newest features, to move ppl to p4's