[gst-devel] Daily IRC logs

[wim.taymans at chello.be]

[06:40] _gst_newt_ joined #gstreamer.
[06:59] ajmitch (ajmitch at p11-max6.dun.ihug.co.nz) left irc: Ping timeout for ajmitch[p11-max6.dun.ihug.co.nz]
[07:01] ajmitch (ajmitch at p11-max6.dun.ihug.co.nz) joined #gstreamer.
[07:14] ajmitch (ajmitch at p11-max6.dun.ihug.co.nz) left irc: Ping timeout for ajmitch[p11-max6.dun.ihug.co.nz]
[07:15] ajmitch (ajmitch at p11-max6.dun.ihug.co.nz) joined #gstreamer.
[08:35] steveb (steveb at node1ee0c.a2000.nl) joined #gstreamer.
[08:37] <steveb> omega_: ping
[08:37] <omega_> pong
[08:38] <omega_> you mentioned the debug colors sucked on white bg
[08:38] <omega_> willing to come up with a colorset that doesn't?
[08:38] <omega_> I can add ~/.gstcolors support for theming <g>
[08:42] <steveb> i only noticed it because i shelled in from work
[08:42] <omega_> ah
[08:43] <steveb> and i changed it to a black background immediately - but there might be some out there who prefer white
[08:43] <omega_> yeah
[08:43] <omega_> bleagh.  glib assertions aren't very informative
[08:44] <steveb> Owen and I had a chat about dynparms yesterday
[08:44] <omega_> and?
[08:44] <steveb> you should check the logs - it was very productive
[08:44] <omega_> ok
[08:45] <omega_> I had a thought:
[08:45] <omega_> would it be useful to go and just plain build what l-a-d is working towards, putting off some of the stuff like dynparms until that's done?
[08:45] <omega_> just to prove it can be done, and provide us with a more concrete testcase and working environment?
[08:46] <steveb> sure, although i am quite happy to hack away quietly with no fixed milestone
[08:46] <omega_> yeah, but I wanna get something working <g>
[08:46] <steveb> i should help with the effort at hand in the areas i know about
[08:46] <omega_> and maybe shock the l-a-d people into figuring something out
[08:48] <steveb> an important element which is missing is a channels2pads (and pads2channels). since LADSPA does stereo stuff using different buffers per channel
[08:48] <omega_> yeah
[08:49] <omega_> or 'channelmerge', 'channelsplit'
[08:49] <steveb> yeah
[08:49] <omega_> with possible type conversion at the same time
[08:49] <steveb> so what is missing in your opinion
[08:49] <omega_> convert from stereo S16LE to dual float streams
[08:49] <omega_> since you have to touch all the data anyway....
[08:49] <omega_> missing for which?
[08:49] <steveb> l-a-d compliance
[08:50] <omega_> compliance?
[08:50] <omega_> lots and lots of acronyms
[08:50] <steveb> ha.
[08:50] <omega_> each must have at least one (preferrably more) 'L' and 'A'
[08:50] <omega_> LALALALALA comes to mind
[08:50] <steveb> AGGAGSTREAMERLAAG\
[08:51] <omega_> um, I'd say a functioning ladspa wrapper, and alsa 0.9 multichannel source/sink
[08:51] <steveb> so how goes ladspa?
[08:51] <omega_> even if it's not optimal, i.e. doesn't use mmap() initially
[08:51] <omega_> not much left do, really
[08:51] <omega_> though to be safe there's more work
[08:52] <omega_> and to be fastest possible, more still
[08:52] <omega_> current impl is a loopfunc that reads from all sink pads, sets pointers, and calls the process() function
[08:52] <omega_> but there's no checking to verify that the buffers are all the same length
[08:53] <omega_> so we need code to either cut or build buffers to match them all, and _pull() as necessary
[08:53] <omega_> eventually I'd like to see aux properties for pro-audio, like a "framesize" property
[08:53] <steveb> so ladspa plugins require uniform size buffers?
[08:53] <omega_> then they can all agree on buffer sizes up front
[08:54] <omega_> yeah, they have these control ports, where I/O is float *
[08:54] <omega_> then process() takes a nsamples
[08:54] <steveb> so you can't set nsamples before each process()?
[08:54] <omega_> bufferpool tricks with this can be useful too, along with some way to use process_adding()
[08:54] <omega_> yes, but nsamples is for *all* inputs at once
[08:54] <steveb> even the control ones?
[08:55] <omega_> no, 'control port' is a unified thing in ladspa
[08:55] <omega_> control ports are float *'s, but can be either control or I/O, depending on flags
[08:55] <steveb> right
[08:56] <omega_> so the gstladspa element has an array of float's where the args go, and it sets the pointers for each control port to the right location in the array
[08:56] <omega_> same thing has to be done for I/O
[08:56] <steveb> are you doing you ladspa stuff in HEAD or INCSCHED?
[08:56] <omega_> but I don't have the structures in place to do a clean map from pad# to control port
[08:56] <omega_> I've made changes in incsched
[08:56] <omega_> I have some local ones too, I'll commit those
[08:56] <omega_> rather, I shouldn't
[08:57] <omega_> you want to work on it?
[08:57] <steveb> no, just look at it
[08:57] <omega_> ok, check either HEAD or INCSCHED
[08:57] <steveb> i'm still on a learning curve with grokking ladspa
[08:58] <omega_> it's quite simplistic, which isn't in its favor IMO
[08:58] <steveb> yeah
[08:58] <omega_> then again, it's quite similar to VST
[08:59] <omega_> but if we can build a demo app that does some interesting live and non-live processing of audio, that gives us a better testbed for various things
[08:59] <omega_> I still haven't shown off gstreamer running the hardware I've had for over a year now ;-(
[08:59] <steveb> what process model would be best for a simple gstreamer gtk app?
[09:00] <omega_> probably pipeline with thread[s]
[09:00] <omega_> so you don't have to worry about iterate()ing the Pipeline
[09:00] <omega_> good test case for thread interlock too
[09:00] <steveb> great :(
[09:01] <omega_> nothing we haven't already done, just a purer form
[09:02] <steveb> i just want to write a tiny real time app which has a few elements (like volume) controlled by sliders
[09:03] <omega_> yup.  use a thread in a pipeline
[09:03] <omega_> or even just a thread on its own will work
[09:04] <omega_> but I wouldn't get used to building like that, there may be a reason in the future to always have a parent Pipeline (it might be enforced)
[09:04] <steveb> are there existing apps i could base it on?
[09:04] <omega_> um not really ;-)
[09:05] <steveb> what does gstplay do?
[09:05] <omega_> I could write up one really easily, if you want an example
[09:05] <omega_> lots lots more junk
[09:05] <steveb> that would be grand
[09:05] <omega_> ok, lemme hack something up... sec.
[09:06] Action: omega_ digs out his gtk book
[09:07] <omega_> actually...
[09:07] <omega_> gstreamer.net/gist.c
[09:07] <omega_> check that out while I write this, that'll give you an idea
[09:08] <steveb> ok
[09:10] Action: omega_ goes to check it out too <g>
[09:12] <steveb> so this drives the pipeline through the async_idle_func
[09:12] <omega_> yeah
[09:12] <omega_> that was before threads even existed I think <g>
[09:14] <omega_> test something out:
[09:14] <omega_> ./gstreamer-launch osssrc ! osssink
[09:14] <omega_> lemme know if that works or locks up
[09:18] <steveb> it seems my soundcard isn't async
[09:18] <omega_> bleck
[09:18] <omega_> that makes things harder
[09:19] <steveb> at least the OSS driver isn't
[09:19] <omega_> what card?
[09:21] <steveb> when i use alsa i use ES1688 driver
[09:21] <omega_> hrm, try snd-pcm-oss ?
[09:22] <steveb> instead of sb?
[09:22] <omega_> no, the proxy driver for oss
[09:23] <steveb> i haven't got alsa compiled at the moment - will do it now.
[09:23] <omega_> ok
[09:25] <omega_> wow, compiled the first time
[09:26] <omega_> didn't run so well though
[09:26] <omega_> for good reason though <g>
[09:30] <omega_> ergh
[09:30] Action: omega_ needs to set up the volume plugin to not reset its chain function, since that doesn't work correctly just yet
[09:30] <omega_> it did once upon a time... <g>
[09:32] <steveb> so what else has a reference to it
[09:32] <omega_> to which?
[09:32] <steveb> the chain func
[09:32] <omega_> the pointer might get copied
[09:32] <omega_> not sure that's what's happening now thoug
[09:32] <steveb> ah
[09:36] <steveb> i need to restart X
[09:36] <omega_> ?
[09:36] steveb (steveb at node1ee0c.a2000.nl) left irc: [x]chat
[09:39] steveb (steveb at node1ee0c.a2000.nl) joined #gstreamer.
[09:40] <omega_> ok, this works now
[09:40] <omega_> HEAD volume.c has fixes to make it work by default <g>
[09:41] <omega_> live.c sent in mail
[09:42] <steveb> alsa is working - still no async audio :(
[09:42] <omega_> bleagh
[09:43] <omega_> ok, I've been thinking of setting up the osssrc/osssink to cooperate for this stuff
[09:43] <steveb> i should buy a USB mic for a laugh
[09:43] <omega_> if you have one of each to the same device file... they open it once and share
[09:43] <omega_> coordinate via the class
[09:43] <steveb> yup
[09:43] Action: omega_ looks up the oss programming guide to see how that'll work
[09:43] <steveb> which address did you send it too?
[09:43] <omega_> the question is then how closely tied are input and output, do they have to match per sample?
[09:44] <omega_> sbaker3 at chello.com, iirc
[09:44] <omega_> er, sbaker
[09:44] <steveb> ok
[09:46] <steveb> actually, maybe it would if oss was only opened once.  The error is "unable to open sound device (in use) 
[09:46] <steveb> is that what you get?
[09:46] <omega_> nope, mine works
[09:46] <steveb> oh
[09:46] <omega_> maestro 2e
[09:50] <omega_> neat.  the oss reference pdf is a bit fragged <g>
[09:52] <steveb> so what is the pad naming convention for elements which have variable pads (like mixers or channelsplit
[09:52] <steveb> )
[09:52] <omega_> well, that's something to be decided
[09:52] <omega_> and how to control them is fuzzy too, because I recently noticed that args are stored in the class, not the instance
[09:53] <omega_> so I have no idea if we can safely add/remove args as needed from a given instance of a mixer
[09:53] <steveb> hm
[09:53] <omega_> we may have to resort to the pointer to 2d array of floats thing
[09:53] <omega_> which is much faster and more direct anyway....
[09:53] <omega_> but more dangerous (though we can try to make it obvious if someone screws up, say, SEGV <g>)
[09:56] <steveb> well, the dynparms api could handle this explictly :)
[09:56] <omega_> erm
[09:56] <omega_> completely different problem
[09:56] <omega_> it does tempt me to device a completely different argument system though
[09:57] <omega_> one more tuned to what the elements need
[09:57] <steveb> gtk get/set is barely adequite
[09:59] <steveb> its not a completely different problem - many of the args will be parameters which should be dynamic
[10:00] <omega_> yes, but the issue of dynparms vs. parameters that come/go based on others is different
[10:00] <omega_> each of the mix points might be a dynparm, yes
[10:00] <steveb> yes
[10:00] <omega_> if you have a 16x16 matrix, that means 256 args, you add another src pad and suddenly it's 16x17, and you're adding 16 arguments
[10:01] <omega_> the part about adding more arguments to a specific instance is what I'm fuzzy on
[10:03] <steveb> when the dynparm is initialised you could flag it as a multi pad dynparm, so a new instance could be created for each new pad, and referenced by pad number (or something)
[10:03] <omega_> hmmm
[10:06] <steveb> i'm just thinking out loud here, but the problem will need to be solved in dynparms eventually anyway
[10:06] <omega_> yeah
[10:06] <steveb> so if we are talking new APIs, there is already one on the table <g>
[10:17] <steveb> to be honest, i would be much use getting alsa working - and you seem to have ladspa in hand
[10:18] <omega_> you wanna give it a try?
[10:18] <steveb> i am talking about dynparms - are you?
[10:19] <omega_> er, 'would' or 'wouldn't' ?
[10:19] <steveb> sorry?
[10:19] <omega_> see above, is that a typo
[10:19] <omega_> ?
[10:20] <steveb> ah, wouldn't
[10:20] <omega_> ok
[10:24] Action: omega_ tries to force osssink to sound odd unless capsnego happens
[10:24] Action: omega_ succeeds <g>
[10:24] <omega_> doh, that sounds funky <g>
[10:25] <omega_> 44100 played out at 11025
[10:26] <omega_> try playing 13-Rage_Against_The_Machine_-_Wake_Up.mp3 that way <g>
[10:29] <steveb> that wouldn't wake up anyone
[10:29] <omega_> erm, nope
[10:29] <omega_> 48000 isn't nearly as amusing as 176400 would be <g>
[10:39] steveb (steveb at node1ee0c.a2000.nl) left irc: Ping timeout for steveb[node1ee0c.a2000.nl]
[11:03] <BBB-[away]> good point, omega (your mail to gtk-list@)
[11:04] <omega_> it surprised me that it was hardcoded ;-(
[11:06] <BBB-[away]> me too
[11:06] <BBB-[away]> what else is glib-config for?
[11:06] Action: omega_ has much fun a) coding while sleeping, b) building a dynamic autoplugger
[11:07] <omega_> if I was sick with something else, I'd probably be 'coding on codeine' <g>
[11:08] <BBB-[away]> coding while sleeping is *not* what I'd call fun :P
[11:08] <BBB-[away]> I generally sleep when I sleep
[11:08] <omega_> entertaining, at least
[11:09] <omega_> and the results, well, just wait till you cvs update <g>
[11:11] <BBB-[away]> does gstmediaplay already work? :PPP
[11:11] <omega_> no
[11:11] Action: BBB-[away] ets very very mean
[11:11] <BBB-[away]> :P
[11:11] <omega_> that's why I'm working on the dynamic autoplugger
[11:11] <BBB-[away]> muhahahahahah
[11:11] <BBB-[away]> oh ok
[11:11] <BBB-[away]> gstmediaplay is the first app I always check
[11:12] <BBB-[away]> and it's funny to see that it still crashes :)
[11:12] <omega_> yeah, it needs help
[11:12] <BBB-[away]> if I've done lavrec/lavplay refactoring and lavpipe restructuring, I'll look at it, ok?
[11:13] <omega_> where?
[11:13] <BBB-[away]> and if the editing in LVS doesn't crash the kernel anymore
[11:13] <BBB-[away]> that's all mjpegtools
[11:13] <BBB-[away]> :
[11:13] <BBB-[away]> :)
[11:13] <omega_> I'll check it out if I have time <g>
[11:14] <BBB-[away]> lol
[11:14] <BBB-[away]> you're full-time employee at ridgerun
[11:14] <BBB-[away]> I'm a poor student
[11:14] <BBB-[away]> *big difference*
[11:14] <omega_> yeah....  I'm also thoroughly screwed up right now: bodyclock, sick, etc.
[11:15] <BBB-[away]> auch
[11:15] <BBB-[away]> that doesn't sound good
[11:15] <BBB-[away]> how about a vacation?
[11:15] <omega_> uh
[11:15] <omega_> you think a vacation stops me from coding?
[11:16] <omega_> think 'prying from cold, dead hands'
[11:16] <omega_> that's something that must be remedied, of course ;-}
[11:16] <BBB-[away]> uhm.....
[11:16] <BBB-[away]> I don't even touch a computer on vacation
[11:16] <omega_> I carry one around if for nothing else than to dump my digicam pics to it
[11:16] <BBB-[away]> (big problem: if you come home after 3 weeks vacation and you get 300 e-mails a day)
[11:16] <omega_> that's what it was for last summer
[11:17] <omega_> hrm, yeah, sounds about right
[11:17] <BBB-[away]> that's 21*300 = 6300
[11:17] <BBB-[away]> my mailer would explode instantly
[11:17] Action: omega_ still waits for someone to build a cheap device with a hard drive and a CF reader, just dumps the CF to the drive on command
[11:17] <omega_> then /me could go on vacation without a laptop
[11:18] <BBB-[away]> if a Miro DC10+ ws available in PCMCIA format, I'd take a laptop too :)
[11:18] <omega_> doh
[11:18] <omega_> then you'd be screwed up too <g>
[11:18] <BBB-[away]> why?
[11:18] <omega_> vacation ~!= work
[11:19] <BBB-[away]> hmm.....
[11:19] <BBB-[away]> are you sure? :P
[11:19] <omega_> hehe
[11:22] Action: BBB-[away] doesn't believe it
[11:22] <omega_> which?
[11:23] <BBB-[away]> <omega_> vacation ~!= work
[11:24] <omega_> it depends on the vacation and whether you take a laptop <G>
[11:24] <BBB-[away]> hm.... very true
[11:25] <omega_> ooooooooh
[11:25] <omega_> the autoplugger is taking shape <g>
[11:26] <omega_> a little brute-force right now, but that's fine
[11:26] <BBB-[away]> screenshot!!
[11:26] Action: BBB-[away] wants to see what it does
[11:27] <omega_> gstreamer.net/images/autoplugger.png
[11:28] <omega_> not that that's too useful <g>
[11:31] <BBB-[away]> is it? :P
[11:31] <omega_> well, that shot doesn't say too much
[11:31] Action: BBB-[away] cannot imagine him doing video-editing in console :)
[11:31] <omega_> hehehe
[11:32] <omega_> that's what ecasound does for audio....
[11:32] <omega_> console-based editing, like doing brain surgery with just stilts taped to your hands...
[11:37] <BBB-[away]> yes
[11:37] <BBB-[away]> sounds cool, though
[11:38] <omega_> what, brain surgery with stilts?
[11:38] <BBB-[away]> yes
[11:38] <BBB-[away]> or with just a pencil
[11:38] <BBB-[away]> (auch)
[11:38] Action: omega_ tries to add another 3 hours timezone difference just to get as far away from BBB-[away] as possible
[11:40] <BBB-[away]> lol
[11:41] <omega_> bleagh.  I must sleep now
[11:44] <BBB-[away]> go ahead
[11:44] <BBB-[away]> I need to get an SDL window in a Gtk window
[11:44] <BBB-[away]> but it complains about broken pipes
[11:44] <omega_> but I keep getting myself into a situation where if I stop, I'll lose track by tomorrow ;-(
[11:44] <omega_> SDL is not nice
[11:44] <BBB-[away]> SDL is very nice, except for today
[11:45] <BBB-[away]> I used it a few time
[11:45] <BBB-[away]> s
[11:45] <omega_> it doesn't cooperate with anything
[11:45] <BBB-[away]> http://ronald.bitfreak.net/images/blend.png
[11:45] <omega_> it's nice if that's all you're using, else it gets in the way
[11:45] <BBB-[away]> http://ronald.bitfreak.net/images/yuvplay.png
[11:45] <omega_> neat
[11:47] <omega_> ok, I sleep now
[11:47] <omega_> l8r
[11:47] <BBB-[away]> byebye
[11:47] omega_ (omega at omegacs.net) left irc: [x]chat
[12:15] wtay-zZz (wim at cable-195-162-214-58.upc.chello.be) left irc: Read error to wtay-zZz[cable-195-162-214-58.upc.chello.be]: EOF from client
[12:35] _gst_newt_ joined #gstreamer.
[12:40] _gst_newt_ joined #gstreamer.
[12:42] wtay (wim at cable-195-162-214-58.upc.chello.be) joined #gstreamer.
[12:42] #gstreamer: mode change '+o wtay' by ChanServ!s at ChanServ
[12:42] #gstreamer: mode change '-o wtay' by wtay!wim at cable-195-162-214-58.upc.chello.be
[13:32] steveb (steveb at node1ee0c.a2000.nl) joined #gstreamer.
[13:33] Nick change: BBB-[away] -> BBB
[13:33] Action: BBB is back (gone 38:15:25)
[13:39] <wtay> yo
[13:40] <BBB> hey there
[13:41] Action: BBB just found out how stupid SDL is
[13:41] <wtay> BBB: good :)
[13:41] <BBB> not good!!!!
[13:41] <BBB> gstreamer crashes
[13:41] <wtay> oops
[13:41] <BBB> SDL is just stupid :P
[13:41] <BBB> so what am I gonna use now?
[13:41] <wtay> yeah, it assumes control over everythig
[13:41] Action: BBB considers building his own *stable* library :P
[13:42] <BBB> I want a GtkWidget with an SDL image in it
[13:42] <BBB> but the image always positions itself at the topleft of the toplevel window
[13:42] <BBB> and I don't want that
[13:43] <wtay> BBB: you got a handle to the XID then?
[13:43] <BBB> yes
[13:43] <BBB> and the XID is right
[13:43] <BBB> look:
[13:43] <BBB> Window-ID: 1869495635
[13:43] <BBB> Window-ID: 10485764
[13:43] <wtay> so whats the problem then?
[13:43] <BBB> but in both cases, SDL will draw itself at the toplevel GtkWindow, not the XID I give to it
[13:44] Action: BBB makes a screeny
[13:44] <wtay> oh
[13:45] <BBB> http://ronald.bitfreak.net/images/bla.png
[13:45] <wtay> uhm
[13:46] <BBB> yuo see that it doesn't draw inside the widget's Gdkwindow ID but inside the toplevel GtkWindow
[13:46] <BBB> and I don't want that
[13:46] <BBB> :)
[13:46] <wtay> I assume the xid you give to it is in the center...
[13:46] <BBB> well, actually
[13:46] <BBB> button                             button
[13:46] Last message repeated 1 time(s).
[13:46] <BBB> widget                               widget
[13:47] <BBB> that's how it is
[13:47] <BBB> but it doesn't draw inside the widget
[13:47] <BBB> but inside the toplevel window :(
[13:48] <wtay> there must be some code in SDL then to find the toplevel window...
[13:49] <BBB> yes, but I don't want that :)
[13:49] <BBB> I want a "SDL-widget" :P
[13:50] <wtay> well...
[13:50] <wtay> what do you think:
[13:50] Action: BBB will make a Gtk gstreamer widget when gstreamer 0.2.0 is stable
[13:50] <BBB> :P
[13:50] <wtay> when I gst_object_destroy an element in a bin, should it be removed from that bin?
[13:50] <wtay> or is it not allowed?
[13:51] <BBB> I think it should be removed
[13:51] <BBB> that's also how i's done in Gtk
[13:51] <wtay> it is?
[13:51] <wtay> hmm
[13:52] <wtay> oh, yes, that ugly hack they have..
[13:52] <BBB> "ugly hack"
[13:52] <BBB> I suppose gstreamer does it much cleaner?
[13:52] <wtay> the gtkobject assumes that it always is insed a container...
[13:52] <wtay> s/insed/inside
[13:53] <wtay> If i implement it in gstreamer, it'll use weak_refs
[13:53] <BBB> and it is, normally
[13:53] <BBB> in 99% of the cases, you're inside a GtkWindow which is a container
[13:54] <wtay> but gtkwidget has a dependency on container then
[13:54] <BBB> I guess so
[13:55] <wtay> well, actually, element has a dependency on gstbin anyway..
[13:55] <BBB> but that's just how it works :)
[14:15] <steveb> wtay: do you think it is safe to assume that number of frames in a buffer will never exceed gint?
[14:16] <wtay> yes
[14:16] <steveb> guint even
[14:17] <wtay> by convention, yes
[14:22] <BBB> make it a guint32
[14:22] <BBB> :)
[14:23] <BBB> we calculated that a movie should be >32hours to go past gint
[14:26] <steveb> Gamelan theater can last longer that that :)
[14:39] <wtay> steveb: yes, but you can't...
[14:39] <wtay> :)
[15:27] <steveb> is there a function in gstreamer core yet which returns the current nanoseconds timestamp?
[15:27] <wtay> gst_trace_read_tsc used to work...
[15:30] <steveb> and the timestamp should be 0 when a pipeline starts?
[15:30] <wtay> uhm no
[15:30] <wtay> a clock is not implemented yet
[15:30] <steveb> nanos since epoch?
[15:30] <wtay> yup
[15:30] <wtay> since PC start
[15:31] <wtay> s/start/boot
[15:31] <wtay> actually clock ticks
[15:31] <steveb> which is what gst_trace_read_tsc returns?
[15:31] <wtay> using RDTSC
[15:31] <wtay> yup
[15:31] <steveb> clock ticks == nanoseconds?
[15:32] <wtay> you can try to use the currnt gst clock implementation which is more what you want
[15:32] <wtay> plugins/mpeg1/parse uses the clock
[15:33] <steveb> well I don't really need any clock - i just want to attach timestamps to the buffers created in sinesrc.  Once the timestamp is initialised, its updated value is implied by how many samples have been produced
[15:34] <wtay> just calculate the time yourself
[15:34] <steveb> i just wanted to know the right way (for now) to initialise it
[15:42] thomas (thomas at adsl-64019.turboline.skynet.be) joined #gstreamer.
[15:42] <thomas> hi
[15:42] <wtay> hi
[15:42] <thomas> slow day ;)
[15:42] <thomas> too hot ?
[15:43] <wtay> very...
[15:44] <wtay> anyway, I'm making progress on object destruction and refcounting...
[15:44] <thomas> hmmm... I hate housekeeping ;)
[15:44] <thomas> but it's a necessary thing
[15:44] <wtay> yup
[15:44] <thomas> I'm doing the same on the message program
[15:44] <wtay> and incsched is going to stress it a lot
[15:44] <thomas> btw it overlays right this time
[15:44] <wtay> cool
[15:44] <thomas> will it be hard to merge incsched right ?
[15:45] <thomas> I mean, there's been a lot of work on both branches
[15:45] <wtay> i'll be ok
[15:45] <wtay> s/i/it/
[16:15] wtay (wim at cable-195-162-214-58.upc.chello.be) got netsplit.
[16:15] BBB (BBB at ucu-105-116.ucu.uu.nl) got netsplit.
[16:15] ajmitch (ajmitch at p11-max6.dun.ihug.co.nz) got netsplit.
[16:15] thomas (thomas at adsl-64019.turboline.skynet.be) got netsplit.
[16:15] steveb (steveb at node1ee0c.a2000.nl) got netsplit.
[16:16] BBB (BBB at ucu-105-116.ucu.uu.nl) returned to #gstreamer.
[16:16] ajmitch (ajmitch at p11-max6.dun.ihug.co.nz) returned to #gstreamer.
[16:16] wtay (wim at cable-195-162-214-58.upc.chello.be) returned to #gstreamer.
[16:16] steveb (steveb at node1ee0c.a2000.nl) returned to #gstreamer.
[16:16] thomas (thomas at adsl-64019.turboline.skynet.be) returned to #gstreamer.
[16:44] <thomas> wtay: can I ask you to test it again ?
[16:45] <wtay> thomas: sure
[16:45] Action: wtay was away
[16:46] <thomas> it's at urgent.rug.ac.be/thomas/download
[16:48] <wtay> cool
[16:49] <thomas> wtay: no errors ?
[16:49] <wtay> none
[16:49] <thomas> cool ;) then I'll write a simple message daemon for my gbox
[16:49] <wtay> some flashes when moving windows around
[16:49] <thomas> wtay: yeah, I'm not quite sure how that works
[16:49] <wtay> but that's an X issue I think
[16:49] <thomas> I think it creates a default 200x200 window I believe
[16:49] <thomas> when you create a pixmap
[16:49] <thomas> I have to check that
[16:50] <wtay> xeyes has the same behaviour
[16:50] <thomas> ok...
[16:50] <thomas> then I can check for that
[16:50] <thomas> I'd like to know how it looks when overlayed on video
[16:50] <thomas> So i'll try to get xine running on the box...
[16:51] <thomas> btw any experience with TV OUT signals ?
[16:51] <wtay> nope
[16:51] <thomas> I mean configuring X for that
[16:51] <thomas> hm ok...
[16:51] <thomas> trial and error then
[16:51] <wtay> neve done that
[16:51] <thomas> I have graphics on the TV, but right now I'm doing it with the framebuffer device
[16:51] <thomas> it looks a bit slow
[16:51] <wtay> I can imagine...
[17:29] _gst_newt_ joined #gstreamer.
[17:33] hadess (hadess at pc2-guil2-0-cust121.gui.cable.ntl.com) joined #gstreamer.
[17:33] <hadess> hi guys
[17:35] <wtay> hi hadess
[17:35] <hadess> hi wtay
[17:35] <hadess> howdy
[18:01] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[18:02] <hadess> Uraeus: heya buddy
[18:02] <Uraeus> hi hadess
[18:02] <wtay> hi Uraeus
[18:02] <Uraeus> hi wtay
[18:02] <wtay> hmm: Your clock is off by 646.1783716 seconds. (134.58.255.2) [15/15]
[18:03] <Uraeus> my clock?
[18:03] <wtay> mine :)
[18:03] <wtay> trying to get ntpdate working...
[18:03] <Uraeus> heh
[18:04] <Uraeus> hadess: have you heard anything about what will happen with Eazel people, will Darin or Andy for instance continue working on Nautilus
[18:04] <Uraeus> ?
[18:04] <hadess> Uraeus: i thought you would have more infos
[18:16] <Uraeus> not yet, tried mailing Bart but he doesn't reply
[18:16] <hadess> hmmm
[18:17] <hadess> i didn't want to join #nautilus and ask, that'd be rude
[18:18] <Uraeus> heh, I did :) Seth confirmed that they are shutting down, but since none of the other Eazelites where there I didn't ask for more info
[18:18] <hadess> ok
[18:23] <Uraeus> the sailboat is now finaly both on the water, engine is working (kinda) and we are almost finished with polishing it :) now we only need a long summer :)
[18:24] <wtay> Uraeus: cool :)
[18:25] <hadess> ok, you're getting personal there, then i can say that i've got a new girlfriend :P
[18:27] <Uraeus> hadess: congratulations !
[18:27] <wtay> hadess: woohooho
[18:28] <hadess> took me nearly 6 months of hard work and chatting, so i'm happy as well :)
[18:28] <wtay> hadess: a cybergirlfriend?
[18:28] <hadess> thanks guys
[18:28] <hadess> wtay: no, i used to work with her, so maybe the fact that i quit my job actually helped
[18:29] <wtay> hehe
[18:29] <Uraeus> hmm, interesting, maybe an idea for me :)
[18:29] <wtay> gotta eat now...
[18:29] Nick change: wtay -> wtay-food
[18:30] <hadess> Uraeus: heh, she didn't accept any dates when we were working together, and then, the day i quit, i asked her out again, and it worked :)
[18:31] Action: Uraeus puts quiting his current job on his schedule for monday
[18:47] Action: Uraeus is off to his mother to get free dinner (out of food myself until my next salary arrives wednesday :)
[18:47] Nick change: Uraeus -> Ura_away
[20:22] hadess (hadess at pc2-guil2-0-cust121.gui.cable.ntl.com) left irc: mooooh!
[20:43] Nick change: Ura_away -> Uraeis
[20:43] <thomas>  
[20:43] Nick change: Uraeis -> Uraeus
[20:43] <Uraeus>  
[20:52] <Uraeus> hmm, silent here, summer must have hit town elsewher too :)
[21:51] steveb (steveb at node1ee0c.a2000.nl) left irc: [x]chat
[23:05] Nick change: ajmitch -> aj_uni
[23:25] <thomas>  
[23:39] thomas (thomas at adsl-64019.turboline.skynet.be) left irc: Client Exiting
[23:55] Uraeus (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[00:00] --- Mon May 14 2001
[00:32] Nick change: wtay-food -> wtay-zZz
[00:51] Nick change: BBB -> BBB-zZz
[00:51] Action: BBB-zZz is away: zZz
[01:45] walken (foobar at c1583255-a.smateo1.sfba.home.com) joined #gstreamer.
[05:04] Dr_Zaius (jeff at h00a0244bc361.ne.mediaone.net) joined #gstreamer.
[06:01] omega_ (omega at omegacs.net) joined #gstreamer.