From: IRC B. <wt...@us...> - 2001-10-24 04:27:38
|
******************************************************************* [03:00] <vishnu> taaz: that's what documentation is for, but yah, maybe it should be cleaned up -- funcs should take GstData * [03:00] <taaz> like if you dont check to see if its an event you'll crash or something right? [03:00] <vishnu> taaz: yah, definitely [03:01] <wingo> that's what alsa does :-\ [03:01] <taaz> i think this situation could be improved [03:01] <wingo> by improving plugins? [03:01] <wingo> only about 60 1 line fixes [03:02] <taaz> ? [03:02] <vishnu> taaz: we can ask plugins to request events explicitly and migrate the plugins gradually [03:02] <taaz> well a better short term hack is to make events subclass empty buffers [03:03] <vishnu> yuck [03:03] <taaz> so at least you dont crash in a totally crazy way [03:03] <taaz> yuck? [03:03] <taaz> err yeah wait [03:03] <taaz> I meant make buffer subclass event [03:03] <vishnu> well, i don't know. maybe it's better than crashing. ask wtay or omega, they'd have to approve it [03:04] <taaz> yeah... like consider buffers just a data event [03:04] <taaz> i can already hear whining about overhead [03:04] <wingo> that's when you want to crash tho -- before it was an infinite loop [03:04] <wingo> it's better than before [03:04] <wingo> eos i'm referring to [03:04] Action: vishnu gives wingo a rubber chicken prize [03:05] <taaz> i find it extrordinarily difficult to program OOP with this GTK/GObject stuff [03:05] <wingo> taken [03:05] <taaz> almost impossible [03:05] <vishnu> taaz: why? you mean gstreamer or gobject? [03:05] <taaz> i mean what i said [03:05] <vishnu> i mean, gstreamer is not exactly following the usual gobject patterns [03:05] <taaz> you have to jump through hoops to do anything [03:06] <vishnu> dunno, i really like gtk 2.0 [03:06] <taaz> i'm more a hardcore OO coder.. like Objective-C, Java, Python, Smalltalk, etc [03:07] <wingo> where them python bindings at? ;) [03:07] <vishnu> taaz: yah, but those are higher-level languages. i like perl too, but doing OO in C is cool [03:08] <taaz> cool? are you crazy? [03:08] <taaz> wingo: yeah yeah... i'll do it sometime ;) [03:09] <vishnu> yah, i mean, i expect it to be harder than java and it definitely offers good performance [03:09] <taaz> its not just harder, its prohibitavly difficult to code anything [03:10] <vishnu> taaz: it's not that bad. you just have to be more formal about it. [03:10] <taaz> speaking of difficult, do these property things get inherited? [03:10] <vishnu> yah [03:13] mwc (ma...@ly...) joined #gstreamer. [03:14] <taaz> so would it be a good idea to expose a "name" arg in GstObject? It's already got the set/get and field, just no property. or does that break something? [03:19] <wingo> why would you do that? just for reference... when do you need to do that to the name? you already have GST_OBJECT_NAME [03:20] <wingo> just wondering, not criticising [03:23] vishnu (jo...@cx...) got netsplit. [03:23] chillywilly (da...@d7...) got netsplit. [03:23] chillywilly (da...@d7...) returned to #gstreamer. [03:23] <taaz> just wanted to give names on -launch command line [03:24] <wingo> use brackets, i think: gstreamer-launch filesrc [ mynamehere ] location=dsasdfa ! .... [03:24] <wingo> see the source, that's iirc [03:24] <taaz> oh, silly me. i shall look into that [03:24] vishnu (jo...@cx...) returned to #gstreamer. [03:24] <taaz> still may be nice to have that as an arg for interactive tools [03:25] <taaz> maybe readonly or something [03:33] <vishnu> taaz: yah, that sounds sensical [03:36] <wingo> o mega, where art thou? ;-) [03:37] <wingo> vishnu: do you use any of gnome in redael? [03:40] <wingo> and another question, do you use libglad? [03:40] <wingo> libglade i mean [03:51] <omega> wingo: ? [03:51] <wingo> name proerty? [03:52] <omega> seems reasonable [03:52] Action: wingo has spilt coffe on his mouse pad [03:52] <omega> about a dozen lines of code, can't hurt anything [03:57] <taaz> writable? [03:57] Nick change: taaz -> taaz-brb [04:10] <tnt> Have you guys seen this: http://advogato.org/article/357.html ? [04:14] <tnt> Maybe Red Hat will take it over. [04:26] mwc (ma...@ly...) got netsplit. [04:28] <vishnu> wingo: no, i don't link with gnome. i'm trying to minimize my library dependencies .. uh somewhat [04:29] <vishnu> wingo: no, i don't use libglade [04:32] mwc (ma...@ly...) got lost in the net-split. [04:32] <wingo> ok [04:32] <wingo> is gtk2 significantly different to work with? [04:33] <vishnu> dunno, i never used gtk-1.2 [04:33] <wingo> than gtk1.2? [04:33] <wingo> oh [04:33] <vishnu> i like 2.0 a lot though [04:36] <vishnu> wingo: there's a Changes-2.0.txt file in gtk+ 2.0 that lists all the programmer visible changes, afaik [04:36] <wingo> ok, i'll check it out [04:41] mwc (ma...@ly...) joined #gstreamer. [05:00] vektor (reet@HSE-Kitchener-ppp3508492.sympatico.ca) joined #gstreamer. [05:00] <vektor> taaz-brb: when you wake up say hi [05:06] chillywilly (da...@d7...) left irc: [05:07] Nick change: taaz-brb -> taaz [05:07] <taaz> hi [05:07] <vektor> hi! [05:07] <vektor> hey taa [05:07] <vektor> z [05:07] <vektor> taaz: How would you like to become FAMOUS? [05:08] <vektor> taaz: ... with or without the capslock enabled. [05:08] <taaz> does that mean i get women, money, and power too?! [05:08] <vektor> Yeah probably. [05:08] <taaz> is it legal? [05:08] <vektor> Completely! [05:08] <vektor> Interested? [05:08] <vektor> I know you are. [05:08] <taaz> sign me up! [05:09] <vektor> Ok! [05:09] <vektor> I need you to set up the configure script stuff for movietime. [05:09] <taaz> yeah, i figured it would be something like that ;) [05:09] <vektor> Hey and by the way, audio/video sync ROCKS now in movietime. [05:10] <vektor> It will never ever go out of sync. [05:10] <vektor> (+/- a small small constant factor). [05:10] <taaz> what did you change? [05:10] <vektor> I now use mmap and do things correctly. [05:10] <vektor> I use the soundcard as a clock. [05:10] <vektor> I'm slightly wrong on the timestamps of my video frames, but it's not noticable. [05:10] <vektor> The audio sync correction made a HUGE difference. [05:11] <taaz> how do you know the soundcard is accurate? [05:11] <vektor> No more magic constants. [05:11] <vektor> Ah that's the key. [05:11] <vektor> It doesn't need to be accurate. [05:11] <vektor> I use it as my clock. [05:11] <vektor> So if it's really 48003 then we're on it. [05:11] <vektor> Anyways, you should try it out and tell me how it goes, but I'd really appreciate it if you could configure-script it up. [05:11] <vektor> I want to post it for release this week. [05:11] <taaz> so like your fingers are broken or what? [05:12] <vektor> No I have some midterms. [05:12] <vishnu> configure isn't that bad. [05:12] <vektor> vishnu: I know, I've done it before. [05:12] <taaz> too much typing fixing sync, too tired now? [05:12] <vishnu> oh huh [05:12] <vektor> taaz: Yeah something like that. [05:12] <vishnu> heh [05:16] harobed (harobed@AC90B951.ipt.aol.com) left irc: Client Exiting [05:17] <vishnu> ogg123 doesn't work ... so i tried gstreamer and it's great :-) [05:19] <taaz> vektor: so how portable is this soundcard thing? [05:19] <taaz> and how flexable? [05:20] <taaz> i guess you're just concerned with dvds... but soundcard stuff isn't a general solution :( [05:20] <vektor> Um, well supported on linux and very flexible. [05:20] <taaz> like for gstreamer or something... we may just have video [05:20] <vektor> Well, sure. [05:20] <vektor> But if you have audio you must use it as a clock. [05:20] Shippou (no...@cr...) left irc: Ping timeout for Shippou[cr934547-a.flfrd1.on.wave.home.com] [05:20] <vektor> You can't use the system clock and resample your audio. [05:21] <vektor> Like, y'know, in DirectShow for example, every fliter graph has a clock source, and it is usually the soundcard. [05:21] <vektor> So, that sort of proves you can have a system where you find the local clock. [05:21] <taaz> i know jack about direct* [05:21] <vektor> Exactly which is why I'm explaining. [05:22] mwc (ma...@ly...) left irc: Ping timeout for mwc[lychee.ntu.edu.au] [05:22] mwc (ma...@ly...) joined #gstreamer. [05:22] <vektor> Anyways I believe I can simulate what I'm doing using the normal read()/write() soundcard API but it will be tricky and just as unportable. [05:22] <vektor> Multimedia applications demand certain features from the underlying API. [05:23] <vektor> Just as the little voice in my head is demanding I get some sleep :( [05:23] omega (om...@om...) left irc: Ping timeout for omega[omegacs.net] [05:23] <taaz> so are you going to copy libmpeg2 to release? [05:24] <vektor> Potentially. [05:24] <vektor> It's stupid though. Part of the point of my app is to depend on readily-available libraries. [05:24] <vektor> But I need certain features from X and to argue my point I need an example application. [05:24] <vektor> :( [05:24] <taaz> whee! [05:25] <taaz> start snail mailing walken requests for api updates ;) [05:25] <taaz> he'd get a kick out of that [05:26] <vishnu> heh [05:26] <vektor> He might assume I'd put anthrax in them. Suspicious mail. I wouldn't want to risk it. :( [05:27] <taaz> i suspect that in all my bills. so i no longer open them [05:28] <taaz> i wonder how many people actually use that excuse when their utils are cut off ;) [05:28] <taaz> so this api stuff... [05:29] <vektor> api stuff. [05:29] <taaz> is it a big performance hit to have opaque types and accesor functions for these flags? [05:29] <taaz> it's much less prone to breakage that way [05:31] <vishnu> yah, much less prone to breakage. can you talk some sense into these guys? i'm ready to resort to violence [05:31] <vektor> taaz: uh... [05:31] <vishnu> i'm getting pumped up. i'm went to the gym today [05:31] <vektor> taaz: no it isn't huge. i don't really give a fuck. i just want to get something released that i can use. [05:32] <taaz> i'm pretty sure walken wont listen to my ideas. lose an extra cycle and the world ends blah blah [05:34] <vishnu> heh [05:42] <taaz> whoop! i'm making a cool little plugin [05:43] <taaz> keeps track of stream stats [05:43] <vishnu> what is it?? [05:43] <taaz> it's cool [05:44] <taaz> if i'm really k-rad i'll add moving average calc to it too [05:44] <taaz> and rates too [05:44] <vishnu> whoa! [05:44] <taaz> i'm not sure how to do some of this in a sane way though [05:48] <taaz> man, you don't realize how many bytes a decoded stream is until you keep track of it [05:48] <vishnu> heh [05:49] <vektor> taaz: So are you going to do that configure stuff? Or should I? [05:50] <taaz> if i do it will you code something cool while you wait? ;) [05:51] <taaz> i can do it... i need a bit of time to finish this other stuff though [05:51] <vektor> ok. [05:51] <vektor> Well if you ahve a chance by thursday that would be cool. [05:53] <vektor> goodnight [05:56] <taaz> alrighty [05:57] <taaz> damnit vektor [05:57] <taaz> you're pgp signed mails make my broken pgp setup take nearly a minute to just decide i can't verify your sig [05:58] <taaz> ok, yeah, this stats element kicks booty [05:59] <taaz> where did the omega go? [06:01] <taaz> this benow track is sweet [06:04] chillywilly (da...@d1...) joined #gstreamer. [06:13] walken (fo...@c1...) joined #gstreamer. [06:14] wingo (wi...@rd...) left irc: My damn controlling terminal disappeared! [06:22] Shippou (no...@cr...) joined #gstreamer. [06:41] wingo (wi...@rd...) joined #gstreamer. [06:41] Nick change: wingo -> wingo-sleep [06:45] mwc (ma...@ly...) left irc: Ping timeout for mwc[lychee.ntu.edu.au] [06:46] chillywilly (da...@d1...) left irc: Read error to chillywilly[d128.as14.nwbl0.wi.voyager.net]: EOF from client [07:02] mef-zZz (ma...@us...) joined #gstreamer. [07:02] Nick change: mef-zZz -> mef [07:03] <mef> anyone tried to build gstreamer on windoze? [07:03] <mef> I am trying right now, but am still diddling with getting pkgconfig to compile. [07:04] <mef> that is, I am trying it using cygwin. [07:14] mef (ma...@us...) left irc: [07:24] mwc (ma...@ly...) joined #gstreamer. [07:31] vishnu (jo...@cx...) left irc: using sirc version 2.211+4KSIRC/1.1 [07:42] steveb (st...@no...) joined #gstreamer. [07:52] walken (fo...@c1...) left irc: l8r [08:09] mwc (ma...@ly...) got netsplit. [08:09] vektor (reet@HSE-Kitchener-ppp3508492.sympatico.ca) got netsplit. [08:09] steveb (st...@no...) got netsplit. [08:09] Shippou (no...@cr...) got netsplit. [08:09] wtay-tv (wi...@ca...) got netsplit. [08:09] evil_monk (trevo@208.141.162.68) got netsplit. [08:09] BBB-zZz (BB...@uc...) got netsplit. [08:09] ShrimpZzZ (marius@131.252.244.168) got netsplit. [08:09] ajmitch (aj...@p8...) got netsplit. [08:09] bstard (Lor...@a2...) got netsplit. [08:09] wingo-sleep (wi...@rd...) got netsplit. [08:11] Nick change: tnt -> tnt-zZz [08:15] ShrimpZzZ (marius@131.252.244.168) got lost in the net-split. [08:15] wtay-tv (wi...@ca...) got lost in the net-split. [08:15] evil_monk (trevo@208.141.162.68) got lost in the net-split. [08:15] BBB-zZz (BB...@uc...) got lost in the net-split. [08:15] bstard (Lor...@a2...) got lost in the net-split. [08:15] ajmitch (aj...@p8...) got lost in the net-split. [08:15] vektor (reet@HSE-Kitchener-ppp3508492.sympatico.ca) got lost in the net-split. [08:15] Shippou (no...@cr...) got lost in the net-split. [08:15] wingo-sleep (wi...@rd...) got lost in the net-split. [08:15] mwc (ma...@ly...) got lost in the net-split. [08:15] steveb (st...@no...) got lost in the net-split. [08:34] ShrimpX (marius@131.252.244.168) joined #gstreamer. [08:34] wtay-tv (wi...@ca...) joined #gstreamer. [08:34] evil_monk (trevo@208.141.162.68) joined #gstreamer. [08:34] BBB-zZz (BB...@uc...) joined #gstreamer. [08:34] bstard (Lor...@a2...) joined #gstreamer. [08:34] ajmitch (aj...@p8...) joined #gstreamer. [08:34] mwc (ma...@ly...) joined #gstreamer. [08:34] steveb (st...@no...) joined #gstreamer. [08:34] vektor (reet@HSE-Kitchener-ppp3508492.sympatico.ca) joined #gstreamer. [08:34] wingo-sleep (wi...@rd...) joined #gstreamer. [09:09] Shippou (no...@cr...) joined #gstreamer. [10:03] mwc (ma...@ly...) left irc: [x]chat [11:44] xav (xav@AMontpellier-201-1-4-3.abo.wanadoo.fr) joined #gstreamer. [11:48] <xav> can't build after a cvs update: make chokes at automake (after sucking my >700Mb ram and 2Gb swap) [11:48] <xav> probably terminated by the kernel OOM killer [11:50] uwe (user424@213.174.92.50) joined #gstreamer. [11:50] <uwe> hi. [11:51] <xav> hi [11:53] <uwe> any idea for good gtk docu? [11:53] Action: xav is away: I'm busy [12:15] Action: xav is back (gone 00:22:02) [12:21] <xav> uwe: GGAD ? [12:22] xav (xav@AMontpellier-201-1-4-3.abo.wanadoo.fr) left irc: boot new kernel [13:18] harobed (harobed@ACA045DE.ipt.aol.com) joined #gstreamer. [13:25] wingo-sleep (wi...@rd...) got netsplit. [13:25] harobed (harobed@ACA045DE.ipt.aol.com) got netsplit. [13:31] wingo-sleep (wi...@rd...) got lost in the net-split. [13:31] harobed (harobed@ACA045DE.ipt.aol.com) got lost in the net-split. [13:52] Nick change: ShrimpX -> ShrimpZzZ [13:58] MM (m.m...@20...) joined #gstreamer. [14:24] wingo-sleep (wi...@rd...) joined #gstreamer. [14:24] harobed (harobed@ACA045DE.ipt.aol.com) joined #gstreamer. [14:24] xav (xav@AMontpellier-201-1-4-3.abo.wanadoo.fr) joined #gstreamer. [14:26] xav (xav@AMontpellier-201-1-4-3.abo.wanadoo.fr) left irc: Ping timeout for xav[AMontpellier-201-1-4-3.abo.wanadoo.fr] [14:40] asmod (stevec@64.5.222.2) joined #gstreamer. [14:47] manuel (user422@213.174.92.50) joined #gstreamer. [14:48] Shippou (no...@cr...) left irc: Ping timeout for Shippou[cr934547-a.flfrd1.on.wave.home.com] [15:05] MM (m.m...@20...) left irc: [15:40] Zygo (zblaxell@209.217.112.246) joined #gstreamer. [15:42] bstard (Lor...@a2...) left irc: Read error to bstard[a213-84-40-242.adsl.xs4all.nl]: EOF from client [15:43] <uwe> manuel: du hier? [15:48] <manuel> uwe: hey uwe.. long time no see! ;-) [15:49] <uwe> manuel: look to the left ;) [15:50] <manuel> uwe: ah there you r.. [16:13] wingo-sleep (wi...@rd...) left irc: Ping timeout for wingo-sleep[rdu25-21-076.nc.rr.com] [16:15] wingo-sleep (wi...@rd...) joined #gstreamer. [16:51] <uwe> manuel: let's take the bus 6:05 (or earlier ;) [16:52] Shippou (no...@ot...) joined #gstreamer. [16:55] xav (xav@AMontpellier-201-1-4-3.abo.wanadoo.fr) joined #gstreamer. [17:02] <xav> hi sleepers [17:03] <xav> any1 got automake to work correctly right now ? It sucks all my mem [17:04] <taaz> what version? [17:13] <xav> cvs [17:14] <xav> err ... debian sid: automake (GNU automake) 1.4-p4 [17:19] harobed (harobed@ACA045DE.ipt.aol.com) left irc: Ping timeout for harobed[ACA045DE.ipt.aol.com] [17:25] vishnu (jo...@cx...) joined #gstreamer. [17:25] <vishnu> wtay? [17:26] uwe (user424@213.174.92.50) left irc: Client Exiting [17:27] manuel (user422@213.174.92.50) left irc: Client Exiting [17:35] xav (xav@AMontpellier-201-1-4-3.abo.wanadoo.fr) left irc: Read error to xav[AMontpellier-201-1-4-3.abo.wanadoo.fr]: EOF from client [17:41] harobed (harobed@ACA22943.ipt.aol.com) joined #gstreamer. [18:22] xav (xav@AMontpellier-201-1-4-3.abo.wanadoo.fr) joined #gstreamer. [18:25] <xav> Hi, I'm back. had to reboot because automake really trashed my machine [18:29] <xav> do you have problems with automake too ? [18:30] <taaz> no [18:30] <taaz> did you read README? [18:30] <taaz> newer automakes don't have that mem issue [18:30] <vishnu> i use automake 1.5-1 [18:33] <xav> mmh ... I'm sure I had automake 1.5 a while ago. is it possible that apt-get downgraded automake ? [18:33] <xav> and autogen.sh didn't warn me about an upatched automake, as it used to do [18:36] <xav> ok, I see now. debian has effectively renamed automake 1.5 to automake1.5, and downgraded automake to 1.4 [18:41] <taaz> yup, just trying to make everyones life suck just that little bit more ;) [18:42] <vishnu> yah, gotta suck out the corners [19:05] <xav> gstwinenc.cc: In function `void gst_winenc_chain(GstPad *, GstBuffer *)': [19:06] <xav> gstwinenc.cc:280: `BitmapInfo' undeclared (first use this function) [19:06] <vishnu> xav: yah, i just comment out that plugin [19:09] <xav> I just added #include <avifile/image.h> and it worked [19:09] <xav> (well, it compiles) [19:09] <vishnu> oh, cool [19:11] <xav> --- gstwinenc.cc 2001/10/17 10:21:25 1.7 [19:11] <xav> +++ gstwinenc.cc 2001/10/23 17:10:23 [19:11] <xav> @@ -26,6 +26,7 @@ [19:11] <xav> [19:11] <xav> #include "gstwinenc.h" [19:11] <xav> #include <avifile/creators.h> [19:11] <xav> +#include <avifile/image.h> [19:11] <xav> [19:11] <xav> /* elementfactory information */ [19:11] <xav> GstElementDetails gst_winenc_details = { [19:11] <vishnu> xav: email to the mailing list [19:14] <taaz> eh? compiles for me i think [19:16] <xav> taaz: not for me. perhaps debian sid's avifile headers have changed [19:16] <taaz> i'm using the almost latest debs [19:16] <xav> almost ;) [19:16] <taaz> pre-sdl craziness changes [19:18] <taaz> you know: "here's a patch, i didn't test it" does not inspire confidence ;) [19:19] <xav> taaz: but that's the truth ! make didn't even finished, I just know that gstwinenc.cc is compiled ok [19:22] <xav> taaz: how can I test that ? [19:23] <taaz> libavifile0.6-dev 0.6.0.20011002-1 [19:23] <taaz> compiled fine for me with that deb [19:32] <xav> well ... you're lucky ;) [19:35] <steveb> xav: i compiled avifile-0.6.0.20011003 from source and it works fine. are you using CVS gstreamer? [19:41] <xav> yes [20:14] ChiefHighwater (pa...@te...) joined #gstreamer. [20:19] <xav> what happens if I connect an src pad which can do video/raw YUV to a sink pad which can do video/raw RGB ? [20:20] <xav> currently it seems the sink element just takes the YUV buffers as if they where RGB, but I think I don't quite understand how this works [20:27] Nick change: wtay-tv -> wtay [20:27] <wtay> yo [20:30] wtay (wi...@ca...) got netsplit. [20:30] asmod (stevec@64.5.222.2) got netsplit. [20:30] Shippou (no...@ot...) got netsplit. [20:30] evil_monk (trevo@208.141.162.68) got netsplit. [20:30] BBB-zZz (BB...@uc...) got netsplit. [20:30] BBB-zZz (BB...@uc...) returned to #gstreamer. [20:30] asmod (stevec@64.5.222.2) returned to #gstreamer. [20:30] wtay (wi...@ca...) returned to #gstreamer. [20:31] evil_monk (trevo@208.141.162.68) returned to #gstreamer. [20:36] Shippou (no...@ot...) got lost in the net-split. [20:39] <vishnu> yo [20:40] <vishnu> wtay? [20:42] <xav> how do I gdb things in tests/ ? [20:42] <xav> libtool gdb doesn't work [20:42] <vishnu> xav: you can edit the shell scripts [20:43] <vishnu> xav: just scroll down to the line that says exec and add a similar line with gdb [20:43] msterret (mst...@xl...) joined #gstreamer. [20:46] <xav> whee ... gdb eats all CPU ... and seems doing I-dunno-what after "998.376000 MHz Pentium III (Coppermine) processor detected" [20:47] <vishnu> xav: it take a long time to read all the symbols from the plugins. be sure you have gstreamer-register up-to-date [20:47] evil_monk (trevo@208.141.162.68) left irc: Client Exiting [20:48] <xav> vishnu: yeah, that's it. thx [20:50] <xav> argh. I have a sigsev in the colorspace converter [20:50] <wtay> vishnu: yes? [20:50] <vishnu> wtay: any comments on my patch for events support? [20:51] <wtay> vishnu: looks good.. [20:51] <vishnu> wtay: cool .. [20:55] <vishnu> gst_pad_send_event (gst_element_get_pad (fv->src, "src"), [20:55] <vishnu> gst_event_new_seek (GST_SEEK_BYTEOFFSET, offset, TRUE)); [20:55] <vishnu> i tested it with pad_send_event [20:55] <wtay> and? [20:55] <vishnu> wtay: it works fine [20:56] <wtay> cool [20:57] evil_monk (trevo@208.141.162.68) joined #gstreamer. [20:57] Nick change: tnt-zZz -> tnt [20:59] <tnt> Good Morning. [20:59] <wtay> yo [20:59] <tnt> Hmmm, I guess it's actually the afternoon. [20:59] <tnt> Good Afternoon. [21:00] <tnt> vishnu: So this new patch of your basically makes it so you can "scrub" now, correct? [21:00] <vishnu> tnt: scrub? [21:01] <tnt> Scrubbing is manually moving through the Video and Audio... usually by dragging something like a scroll bar... you control where you are, and the speed you move at. [21:01] <xav> is there a way to force colorpace output to RGB ? [21:01] <xav> from gstreamer-launch [21:02] <vishnu> tnt: yah. my video player has that ability, actually [21:02] <tnt> tnt: Can it go backward too? [21:02] <tnt> vishnu: Can it go backward too? [21:02] <vishnu> tnt: backward? not smoothy but it can skip back and play forward [21:02] <tnt> (I was talking to myself there, for a minute :-) ) [21:03] <wtay> xav: nope [21:03] <tnt> vishnu: Hmmm,... to bad... you patch almost gives scrubbing then. [21:03] <tnt> Does your player have a website? [21:03] <vishnu> tnt: to play backward, you'd need to seek before every frame. it's probably possible, but tricky [21:04] <wtay> tnt: scrubbing requires a bit more work from the app [21:04] <wtay> tnt: and mpeg2dec doesn't really handle it efficiently [21:04] <vishnu> tnt: yah, my player is part of redael -- http://redael.berlios.de/ [21:05] <vishnu> tnt: actually, i haven't uploaded the recent source code yet [21:05] <tnt> vishnu: You need some screenshots :-) [21:05] <vishnu> tnt: click on documentation for screenshots [21:06] <tnt> Is it GNOME based, GTK based, or something else? [21:07] <vishnu> tnt: just gtk 2.0 and gstreamer. no additional dependencies [21:08] <vishnu> tnt: join the mailing list if you like ;-) [21:09] <tnt> Where's the archive for the 'devel' mailing list? [21:10] <tnt> Or the 'announce' mailing list? [21:10] <vishnu> tnt: there aren't any messages yet. <g> i moved to berlios recently [21:10] <tnt> Ahhh... I see the mailing lists are *very* high volume, as your webpage describes :-) [21:11] <vishnu> tnt: heh, i don't want to surprise anyone if there really is a mail flood someday [21:11] <tnt> :-D [21:12] <vishnu> tnt: generally there is more anger about too much mail than too little ;-) [21:12] <tnt> Ya... the devel mailing list for my project, matterial, is quiet sometime, and then sometimes it jumps to like 50 messages a day... some people get quite a surprise. [21:13] <vishnu> tnt: yep :-) [21:16] <ajmitch> hi all [21:17] <tnt> Hello. [21:24] Nick change: tnt -> tnt-out [21:47] Action: taaz wants to go home and play with new guilaunch... [21:50] <wtay> vishnu: applied your patch [21:50] <vishnu> wtay: thank you! now our trees are in sync :-) [21:51] <wtay> cool, and now I understand what's going on :) [21:51] <ajmitch> hehe [21:56] <vishnu> my app can use the next generation of debs for gtk+ and gstreamer without additional modifications [21:56] <wtay> vishnu: is gst feature complete now for you? [21:57] <wtay> I'm writing a TODO list now... [21:58] <vishnu> wtay: it's not feature complete at all. rather it has the absolute minimum sufficient features. ;-) [21:58] <wtay> what fdo you need more? [21:59] <vishnu> wtay: A/V sync would be nice. a time->offset mapping is the most urgent thing, for my stuff [21:59] <vishnu> wtay: i'd really prefer to seek by time instead of by offset [21:59] <wtay> vishnu: yup, clocking is essential [22:00] <wtay> that's a major todo still [22:00] <vishnu> wtay: it would also be neat to handle vcdsrc, dvdsrc and mpeg1 files. gstreamer can probably do it now, but i haven't spent the time to figure it out [22:00] <wtay> ok, those are plugins, someone should just write/rewrite them [22:01] <wtay> mpeg1 should work fine too [22:01] <vishnu> wtay: yah it's mostly a matter of testing and tweaking [22:01] <wtay> what I would like to do is send the seek event in the mpeg2dec src pad [22:01] <ajmitch> wtay: gonna try for a release in the next month or so? ;) [22:02] <wtay> which sends it to the demuxer which does the time/byte conversion using timecache [22:02] <wtay> ajmitch: "or so", yes :) [22:03] <vishnu> wtay: seek to a particular frame? dunno, maybe audio is easier? [22:03] <wtay> vishnu: time seek [22:03] <wtay> vishnu: frame == time/rate (in the naive case) [22:04] <vishnu> wtay: yah time seek. but will the seek has per-frame resolution or 48khz resolution (audio) [22:04] <wtay> vishnu: per frame I would say [22:04] <wtay> vishnu: for audio it should be sample accurate [22:05] <vishnu> wtay: well .. whatever. any kind of time->offset mapping is better than nothing [22:05] <wtay> yes [22:05] <wtay> time seeking is essential for an NLE lib I guess [22:05] <vishnu> yes, certainly [22:06] <wtay> and I would love to play some media types backwards too :) [22:06] <vishnu> presently, all my bookmarks are tied to a particular vob file. i can't rescale it or anything because that would change the bookmark offsets (!) [22:07] <vishnu> slow motion, backwards, etc. yah [22:08] Action: wtay dreams of _set_clock(- _get_clock()) [22:15] steveb (st...@no...) left irc: advance! [22:16] ajmitch (aj...@p8...) left irc: Ping timeout for ajmitch[p8-max4.dun.ihug.co.nz] [22:21] omega (om...@om...) joined #gstreamer. [22:27] msterret (mst...@xl...) left #gstreamer. [22:29] <wtay> yo [22:29] <omega> yo [22:30] Shippou (no...@cr...) joined #gstreamer. [22:30] <wtay> omega: I'm going to make the scheduler plugable [22:31] <omega> eek <g> [22:31] <wtay> hehe [22:31] <omega> any reason to do that now as opposed to later, say afer doing a release? [22:31] <wtay> no [22:32] <omega> ok, let's wait <g> [22:34] Action: omega just RMA'd another maxtor drive that's having troubles [22:34] <omega> but this [22:34] <omega> this'll give me a chance to dupe drives more easily when I build my new gateway machine later this week [22:39] <ChiefHighwater> so, what number will this release be? [22:39] <omega> 0.2.2 [22:39] <omega> with 0.3.0 coming up soon [22:40] <wtay> we need a default event handler.. [22:40] <omega> yup [22:41] <wtay> any idea as how it will work? [22:41] Action: omega reads through the -cvs mail [22:41] <ChiefHighwater> codename: mugshot...a picture taken for future reference? [22:42] <wtay> mugshot? [22:42] <ChiefHighwater> the picture police take of you to put on file when you get arrested [22:42] <omega> wtay: picture of you taken through your beer mug <g> [22:43] <omega> same thing in some cases [22:43] <wtay> ah :) [22:43] <ChiefHighwater> how about "Thumbnail"...those pics are often 2x2 [22:43] chillywilly (da...@d4...) joined #gstreamer. [22:43] <ChiefHighwater> Ello [22:43] <omega> taaz: here? [22:44] <ChiefHighwater> just playing off the idea that this release is really a snapshot so that we can do the major push for 0.3 [22:44] <omega> well, it's got a huge amount of new stuff [22:44] <ChiefHighwater> maybe "snapshot"? [22:44] asmod (stevec@64.5.222.2) left irc: [x]chat [22:44] <wtay> streamshot? [22:45] <wtay> hehe, we're actually going to have 100% API doc coverage for this release :) [22:45] <omega> cool [22:45] <ChiefHighwater> but isn't a lot of the new stuff <almost> done and really waiting for 3.0 to really get movin? [22:45] Action: wtay proud [22:45] <omega> I get a 1.8MB diff between 0.2.1 and HEAD [22:45] <omega> and I dunno if that includes all the new files or not, checking [22:46] <omega> no, it doesn't... [22:46] <wtay> I lost my cvs archives... you might need to send them to me so I can make a compilation of changes [22:46] <omega> any idea what the cvs diff flag is to do that? [22:46] <omega> lost your cvs archives? [22:46] <wtay> mail commit logs.. [22:47] <omega> ok, yeah, I can gather them [22:47] <omega> back to what date? [22:47] <wtay> 0.2.1 release date.. [22:47] <omega> looks like ~3mo ago [22:47] <omega> wow, thought it was longer ago [22:48] <omega> June 27 is last change date on configure.base for that tag [22:48] <wtay> 27 June, 2001 [22:48] <ChiefHighwater> ~4 mo [22:48] <omega> 3mo3wk [22:49] <omega> ok, rdiff shows a diff of 2.9MB [22:49] <wtay> wow [22:50] <omega> a large chunk of which is ChangeLog [22:50] <wtay> hmm [22:50] <omega> which is about 512KB [22:51] <omega> btw, that's a unidiff, too [22:52] ajmitch (aj...@p3...) joined #gstreamer. [22:52] Zygo (zblaxell@209.217.112.246) left irc: Read error to Zygo[209.217.112.246]: Connection reset by peer [22:53] <taaz> omega: here now [22:53] <taaz> what up? [22:53] <omega> taaz: did you have any neat ideas re: events and buffers last night? [22:54] <wtay> thomasvs_: how much longer do we have to look at that stupid compile error? [22:55] <taaz> omega: some, though i was busy doing other cool stuff [22:57] <omega> anything interesting yet? [22:57] <taaz> wtay: could add something about how to get timestamps from byte interface of bytestreams to TODO list [22:57] Shippou (no...@cr...) left irc: Ping timeout for Shippou[cr934547-a.flfrd1.on.wave.home.com] [22:57] <taaz> wtay: though any solution i have come up with is no better than just dropping the byte interface and just using buffers [22:57] <taaz> omega: i made a cool plugin last night [22:58] <omega> oh? [22:58] <wtay> taaz: the definition of a timestamp on a buffer is the time the first byte of the buffer should be presented.. [22:58] <wtay> taaz: bytestream does that just fine [22:58] <omega> wtay: -cvs archives sent (415KB .bz2) [22:58] <taaz> gststatistics, identity-type element that keeps track of buffers/bytes/events. does some basic timing on it too so you get bandwidth reports as well [22:58] <wtay> omega: ok, I'll compile a nice "new stuff" log [22:58] <omega> 795 messages [22:59] <omega> cool [22:59] <wtay> neat [22:59] <omega> though the trace mechanism will be able to do that offline later, too [23:00] <taaz> wtay: if you use the byte interface then only way to get timestamps is to do a buffer peek too... which is really just more work than only doing the buffer peek and using the data pointer from it (i think) [23:00] <wtay> taaz: true [23:00] <taaz> i'm thinking in terms of mpeg2parse setting timestamps and wanting a52dec (or whatever) to just pass that through [23:01] <omega> bytestream could store the latest timestamp (but it would have to cycle it through as buffers are flushed out of the tail position) [23:01] <wtay> hmm, -guilaunch seriously rocks, but it's slowly turning into gsteditor.. [23:01] <omega> well, to some extent that's good, as far as the various dialogs [23:01] <omega> though he should look at what the editor has so far [23:01] <omega> I'll mail him [23:02] <ChiefHighwater> isn't he a little big? How much postage would that be? And won't he need some food? [23:02] <omega> hmm, depends on how far and how high (airmail or slow-boat) [23:03] <ChiefHighwater> and make sure they don't burn him with the rest of the white house mail [23:03] <omega> oh? [23:03] <taaz> omega: what should i do with this stats element? it's really cool and imho almost useful enough to put in gst/elements/ ;) [23:03] <wtay> taaz: isn't it possible to add the features to identity? [23:04] <taaz> wtay: no, i refuse. we have this cool pipeline stuff, let's use it. no reason to put non-identity features in identity. i question the addition of that duplicate stuff in there even. [23:05] Action: taaz will start making demands next ;) [23:05] Action: omega needs to figure out what this duplicate stuff is [23:06] <taaz> wtay: speaking of duplicate, it's not going to work too well with events [23:06] Action: wtay needs to figure out why identity should not count buffers [23:06] <taaz> wtay: and identity doesn't handle eos (ie, going to PAUSE) properly [23:06] <wtay> taaz: that's a bug in identity [23:07] <taaz> wtay: seriously, why should identity do -anything- except a super simple passthrough? [23:07] <wtay> taaz: oh, identity does a lot more these days, like different scheduling options and such [23:07] <wtay> taaz: and sleep time... [23:08] <omega> taaz: it is a testing plugin [23:08] <omega> it was written to stress-test the scheduling, primarily [23:08] <wtay> taaz: this plugin is designed to test out a lot of stuff [23:09] <omega> just like fakesrc and fakesink [23:09] <wtay> fakesrc is out most complex plugin now :) [23:09] <taaz> btw, i have no clue how to watch video with -launch. it fails any way i try it :( [23:10] <wtay> identity should also be able to copy-on-write buffers in the future.. [23:10] <omega> taaz: such as? [23:10] <wtay> taaz: filesrc location=/opt/data/DolbyDigitalBroadway.vob ! mpeg2parse video_0! queue ! { mpeg2dec ! xvideosink } [23:10] <wtay> works for me [23:11] wtay (wi...@ca...) left irc: Read error to wtay[cable-195-162-215-201.upc.chello.be]: EOF from client [23:11] <omega> whoops [23:11] <vishnu> taaz: don't use a thread [23:11] <omega> vishnu: you have any ideas as to how to *fix* threads? [23:11] <vishnu> omega: i don't think you want to hear my suggestions ;-) [23:12] <omega> why's that? [23:12] <omega> taaz: works for me too [23:12] <vishnu> how about you get an SMP machine and try to debug it? [23:12] <omega> I'm working on it. but I asked if *you* had any ideas [23:12] Action: vishnu hides under a rock [23:13] <omega> great. Xv is screwed up on my machine [23:13] wtay (wi...@ca...) joined #gstreamer. [23:13] #gstreamer: mode change '+o wtay' by ChanServ!s@ChanServ [23:13] <wtay> when it doesn't crash my X server :) [23:13] #gstreamer: mode change '-o wtay' by wtay!wi...@ca... [23:13] <taaz> ok, so like it doesn't work for me, yes i'm using the same cmd line from the man page and all [23:14] <omega> you have HEAD [23:14] <omega> ? [23:14] <taaz> of course! ;) [23:14] <omega> hmm, I'd confirm that... [23:14] <omega> not just have the source, but, um, built too <g> [23:15] <taaz> gotta go push start a car... brb [23:20] <omega> wtay: so, is that TODO for 0.2.2 ? [23:21] <wtay> default event handlers. [23:21] <omega> ok, how should those work? [23:21] <wtay> an element should return FALSE in the event handler, which would trigger the default handler for one [23:21] <omega> ok, that's only for chained and reverse events [23:22] <wtay> for elements without event handler the default handler would be triggered always [23:22] <omega> hmm? [23:22] <wtay> yes [23:22] <omega> should I look at a specific example plugin? [23:22] <wtay> not that I know of, no [23:23] <omega> well, let's take a52dec first [23:23] <wtay> we have two cases basically.. [23:24] <wtay> a) the event handler (for which the _send_event code looks good) [23:25] <wtay> b) the downstream events (which require an element flag) [23:26] Zeenix (ze...@13...) joined #gstreamer. [23:26] <Zeenix> hello all [23:26] <wtay> yo [23:27] <Zeenix> wtay: i think the RtpRecv will be ready tommorow [23:27] <wtay> cool [23:27] <Zeenix> wtay: but cant guarantee that it would work too [23:28] <wtay> omega: a52dec is almost correct, the only thing it should do is call the default handler for the events it doesn't know abourt [23:28] <vishnu> Zeenix: release early & often :-) [23:28] <omega> wtay: ok [23:28] <wtay> omega: thing is... [23:28] <Zeenix> omega: oh, i see reply from robla in my inbox [23:28] <omega> cool [23:29] <wtay> omega: the default handler should either do _push (event) or gst_pad_send_event [23:29] <omega> hmmm [23:29] <Zeenix> omega: forwarding the message to you, its small [23:29] <wtay> upstream or downstream... [23:30] <omega> well, ok, the case of a52dec... [23:30] <omega> the default case of the event switch [23:30] <omega> in this case it's looped, so we can do a pad_send_event [23:30] <Zeenix> omega: email ? sorry, i should remember it [23:30] <omega> om...@te... [23:30] <wtay> hmm.. pad_send_event is meant for upstream events.. [23:31] <taaz> can i spam you all for a sec? [23:31] <taaz> ./tools/gstreamer-launch httpsrc location=http://us.benow.ca:10390/ ! statistics [mp3] buffer_update_freq=10 ! mad ! statistics [raw] bytes_update_freq=100000 ! fakesink silent=true [23:31] <omega> only if we don't end up on someone *elses* list... [23:31] <taaz> statistics: (mp3) total: s:19.4694 buffers:400 bytes:558348 events:0 [23:31] <taaz> : (mp3) total: buf/s:20.5451 B/s:28678.2 e/s:0 B/buf:1395.87 [23:31] <taaz> : (mp3) last: s:0.570302 buffers:400 bytes:558348 events:0 [23:31] <taaz> : (mp3) last: buf/s:17.5346 B/s:18323.6 e/s:0 B/buf:1045 [23:31] <omega> [] ? [23:31] <taaz> statistics: (raw) total: s:19.9688 buffers:1342 bytes:6183936 events:0 [23:31] <taaz> : (raw) total: buf/s:67.2048 B/s:309680 e/s:0 B/buf:4608 [23:31] <taaz> : (raw) last: s:0.55719 buffers:1342 bytes:6183936 events:0 [23:31] <taaz> : (raw) last: buf/s:39.4838 B/s:181942 e/s:0 B/buf:4608 [23:31] <taaz> isn't that neat? [23:32] <omega> cool [23:32] <wtay> nice [23:32] <omega> that required mods to -launch ? [23:32] <Zeenix> omega: sent [23:32] <taaz> no [23:32] <omega> what's the [mp3] then? [23:32] <taaz> [] is in there already to name elements [23:32] <wtay> [] is an element name IIRC [23:32] <omega> oh [23:32] <wtay> arguably not needed btw [23:32] <omega> a space is allowed before it? [23:32] <taaz> that's why i asked about the GstObject name property yesterday. [23:32] <wtay> name=mp3 would work too actually [23:33] <omega> wtay: do we have that property? [23:33] <taaz> wtay: i dont think name is exposed as a property yet [23:33] <wtay> hmm.. no.. [23:33] <wtay> it should [23:33] <taaz> could/should be [23:33] <wtay> should be [23:33] <omega> should be in gstobject.c [23:33] <wtay> yes [23:34] <omega> taaz: you can add that in a couple minutes, while we figure out events <g> [23:34] <taaz> so anyway, this stats thing can print or send an 'update' signal on buffer/byte/event count thresholds... it's good for timing a 'dd' test too... gstreamer is actually not too bad as far as a dd replacement goes ;) [23:35] <wtay> omega: so, how should the default handler know about the _push? [23:35] <omega> wtay: we've gotta have several default handlers ;-( [23:35] <wtay> omega: yup.. unfortunatly.. [23:35] <omega> taaz: no, especially once we have a filesink written the same way as filesrc, with bufferpools and such [23:36] <omega> wtay: my GstDiskFormatCache idea has to be retought somewhat in light of the filesrc, esp with the possibility of writable buffers coming from filesrc.... [23:37] <omega> also, has anyone done a docs build recently that can be put on the website as a snapshot? [23:38] <wtay> I have [23:38] <taaz> they build now?! [23:38] <wtay> I'll put them online soon [23:38] <wtay> taaz: they always did [23:38] <taaz> haha [23:38] <wtay> on my PC :) [23:38] <wtay> which is simply debian unstable so... [23:39] <wtay> oh right.. you need one obscure .deb not in unstable.. [23:39] <taaz> the only reason i haven't updated the debs on the site is because i spend crazy amounts of time trying to fix docs to build at all [23:40] <taaz> and i just give up and curse at those voodoo makefiles [23:40] <wtay> make html is all you need [23:40] <wtay> s/you/I/g :) [23:40] <Zeenix> omega: so are you allowing the "rate" in the osssrc/sink to start from 4 or 5000 instead of 8000 ? [23:40] <taaz> ok, i'll try again soon [23:41] <omega> the lower limit is set by the OSS API, which I think is actually 8KHz [23:41] <wtay> omega: actually 1 API for a default handler is enough [23:41] <taaz> wtay: it's unacceptable to require any debs not in the deb arcives though :( autobuilders need to be able to build this thing at some point [23:42] <Zeenix> the osss goes to 4000 on my sys if asked too [23:42] <Zeenix> s/too/to [23:42] <omega> ok, then the caps should be changed [23:42] <wtay> taaz: gnome-doc-tools_1.0-1_all.deb [23:43] <wtay> Zeenix: you can chenge them, ther are arbitrarily choosen [23:43] <Zeenix> omega: yes & if the sound card doesnt support it, it would fall to the nearest match [23:43] <wtay> omega: ..since the only time you're going to call the default handler is for downstream events [23:44] <omega> hmm, ok [23:44] <wtay> omega: for upstream events you simply return FALSE in the handler [23:44] <omega> well, so there are two general classes of problems afaict: single dest pad, and multi dest pad [23:44] <Zeenix> wtay: check inbox plz [23:45] <wtay> omega: just loop over the pads and send the event on all of them [23:45] <omega> ok, so how does the default handler do that? does the plugin loop over them all? [23:45] <wtay> omega: in case of EOS, change the elements state [23:46] <wtay> omega: the default handler gets the pads of the plugin and loops over them.. [23:46] <omega> ok [23:46] <omega> ok, so let's make a list of where event handling needs to be added in the core... [23:46] <wtay> so, there are two default handlers internally, [23:47] <wtay> omega: look at gstpad.c:1987 [23:47] <omega> gboolean [23:47] <wtay> Zeenix: can I add this to cvs soon? [23:48] <omega> ok [23:48] <wtay> that is the upstream handler [23:48] <omega> ok, so *pad is a srcpad? [23:49] <wtay> it calls the event handler of the plugin if it has one and triggers the default upstream handler if the handler returns FALSE [23:49] <wtay> omega: yes [23:49] <wtay> omega: for now it is [23:49] <Zeenix> wtay: hmm..., lets hope it will work when i build it tommorow [23:50] <wtay> omega: then there is something like a default handler on line 1963 [23:51] <omega> right [23:52] <Zeenix> wtay: but i dont know what should i do with the rate, i wanted to make it an object var. in GstRtpRecv like port & mtu, but i think it doesnt fit there [23:52] <wtay> Zeenix: it's ok, I think [23:53] <wtay> omega: test/events/seek.c is an example of and app sending a seek event [23:54] <Zeenix> omega: i saw that RoboCar for which i'll be coding for, it seemed so primitive, wheels were made of wood [23:55] <omega> heh [23:55] Action: wtay wants guppi 0.40 [23:56] Action: Zeenix announces RH Linux 7.2 incase anybody doesnt know that already [23:56] <omega> well, apparently ximian and enigma (rh72) are quite incompatible right now, so I'll be waiting until that sorts out [23:58] <wtay> omega: gst_pad_event_default should remain static and be renamed to _event_default_upstream or something. Then gst_element_event_default should handle the downstream events [00:00] --- Wed Oct 24 2001 [00:02] <omega> so, I'm gonna make a table of what we need to do [00:02] <Zeenix> wtay: had a look at the code ? [00:03] <wtay> Zeenix: I'll do that tomorrow I you don't mind [00:03] <wtay> I need sleep soon [00:03] Action: wtay is very tired [00:03] <omega> I'll see if I can write this up before you sleep [00:04] <wtay> ok. I'm going to prepare myself... [00:04] <Zeenix> wtay: no i dont, you need a mind to mind anything <g> [00:04] Action: vishnu volunteers to sleep for wtay so wtay can stay up longer [00:04] <ChiefHighwater> hehe [00:05] <Zeenix> vishnu: plz do that for me too [00:05] <vishnu> :-) [00:05] <omega> if that were possible, we'd have sleep farms all over the place. would be nice [00:06] <taaz> job title: "senior sleeper engineer" [00:07] <Zeenix> taaz: wtay fits for this job, he could then code all the night long [00:08] <wtay> I'm willing to buy 4 hours of good quality sleep :) [00:08] <wtay> $10/hour [00:09] <vishnu> no thanks, i'll do it for free ;-) [00:09] <omega> wtay: so in a chained element, if it handles events, how do we go about forwarding events? do we want a generic forwarder? [00:10] <wtay> omega: yes [00:10] <omega> or if it handles EOS, it should have the code for sending the event on in each event case? [00:10] <taaz> ok, sorry to ask a rtfm question: what should i look at to acquire a clue about this new event system? [00:10] <taaz> how do you have a generic forwarder? [00:11] <vishnu> taaz: plugins/mpeg2/parse/mpeg2parse.c has fairly extensive event support [00:11] <taaz> does that just default to taking any event on input and forwarding to all output pads? [00:11] <wtay> taaz: yes, basically [00:11] <wtay> taaz: but it also "handles" it, like doing stuff with an EOS event [00:11] <omega> wtay: that's not what I mean.. [00:11] <taaz> maybe that should be done for caps too... ie, so no need for that sort of code in identity element [00:11] <wtay> omega: ? [00:12] <omega> for events that have been explicitly handled, do we want a function that can be called that handles sending the events on to all src pads? [00:12] <omega> or just have the element do that [00:12] <wtay> omega: oh, ok if the events handler of the element doesn't return FALSE we do nothing [00:13] <omega> wait... in the chain function [00:13] <wtay> omega: else we perform everything we would do when the element didn't have a handler [00:13] <wtay> omega: oh, right.. [00:13] <wtay> omega: but that's the same thing as with a loop based element [00:13] <omega> right [00:13] <omega> Incoming events: Need a flag to say whether an element can handle events. If flag is set, the event [00:13] <omega> pointer get passed to the chain function. If not, the scheduler has to insert a handler that can deal [00:13] <omega> with events. [00:14] <omega> for chained elements, downstream events [00:14] <wtay> yes [00:14] <wtay> the scheduler should do a IS_EVENT probably.. [00:14] Shippou (no...@ot...) joined #gstreamer. [00:15] <omega> so this isn't a handler, it's *in* the chain function [00:15] <omega> because the chain function is passed an event instead of a buffer [00:15] <wtay> yes, downstream event s don't have a handler [00:15] <wtay> s/have/require/ [00:16] mef (ma...@us...) joined #gstreamer. [00:17] <omega> yo [00:17] <wtay> but that requires an IS_EVENT check on every push :( [00:17] <mef> howzit [00:17] <wtay> hi [00:17] wingo-sleep (wi...@rd...) left irc: Ping timeout for wingo-sleep[rdu25-21-076.nc.rr.com] [00:17] <omega> wtay: right ;-( [00:17] <taaz> wtay: so? [00:17] <taaz> isn't the element going to have to do that anyway? [00:17] <mef> well... I have not made any progress on getting gstreamer to compile on my win/me laptop. [00:18] <mef> Still need to fix pkgconfig to compile using the version of cygwin I have. [00:18] Action: omega runs to find a gun with which to put mef's laptop out of its misery [00:18] <taaz> from a user standpoint (ignoring underlying impl for the moment) it would seem like you would want the following: [00:18] <omega> or a win2k or win98 disc... [00:18] <mef> Who else has attempted to get gstreamer to work under cygwin? [00:18] <omega> no one afaik [00:18] <mef> ok [00:18] <taaz> for chain elements: the normal buffer handling code we have now [00:18] <vishnu> met: what a waste of time, imho [00:18] <mef> I'll keep trying. [00:18] <taaz> plus event callbacks as well [00:19] <taaz> that way a buffer handling function could handle buffers [00:19] <mef> I know where to look to get directX based audio and video. So I am hoping to get the core compiled on windows on cygwin and then get a simple example to work. [00:19] <taaz> and event callback function(s) could handle specific events [00:19] wingo-sleep (wi...@rd...) joined #gstreamer. [00:19] <taaz> get rid of the case statements in the element code [00:19] Nick change: vishnu -> vishnu-sleep [00:20] <wtay> taaz: we discussed that and decided not to do that.. [00:20] <taaz> which would allow elemnts to easily have default implementations [00:20] <taaz> this doesnt work for loops i think [00:21] <taaz> wtay: ok, but it seems likeyou are just hacking around doing this and just making things harder for the elements and maybe saving a few checks here and there [00:21] <taaz> sorry, i really dont quite understand all this yet [00:21] <wtay> taaz: I don't think we can avoid checks anyway [00:21] <mef> On a completely different note: anyone have an idea whether gstreamer could work on EL/IX based systems -- like eCos? [00:21] <omega> possibly [00:21] <wtay> taaz: you either split buffers and events in the scheduler or in the plugin, the check is the same [00:21] <omega> if it's POSIX-ish, very likely [00:22] <taaz> wtay: exactly, so why not keep the checks in just one place rather than in every plugin? [00:22] <omega> there's a point to that, but... [00:22] <mef> ok... something worth looking into. [00:22] <omega> the problem is that in many cases the events must be handled inline with buffers [00:23] <wtay> right.. [00:23] <omega> and to do that with a separate chain/loop and event handler means lots of element-specific issues to sync between then *anyway* [00:23] <taaz> omega: that's certainly the case for loops... but chain elemetns are serialized right? [00:23] <mef> Equator's MAP-CA doesn't run Linux. They are trying to port Linux to it, but I think it might be better of if they worked on getting eCos to work on it. [00:23] <omega> heh [00:23] <wtay> taaz: right.. [00:24] Action: omega needs to spend some time dreaming up better solutions to these problems, like making the whole scheduling system event (!gstevent) driven [00:24] <taaz> know what i would do? [00:25] <taaz> eh, something like what omega is probably thinking i guess ;) [00:25] <wtay> it would unify the upstream and downstream event handler though... [00:25] <omega> wtay: for chained elements, possibly [00:25] <mef> omega: have you read about Eddie Kohler's "click modular router". [00:25] <taaz> you could have a default 'chain' handler for 'events' [00:26] <omega> mef: nope, reference? [00:26] <taaz> GstBuffers would just be a event subclass [00:26] <omega> taaz: right [00:26] <mef> http://www.pdos.lcs.mit.edu/click/ [00:26] <omega> event subclass is quite heavy [00:26] <taaz> and you put the case statement thing in the default handler [00:26] <omega> we already subclass GstData [00:26] <taaz> which for chained elements would do the dispatch to various callbacks based on type [00:26] <omega> for both events and buffers [00:27] <mef> It is primarily for building IP router like things, but there may be some ideas that will apply to gstreamer. [00:27] <omega> yeah, I'll have to read through it [00:27] <taaz> so chain element could override the default handler for custom needs, else it would be straightforward to have defaults for everthing and just override the events (including buffer handling) you need [00:27] <mef> Worth reading his TOCS paper and his dissertation on the topic. [00:27] <omega> first glance it looks quite similarly architected [00:28] <taaz> omega: define 'heavy'? like with experimental numbers ;) [00:28] <omega> wow. ok, everyone go read through that click reference [00:28] Action: Zeenix wont be able to sleep untill he see's his code doing 'physical' work [00:28] <taaz> in any case, from an OOP point of view this casting of GstBuffer to an event type is wrong [00:28] <omega> taaz: heavy as in memory [00:28] <omega> taaz: both are subclasses if GstData [00:29] <omega> we're calling it GstBuffer still because it's a typing convenience [00:29] <omega> as in, not having to add 20KB of code to cast everything around [00:29] <taaz> omega: with all due respect, that's total crap way to code [00:29] <mef> What is nice about "Click" is that they nicely defined a push and pull model. Mind you that i have not worked with gstreamer and don't know whether you have defined the same things. But heck... engineering is not about re-inventing the wheel but making it rounder. :) [00:29] <omega> taaz: you try adding GST_BUFFER(data) in every single place that needs it [00:29] <omega> and see what the code looks like then [00:30] <taaz> if you forget to check if it's an event or not, and assume a buffer, you can segfault [00:30] <omega> mef: yeah, it looks quite similar so far, I'll have to read what they do for their dataflow model [00:30] <taaz> if you get in a GstBuffer* you should reasonable be able to expect its a buffer. [00:30] <mef> glad to be of some help... [00:30] <omega> but their quick pipeline description language is quite similar to gst's [00:30] <mef> They have some neat optimizations that you might want to read into. [00:30] <omega> yeah [00:31] <mef> well... I better get back to working on my dissertation defense slides... god I can't wait to be done with that! [00:31] <omega> heh [00:31] <mef> cia [00:31] <mef> ciao [00:32] <omega> l8r [00:32] mef (ma...@us...) left #gstreamer. [00:32] <BBB-zZz> hmm..... [00:33] Action: BBB-zZz hasn't talked all day [00:33] <BBB-zZz> that's bad [00:33] <wtay> taaz has a point [00:33] <taaz> anyway, this is one reason i wrote that lat tests and now stats element. so we can test performance of new design ideas [00:33] <omega> yes, I agree that it's nasty, but passing GstData* around and casting it all the time is nastier. I know, I tried to do it [00:34] <wtay> the problem is solved with two handlers [00:34] <omega> for chained elements, yes [00:34] <taaz> i really have no basis to determine if any of this stuff makes any noticable difference in the end [00:34] <taaz> wtay: for chained elements you could actually have different handlers for each event too [00:35] <wtay> taaz: I don't like that idea [00:35] <omega> many more pointers, but no performance difference, and harder to code [00:35] <omega> more functions to write [00:35] <wtay> taaz: it doesn't scale too well and you need much more pointers [00:35] <omega> switch has to be done somewhere, might was well consolidate it into the event handler [00:36] <taaz> ok, well a convienience func/struct could be setup to do that anyway [00:36] <taaz> or inconvienience depending on your viewpoint [00:36] <wtay> I still prefer a switch in the plugin [00:37] <taaz> we can do both [00:38] <omega> there's no reason to do both [00:38] <wtay> or maybe I could live with a callback that takes the individual event fields appart and send them as arg to the callback [00:39] <wtay> if there is no registered callback it gives the raw event and you can still do the switch [00:39] <wtay> bleagh [00:39] <taaz> maybe i'll whip up a python prototype [00:39] <taaz> just to compare design ideas [00:40] <wtay> great, I'll learn python then to understand it :) [00:41] <taaz> course, pythons lack of switch statement will make it look odd... [00:41] <wtay> taaz: if..else if..else if...else if... else.. :) [00:41] <taaz> yeah i know [00:41] <taaz> there's a school of thought that OO programs have no need for switch statements [00:42] <wtay> the point of a switch is that the compiler does a binary search on the values.. [00:42] <taaz> can all be done, and be mucho more flexable, with polymorphism [00:42] <taaz> but this is low level stuff so ... [00:43] <Zeenix> i'll be right back soon [00:43] <omega> wtay: docs snapshot before you sleep? [00:43] Zeenix (ze...@13...) left #gstreamer. [00:43] <wtay> omega: tomorrow.. I'm off to bed now [00:43] <wtay> cya [00:43] <omega> bleagh [00:43] <omega> ok [00:43] Nick change: wtay -> wtay-zZz [00:43] <taaz> yeah yeah... python prototype. i'll dothat so we can maybe talk about this in some sane way [00:43] <omega> ok [00:43] <omega> I'm gonna go read the click stuff [00:50] ChiefHighwater (pa...@te...) left irc: [00:54] arik (arik@168.191.238.91) joined #gstreamer. [00:54] <arik> hi all [00:54] <ajmitch> hey arik [00:54] <arik> hey aj [00:56] sienap (sy...@s3...) joined #gstreamer. [00:56] <sienap> hoi [01:07] Zeenix (ze...@13...) joined #gstreamer. [01:07] <Zeenix> yo again [01:07] <arik> yo [01:08] <Zeenix> so should i assume that no one minds a frequency or rate var. in RtpRecv ? [01:09] <Zeenix> & a property installed for it like port & mtu [01:12] <omega> Zeenix: it should come from the caps that are negotiated with its peer element [01:12] <arik> omega: howdy [01:12] <omega> yo [01:12] <arik> i got the second phone line [01:12] <arik> finally [01:13] <omega> heh [01:14] <sienap> yo zeenix! [01:14] <arik> omega: time to start thinking about a picogui videosink [01:15] <Zeenix> omega: it doesnt seems possible ATM [01:15] <sienap> we didn't have any phone bills for around 10 months.. .. friday one came in and they calculated the other months from the current cost [01:15] <sienap> that is around 7k guilders (being something like 3k dollars) [01:15] <sienap> aka i am fucked[tm] [01:16] <omega> Zeenix: it's definitely possible. when you get new caps, you query the caps for the rate, and set that as the rate of the rtp channel [01:16] <sienap> .. some reaction ? [01:16] <omega> arik: what kind of video output support is in picogui? [01:16] <arik> omega: i'm not sure yet, i was gonna start looking today [01:16] <omega> sienap: you should be able to work out a payment plan, because it's their screwup [01:17] <Zeenix> omega: no rate on the rtpchannel [01:17] <sienap> omega for sure.. but i am still not sure how they came up with that 5k [01:17] <sienap> it is pretty obvious calculated [01:17] <Zeenix> omega: otherwise i would have done like that [01:17] <sienap> since they can't give any specifications [01:17] <omega> Zeenix: then why does the rate matter? [01:17] <Zeenix> omega: it matters for my app <g> [01:18] <sienap> anyway [01:18] <sienap> i am off [01:18] <sienap> bye :) [01:18] sienap (sy...@s3...) left #gstreamer. [01:18] <omega> Zeenix: your app should be able to query the caps of the rtpsend and get it [01:19] <... [truncated message content] |