[gst-devel] Daily IRC logs

[wim.taymans at chello.be]

[06:50] walken (foobar at c1583255-a.smateo1.sfba.home.com) joined #gstreamer.
[06:50] <taaz> hey walken 
[06:50] <walken> hi david
[06:51] <walken> whats up ?
[06:51] <walken> is linuxvideo.org accessible for you ?
[06:51] <taaz> nope
[06:52] <taaz> don't tell me you were about to do coding today and site went down
[06:53] Action: walken says nothing :)
[06:53] <walken> dont care much
[06:53] <walken> I was gonna work on ac3dec.new
[06:53] <walken> cvs server was a bit fucked up already
[06:53] <walken> (I messed up when I did the initial import)
[06:56] <walken> and you whats you beed doing lately ?
[06:58] Nick change: omega_phone -> omega_
[06:59] <walken> hi
[06:59] <omega_> yo
[07:05] <walken> hmmmm
[07:05] <walken> someone wants to use libmpeg2 in a non-GPL product
[07:06] <omega_> ?
[07:06] <omega_> is libmpeg2 gpl or lgpl?
[07:06] <walken> asks me about equivalent commercial libraries and stuff
[07:06] <walken> GPL
[07:06] <omega_> hmm
[07:06] <walken> I actually know the guy but he's asking for his company
[07:07] <walken> I guess I'm gonna tell him its only OK if he wants to fork off large amounts of cash to the EFF *and* if aaron agrees
[07:07] <omega_> hehe
[07:07] <omega_> what about other authors?
[07:07] <walken> I guess we'd have to ask them too :)
[07:08] <walken> on the purely libmpeg2 x86 side there arent too many of them though
[07:08] steveb (steveb at node1ee02.a2000.nl) joined #gstreamer.
[07:08] <omega_> yo
[07:09] <steveb> yo
[07:13] <steveb> so what do you think should happen to the old parameter get/set functions in plugins after dparams are working? maybe they should be kept for parameters that should only changed in the stopped state
[07:13] <omega_> steveb: hmmm
[07:13] <omega_> I would say that dynamicparams are a special case, not the norm
[07:15] <steveb> so different APIs will update the same variables?
[07:16] <omega_> unlikely
[07:16] <omega_> though... who knows?
[07:16] <omega_> obviously only an idiot would use both mechanism simultaneously
[07:16] <omega_> but I'd like to even find a way to use the get/set setup for dynamicparams
[07:16] <steveb> obviously :)
[07:22] <steveb> should we settle on dynparams (short, descriptive) instead of dparams, dynamicparams...
[07:23] <omega_> or dynparms
[07:24] <taaz> how does this dynamicparam stuff relate to the future event system?
[07:24] <omega_> it doesn't
[07:24] <steveb> seperate
[07:24] <taaz> should it?
[07:24] <omega_> although it could, but I don't see how
[07:25] <steveb> so events are for things like EOS, seek etc?
[07:25] <omega_> yeah
[07:27] <steveb> so if i were to start coding dynparams this weekend, it would be nice if I could commit to HEAD since it is a new API which doesn't clash with anyone elses work
[07:27] <omega_> yeah
[07:28] <steveb> i was going to make sinesrc my test element (plus whatever i do in test/)
[07:28] <omega_> ok
[07:30] Action: omega_ just added bash cmdline completion for ./configure args
[07:31] <steveb> bad omega
[07:38] Action: steveb commutes
[07:38] steveb (steveb at node1ee02.a2000.nl) left irc: [x]chat
[07:46] Action: taaz commutes to my bed
[07:46] <omega_> 'night
[07:46] Nick change: taaz -> taazzzz
[08:04] ajmitch_ (ajmitch at p38-max2.dun.ihug.co.nz) joined #gstreamer.
[08:04] ajmitch (ajmitch at p27-max3.dun.ihug.co.nz) left irc: Ping timeout for ajmitch[p27-max3.dun.ihug.co.nz]
[08:04] Nick change: ajmitch_ -> ajmitch
[08:33] Nick change: ajmitch -> ajmitch_
[08:41] Nick change: ajmitch_ -> ajmitch
[08:46] Nick change: ajmitch -> ajzzzz
[08:46] <walken> pouet pouet
[08:46] <omega_> ?
[08:47] <walken> just looking if you're alive :)
[08:47] <omega_> sorta
[08:47] <walken> whats you doing ?
[08:47] Action: omega_ is sick
[08:47] <walken> ugh :(
[08:47] <omega_> right now I'm working on adding tsc timing support to libcodec
[08:49] Action: walken doing ac3dec work
[08:49] <omega_> fun fun
[08:54] <omega_> ok, some numbers on the idct:
[08:55] <omega_> C version takes ~1453 cycles, mmxext takes ~684
[08:55] <omega_> mmx is ~717
[08:56] <omega_> but there's significant variance over time, i.e. the first 4356 mmx idct's avg 603 cycles each
[09:00] steveb (stevebaker at 212186169160.chello.com) joined #gstreamer.
[09:00] <omega_> yo
[09:00] <steveb> yo
[09:03] <steveb> what is the syscall to get current nanoseconds timestamp?
[09:03] <omega_> there is no standard one in linux afaik
[09:03] <walken> gettimeofday
[09:04] <omega_> you can get the cycle counter with rdtsc (see HEAD:gst/test/lat.c)
[09:04] <omega_> that's in usec
[09:04] <steveb> right
[09:04] <walken> if you do a syscall you dont want nanos :)
[09:04] <omega_> heh
[09:05] <walken> omega. is this libmpeg2 idct ?
[09:05] <walken> I thought we were way better
[09:05] <walken> like around 250 cycles
[09:06] <omega_> yeah
[09:06] <walken> hmmm
[09:06] <walken> weird
[09:06] <omega_> static inline lc_idct_8x8_inplace_S16(int16_t * block) {
[09:06] <omega_>   guint64 start,end;
[09:06] <omega_>   __fppi_lc_idct_8x8_inplace_S16++;
[09:06] <omega_>   lc_rdtscll(start);
[09:06] <omega_>   __fp_lc_idct_8x8_inplace_S16(block);
[09:06] <omega_>   lc_rdtscll(end);
[09:06] <omega_>   __fppc_lc_idct_8x8_inplace_S16 += end - start;
[09:06] <omega_> }
[09:07] <omega_> that's the code that does the timing.  __fp_lc_.... is a function pointer, pointing directly to the implementation
[09:07] <walken> hmmm
[09:07] <walken> I was doing 1000s of idcts in a loop to time it
[09:07] <walken> in place
[09:07] <omega_> right
[09:07] <omega_> this times it in context
[09:07] <walken> of course at the end it was doing idct of idct of idc but :)
[09:07] <omega_> hehehe
[09:08] <walken> oh
[09:08] <walken> so you probably measure the not-in-l1 behaviour
[09:08] <omega_> yeah, whatever the surrounding code causes
[09:10] <walken> ok
[09:10] <walken> seems like a huge huge impact though
[09:10] <omega_> yeah
[09:31] ajzzzz (ajmitch at p38-max2.dun.ihug.co.nz) left irc: Ping timeout for ajzzzz[p38-max2.dun.ihug.co.nz]
[09:57] ajzzzz (ajmitch at p31-max7.dun.ihug.co.nz) joined #gstreamer.
[10:27] Action: omega_ goes to sleep
[10:27] omega_ (omega at omegacs.net) left irc: Z at 1099)
[10:28] Nick change: maYam_busy -> maYam
[11:28] steveb (stevebaker at 212186169160.chello.com) left irc: quit has steveb, yes
[11:45] walken (foobar at c1583255-a.smateo1.sfba.home.com) left irc: ircII EPIC4-1.0.1 -- Are we there yet?
[11:46] matth-waking (matth at qwest.dsplinux.net) left irc: Ping timeout for matth-waking[qwest.dsplinux.net]
[11:46] BBB (BBB at ucu-105-116.ucu.uu.nl) joined #gstreamer.
[11:50] matth-waking (matth at qwest.dsplinux.net) joined #gstreamer.
[12:39] ajzzzz (ajmitch at p31-max7.dun.ihug.co.nz) left irc: Ping timeout for ajzzzz[p31-max7.dun.ihug.co.nz]
[12:40] ajzzzz (ajmitch at p20-max2.dun.ihug.co.nz) joined #gstreamer.
[13:06] <BBB> has someone in gstreamer already worked on the concept of "editing lists"?
[13:37] steveb (stevebaker at 212186169160.chello.com) joined #gstreamer.
[13:45] ajzzzz (ajmitch at p20-max2.dun.ihug.co.nz) left irc: Ping timeout for ajzzzz[p20-max2.dun.ihug.co.nz]
[14:11] ajzzzz (ajmitch at p57-max11.dun.ihug.co.nz) joined #gstreamer.
[15:38] ajzzzz (ajmitch at p57-max11.dun.ihug.co.nz) left irc: Ping timeout for ajzzzz[p57-max11.dun.ihug.co.nz]
[15:42] ajzzzz (ajmitch at p11-max6.dun.ihug.co.nz) joined #gstreamer.
[15:47] thomas_ (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[15:48] Nick change: maYam -> maYam_away
[16:27] Nick change: maYam_away -> maYam
[16:30] steveb (stevebaker at 212186169160.chello.com) left irc: quit has steveb, yes
[17:15] Nick change: wtay-zZZZz -> wtay
[17:15] <wtay> yo
[17:15] <wtay> BBB: editing lists are orthogonal to gstreamer...
[17:25] <maYam> welcome to the weekend, wtay
[17:26] <wtay> maYam: whooohooohooo !
[17:28] Nick change: taazzzz -> taaz
[17:32] <BBB> uh?
[17:32] <BBB> wtay: no, an editing list is part of using gstreamer ;)
[17:33] <wtay> BBB: true
[17:33] <wtay> BBB: I'm planning on creating a library over gst to handle editing lists..
[17:33] <wtay> http://msdn.microsoft.com/library/psdk/directx/dx8_c/ds/des/des_intro.htm
[17:35] <BBB> wtay: that would be cool
[17:35] <BBB> in the best case, I want mjpegtools to start using the same kind of editing lists
[17:35] <wtay> we need a good event system before we can handle that though
[17:35] <wtay> we need an editlist to gstreamer compiler in some way
[17:35] <BBB> our problem is that we can already do it but only with multiple editing lists - and that sucks :|
[17:35] <BBB> wtay: fully agree
[17:36] <BBB> but editlist+gstreamer = NLE
[17:36] <BBB> :)
[17:36] <BBB> it's really that simple
[17:36] <wtay> the idea of the editing services is to create a timeline hierarchy...
[17:36] <wtay> when the timeline needs images, it'll use gstreamer to get them
[17:37] <wtay> so when you tink of the timeline being drawn top to bottom, the gstreamer pipelines are drawn left to right...
[17:38] <BBB> hmm.....
[17:39] <BBB> sounds all vague, still, I'll look @ it tonight
[17:39] <BBB> first, I need food
[17:39] <BBB> :)
[17:39] <BBB> brb (gonna cook dinner)
[17:39] <wtay> yeah, it's not really clear to me either..
[17:57] taaz (dlehn at 66.37.66.32) left irc: Ping timeout for taaz[66.37.66.32]
[17:59] <thomas_> wtay: got the transparency right on that little program
[17:59] <thomas_> added a pixmap as well
[18:00] taaz (dlehn at 66.37.66.32) joined #gstreamer.
[18:00] <wtay> thomas_: cool
[18:00] <wtay> hi folks
[18:03] <BBB> http://ronald.bitfreak.net/images/yuvplay.png
[18:03] <BBB> http://ronald.bitfreak.net/images/blend.png
[18:04] <BBB> that's how we handle that
[18:05] <wtay> neat
[18:05] <BBB> I like it ;)
[18:06] <BBB> you know... I just started thinking.....
[18:06] <BBB> if you make the editlist wrapper for gstreamer
[18:06] <BBB> I just input the editlist
[18:06] <BBB> and I get the pipework back, right?
[18:06] <BBB> then, making a NLE is really easy
[18:07] <wtay> it's a bit too heavy for a plugin IMO
[18:07] <wtay> what about caching etc?
[18:08] <wtay> you'll need a tree of plugable timelines etc..
[18:09] <BBB> yes, but isn't that the whole job of a NLE (GUI in general)?
[18:09] <BBB> and I think you could make the wrapper a plugin
[18:09] <BBB> we made our editlist/pipelist wrappers plugins fo mjpegtools as well
[18:10] <wtay> I'm not sure about that yet..
[18:10] <wtay> you'll need dynamic pluging, which is an app issue IMO
[18:10] <wtay> and a timeline scheduler
[18:12] <BBB> the scheduler should be easily implementable in gstreamer itself
[18:12] <BBB> that isn't for the NLE, imho
[18:12] <BBB> dynamic plugging, you probably mean to switch effects (nodes?) and scenes (input) dynamically? That's clearly an app issue
[18:13] <BBB> and an app can do that if it's not too badly written
[18:13] <BBB> that's not difficult, though, really
[18:13] <BBB> I already did that part for the mjpegtools
[18:13] <BBB> :)
[18:13] <BBB> how else do you think I made these images I just showed you
[18:13] <BBB> ?
[18:13] <BBB> :P
[18:14] <wtay> I mean, who is going to handle the pluging and dynimic connections etc?.. the timeline scheduler
[18:14] <wtay> like:
[18:14] <wtay> at time X start pipeline Y seek to Y run for Z into plugin Q
[18:14] <BBB> the timelinescheduler... hmm.....
[18:14] <BBB> then, the app should have it's own timelinescheduler, you mean?
[18:14] <BBB> hmm.....
[18:14] <BBB> difficult
[18:15] <wtay> your editlist is linear, there is no reuse in timeline pieces
[18:15] <wtay> BBB: indeed
[18:15] <BBB> editlists are, pipelists (our editlist v.2) aren't linear
[18:16] <BBB> at least, they're not supposed to be :)
[18:16] Action: BBB needs to look into XML
[18:16] <wtay> ok
[18:17] <wtay> we need objects to model the hierarchy
[18:17] <wtay> much like a gstreamer upside down...
[18:20] <BBB> I once made a proposal for such an object hierarchy in mjpegtools
[18:20] <BBB> but that wasn't very good
[18:20] <BBB> had some problems
[18:20] <BBB> I actually didn't like it...
[18:20] <wtay> like?
[18:21] <BBB> well, it was an object system of input movies, samples (scenes) out of each input movie, objects of results after transformatrions/effects, etc.
[18:21] <wtay> when seeking is done, I'll try to prototype something
[18:21] <BBB> but it was very difficult to use to, for example, input a new movie at an arbitrary position
[18:21] <wtay> gstes_add_timeline?
[18:22] <BBB> I can send you the e-mail containing the objects (structs) that I wanted to make
[18:22] <wtay> sure
[18:22] <BBB> es?
[18:22] <wtay> editing services?
[18:22] <BBB> ok
[18:22] <BBB> what's your emailaddy?
[18:22] <wtay> or _add_track etc..
[18:22] <wtay> wim.taymans at chello.be
[18:23] <wtay> I don't like the MS concept of audio/video, I think they are all media tracks
[18:23] <BBB> well.....
[18:23] <BBB> we take them together
[18:23] <BBB> so audio+video  = same object
[18:24] <wtay> audio/video is a sink/gui issue
[18:24] <BBB> but you can of course think of an additional soundtrack (backgroundmusic)
[18:24] <BBB> :)
[18:24] <wtay> just like an additional video overlay
[18:24] <BBB> but that is probably not what you mean
[18:24] <wtay> I don't even care if it's a 3D object...
[18:24] <BBB> btw, what exactly does gstreamer use to put the image/video on the screen? SDL?
[18:25] <BBB> or it's own library?
[18:26] <wtay> num_frames? for audio?
[18:26] <wtay> plain X and Xv images
[18:27] <BBB> hmm..... ok
[18:27] <BBB> and num_frames is for video
[18:27] <BBB> this was only for video
[18:27] <BBB> we never looked at audio
[18:28] <wtay> ok
[18:28] <wtay> I think it should be more general
[18:29] <wtay> and timestamped only
[18:29] <BBB> but basically, you could think of audio and video as the same thing as long as gstreamer itself can handle that
[18:29] <BBB> I think it should be timestamped too...
[18:29] <BBB> without timestamping, it's just too ununderstandable
[18:30] <wtay> I think of it as a scheduler that would start/stop/seek gst pipelines at certain timestamps and connect them with plugins, this all being dynamic over time
[18:32] <wtay> we need tracks with multiple gst pipelines in it (no effects between them, just playback)
[18:32] <wtay> then those tracks go into a composition (with effects between tracks)
[18:32] <wtay> compositions can go into compositions and that's it
[18:33] <wtay> compositions and tracks are out two objects
[18:33] <wtay> s/out/our
[18:33] <BBB> track = what I called input sequence
[18:33] <wtay> ok
[18:33] <BBB> composition = what I called result
[18:33] <BBB> right?
[18:33] <BBB> i my e-mail to gst-dev
[18:33] <BBB> si/in
[18:33] <BBB> grmbl
[18:34] <BBB> s/i/in
[18:34] <BBB> and what if one movie is in multiple sequences?
[18:35] <BBB> for example, I would think of a sequence as a 'scene'
[18:35] <BBB> and one movie usually has many many scenes
[18:35] <BBB> can gstreamer open one single movie multiple times?
[18:35] steveb (steveb at node1ee02.a2000.nl) joined #gstreamer.
[18:35] <BBB> (mjpegtools has protection not to - I guess with a reason)
[18:35] <wtay> sure
[18:35] <BBB> hmm.....
[18:35] <BBB> then the whole 'input' object can be omitted
[18:35] <wtay> yes
[18:36] <wtay> only tracks and compositions IMO
[18:36] <BBB> and then, you create a list of compositions which is what you see on the screen.....
[18:36] <BBB> ok
[18:36] <wtay> tracks = image source, compo = effects between them
[18:36] <BBB> yup
[18:36] <wtay> tracks == media source to be correct
[18:36] Action: BBB hecks out latest gstreamer CVS release
[18:37] <BBB> should I take a tagged release or just the main trunk?
[18:38] <wtay> depends on what you want :)
[18:38] <BBB> just, try it out :)
[18:38] <wtay> HEAD is most functional
[18:38] <BBB> see if the new scheduler omega finished some time ago works
[18:38] <wtay> INCSCHED is the future
[18:38] <BBB> HEAD = main trunk?
[18:39] <wtay> yup
[18:39] <wtay> brb
[18:39] <BBB> hmm....
[18:39] <BBB> ok
[18:40] thomas_ (thomas at 212-100-172-175.adsl.easynet.be) left irc: [x]chat
[18:43] <BBB> ./autogen.sh: line 60: 23039 Killed                  automake --add-missing
[18:43] <BBB> :?
[18:44] <BBB> [rbultje at tux gstreamer]$ automake
[18:44] <BBB> Killed
[18:44] <BBB> [rbultje at tux gstreamer]$ 
[18:44] <BBB> ???
[18:45] <steveb> BBB: you might have run out of memory
[18:45] <BBB> hm
[18:45] <BBB> brb
[18:45] <BBB> yup
[18:45] <BBB> I have
[18:45] <BBB> swap = full
[18:45] <BBB> gotta restart X
[18:45] <steveb> you need the automake patch that richard wrote to fix that
[18:45] BBB (BBB at ucu-105-116.ucu.uu.nl) left irc: Read error to BBB[ucu-105-116.ucu.uu.nl]: EOF from client
[18:47] BBB (BBB at ucu-105-116.ucu.uu.nl) joined #gstreamer.
[18:47] <steveb> you need the automake patch that richard wrote to fix that
[18:47] <BBB> oh - so I didn't need to restart X....:)
[18:47] <BBB> hm
[18:47] <BBB> where do I find the patch?
[18:47] <steveb> automake eats all your memory without it
[18:48] <BBB> yup, I noticed
[18:48] <steveb> richardb posted it to the list
[18:48] <BBB> hmm.... when?
[18:48] Action: BBB gets 500 emails a day - hard to keep track
[18:48] <steveb> 2-3 weeks ago
[18:50] ChiefHighwater (paul at temple-baptist.com) joined #gstreamer.
[18:50] <BBB> hmm..... I don't think I have it
[18:51] <BBB> the last e-mail I didn't delete is from 1-5, so 10 days ago
[18:54] <steveb> DCCing it to you
[18:56] <BBB> should I apply it to Makefile.am?
[18:57] <steveb> no, your automake script in /usr
[18:57] <BBB> oh, ok
[19:00] <BBB> trying out now.....
[19:03] <BBB> I guess it works :)
[20:09] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[20:09] <Uraeus> hi
[20:15] <wtay> hi
[20:24] omega_ (omega at omegacs.net) joined #gstreamer.
[20:25] <wtay> hello
[20:25] <omega_> yo
[20:40] <BBB> is gstmediaplay still supposed to work?
[20:42] <wtay> noy in INCSCHED, that's what I'm trying to fix now
[20:43] <BBB> I'm crashing it all the time :)
[20:45] <wtay> yeah, me too
[20:46] <BBB> lol
[20:48] <omega_> proof that /me isn't fully awake:
[20:48] <omega_> terminal 1: cd gst.incsched1;cvs update -dP
[20:48] <omega_> terminal 2: cd gst.incsched1;cvs update -dP
[20:49] <BBB> hmm.....
[20:49] <wtay> hehehehe
[20:49] <BBB> thisnis like when I downloaded in two terminals at the same time (console-ftp)
[20:49] <wtay> and what happens then?
[20:49] Nick change: omega_ -> omega_breakfast
[20:49] <BBB> I was downloading the same file in both terminals over and over agauin :P
[20:49] <BBB> then they both don't work
[20:49] <omega_breakfast> the first wedged on a lock for a minute, the other bailed
[20:51] Nick change: ChiefHighwater -> CHW-away
[21:05] <omega_breakfast> wtay: I'm gonna write up a bit on the autoplugger meta-element, then I'll need some comments
[21:05] <wtay> ok, I'm now trying to get autoplug working
[21:05] <omega_breakfast> cool
[21:07] Nick change: omega_breakfast -> omega
[21:08] <steveb> omega: care to contribute to the dynparams thread on the list?
[21:08] <omega> yeah, I will in a little while
[21:08] <steveb> ok
[21:15] hadess (hadess at pc2-guil2-0-cust121.gui.cable.ntl.com) joined #gstreamer.
[21:15] <wtay> yo
[21:16] <hadess> heya wtay
[21:16] <taaz> heh... omega: did you ever respond to my event idea post? ;)
[21:17] <hadess> i'm looking for a new job guys
[21:18] <wtay> hadess: good
[21:18] <taaz> hadess: i'll pay you to do my laundry.  interested?
[21:18] <hadess> taaz: not really
[21:18] <hadess> i finished with the old one today
[21:22] <BBB> hadess: do my exams and I'll buy you an ice-cream
[21:22] <BBB> :P
[21:24] <omega> hadess: any leads?
[21:24] <hadess> omega: there are some linux admin jobs in london, might go for that
[21:25] <hadess> i'm gonna apply for suse, mandrake, redhat and va as well, they're all in the area
[21:26] <wtay> cool
[21:26] <wtay> omega: autoplug.c checked in
[21:26] <wtay> omega: works for mp3/ogg/mpeg1 video
[21:26] <wtay> omega: fails for system streams and mpeg2
[21:27] Action: wtay waits for that guy that claims to have registered the "omega" nick...
[21:27] <omega> any other stuff I need to rebuild, or just autoplug?
[21:27] <wtay> just autoplug
[21:28] <omega> erm, undefined reference to 'gst_object_unref'
[21:28] <omega> you were saying?
[21:28] <wtay> oh, yeah
[21:28] <wtay> sorry... I though you allready built that :)
[21:28] <omega> just autoplug (and libgst.la)
[21:29] <wtay> yup
[21:30] <wtay> it looks like it always fails when more than one thread is used...
[21:30] <omega> hrm
[21:31] <omega> did you rev it to use autoplugcache?
[21:31] <omega> ** CRITICAL **: file gstdisksrc.c: line 222 (gst_disksrc_get): assertion `GST_FLAG_IS_SET (src,GST_DISKSRC_OPEN)' failed.
[21:31] <omega> playing a vorbis
[21:32] <omega> erm
[21:32] <wtay> yeah
[21:32] Action: omega rebuilds all of gstreamer because GstElement grew
[21:32] <omega> just autoplug (and libgst.la, oh, and all the plugins too)
[21:33] <wtay> err, yeah and build the docs too, to be sure <g>
[21:33] <omega> that's what `cd gst.incsched1;make` does....
[21:33] <taaz> is it worth debugging why lat.c with queues fails randomly on a smp system?  or should i just wait for incsched?
[21:37] <omega> wait for incsched, we know HEAD interlock is broken
[21:38] <taaz> ok
[21:40] <taaz> steveb: you there?
[21:41] <steveb> ja
[21:41] <taaz> just been thinking about dynamic params stuff
[21:42] <steveb> and?
[21:42] <taaz> hmm... i'm not sure i understand how it solves some problems
[21:42] <taaz> mainly real time control issues
[21:43] <omega> I was gonna post this on the list, but imo real-time won't use dynparms
[21:43] <omega> at least, real-time *live*
[21:43] hadess (hadess at pc2-guil2-0-cust121.gui.cable.ntl.com) left irc: stuff
[21:43] <omega> I mention it in the wiki, at least
[21:43] <steveb> i think it could be designed to
[21:44] <omega> what advantage does dynparms give to a live situation?
[21:44] <taaz> yeah, i mean adjusting equalizer sliders in real time sort of stuff
[21:44] <omega> by the time the next change in the knob happens, you're already too late to change it "at the right time", so you just change it as soon as you can
[21:44] <steveb> you can write an interpolator which prevents discontinuities by people moving sliders too fast
[21:45] <omega> but that can be handled other ways
[21:45] <steveb> so the rate of change is sane - if that is what you want
[21:45] <omega> I don't think dynparms is the solution to this particular problem
[21:45] <omega> dynparms imo is best suited for non-live (realtime or no) "offline" rendering
[21:46] <taaz> in the wiki disadvantages section of pads for control you imply you could have a chained element... but multi input elements have to be looped right?
[21:46] <omega> taaz: not necessarily, but for sanity yes
[21:47] <omega> if you want to implement a state machine and handle the potential buffering requirements internally, you can make it chained
[21:48] <omega> but if you end up getting stuck into a loopfunc anyway, woe be unto you if you have an asymmetric buffer sequence requirement, cause the wrapper is 1:1:1:...
[21:49] Nick change: CHW-away -> ChiefHighwater
[21:50] <taaz> i started to come up with some solutions to unify events, control, and data processing... but they all involve lots of cothreads.  which will not work with this 64 cothread limit. :(
[21:51] <omega> why lots of cothreads?
[21:51] <omega> write it up anyway, if could be relevant regardless
[21:52] <steveb> i can see that dynparams doesn't help a lot in RT, but i don't see what problems it causes
[21:52] <taaz> its probably based on that stuff i wrote in the event post to the list way back
[21:52] <omega> steveb: extra latency in getting the change actually made
[21:52] <omega> remember, the instant the change is made, you're already late in actuating it
[21:52] <omega> taaz: if it takes dynparms into account, it's new ;-)
[21:53] <taaz> is it worth trying to solve the issue of sample accurate events?
[21:53] <omega> steveb: imo, a single variable that's actuated directly, on buffer boundaries, is plenty sufficient for a live situation, because a) buffers will be small, and b) overhead is baaaad
[21:53] <omega> taaz: for offline stuff, yeah
[21:53] <taaz> its hard to do if that sample is in the middle of a buffer
[21:53] <steveb> but in the live case no other framework claims to update it any quicker than the buffer rate
[21:54] <omega> steveb: correction: no other framework claims to do the live case at all
[21:54] <steveb> omega: i am sure dynparams could be optimised to do just that in the RT case
[21:55] <omega> but I'm claiming that dynparms doesn't gain us anything anyway, given human perception of the one-off live output
[21:55] <taaz> so what do other frameworks use for control data?  like VST and other pro commercial tools?
[21:55] <steveb> except a uniform elements API for live and non-live cases
[21:55] <omega> when you're talking about 64 samples @ 48khz, no human can detect stairstepping at that rate unless they listen many times and know what they're listening for, esp in a reverb-happy auditorium
[21:56] <omega> steveb: ok, that's a good goal, but then dynparms has to be very very very low overhead in the simple case
[21:56] <steveb> omega: i accept your challenge :)
[21:56] <omega> steveb: good ;-)
[21:57] <steveb> stairstepping at its extreme would sound like loud clicks and pops - yuck
[21:57] <omega> yes, but also remember that any controller software for this will deal with max-delta itself
[21:58] <omega> and best case you'll actually have a physical knob enforcing max-delta
[21:58] <steveb> ah, ok. I was trying to solve that too
[21:59] <omega> controller code can solve that particular problem much more cheaply, but yeah, I can see cases where it might want to use dynparms for a moment to smooth out a quick transition
[21:59] <omega> or it could just use a customized gain element that does the ramping itself, but that's starting to push things too far ;-)
[21:59] <steveb> yeah
[22:01] <steveb> how about the pads vs new API issue?
[22:01] <omega> wtay: bleck, vorbis spews neat cothread warnings: same-switch, NULL-switch
[22:02] <omega> hmmmm
[22:02] <wtay> omega: hmm, ot here
[22:02] <wtay> s/ot/not
[22:04] Nick change: maYam -> maYam_OmenII
[22:04] <wtay> maYam_OmenII: boo!
[22:06] <maYam_OmenII> wtay, you better don't come into the living room or you'll have nightmares again
[22:06] <maYam_OmenII> like when you saw that movie with the Volkswagen
[22:06] <wtay> maYam_OmenII: something could happen this night... when you're asleep...
[22:07] <maYam_OmenII> ..when i'm asleep and you're in panic you mean..
[22:07] <maYam_OmenII> :p
[22:07] <wtay> maYam_OmenII: :(
[22:09] <omega> http://www.suck.com/daily/2001/05/11/e.gif
[22:09] <wtay> heh
[22:09] <steveb> now there is some motivation
[22:09] Action: wtay is adding a new gstinfo category
[22:11] Action: wtay is having trouble finding good colors
[22:11] <omega> does /me smell another contest?
[22:11] Action: omega has an idea: DEBUG themes!
[22:12] <wtay> oh no!
[22:12] <omega> since it's just a table of strings, it's rewritable at run time, so you just load a new theme in <g>
[22:12] <steveb> anyone tested these colours on a white background? not good
[22:12] <omega> steveb: good point
[22:12] <steveb> but then again, who cares!
[22:12] <omega> so themes really aren't just a stupid idea
[22:17] <steveb> with dynparams i think i need a better name than 'interpolator' - basically it is an object which returns a value for a given timestamp
[22:18] <steveb> but there are so many versions of this behaviour i don't think interpolator does it justice - how about iterator? time_iterator?
[22:19] <omega> doesn't sound right
[22:19] <omega> interpolator is the best I can think of, since that's what it does
[22:21] <steveb> except when it doesn't
[22:22] <omega> well, it just depends on how often/when you sample <g>
[22:22] <steveb> i'll stick with interpolator
[22:26] <omega> wtay: how mature is the audio end of mpeg1 encoding?
[22:26] <wtay> omega: non thread safe
[22:26] <omega> if I can get dvdec to output audio, can a program be built that can easily transcode DV to mpeg1 A/V ?
[22:26] <wtay> omega: sorta works
[22:26] <wtay> yes
[22:26] <wtay> very easy
[22:27] <wtay> no automatic muxer 'cause the multiplexer is broken
[22:27] <omega> ChiefHighwater would like to get ~5min of DV transcoded to mpeg1 in short order after capture
[22:27] <omega> Sunday morning
[22:27] <omega> if it can't be done that soon, it can wait, but it'd be cool if it can be done 'immediately'
[22:28] <wtay> ok, can be done, I have mpeg2 to mpeg1 A/V already to start from
[22:28] <omega> cool
[22:28] <omega> ok, I'll see if I can get dvdec to do audio sometime today
[22:29] <ChiefHighwater> 8-]
[22:31] <omega> from l-a-d:
[22:31] <omega> Average time for a context switch:
[22:31] <omega> 2755ns = 2.755us
[22:31] <omega> on a K6 333
[22:31] <wtay> uh
[22:32] <omega> for a PIII 800 it's 0.715us
[22:32] Nick change: ajzzzz -> ajmitch
[22:33] <wtay> is that good or bad?
[22:34] <ChiefHighwater> sounds good to me 8-] (if that means anything)
[22:37] <omega> um, neither
[22:37] <omega> that's just 'measured' latency for a thread->thread switch on various machines, as done by someone on l-a-d
[22:37] <steveb> what would the cothread equivalent be?
[22:38] <omega> less time
[22:38] <omega> <g>
[22:38] <steveb> obviously
[22:38] <omega> sec...
[22:39] <omega> I'm measuring *total* latency of .992usec with gstreamer including *2* cothread switches
[22:40] <omega> that includes buffer passing, a couple indirect function calls each way, etc.
[22:40] <omega> on a PIII/500
[22:41] <omega> btw, the l-a-d numbers are ~ in line with the numbers from lmbench posted recently on /.
[22:43] <omega> ns 4.77 sucks
[22:44] Action: omega backrevs to 4.76
[22:44] Action: wtay is a happy galeon user
[22:46] Action: steveb likes moz
[22:47] <omega> let's hope 4.75 doesn't crash randomly like 4.77 does
[22:47] Action: omega never had significant trouble before rh7.0 update had 4.77
[22:47] Action: omega should get moz 0.9
[22:48] <wtay> yes
[22:48] <steveb> 'night
[22:48] <wtay> cya
[22:49] steveb (steveb at node1ee02.a2000.nl) left irc: [x]chat
[22:50] Action: omega gets moz 0.9
[22:52] <ajmitch> morning...
[22:52] <ajmitch> moz 0.9 is good
[22:52] <ajmitch> haven't used ns 4.x for 6 months or so
[22:54] Action: omega installs moz 0.9
[22:54] Action: ajmitch uses mozilla to get a nz passport application form...
[22:54] <taaz> omega: just apt-get it ;)
[22:55] <ajmitch> taaz: too complicated ;)
[22:55] <omega> run, moz, run!  see moz run!
[22:55] <taaz> well.. you do have to add alternate apt source... not in main archives
[22:55] <wtay> once you get the hang of gecko, you'll never look back at that horrible beast called netscape
[22:55] <ajmitch> taaz: yeah, quite a challenge that
[22:56] <ajmitch> wtay: using galeon debs or cvs?
[22:56] <wtay> galeoncvs
[22:56] <wtay> apt
[22:56] <taaz> so does moz still crash all the time?  i try it every few weeks and crash it within 10 mins... :(
[22:56] <wtay> debs
[22:56] <wtay> taaz: rock solid here
[22:56] <ajmitch> taaz: i usually have it running for a week or so at a time
[22:56] <wtay> taaz: galeon, that is...
[22:56] <taaz> does moz do java and https?
[22:57] <wtay> yes
[22:57] <ajmitch> yup (well, should do)
[22:57] <taaz> and flash?
[22:57] <wtay> yes
[22:57] <ajmitch> java isn't quite working here
[22:57] Action: ajmitch kicks moz
[22:57] Action: taaz shall try moz latter
[22:57] <taaz> later too
[22:57] <wtay> java support isn't perfect yet (no liveconnect and signed applets crash it)
[22:58] <omega> neat.  reduce the font size <5% and it renders at 100%
[22:59] <wtay> who needs java, anyway..
[22:59] <ajmitch> wtay: i want it for web-based banking ;)
[22:59] <wtay> ajmitch: me too actually, but that's all it's use for me
[22:59] <omega> web-based banking with java? ick
[23:00] <wtay> omega: what else? digipass?
[23:00] <ajmitch> wtay: only prob is that moz isn't loading the java plugin here ;)
[23:00] <omega> ssl http html
[23:00] <wtay> omega: plain passwords over https?
[23:01] <omega> how's that more/less secure than java via ssl?
[23:01] <wtay> omega: we just use the java to calculate a digital signature...
[23:01] <wtay> RSA based, is more secure than passwords
[23:03] <omega> ick, I want to change Ctrl-Shift-L back to Ctrl-L
[23:03] <wtay> omega: yeah, you'll need to get used to it...
[23:04] <omega> ctrl-L doesn't do anything new, why'd they change it??
[23:05] <taaz> and more importantly... why isnt the keymap->function mapping configurable?
[23:05] <omega> right.
[23:05] <omega> another thing: moz annoys me for the same reason KDE does: they went with their own object system
[23:08] <ajmitch> a project for the weekend - replace moz's component system with bonobo ;)
[23:08] <omega> they could have at least used corba underneath
[23:09] <ajmitch> yeah
[23:09] <wtay> yeah, I'm still waiting for gtkheml2
[23:09] <wtay> s/gtkheml2/gtkhtml2
[23:09] <ajmitch> btw, what are the plans for pipelines that go over the network in gstreamer?
[23:09] <ajmitch> planning to use corba?
[23:10] <wtay> hmm, no
[23:10] <wtay> it's an app issue
[23:10] <ajmitch> ok
[23:12] <wtay> omega: I'm interested in doing java bindings for gstreamer...
[23:12] Action: omega wonders what wtay put in his last cigarette
[23:12] <ajmitch> wtay: java? heh, i am forced to learn that next semester
[23:13] <wtay> omega: I'm a java programmer at work, remember? <g>
[23:13] Action: omega wonders what wtay's been putting in his last 10^N cigarettes
[23:13] <ChiefHighwater> do you REALLY want to know?
[23:14] <wtay> finest American blend :-)
[23:15] <wtay> http://www.ridgerun.com/products/chartJava.gif
[23:15] <wtay> hmmm
[23:15] <omega> erm, ok
[23:15] <wtay> hehehe
[23:16] <omega> maybe you can get rr to pay you consulting fees to do it ;-)
[23:16] <ajmitch> hehe
[23:16] <wtay> I'll give them my account number :)
[23:16] Action: omega should know this chart, he has several copies with him
[23:17] <ajmitch> wtay: what made you want to work as a java programmer? ;)
[23:17] Action: wtay thinks omega should know about how gstreamer is going to be used :-)
[23:17] <omega> dynamic autoplugging carries with it some issues regarding capsnego that are going to be intersting
[23:17] <wtay> ajmitch: bad luck
[23:18] <wtay> ajmitch: as if I want to work...
[23:18] Nick change: BBB -> BBB-[away]
[23:18] Action: BBB-[away] is away: zzz
[23:27] <omega> wtay: so, some questions about capsnego
[23:28] <omega> if I have two pads, one has accurate caps, the other has no caps
[23:28] <omega> what happens?
[23:30] <wtay> during connection, caps nego will happen
[23:30] <wtay> if the caps is compatible with the other pads template, the other pad will get the same caps
[23:30] <wtay> if the other pad has a negotiate function, that one will be called instead
[23:31] <ChiefHighwater> what in the world does RealPlayer think it is accomplishing by not allowing me to save files from within their player?
[23:31] <omega> copy controls
[23:31] <wtay> ChiefHighwater: simple: copy control
[23:31] <ChiefHighwater> so I go to Windows\temp and copy it myself
[23:31] <wtay> yup :)
[23:32] <ChiefHighwater> how dumb do they think I am? (don't answer that) 8-]
[23:32] <omega> ChiefHighwater: only if it's downloaded
[23:32] <omega> if it's a pnm: url, it's only streamed
[23:32] <wtay> hmm, they do keep a copy around on disk too I think
[23:33] <ChiefHighwater> this is a promo of the new Zoo attraction...4M to dl, then to open it an 8M install to upgrade my player, which closes my browser and I have to go DL the video again
[23:33] <ChiefHighwater> stupid
[23:33] <ChiefHighwater> yes, there is always a copy somewhere, just have to find it
[23:34] <omega> wtay: not that I know of
[23:35] <omega> wtay: so what happens if the source pad has just a padtemplate, the sink pad has nothing?
[23:35] <ChiefHighwater> I don't dl that much video, but whenever I have, I can always find it stashed on my harddrive (so long as I don't close the player)
[23:35] <wtay> omega: nothing
[23:35] <wtay> omega: the src pad has to set the caps at some point
[23:35] <omega> ok
[23:36] <omega> ok, so then the question is:
[23:36] <wtay> omega: or the sink pad (which start nego too)
[23:36] <omega> if you have an autoplugger connected to something with just a padtemplate...
[23:36] <omega> how does the autoplugger then decide what to autoplug?
[23:36] <omega> should it wait for the caps to settle, or try to construct a pipeline based on the padtemplates?
[23:37] <wtay> hmm
[23:37] <wtay> I think it should wait for the caps
[23:37] <omega> and do we have any guarantees that data can't flow through pads that don't have valid caps set?
[23:37] <wtay> it's forbidden
[23:37] <omega> how?
[23:38] <wtay> by convention :)
[23:38] <omega> erm
[23:38] <omega> ok, then we need to start a wiki page where we add things that need to be tested to validate an element
[23:38] <omega> GstElementValidation
[23:39] <wtay> ideally, flow can only happen on a pad that has caps compatible with its template
[23:39] <omega> no idea where I'm gonna attach it
[23:39] <wtay> how can you validate runtime dehaviour like this?
[23:39] <wtay> s/dehaviour/behaviour
[23:41] <omega> that's a hard problem, but we can at least autoplug on the pads and see if they behave
[23:41] <omega> ok, page exists
[23:44] <wtay> you'll need to select the next element as soon as the caps are set..
[23:44] <omega> right
[23:45] <omega> btw, I moved the connected callback and schedule_pad_connect() to *after* the nego
[23:45] <wtay> you choose the element based on the templates and try to _connect it, it'll fail if capsnego fails and you can select another element then
[23:45] <omega> ok, lemme just outline the scenarios then and get this mail posted
[23:46] <omega> then we can decide the best way to do it
[23:46] <wtay> ok
[23:53] <Uraeus> evening people
[23:53] <wtay> hello
[23:53] <ajmitch> morning
[23:54] <Uraeus> why are people (especially wtay and omega) not participating in the dynamic parameters debate?
[23:55] <ajmitch> i'm not participating cos i don't know enough
[23:55] <wtay> I don't understand the problem...
[23:55] Action: Uraeus has blisters in his hands after spending the day trying to pull the boat into deeper water
[23:55] <ajmitch> ah, still trying to get the boat out? ;)
[23:56] <Uraeus> yup
[23:57] <Uraeus> the tide is getting higher and will be even higher tommorow unfortunatly I am not sure it will be enough
[23:58] <ajmitch> use big balloons ;)
[23:58] <omega> or in the case of the harbormaster, use big baffoons
[23:59] <ajmitch> hehe
[23:59] <Uraeus> hehe, well that harbourmaster asshole did suggest that we should try lifting the boat higher using truck tires; like we have a lot of them laying around
[00:00] --- Sat May 12 2001
[00:00] <omega> waitasec.  he put the thing there with his crane.  why can't he get it out of there with the same crane??
[00:00] <ajmitch> the harbourmaster is still able to walk? hasn't had an unfortunate accident?
[00:00] <Uraeus> omega: he can, but he can't put in anywhere else expect on land
[00:00] <Uraeus> s/expect/except/
[00:00] <omega> or raise it so you can put tires under it
[00:01] <omega> under/around
[00:01] <Uraeus> yes, he can do that, but we don't really have any tires
[00:01] <ChiefHighwater> proly cant raise it high enought to free the keel w/o toppling it
[00:01] <omega> erm, if he put it there, he should provide the tires....
[00:01] <ajmitch> so why does this fool still have a job? ;)
[00:01] <Uraeus> well he owns the place :)
[00:02] <ajmitch> oh...
[00:02] <ChiefHighwater> i suppose his dock is kinda tied up with your boat stuck under his crane
[00:02] <wtay> omega: pad.caround line 580, it should check for realsrc->sched != NULL... and what about removing the scheduler for the other pad?
[00:03] <Uraeus> ChiefHighwater: unfortunatly no, he manages to put the lighter boats on the water with a mobile crane instead :(
[00:03] <wtay> omega: like in the connect case..
[00:04] <omega> wtay: HEAD?
[00:04] <ChiefHighwater> Uraeus:rats..would be nie to know he was losing business for being an idiot
[00:04] <wtay> INCSCHED
[00:04] <omega> line 580 is a comment in my copy
[00:04] <omega> what context?
[00:04] <wtay> omega: yeah, look around it, in the disconnect function when you remove the scheduler
[00:04] <Uraeus> ChiefHighwater: hmm, that was  not a very christian viewpoint :)
[00:04] <ajmitch> lol
[00:04] <ChiefHighwater> Uraeus: tell him t put his crane on a barge and haul you out to depth
[00:06] <omega> wtay: good point
[00:06] <wtay> omega: thank my testsuite.. <g>
[00:06] Action: omega wonders if taaz heard that <g>
[00:09] Nick change: ajmitch -> ajbusy
[00:11] <wtay> omega: is that supposed to be an "else", connected pads cannot both have a scheduler at the same time?
[00:11] <omega> huh?
[00:12] <wtay> look in the _connect function..
[00:12] <wtay>  GST_SCHEDULE_PAD_CONNECT
[00:14] <omega> hrm, that's fuzzy
[00:14] <omega> strictly speaking, if the pads have different schedulers, then neither needs to know
[00:14] <omega> but the idea is that if they are *going* to have the same sched, then we might as well let the sinkpad's scheduler know right away, just in case
[00:15] Action: taaz high-fives wtay for working on a testsuite!
[00:17] <wtay> well, I wanted to do refcount/destroy testing but then I decided to do complete module testing..
[00:17] Action: Uraeus is restaring X to test Nautilus 1.0.3
[00:17] Uraeus (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[00:19] <taaz> omega: read the last book posted to lad?  i didn't read it all but looks like pieces of gstreamerism in there
[00:19] <omega> started scanning it, will read it later today
[00:19] Action: wtay runs aof-slay to test nautilus 1.0.3
[00:20] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[00:20] <Uraeus> wow, this was a real nice improvement :)
[00:21] <omega> what, having to restart X to test nautilus?
[00:21] <wtay> Uraeus: next time jst run oaf-slay
[00:21] <Uraeus> wtay: ok, thanks
[00:21] <omega> oaf-kill-maim-destroy
[00:23] <Uraeus> the speed increase is definetly feelable
[00:23] <Uraeus> and the news view is cool
[00:23] <Uraeus> all we need now is a gstreamer component for nautilus :)
[00:24] <wtay> yeah, the news view rocks!
[00:24] <omega> what happened to those people working on that?
[00:25] <omega> #31, 2nd reference should be 13:12, not 13:!2
[00:25] <omega> #23, 1st, 4:10 not 4:!0
[00:26] <omega> doh, wrong window....
[00:26] Action: omega hates this xchat bug it's confusing
[00:38] NumbNutz (u1567830 at pc-62-31-193-51-du.blueyonder.co.uk) joined #gstreamer.
[00:38] <omega> yo
[00:38] <Uraeus> hi
[00:38] <NumbNutz> howdy
[00:38] Nick change: NumbNutz -> Fatal_2
[00:39] <Fatal_2> hows gstreamer development going guys?
[00:39] <wtay> hi
[00:39] <wtay> slowly getting there...
[00:39] <omega> attempting to finish off a major branch and merge it into HEAD
[00:40] <Fatal_2> neat... is that in prep for a new release?
[00:40] <omega> yup
[00:40] <wtay> attempting to build a testsuite and do refcounting/destruction without memleaks...
[00:40] <omega> wtay: remember, exit() is your friend
[00:40] <wtay> omega: if all else fails, yes <g>
[00:41] <omega> well, and at least as of right now, all else really does fail <g>
[00:41] <Fatal_2> thats good news.. i was reading on the web site that there is plans to support tuners (eg: wintv cards?)
[00:41] <omega> already is support for v4l
[00:42] <wtay> somewhat..
[00:42] <Fatal_2> oh ok...
[00:43] <Fatal_2> i cant use my wintv card yet (wintv pvr) .... neils decarpenter is (hopefully!) getting a driver together for it.. but until then.. :(
[00:44] <omega> it's not a bt8x8?
[00:44] <Fatal_2> yep it is bt878 but it also has a KFIR mpeg-2 encoder chip... and so can sorta get a picture but no sound at the moment :(
[00:45] <omega> oooooh
[00:45] Action: omega wants
[00:45] <wtay> cool
[00:45] <omega> any idea if drivers for this chip exist or will exist?
[00:45] <Fatal_2> heh
[00:45] <omega> and does it do mpeg2 decoding as well?
[00:45] <Fatal_2> omega: no the decoding is done in software :(
[00:45] <wtay> hmm
[00:46] <omega> ick
[00:46] <omega> but drivers for the encoder chip?
[00:46] <wtay> shouldn't be hard to do the decoding on the same HW..
[00:46] <Fatal_2> there are only windoze drivers.. but a gentleman by the name of Neils Decarpenter is trying to build a driver using softice logs and stuff like that
[00:46] <omega> cool
[00:46] <omega> url/email?
[00:46] <wtay> hehe, I remember softice :)
[00:47] <Fatal_2> umm.. www.sourceforge.net/projects/wintvpvr i think... ill check
[00:47] <Fatal_2> might be projects/pvr even...
[00:48] Action: Uraeus is rebooting to test my new devfs enabled NVidia driver
[00:48] Uraeus (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[00:48] <Fatal_2> im connecting to IRC at the moment through my unreal tournament client under win98 :)
[00:48] Action: omega doesn't expect to see Uraeus back for a while
[00:48] <omega> doh
[00:48] <Fatal_2> only irc client i have right now..
[00:49] <Fatal_2> brb.. hopefully it wont crash when i alt-tab
[00:49] Fatal_2 (u1567830 at pc-62-31-193-51-du.blueyonder.co.uk) left irc: Read error to Fatal_2[pc-62-31-193-51-du.blueyonder.co.uk]: Connection reset by peer
[00:49] <wtay> heheh
[00:51] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[00:51] <Uraeus> bummer
[00:51] <wtay> oooh, that's fast
[00:51] <wtay> erm
[00:51] <wtay> no go?
[00:51] <Uraeus> nope, the NVIDIA driver still reset at boot
[00:52] <Uraeus> brb
[00:52] Uraeus (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[00:54] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[00:55] <omega> looks like this guy has a good shot at getting the wintv pvr card to work, which makes it the idea card for the timeshifter
[00:55] <omega> except it's $250
[00:56] <omega> $231 pricewatch
[01:00] Action: Uraeus discovers why the devfs patch to the nvidia driver didn't work, or actually discovers that he didn't really apply it. that explains a lot :)
[01:01] <omega> whoops
[01:02] <Uraeus> brb
[01:02] Uraeus (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[01:04] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[01:04] <Uraeus> better
[01:25] <omega> ok, not really complete, but autoplugger scenarios sent
[01:30] <Uraeus> wtay: testest newest galeon compiled for 0.9 mozilla?
[01:33] ChiefHighwater (paul at temple-baptist.com) left irc: Read error to ChiefHighwater[temple-baptist.com]: Connection reset by peer
[01:33] <wtay> Uraeus: I don't think it works... 
[01:35] <wtay> leaked: 19189760
[01:35] <Uraeus> wtay: it does, but there is a compile option called --enable-mozilla-cvs, I have it running now and it beats the socks of anything I have tried before
[01:35] <Uraeus> even earler versions of Gal+moz
[01:35] <wtay> cool
[01:35] <Uraeus> it renders FAST, konqueror can just roll over and die :)
[01:37] <Uraeus> well I need to get up early to catch the tide :(, so goodnight everyone
[01:37] Uraeus (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[01:52] Nick change: maYam_OmenII -> maYam_sleep
[02:10] <wtay> I'm off to bed.. cya all
[02:11] Nick change: wtay -> wtay-zZz
[04:29] Nick change: ajbusy -> ajmitch
[05:04] Nick change: ajmitch -> ajbusy