From: IRC B. <wt...@us...> - 2002-03-17 05:30:37
|
******************************************************************* [03:01] <rehan> hello? [03:03] Nick change: wtay-tv -> wtay [03:03] <wtay> rehan: for a dynaic pad you should listen to the new_pad signal [03:03] <rehan> is that what the mpegdemux will do? [03:03] <wtay> rehan: yes [03:03] <wtay> rehan: testing it with gst-launch might be easier.. [03:05] <rehan> it fails to connect the pads [03:05] <wtay> something like: gst-launch filesrc location=/dfff/ff ! mpegdemux video_00! { queue ! dxr3sink } [03:05] <rehan> oh - is it video_00? and i did't know that you had to add the pad name to the gst-launch options [03:06] <wtay> rehan: yeah, launch will look for the dynamich video_00 pad on mpegdemux and will use it to connect mpegdemux and the queue [03:07] <rehan> wow! it's running :))) [03:07] <wtay> rehan: yay! [03:07] <wtay> rehan: does it work? [03:07] <rehan> i'm off downstairs now to see if it's actually running the video properly [03:07] <wtay> heh [03:08] Action: wtay is compiling gargnome [03:14] <rehan> doesn't work - but it works when i do gst-launch filesrc location=1.m1v ! dxr3video [03:14] <rehan> ie i'm piping just the mpeg video stream to the dxr3video sink [03:14] <wtay> is that a multiplexed stream? [03:14] <rehan> the audio works by itself as well, but i'm trying to find a quick way to test them both together [03:15] <rehan> 1.m1v is just a video stream (i demuxed it with another program) [03:15] <wtay> uhm [03:15] <rehan> i'll look into the signal thing [03:16] <rehan> thanks [03:16] <wtay> np [03:25] Action: wtay needs sleep, cya [03:25] Nick change: wtay -> wtay-zZz [03:26] Company (Company@pD900416E.dip.t-dialin.net) left irc: Remote closed the connection [03:31] fuguy (~ha...@fd...) joined #gstreamer. [03:35] <fuguy> achoooo! [03:40] fuguy (ha...@fd...) left irc: "[x]chat" [03:41] fuguy (~ha...@fd...) joined #gstreamer. [03:52] polytarp (~ph...@d1...) joined #gstreamer. [04:04] rowenc (~rowenc@Hong-231-192.PLU.edu) joined #gstreamer. [04:05] polytarp (~ph...@d1...) left #gstreamer ("Client Exiting"). [04:06] foxdragonx (~fox@216.194.26.216) joined #gstreamer. [04:13] <fuguy> achoo! [04:13] billh (bi...@ws...) left irc: Remote closed the connection [04:13] <RagingMind> rehan: dxr3? I just finnished a movie, too bad I didn't wait a few(?) more days ;) [04:13] <RagingMind> fuguy: gazoontite [04:14] billh (bi...@ws...) joined #gstreamer. [04:15] <rehan> it works, i think. i'm struggling with the other parts of gstreamer that i don't understand at the moment [04:15] <RagingMind> I'm not a programer, but I think I have the basics of -launch down :) [04:16] <RagingMind> actually I'm pretty sure about the basics, its the more advanced stuff I don't know... [04:17] <RagingMind> I'd be happy to test [04:18] <rehan> shall i email it to you or something? [04:19] <RagingMind> brb (30min) [04:31] rowenc (rowenc@Hong-231-192.PLU.edu) left irc: "Client Exiting" [04:59] chillywilly_ (~da...@d2...) joined #gstreamer. [05:01] fuguy (ha...@fd...) left irc: "[x]chat" [05:06] <RagingMind> back [05:15] chillywilly (da...@d1...) left irc: Read error: 113 (No route to host) [05:51] dap (dap@SR3745.resnet.ucsb.edu) left irc: Read error: 104 (Connection reset by peer) [05:51] dap (~dap@SR3745.resnet.ucsb.edu) joined #gstreamer. [05:54] foxdragonx (~fox@216.194.26.216) left #gstreamer. [06:04] <rehan> aha - i have to go mpegparse->mpegdemux->queue->dxr3video :) [06:29] RagingMind (Rag...@fl...) left irc: "Client Exiting" [07:01] _gst_newt_ joined #gstreamer. [07:02] apoc-zZz (ap...@dy...) got netsplit. [07:02] Nick change: chillywilly_ -> chillywilly [07:08] apoc-zZz (~ap...@dy...) got lost in the net-split. [07:09] artm (ar...@ne...) left irc: Read error: 110 (Connection timed out) [07:13] apoc-zZz (~ap...@dy...) joined #gstreamer. [07:13] artm (ar...@ne...) joined #gstreamer. [07:23] chillywilly (da...@d2...) left irc: Remote closed the connection [07:23] chillywilly (~da...@d2...) joined #gstreamer. [07:44] rehan (ro...@12...) left irc: Remote closed the connection [07:52] rehan (~ro...@12...) joined #gstreamer. [08:08] billh (bi...@ws...) left irc: Remote closed the connection [08:09] billh (bi...@ws...) joined #gstreamer. [08:28] billh (bi...@ws...) left irc: Remote closed the connection [08:28] billh (bi...@ws...) joined #gstreamer. [08:43] billh (bi...@ws...) left irc: Remote closed the connection [08:44] billh (bi...@ws...) joined #gstreamer. [08:44] billh (bi...@ws...) left irc: Remote closed the connection [08:44] billh (bi...@ws...) joined #gstreamer. [08:51] rehan (ro...@12...) left irc: "using sirc version 2.211+KSIRC/1.1" [08:53] billh (bi...@ws...) left irc: Remote closed the connection [08:54] billh (bi...@ws...) joined #gstreamer. [09:33] walken (fo...@12...) joined #gstreamer. [10:22] billh (bi...@ws...) left irc: Read error: 110 (Connection timed out) [10:32] billh (bi...@ws...) joined #gstreamer. [10:39] steveb (~st...@no...) joined #gstreamer. [10:54] steveb (st...@no...) left irc: "new kernel" [10:55] apoc-zZz (ap...@dy...) left irc: "Client Exiting" [10:56] steveb (~st...@no...) joined #gstreamer. [11:48] omega (om...@om...) left irc: "zzzzzz" [11:54] montz (~mo...@ad...) joined #gstreamer. [11:55] montz (mo...@ad...) left irc: "Client Exiting" [11:59] montz (~montz@213.219.74.241) joined #gstreamer. [12:15] dap (dap@SR3745.resnet.ucsb.edu) left irc: Read error: 110 (Connection timed out) [12:15] billh (bi...@ws...) left irc: Remote closed the connection [13:01] chillywilly_ (~da...@d1...) joined #gstreamer. [13:16] montz (montz@213.219.74.241) left irc: Remote closed the connection [13:18] chillywilly (da...@d2...) left irc: Read error: 113 (No route to host) [13:31] Company (~Company@pD9500501.dip.t-dialin.net) joined #gstreamer. [13:31] <Company> hi all [13:33] <thomasvs> hey company [13:41] richardb (~ri...@pc...) joined #gstreamer. [13:41] richardb (ri...@pc...) left irc: Client Quit [13:41] richardb (~ri...@pc...) joined #gstreamer. [15:10] Nick change: chillywilly_ -> chillywilly [15:31] RagingMind (~Rag...@fl...) joined #gstreamer. [16:12] apoc_ (~ap...@dy...) joined #gstreamer. [16:13] apoc_ (ap...@dy...) left irc: Client Quit [16:23] apoc_ (~ap...@dy...) joined #gstreamer. [16:25] <RagingMind> is dvdsrc broaken? [16:28] <RagingMind> well... [16:28] <RagingMind> RagingMind@Mut:~$ gst-inspect | grep dvd [16:28] <RagingMind> INFO (27082: 0) Initializing GStreamer Core Library [16:28] <RagingMind> INFO (27082: 0) CPU features: (808029bf) MMX 3DNOW [16:28] <RagingMind> dvdsrc: dvdsrc: DVD Source [16:29] <RagingMind> for when someone comes around to see... [16:29] <RagingMind> RagingMind@Mut:~$ gst-inspect dvdsrc [16:29] <RagingMind> INFO (27092: 0) Initializing GStreamer Core Library [16:29] <RagingMind> INFO (27092: 0) CPU features: (808029bf) MMX 3DNOW [16:29] <RagingMind> couldn't construct element for some reason [16:30] <apoc_> RagingMind : gst-inspect dvdsrc works here [16:30] <RagingMind> "gst-launch dvdsrc" is what I'm actually after... [16:31] <RagingMind> well I have to go. Could someone ask again later? (Please) [16:31] RagingMind (Rag...@fl...) left irc: "Client Exiting" [16:44] Action: BBB|zZz is away: having fun @ concerts [16:44] Nick change: BBB|zZz -> BBB|SystemofaDown [17:12] Action: chillywilly is away: I'm busy [17:13] <apoc_> BBB : around ? [17:36] foxdragonx (~fo...@as...) joined #gstreamer. [17:38] <apoc_> yo [18:00] foxdragonx (fo...@as...) left irc: "Download Gaim [http://gaim.sourceforge.net/]" [18:44] <Procule> Does someone know if there is a autoconf macro to check for ImageMagick ? [18:46] <apoc_> Procule : dunno but there is a Magick-config file [18:48] <Procule> I really don't know how to make those macro scripts :/ I took a lot of times to just add GTK+ and gdk-pixbuf checks [18:51] <apoc_> Procule : I can't help you ... ask thomasvs ... He's the man you're looking for ;) [18:53] <Procule> hehe thanks, I'll code the program before make the installation [18:55] <apoc_> Procule : what are you coding ? [18:55] <Procule> I've started my webcam project [18:56] <Procule> http://powa.sytes.net [18:56] <Procule> I've just made the video stream working [18:56] <Procule> but it runs nice :-) [18:57] <apoc_> Procule : I remember you don't use gstreamer ;) ? [18:58] <Procule> no I don't use it [18:58] <apoc_> hmm nice picture on the web site ;) [18:59] <Procule> hehhe yes [19:00] <Procule> I'll use imagemagick to save and modify the pictures, it does exactly what I want [19:04] apoc_ (ap...@dy...) got netsplit. [19:05] apoc_ (~ap...@dy...) returned to #gstreamer. [19:52] Ridcully (~as...@p5...) joined #gstreamer. [20:08] Action: chillywilly is back (gone 02:56:18) [20:23] dap (~dap@SR3745.resnet.ucsb.edu) joined #gstreamer. [20:25] Nick change: apoc_ -> apoc-away [20:25] rehan (~ro...@12...) joined #gstreamer. [20:52] RagingMind (~Rag...@fl...) joined #gstreamer. [20:53] <RagingMind> yllo all [20:58] <Procule> what does "dereferencing pointer to incomplete type" really mean ? [21:00] <Procule> aaaah I wasn't using the right structure.. [21:02] chillywilly (da...@d1...) left irc: Read error: 104 (Connection reset by peer) [21:03] chillywilly (~da...@d1...) joined #gstreamer. [21:04] <RagingMind> hi rehan, any progress? (it wouldn't compile for me) :( [21:13] RagingMind (Rag...@fl...) left irc: Remote closed the connection [21:14] RagingMind (~RagingMin@204.212.125.186) joined #gstreamer. [21:30] mattias (ma...@ga...) got netsplit. [21:36] mattias (~ma...@ga...) got lost in the net-split. [21:36] mattias (~ma...@ga...) joined #gstreamer. [21:36] rehan2 (~reh...@12...) joined #gstreamer. [21:36] rehan2 (~reh...@12...) left #gstreamer. [21:57] mattias (ma...@ga...) got netsplit. [22:03] mattias (~ma...@ga...) got lost in the net-split. [22:09] mattias (~ma...@ga...) joined #gstreamer. [22:23] <ds> ! [22:23] <Company> ? [22:26] <steveb> ~ [22:37] rehan2 (~reh...@12...) joined #gstreamer. [22:37] rehan2 (~reh...@12...) left #gstreamer. [23:00] billh (bi...@ws...) joined #gstreamer. [23:09] steveb (st...@no...) left irc: "l8er" [23:16] mattias (ma...@ga...) left irc: Read error: 110 (Connection timed out) [23:31] Uraeus (~csc...@c1...) joined #gstreamer. [23:31] <Uraeus> evening [23:33] ds (ds...@12...) left irc: "galeon printed 2 GB to .xsession-errors, and I need to restart X to delete it" [23:33] <Uraeus> Company: how is the new event system coming along? [23:35] ds (~ds...@12...) joined #gstreamer. [23:35] <Uraeus> hi ds [23:37] <Company> Uraeus: it's humming along nicely [23:37] <Company> Uraeus: but I want someone (read: wtay or omega) to review the changes to be sure I'm not doing really stupid stuff :) [23:38] <Uraeus> Company: darn, and I who was just planing to volunteer to review myself :) [23:38] <Company> Uraeus: do it :) [23:38] <thomasvs> Company: I'm checking out the branch, where should I start to check out what you did ? [23:38] <thomasvs> what's a good first taste ? [23:39] <Company> thomasvs: currently only mad and osssink do work [23:39] Action: Uraeus just saw 'A Beautiful Mind' at the cinema a really facinating movie [23:39] <thomasvs> twisting reality a bit though [23:40] <thomasvs> least that's what I read [23:40] <Company> thomasvs: and the core should work. So just code reviewing works perfectly well :) [23:41] <Uraeus> it is but I think they have stayed closed to the truth where it really matters, but they don't claim to be a documentary either [23:45] <Uraeus> thomasvs: guess I found the movie extra fascinating due to the fact that the last exam that I missed to get my degree, that it took me 5 years after graduation to actually do, had nash equilibrium as one of its core topics :) [23:46] <thomasvs> Uraeus: heh, funny ;) [23:46] Action: thomasvs tries to clean up his 6 GB overflowing home dir again [23:48] ds-irssi (~ds...@12...) joined #gstreamer. [23:48] Action: ds-irssi tries out a new irc client [23:50] <rehan> hi [23:50] <rehan> it plays my mpeg1 program stream fine now [23:51] <rehan> someone on the dxr3 irc channel told me that i don't need an audio sink cos the oss one should work [23:51] <rehan> however, it doens't for me [23:51] <rehan> i guess i'll clean it up today and then mail it to whoever i'm supposed to mail it to [23:52] RagingMind (RagingMin@204.212.125.186) left irc: Read error: 113 (No route to host) [23:52] <rehan> does anyone know who that is? how do i get a new plugin into the cvs? [23:53] <taaz> gstreamer-devel list a good start [23:54] <rehan> i found the sync works MUCH better than mplayer, although i haven't tried pausing and restarting yet [23:54] <rehan> that's when it really goes bad with mplayer [23:55] Nick change: ds -> ds-bitchx [23:55] Nick change: ds-irssi -> ds [23:57] Uraeus (csc...@c1...) left irc: "Client Exiting" [23:59] ds-bitchx (ds...@12...) left irc: "[BX] They killed Kenny! THOSE BASTARDS!" [00:00] --- Sun Mar 17 2002 [00:02] rehan (ro...@12...) left irc: "using sirc version 2.211+KSIRC/1.1" [00:02] rehan (~ro...@12...) joined #gstreamer. [00:03] ds (ds...@12...) left irc: "leaving" [00:03] ds (~ds...@12...) joined #gstreamer. [00:05] erc (~er...@66...) joined #gstreamer. [00:10] ds (~ds...@12...) left #gstreamer. [00:11] ds (~ds...@12...) joined #gstreamer. [00:32] RagingMind (~RagingMin@204.212.125.65) joined #gstreamer. [00:35] <Company> wtay, GET UP [00:36] Action: Company throws tomatoes [00:36] <erc> can someone help me get started? [00:37] <ds> anyone have jumper cables for erc? [00:37] <Ridcully> is some gstreamer dev on the cebit? [00:38] Action: taaz hands erc a shot: liquor than beer, never fear... [00:39] <erc> what's the first thing i should do after compiling and installing? should gst-register work? [00:39] <Company> Ridcully: I don't think so - but I'm closest to it I guess ;) [00:39] <Company> erc: yes, you should call gst-register [00:39] <taaz> ds: man i suck so much. i'm sorry i haven't gotten that deb stuff in cvs yet. i'm just finishing up stuff i've been swamped with all week so i think i'll be able to work on the debs tonight [00:40] <Company> erc: that will register all available plugins [00:40] <ds> taaz: no problem. [00:41] <Company> erc: you might want to try some stuff from tools/README to get into gst-launch [00:42] <erc> ok, hmmm, assertion failing in gst-register... have to check this out... [00:42] <RagingMind> taaz: life. we understand [00:46] Nick change: Ridcully -> Rid-sleep [00:51] rehan (ro...@12...) left irc: "using sirc version 2.211+KSIRC/1.1" [00:52] <erc> what version of libxml should i be using? [00:52] <Company> isn'T configure checking that? [00:53] <Company> libxml2-2.something [00:54] <erc> yes, it checks for >= 2.4.0 [00:56] <Company> but if it's build it should work I think [00:56] <Company> what's the error message you get? [00:56] <erc> it won't compile with HAVE_LIBXML2 defined ... i should have that defined right? [00:56] <Company> it should, yes [01:04] <erc> ah hah, found the problem... picking up the wrong version of libxml [01:09] <erc> yay, gst-register works now [01:09] <erc> how do i run the testsuite? [01:10] <Company> make check [01:10] <Company> but the testsuite doesn't do much [01:11] <erc> thanks [01:12] <erc> well, it failed so i guess it's doing its job ;-) [01:12] <Company> heh [01:12] <erc> argh... has anyone ever run this on anything non-linux? [01:12] <Company> yes, some guys try to get it running on ppc [01:12] <erc> ppc linux? [01:13] <Company> don't know [01:13] <ds> omega has tried Solaris, I think [01:13] <ds> I use Linux/ppc almost exclusively [01:14] <erc> i would like to run it on freebsd/i386 [01:14] <Company> good luck :) [01:14] <erc> Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' [01:14] <ds> cool, if you can get all the dependencies installed [01:15] <erc> is there a way to compile it without pthreads? (the pthreads library is calling the abort) [01:15] <ds> erc: try running the cothreads tests (in the cothreads directory). If that fails, yell at wingo [01:15] <erc> that's the one: FAIL: cothreads-gthreads [01:17] <Company> erc: it might be a little difficult to get it working on non-linux because noone tried it in a long time [01:17] sweeze (~jba...@sw...) joined #gstreamer. [01:18] <Company> erc: but you would be a great help if you get it running and send patches [01:18] <erc> hmmm... i would like to but i need to understand the threading model a bit better. [01:19] <Company> erc: I didn't do anything of the threading stuff, it was done by wingo [01:20] <Company> erc: the code is in gst/schedulers/* gst/cothreads.[ch] and gst/gstthreads.[ch] [01:21] <erc> and libs/ext/cothreads/cothreads [01:21] <erc> i think [01:21] <ds> erc: cothreads allegedly works on a variety of platforms. There's a good chance that it's just a cothreads configuration issue [01:21] <Company> erc: and if you use the new scheduler, there is libs/ext/cothreads/* but you probably don't use it because you use the default stuff [01:21] <ds> cothreads is autoconfigured, btw [01:22] <ds> Company: basicsched still uses the old cothreads? [01:23] <Company> ds: I thought it does [01:24] <Company> ds: we would've deleted the two gst/cothreads.[ch] files, wouldn't we? [01:25] <ds> Company: that would make sense... [01:25] <Company> ds: the two schedulers share 99% of the code, I'm pretty sure the default scheduler still uses the old code [01:26] <sweeze> sorry to be that annoying nagging user, but how are debian packages for 0.3.3 coming along? [01:27] <ds> sweeze: sssshh!! we don't talk about that while taaz is around [01:27] <ds> taaz is very busy [01:27] <sweeze> ds: i see :) at least i apologized ;-) [01:27] Action: ds is compiling Debian packages from CVS [01:28] sweeze (jba...@sw...) left irc: "Client Exiting" [01:29] <erc> okay, what kind of linux magic is SIGUSR1? [01:29] Action: taaz reaaaallyyy wants to work on debs... [01:30] <ds> erc: it's probably just a generic interthread wakeup signal [01:30] <ds> SIGUSR1 is posix [01:40] <erc> ugh... this is very non-portable [01:41] <ds> which probably explains the need for new cothreads [01:43] <Company> erc: you can try to run the with --scheduler=standard [01:43] <ds> Chris-: sed 's/ */ /g' [01:43] <ds> grr. [01:43] <erc> right now i'm trying to run make check in libs/ext/cothreads [01:44] <Company> erc: that will use the new but experimental scheduling stuff [01:44] Nick change: wtay-zZz -> wtay [01:44] <wtay> yo [01:45] <wtay> Company: looks good to me [01:45] <Company> damn, GTK is so non-threadsafe, it's not funny [01:45] <Company> wtay: I just wanted to commit the new queue :) [01:45] <wtay> Company: the only thing that troubles me is where the event is handled by the scheduler, it's in the critical path. omega should look at it [01:46] <wtay> Company: but the rest looks very nice :) [01:46] <Company> wtay: I just put it somewhere, you can easily toss it around [01:46] <Company> it should only be called often enough [01:47] <wtay> Company: it's only for upstream events I suppose.. [01:47] <Company> wtay: yes, for all ooo events [01:48] <Company> wtay: the new system easily allows adding downstream events, too [01:50] <Company> the problem now is that I'm hitting a wall [01:52] <Company> if we want to use this system, we have to update all plugins - and I don't know them very well, so I would probably mess up the rewrite [01:52] <wtay> Company: isn't it only the event handling that needs updating? [01:53] <Company> wtay: mostly - there are some changes to the buffer system and to function prototypes [01:54] <Company> wtay: you don't call gst_buffer_new() anymore - you're going to call gst_pad_new_buffer(pad, buffersize) most of the time [01:54] <wtay> Company: uhm? [01:55] <Company> the pad supplies the bufferpool that creates the buffer with the given size [01:55] <wtay> uh oh [01:55] <wtay> why is that? [01:55] <wtay> what wrong with _buffer_new? [01:56] <Company> most of the time you want to use the bufferpool, no? [01:56] <wtay> I would make that explicit [01:57] <Company> you can still call gst_buffer_new [01:57] <Company> though it's now gst_buffer_new (pool, size) where both can be NULL or 0 [01:57] <wtay> ok, so you just changed the gst_pad_get_bufferpool / gst_buffer_new_from_pool in one call [01:58] <Company> buffers now have a mandatory bufferpool btw [01:58] <wtay> Company: I want gst_buffer_new() and gst_buffer_new_something(foo, bar) [01:59] <Company> wtay: I changed it explicitly because you get compile errors this way and need to change it and do it right :) [02:00] <wtay> Company: not if gst_buffer_new() == gst_buffer_new_something (NULL, 0) [02:00] <wtay> because passing NULL and 0 looks silly IMO [02:01] <Company> well, you have to look at it which is a huge difference :) [02:02] <Company> but we can safely do a #define gst_buffer_new() gst_buffer_new_something (NULL, 0) though that would encourage using this method [02:03] <wtay> I would do it that way [02:04] <wtay> cause getting and caching/freeing/not using the bufferpool explicitly is much more flexible [02:04] <Company> it's ok with me, but we should document that gst_pad_new_buffer is the preferred way [02:05] <wtay> sure [02:06] <Company> but the buffer changes definitely need some looking into :) [02:06] <wtay> Company: are you 100% sure the memchunks are thread safe? [02:07] <Company> wtay: I tend to trust the glib team :) [02:07] <Company> they use a global lock for all chunks, just like malloc does [02:07] <wtay> Company: we need to implement our own thing.. [02:08] <Company> wtay: our own thing for what? [02:08] <wtay> memchunks.. [02:08] <Company> why? [02:08] <wtay> and make glib accept it.. [02:09] <wtay> Company: test/memchunk/gstmemchunk is around 100 times faster or so [02:10] <Company> don't use the lock, it's not needed [02:12] <wtay> hmm.. I should remove other locks around memchunks too then.. [02:13] <Company> gmemchunk + lock is slower by far than malloc [02:13] <wtay> memchunk should also help with memory fragmentation [02:16] erc (er...@66...) left irc: Read error: 104 (Connection reset by peer) [02:16] erc (~er...@66...) joined #gstreamer. [02:17] <Company> the gstmemchunk stuff is still faster by far [02:17] <wtay> it's theoretical case of course [02:17] <wtay> same thing could be done for GList [02:18] <wtay> effectively making it thread safe without those ugly locks [02:18] <Company> but it's assembler, so it's not very portable [02:19] <wtay> an optimisation for specific platforms.. similar constructs exist for other chips [02:20] <wtay> thing is that using locks in a lowlatency environment is considered evil.. [02:21] <ds> wtay: so is threading... [02:21] <wtay> ds: right, so we should make sure that when you don't use threads, no pthread function is called at all.. [02:22] <Company> we can easily use our own memchunks, that's three lines of code [02:22] Action: ds would write ppc optimizations [02:23] <wtay> Company: I did at some point, but it was not noticable in lat.c or any other app (too little buffers get allocated) [02:23] erc (er...@66...) left irc: Read error: 104 (Connection reset by peer) [02:24] <wtay> I'm not sure that libpthread doesn't do nasty things with locks even if you don't have any threads.. [02:24] <Company> wtay: I think that's the main problem - but if we used them it would at least proof that they work and would be good advertising for inclusion in glib :) [02:25] <wtay> Company: there's one thing the implementation doesn't do, and that's shrinking the mempool. It only expands [02:26] <Company> but the glib guys are more interested in portability and bugfreeness than in speed [02:26] <wtay> Company: yes (unfortunatly) [02:26] <Company> I think they have their priorities right [02:27] <Company> but I don't want to do low latency audio :) [02:29] <wtay> well, JACK uses a mutex too :) [02:30] <Company> wtay: we will get severe problems with the player if the player should use threads [02:30] <Company> because gtk+2 has not looked at multithreading very closely [02:31] <wtay> Company: use gdk_lock etc [02:32] <Company> wtay: buggy - gtk2.0 doesn't even allow opening the file dialog when you use threads in gdk [02:32] <wtay> Company: should not be a problem as we open a new socket to X in the videosink [02:32] <wtay> Company: point is that Xlib is not thread safe, so all access to the socket should be protected [02:32] <wtay> Company: as in g_assert? [02:33] <wtay> Company: nautilus uses threads.. [02:33] <Company> wtay: GtkTreeView locks a mutex twice [02:33] <wtay> that's a bug I would say.. [02:34] <Company> it is - I'm just saying that they haven't looked at it very well and it will be buggy [02:35] <wtay> hm ok [02:35] <wtay> they'll appreciate bug reports :) [02:36] <Company> 74126 [02:37] <Company> but I'm still getting async errors from Xlib - even when properly using gdk_threads_enter/leave [02:39] <wtay> bah [02:39] <wtay> Company: that's when you convert the video bin to a thread? [02:40] <Company> that's not working at all, because the video widget isn't threadsafe yet [02:40] <wtay> ok [02:40] <Company> that's when I'm putting audio into a thread and use the time information of osssink to set the slider [02:41] <wtay> Company: you did call gdk_threads_* around the gtk_main too I assume.. [02:41] <Company> wtay: I did [02:42] <wtay> no other callbacks that might update some widgets? [02:42] wingo (~cha...@ad...) joined #gstreamer. [02:42] <wingo> hey folks [02:43] <wtay> hi [02:43] <Company> nope, just that one - and that's using the gdk_threads_enter/leave [02:43] <Company> hi wingo [02:43] <wingo> hi Company [02:43] <wingo> Company: some spelling probs in your latest commit [02:43] <Company> hm? [02:43] Vakor (ms...@c1...) left irc: "Leaving." [02:43] <wingo> check GST_OFFSET_IS_INVALID [02:43] <wingo> i can mail you them if you like (no cvs right now) [02:44] <wingo> hey, ya'll aware that glib can construct the prop values for us? [02:44] <wingo> so that props can be initialized to their defaults [02:44] <wingo> no need to keep the object init in sync with the paramspec declaration that way [02:44] <Company> wingo: fixed [02:45] <wingo> cool [02:45] <wtay> wingo: ? [02:45] <wingo> imho queue's 'max-level' should be called 'size' :) [02:45] <Company> wingo: yeah, we can still change that [02:46] <Company> wingo: more important: anything with the buffer rewrite you don't like? [02:47] <wingo> wtay: http://developer.gnome.org/doc/API/2.0/gobject/gobject-gparamspec.html#GPARAMFLAGS [02:47] <wingo> see the construct flag [02:47] chillywilly (da...@d1...) left irc: [02:47] <wingo> Company: still looking at it; [02:47] <wingo> are GST_BUFFER and GST_DATA just casts ? [02:47] <wingo> without type checking i mean [02:47] <Company> yes [02:48] <wingo> but it looks really nice to me :) [02:48] <wingo> hey [02:48] <Company> but you could include some checking if you wanted to [02:48] <wingo> what is gst_pad_new_buffer about? [02:48] <Company> wingo: the preferred way to create buffers [02:48] <wingo> ok [02:48] Action: wingo will check [02:48] <Company> you call that to use the right bufferpool [02:49] <wingo> hmm [02:49] <wingo> the pad's pool? [02:49] <Company> yes [02:49] <wtay> Company: does it cache the pool in the pad? [02:49] <wingo> that is really neat [02:49] <wtay> Company: does it use the peer pad's pool? [02:49] <Company> wtay: not yet - but we should really do it [02:49] <wtay> Company: make sure to clear it on unconnect.. [02:49] <Company> at least if we wanted to use this method :) [02:50] <wingo> Company: a minor quibble, but i like spaces between functions :) [02:51] <Company> wingo: me too, but I sometimes forget them when I'm thinking [02:51] <wingo> style is easy to fix, code is harder to write ;) [02:52] <wtay> Company: you should also be carefull with gst_pad_get_buffer, what if there is no pool, will it allocate a buffer itself or can I still allocate my own buffer etc.. [02:52] <Company> wtay: currently it just uses the default pool when there is none [02:53] <wtay> Company: so if I had my own malloced data, I would have to memcpy it into the new buffer.. [02:53] <wtay> Company: whereas creating my own buffer, setting the buffer in the data field would be faster in that case [02:54] <wingo> Company: do you run the gstplay gstreamer object in a separate thread? [02:54] <Company> wtay: no, you could write your own pool (filesrc does that) [02:54] <wtay> Company: yes, but then I would not be able to use the peer's bufferpool [02:54] <Company> wingo: no [02:55] <wingo> Company: sorry to bother, but you still have INVLAID in part of the macro :-/ [02:55] <wingo> wtay: when would you want the peer's pool? [02:55] <wtay> wingo: videosink, osssink.. [02:55] <wingo> hmm [02:55] <wingo> ok [02:55] <wingo> i see :) [02:56] <wtay> I guess gst_pad_get_bufferpool would still exist.. [02:56] <Company> wtay: the pool is only interesting, if you want your data allocated - if you supply your own, you should supply your own bufferpool [02:57] <wingo> maybe more for internal use though [02:57] <Company> wingo: yes, but it should just return pad->bufferpool, which has to be set upon connection of the elements [02:57] <Company> s/elements/pads [02:57] <wingo> mmm, tv [02:57] Nick change: wingo -> wingo-tv [02:58] <wtay> Company: some libs might give a malloced buffer with data that you can just add to the buffer data field or memcpy in the buffer from the bufferpool (if any) [02:59] <wtay> Company: not sure that is the right design for a library but.. [02:59] <Company> wtay: if you have malloced data, you can use the default pool with no size - gst_buffer_new (NULL, 0) [02:59] <wtay> Company: ah, then you get a buffer with no data, ok, fine |