From: IRC <wt...@us...> - 2003-10-15 05:42:12
|
******************************************************************* [03:13] Company (~Company@pD9E33AF2.dip.t-dialin.net) joined #gstreamer. [03:13] steveb_ (~st...@21...) joined #gstreamer. [03:13] abraar (~foo@AToulouse-105-1-33-141.w81-248.abo.wanadoo.fr) joined #gstreamer. [03:16] lilo (le...@li...eenode) joined #gstreamer. [03:18] md` (ill...@md...) joined #gstreamer. [03:18] walters (wa...@ve...) joined #gstreamer. [03:18] alley_cat (All...@p5...) joined #gstreamer. [03:18] chillywilly (danielb@CPE-24-167-193-166.wi.rr.com) joined #gstreamer. [03:18] taaz (~dlehn@66.37.66.32) joined #gstreamer. [03:25] walters (wa...@ve...) left irc: "displacing" [03:51] <Company> yay [03:51] Action: Company has a function call that takes a gchar *** [03:51] <desrt> :) [03:52] <desrt> returns a gchar ** by reference? [03:53] <Company> yeah [03:54] <desrt> that's sane enough :) [03:59] <ds-work> why do we have GST_OBJECT_DESTROYED()? [04:00] Action: desrt hopes debugging(?) [04:01] <Company> ds-work: probably because we once had gst_object_destroy [04:01] Action: Company votes for "KILL IT" [04:01] <ds-work> the only usage appears to be in code that checks whether _freed_ _memory_ used to be a GstObject [04:02] <Company> ds-work: gst/gsttype.[ch] [04:02] <Company> ds-work: do we need informations about mime types? [04:03] <ds-work> Company: I've been meaning to replace that with GQuarks [04:04] <ds-work> as part of the GstCaps reqrite [04:04] <Company> ds-work: so we need no matching from mime type to extensions or something like that? [04:04] <ds-work> that may be part of the code [04:05] <Company> well, i was trying to get rid of it ;) [04:05] <ds-work> we don't use extensions currently [04:05] <ds-work> but we define them everywhere [04:05] <Company> no, but they might come in useful if you want to use gimp style saving [04:05] <ds-work> I don't know if that's wise or not [04:05] <ds-work> some of it could be useful [04:05] <Company> i'll provide them in the typefindfunctions [04:05] <ds-work> the reimplementation of GQuarks is not [04:06] <Company> i was wondering if it is useful to have functions for caps [04:06] <Company> like gst_caps_compare [04:06] <Company> per mime type [04:06] <Company> or gst_caps_select_best [04:06] <Company> or whatever [04:07] <ds-work> no [04:08] <ds-work> optimality of caps is up to the application [04:08] <ds-work> the user knows best [04:08] <Company> uhm yeah, kind of [04:08] <Company> osssrc ! osssink should use what format by default? [04:09] <ds-work> with no QoS, it should do whatever the elements randomly negotiate [04:09] Action: desrt guesses audio/raw [04:09] <Company> ok, that sounds ok [04:09] <Company> desrt: the point was _what_ audio/raw format [04:09] <Company> desrt: stereo/mono? litlle/big endian? [04:09] <ds-work> wtay suggested filter elements for that [04:09] <ds-work> osssrc ! qos_audio ! osssink [04:09] <Company> use filtered caps (d'oh) [04:10] <ds-work> the qos_audio element decides the optimal caps [04:10] <desrt> 2 channel. platform endian (less marshalling = good). 16 bit. [04:10] <desrt> 44.1kHz :) [04:10] <Company> desrt: not surround 24 bit 192kHz? [04:10] <Company> the pro audio guys will be pissed ;) [04:11] <desrt> they can bite me. most of us still think CDs are pretty neat :) [04:11] <Company> and i prefer to please them [04:11] <Company> would you use a framework that pro guys prefer? ;) [04:12] <desrt> 99% of your users play ogg/mp3 with 2 channels of 16bit 44100 samples/sec data :) [04:12] <ds-work> all I care is that those two elements can negotiate _something_ [04:12] <Company> ds-work: that qos_audio element could really be replaced with relink_filtered :) [04:12] <desrt> (not like that matters for src!sink) [04:12] <Company> desrt: ian can't ;p [04:12] <ds-work> Company: if you want to specify exact caps [04:12] <desrt> Company; weird soundcard or what? [04:13] <Company> desrt: yep [04:13] <desrt> does gst have resampling shims? [04:13] <Company> ds-work: yeah [04:13] <ds-work> Company: but if you want to pick the optimal based on a caps intersection, you need something sparter [04:13] <ds-work> smarter [04:13] <ds-work> Company: although that's something I thought about when redesigning caps [04:14] <ds-work> i.e., each caps prop has some concept of what is better [04:14] <Company> ds-work: anyway, i'll just ditch type/typefind matching and move all current stuff to typefind and make caps use quarks [04:14] <ds-work> I decided against that [04:14] <Company> currently that is implied [04:14] <Company> or supposed to be implied [04:16] Action: desrt builds 064 [04:17] <desrt> how's the spider and/or metadata stuff coming, company? [04:17] <desrt> (in 07... not 064 i assume...) [04:17] <Company> desrt: yep. it's on hold because typefinding sucks and needs a redesign [04:18] <desrt> fair enough :) [04:18] <desrt> question about spider... [04:18] <desrt> if i start a pipeline, src!spider!sink... where src is an ogg.... [04:18] <desrt> then NULL the pipeline... change src to an mp3... then PLAYING [04:18] <Company> doesn'T work [04:19] <desrt> is spider supposed to pick up the new stream or should i be destroyed/recreating the spideR? [04:19] <Company> the second case [04:19] <desrt> hmm [04:19] <desrt> it will be that way forever? [04:19] <Company> spider is older than events and only events allow to detect that :/ [04:19] <Company> no, a new autoplugger will be able to handle that [04:19] <Company> s/will/should/ [04:19] <desrt> oh. [04:19] <desrt> i thought that NULL was like "element totally forgets any state that it had" [04:20] <Company> ye [04:20] <Company> yep [04:20] <Company> but it doesn't do that [04:21] <Company> spider is buggy and we're still waiting for someone to fix it *hinthint* ;) [04:21] <desrt> heh [04:21] <desrt> i seem to be its biggest user right now too :P [04:21] <desrt> (or certainly, most irritating) [04:25] <ds-work> Company: kill GstType, keep GstTypeFactory (in whatever form) [04:26] <Company> ds-work: that's what i'm doing [04:26] <ds-work> Company: it will be nice to link extensions and media types -- save that [04:28] <ds-work> when does dispose get called in the GObject model? [04:29] <Company> when the object is unreffed the last time [04:29] <Company> then dispose is called and after that finalize is called [04:30] <ds-work> what is the purpose of functions called destroy, then? [04:31] <Company> destroying the object [04:32] <Company> unreffing it until its refcount reaches 0 [04:33] <ds-work> ah, ok. so the way we use it is wrong :) [04:33] <desrt> so... just so we're on the same level here... gstreamer randomly picks the colour for the pid numbers on startup, right? :) [04:33] Action: desrt smirks [04:33] <Company> we don't want to use destroy [04:34] <Company> destroy is a hack around refcounting in gtk, nothing more [04:34] <Company> desrt: in 0.6 that might be true (i'm not sure), in HEAD they're fixed [04:34] <ds-work> I guess we don't do it much (if at all) for GObjects [04:34] <desrt> hm. i get no output with my slightly dated head. [04:34] Action: desrt shrugs [04:34] <Company> desrt: i think in 0.6 some of it is based on the process id [04:35] <Company> ds-work: no, we don't do it, that's why it's gone [04:35] <ds-work> desrt: in 0.6, it's the PID%6, iitc [04:35] <desrt> Company; i'm guessing it does something like using the low 3 bits of the pid for the colour [04:35] <desrt> oh. or that :) [04:35] <Company> ds-work: it's fundamentally wrong for refcounting [04:35] <desrt> ds-work; for readability when threads are involved? [04:36] <ds-work> desrt: yup [04:36] <ds-work> desrt: so different threads are different colors [04:36] <Company> ds-work: i'll not save type/extension matches, that's too much work for something unused [04:36] <desrt> i always used to think it had something to do with if it was the main thread or not... so i thought maybe it was another colour of gst was already running elsewhere or something [04:36] <ds-work> desrt: of course, that all goes out the window when getpid() returns the same value for every thread [04:37] <ds-work> Company: why would it be hard? How are you changing typefactory? [04:37] <Company> ds-work: i don't let typefactories depend on type anymore [04:38] <Company> ds-work: as typefind functions might return one of multiple types [04:39] <ds-work> Company: ok, I get it [04:39] <ds-work> Company: we'd need a separate media type / extension registry [04:39] <ds-work> Company: it's a good idea to have that, though [04:40] <desrt> #define GST_DEBUG_THREAD_ARGS(id) ( ((id) < 0) ? 37 : ((id) % 6 + 31) ), (id) [04:40] <desrt> mmm [04:40] <Company> ds-work: sure, implement it when you need it :) [04:41] Action: desrt uses these guys for his own debug messages :) [04:46] Smeven (~Smeven@63.169.97.78) joined #gstreamer. [04:53] <Smeven> i am having some audio syncing problems with gst-player.....is there any way to correct this problem? [04:53] <desrt> hm. this seems to be something i'm not allowed to do :) [04:54] <ds-work> Smeven: is it with esd? [04:54] <Smeven> ds-work, yes [04:54] <Smeven> i think so [04:54] <ds-work> Smeven: upgrade to gstreamer-0.6.4 [04:54] <Smeven> isnt that what gnome uses? [04:54] <ds-work> it was released today [04:55] <ds-work> (and more importantly, gst-plugins-0.6.4) [04:56] <Smeven> it completely fixes the problem? [04:57] <ds-work> there were problems with esd in everything before 0.6.4 [04:57] <desrt> woh! [04:58] <desrt> playing a song with gst with info mask 0xffffffff and the console on gnome-terminal produces some awesome sounding output :) [04:59] <Company> you can use -1 instead of 0xffffffff [05:00] <desrt> hmm. good call [05:00] <desrt> something tells me i'll never be using either again, though :) [05:01] <desrt> one wonders if gst outputs more data to /dev/dsp or to stdout :) [05:04] <Company> /dev/dsp [05:04] <Company> but it might output more to stderr [05:05] <desrt> i'd believe either. [05:08] <desrt> one last question. what's the future? [05:09] <Smeven> i wonder how soon this will be in gentoo [05:09] <desrt> ie: will there be spider, or will there be more like mimetype based autoplugs? [05:10] <ds-work> somewhere in between, probably [05:11] <ds-work> spider appears to be too general (and therefore dumb) [05:11] ChristianHJW (~chr...@p5...) joined #gstreamer. [05:12] <desrt> hm [05:12] <desrt> well [05:12] <desrt> i like spider, if by nothing more than the fact that it's ridiculously easy to use :) [05:12] Action: desrt goes to bed [05:12] <desrt> peace :) [05:17] <Company> ds-work: ds...@sc...? [05:21] <ds-work> yes [05:22] <ds-work> Company: could you look at add_remove_test3() in testsuite/refcount/bin.c [05:22] <ds-work> it creates a bin, adds an element, then _unrefs_ the element [05:22] <ds-work> it expects that the element is automatically removed from the bin [05:22] <Company> that is supposexd to break [05:22] <ds-work> do we want that? [05:22] <Company> yes [05:23] <Company> the reference to the element is owned by the bin [05:23] <ds-work> so the app unreffing that element is illegal [05:23] <Company> yes [05:24] <ds-work> thanks for making me feel sane [05:24] <Company> ds-work: i sent you the new typefind header, please comment on it, i want to start implementing it tomorrow [05:25] <Company> and i'm off to bed now, gnight [05:25] <ds-work> later [05:30] <ChristianHJW> ds-work : you read my quest for a short email to our list ? [05:31] <ChristianHJW> ds-work : please please, could you rop a very short email to matroska-devel AT lists.matroska.org, with a log file ? [05:32] <ds-work> ChristianHJW: sure [05:33] <ds-work> ChristianHJW: but I wanted to make sure that using libebml-0.6 and matroska-0.5 is not completely bogus [05:33] <ChristianHJW> :) ... thx [05:34] <ds-work> ChristianHJW: is it completely bogus? on first glance, they are Just Not Compatible [05:36] <ChristianHJW> have to check [05:36] <ds-work> it appears that 0.5.2 is compatible [05:38] Smeven (~Smeven@63.169.97.78) left irc: "Leaving" [05:38] jcsston (jcsston@204.96.16.19) joined #gstreamer. [05:40] <ChristianHJW> ds-work : jcsston came to help [05:40] <ChristianHJW> jcsston : does libmatroska 0.5 not compile with libebml 0.6 ? [05:41] <ChristianHJW> must be limatroska 0.5.2 ? [05:41] <jcsston> yes. IIRC there are some new methods. [05:43] <ds-work> yeah, it compiles fine now with 0.5.2 [05:44] <ds-work> btw, can either of you help us get some matroska files for our media test suite? [05:46] <ChristianHJW> moment [05:46] <ChristianHJW> http://matroska.free.fr/samples/ [05:49] <ds-work> any that are known to be freely distributable? [05:49] <ChristianHJW> Hmmm .... not that i know of :( [05:50] <ChristianHJW> i maybe have to release one of my home made videos :P [05:50] <ChristianHJW> lol [05:50] <ChristianHJW> nite now, Iris is asleep again [05:50] <ds-work> we're not looking for quality here... [05:50] <ChristianHJW> thx for your help ds-work [05:50] <ds-work> we're looking for md5sums :) [05:50] <ds-work> no prob [06:09] ChristianHJW (~chr...@p5...) left irc: Read error: 110 (Connection timed out) [06:26] jcsston (jcsston@204.96.16.19) left irc: Read error: 104 (Connection reset by peer) [06:51] mrkidd (~mr...@12...) joined #gstreamer. [06:52] <mrkidd> does anyone know how to retrieve metadata (artist, album) from a file via gstreamer? [06:54] Marsupilami23 (~Mar...@15...) joined #gstreamer. [06:56] walters (wa...@ve...) joined #gstreamer. [06:57] <mrkidd> it seems that GstCaps and GstPads are the way to get that info [06:57] <mrkidd> but it's very confusing from the docs as to how I go about setting up those objects from an element or pipeline [06:58] <ds-work> in 0.6 or HEAD? [06:59] <mrkidd> 0.6 [07:10] <mrkidd> in the gst-player sources, it looks like they get a GstCaps object by doing a g_value_peek_pointer into an element [07:14] <mrkidd> but it is very confusing as to where the value struct actually comes from [07:17] Marsupilami23 (~Mar...@15...) left irc: "I don't wanna grow up, I'm a Toys R Us Kid. There's a million toys at Toys R Us that I can play with!" [07:19] md` (ill...@md...) left irc: Read error: 110 (Connection timed out) [08:06] herzi (~he...@ki...) joined #gstreamer. [08:34] Action: wheels is back [08:48] kmaraas (~km...@14...) left irc: "Leaving" [08:58] md` (ill...@md...) joined #gstreamer. [08:59] thomasvs (~thomas@217.136.122.190) got netsplit. [09:03] <mrkidd> anyone here used the spider autoplugger and could help me out? [09:05] thomasvs (~thomas@217.136.122.190) got lost in the net-split. [09:07] mrkidd (~mr...@12...) left irc: "Leaving" [09:14] thomasvs (~th...@19...) joined #gstreamer. [09:17] athom (~the...@so...) joined #gstreamer. [09:23] <thomasvs> ds-work: I'm pretty sure there's no Werror in the tarballs, but I did check and it seems in plugins you had the logic reversed [09:23] <thomasvs> whcih I fixed at the end [09:23] <ds> thomasvs: cool, thanks [09:24] <ds> he noticed it in the prereleases anyway [09:24] harshy|lap (~ha...@dh...) joined #gstreamer. [09:25] harshy (~ha...@dh...) left irc: Read error: 113 (No route to host) [09:25] Marsupilami23 (~Mar...@15...) joined #gstreamer. [09:28] walters (wa...@ve...) left irc: Remote closed the connection [09:39] Marsupilami23 (~Mar...@15...) left irc: "I don't wanna grow up, I'm a Toys R Us Kid. There's a million toys at Toys R Us that I can play with!" [09:41] <thomasvs> ds: I'm pretty sure it's fine this time [09:42] <thomasvs> ds: but never say never [09:48] thaytoo (ja...@ad...) left irc: "leaving" [09:54] <athom> how should a typefind plugin be integrated in a "{somesrc ! queue} ! somesink" pipeline? "{somesrc ! typefind ! queue} ! somesink"? [09:55] <athom> and then unlink the typefind as soon as the type was found? [09:56] <thomasvs> athom: you don't need to put it in a complete pipeline [09:56] <thomasvs> you just do src ! typefind [09:56] <thomasvs> when you find it, you remove typefind, and put src in your pipeline [09:56] <athom> this won't cause the first buffer to get lost in the typefind?` [09:59] <thomasvs> yeah - but you can reset [10:00] <thomasvs> alternatively, I think there is a typefindcache element that does this too [10:01] <athom> does reset mean seek to 0 or is there a better way? [10:01] wheels (~sc...@ds...) left irc: "using sirc version 2.211+KSIRC/1.3.8" [10:05] dolphy (~do...@po...) joined #gstreamer. [10:06] swentel (sw...@d5...) joined #gstreamer. [11:13] md` (ill...@md...) left irc: [11:19] md` (ill...@md...) joined #gstreamer. [11:22] kmaraas (~km...@18...) joined #gstreamer. [11:23] dolphy (~do...@po...) left irc: Remote closed the connection [11:26] <thomasvs> seek to 0 is fine [11:28] dolphy (~do...@po...) joined #gstreamer. [11:28] wheels (~sc...@ds...) joined #gstreamer. [11:30] dolphy (~do...@po...) left irc: Remote closed the connection [11:31] dolphy (~do...@po...) joined #gstreamer. [11:36] teuf (~te...@gr...) joined #gstreamer. [11:36] murali (~Bala@202.54.13.34) joined #gstreamer. [11:42] <teuf> hi [11:48] Rotty (~an...@ch...) joined #gstreamer. [11:49] dolphy (~do...@po...) left irc: Remote closed the connection [11:51] dolphy (~do...@po...) joined #gstreamer. [12:09] TD (mh...@by...) joined #gstreamer. [12:14] <wheels> ds: Ok -- recompiling gst-plugins on GCC 3.3 at the moment and I have to withdraw my affirmation from yesterday -- gst-plugins definitely takes a *lot* longer to compile than JuK. ;-) [12:22] swentel (sw...@d5...) left irc: [12:29] swentel (sw...@d5...) joined #gstreamer. [12:41] abraar- (~foo@AToulouse-105-1-14-172.w80-15.abo.wanadoo.fr) joined #gstreamer. [12:42] abraar (~foo@AToulouse-105-1-33-141.w81-248.abo.wanadoo.fr) left irc: Nick collision from services. [12:42] Nick change: abraar- -> abraar [12:43] sublett (~rv...@21...) joined #gstreamer. [12:47] smoke (sm...@ch...) joined #gstreamer. [12:59] Action: wheels uploads suse packages for 0.6.4... [13:03] Action: smoke doesnt use suse, but thinks that suse users will be really happy :) [13:06] <wheels> Right. I'm the resident SuSE weenie. :-) [13:06] <thomasvs> sorry dude :) [13:06] <wheels> thomasvs : Dude, you use Redhat -- you're no better. ;-) [13:07] <thomasvs> sucker of corporate dick, that's me [13:07] <TD> lol [13:07] <TD> perhaps not anymore [13:07] <TD> does fedora still look pretty? the website is lacking something without the red hat logo [13:08] <wheels> TD : I believe with fedora it's gone from "sucker of corporate dick" to "corporate bitch" :-) [13:08] <TD> heh [13:37] Nick change: TD -> TD[lunch] [13:44] Uraeus (~csc...@wp...) joined #gstreamer. [13:45] <Uraeus> hello [14:06] BBB (~rb...@ph...) joined #gstreamer. [14:11] <Uraeus> morning BBB [14:11] <BBB> hi [14:16] <dolphy> Uraeus: morning has gone away you late sleeper :) [14:16] <BBB> screenies guys! [14:16] <BBB> http://ronald.bitfreak.net/images/gst-mixer.png [14:16] <BBB> I've changed layout slightly [14:16] <BBB> http://ronald.bitfreak.net/images/gst-record.png [14:16] <BBB> current gst-rec dev. snapshot [14:16] <BBB> http://ronald.bitfreak.net/images/gst-record-prefs.png [14:16] <BBB> preferences screen, gives a slight indication of what I'm intending to do [14:16] <BBB> :) [14:18] <BBB> code is in CVS, btw [14:18] <BBB> I want the mixer in Gnome-2.6 if GStreamer-0.8 makes it into Gnome-2.6 [14:18] <BBB> Gst-rec should be "functional" by then [14:18] <BBB> it doesn't have to be part of Gnome [14:19] <BBB> but distributions should be able to put it in there if they want [14:27] kmaraas (~km...@18...) left irc: Read error: 104 (Connection reset by peer) [14:30] Nick change: TD[lunch] -> TD [14:30] <Uraeus> dolphy: I had a looong weekend :) [14:31] <Uraeus> BBB:looks great :) [14:32] <thomasvs> BBB: you can't get gst-rec into a dist unless it works with a free codec, for example, theora [14:32] <thomasvs> other than that, looks great, but gst-rec looks like it's not working yet based on the screenshot :) [14:33] <BBB> thomasvs: it does [14:33] <BBB> it can do MJPEG, raw YUV, raw RGB [14:33] <BBB> xvid, if you consider that free [14:33] <BBB> matroska, avi, asf (might be free, unsure) [14:34] <BBB> ogg, flac, pcm/wav [14:34] <BBB> etc. [14:38] <wheels> Ok, for those who have interest (i.e. doing the release announcement or links or whatever) SuSE packages are here: http://developer.kde.org/~wheeler/files/gstreamer-packages/SuSE-8.2/ [14:38] <wheels> They work at least on my machine. :-) [14:38] <BBB> wheels: cool!! thanks :) [14:38] <BBB> should I add them to the release page? [14:38] <wheels> sure [14:39] <wheels> I'll put some up for 9.0 at some point before or shortly after it's out... [14:41] <Uraeus> wheels: looks great :) [14:42] <Uraeus> wheels: btw, I had to smile when walters commited your fixes to rb, it is not often a @kde.org address appears in GNOME CVS logs ;) [14:42] <wheels> Uraeus : Yeah, I had fun with that myself. :-) That's actually the second round of those... :-) [14:43] <wheels> Uraeus : Especially since I'm the author of the KDE "competitor" or something... ;-) [14:45] <Uraeus> wheels: be carefull, you might find yourself in front of a KDE tribunal for judgement if your name appears to often in GNOME CVS <g> [14:45] <wheels> Have my CVS account deactivated for treason, eh? :-) [14:45] <wheels> That or Walters might face the same. :-) [14:46] <Uraeus> yeah, walters get punished for allowing trojan horse KDE code into CVS ;) [14:47] <wheels> Hey -- *I* was fixing C++-isms. :-) [14:47] <BBB> *grin* [14:47] Action: BBB adapts the web page [14:48] <BBB> stupid CVS WWW [14:48] <BBB> :/ [14:48] <BBB> grr [14:48] <BBB> Uraeus: do you want to do it? [14:48] <Uraeus> BBB: sure :) [14:48] <BBB> I'm trying to i18n'ize gst-mixer/gst-record [14:48] <BBB> doing two things at the same time sucks [14:48] <Uraeus> BBB: why do you think our CVS WWW setup sucks? [14:48] <BBB> oh, because SF is slow [14:53] <dolphy> BBB: i had a long discussion with ds and company yesteday about Video sink API [14:53] <dolphy> BBB: we all basically agree on the fact that the GstVideoSink class should implement a global video sink interface [14:54] <dolphy> BBB: that let's you handle all kind of video sink [14:55] Nick change: TD -> TD[gone] [14:56] <BBB> well, propose some actual interface so I can see how it looks ;) [14:57] <BBB> I personally think it doesn't make sense to have different video interfaces for srcs and sinks [14:57] <BBB> so they must be the same [14:57] <dolphy> BBB: i first need to walk through interfaces and understand how it works [14:57] <BBB> so even if it's a videosink interface api, it needs to be a video interface api [14:57] <BBB> ;) [14:57] kmaraas (~km...@18...) joined #gstreamer. [14:57] exdaix (~ex...@pc...) joined #gstreamer. [14:57] <dolphy> BBB: but still the theorical process itself of a video sink is not clear for everybody [14:58] <dolphy> BBB: people are naturally putting the process in a Xlib like process [14:58] <dolphy> BBB: which is wrong for other backends [14:59] <BBB> I know [14:59] <BBB> that's why I need someone to propose something for the others [14:59] <BBB> I'm fine with a general way for all [14:59] <BBB> but - it needs to be *strictly* defined [14:59] <dolphy> i ll try [14:59] <exdaix> Hello everyone, I have a quick question: I just installed Rhythmbox through Apt on Fedora 0.94. When I try to play a MP3 stream, or any MP3 file at that (I haven't checked .ogg yet) a pop-up appears and says: "Failed to create spider element; check your installation." Any help? [14:59] <BBB> for each of the backends [14:59] <BBB> i.e., I need to call one or two functions and have a working video X overlay [14:59] <BBB> similarly, I need to call one or two functions and have a working FB overlay [15:00] <BBB> there shouldn't be any undefined pointer magic, because that won't help us [15:00] <BBB> so your proposal of a pointer and one generic function for all is fine [15:00] <BBB> but for each - X, FB, ... - define *what* is in the pointer [15:00] <dolphy> yup [15:00] <BBB> define strictly how it works, I don't care, write an example widget for X, FB, etc. [15:00] <BBB> as long as it's clear and defined how it works [15:00] <dolphy> i ll have a hard time understanding interfaces before that anyway :) [15:01] <BBB> because that's my end goal with the interfaces ;) [15:01] <BBB> to make something that always works for each element [15:02] <dolphy> if i understand it right you have done a custome GstInterface implementation [15:02] <BBB> nope [15:02] <BBB> I was planning on that [15:02] <BBB> but I just used GInterface [15:02] <BBB> and added one 'prerequisite' interface (GstInterface) to each of our GInterfaces [15:02] <dolphy> where can i get a good example on how interfaces might help me in that processs ? [15:02] <BBB> GstInterface is a tiny add-on which makes it per-instance [15:03] <dolphy> the mixer ? [15:03] <BBB> for example [15:03] <BBB> yes [15:03] <BBB> the mixer is the best example of an interface, currently [15:03] <BBB> just imagine an application using gstreamer that wants to use an interface [15:03] <BBB> what API would that application want [15:03] <BBB> and then make that API in a reasonable manner, implementable by plugins etc. [15:04] <BBB> 'realistic' [15:04] <BBB> and implement it :) [15:04] <dolphy> yes but i m used to do that for public methods of a class [15:04] <dolphy> not really for an inteface [15:04] <dolphy> that's why my heart slipped to subclassing for that need [15:05] <dolphy> (the mixer is in gst-sandbox module ?) [15:05] <thomasvs> exdaix: what does gst-inspect spider say ? [15:05] <thomasvs> exdaix: and where did you get rhythmbox from ? [15:06] <BBB> dolphy: yes [15:06] <BBB> thomasvs: do you know why I get 'Makefile.am:2: invalid variable `desktop_DATA''? [15:06] <BBB> I'm trying to i18n'ize gst-mixer/gst-record [15:06] <thomasvs> BBB: you didn't set desktopdir in the Makefile.am [15:06] Action: BBB retries [15:07] <BBB> I did, but below the definition of DESKTOP_data... let's stry on top [15:07] <BBB> yay, this works :) [15:07] <BBB> thnx [15:07] <thomasvs> np [15:08] <exdaix> thomasvs: I got rhtthmbox from Apt, and from the official repository I believe [15:08] <exdaix> thomasvs: gst-inspect shows a lot of stuff [15:08] <exdaix> thomasvs: I just checked .ogg files, they play fine [15:10] <BBB> [rbultje@shrek po]$ intltool-update -m [15:10] <BBB> intltool-update: Unable to determine package name. [15:10] <BBB> Make sure to run this script inside the po directory. [15:10] <BBB> gr... [15:11] <BBB> I'm almost there [15:13] <thomasvs> exdaix: I said "gst-inspect spider" [15:13] <exdaix> thomasvs: yea, that outputs a lot of stuff [15:13] <dolphy> BBB: hmm need your help [15:13] <wheels> exdaix : Welcome to the wonderful world of software patents. :-) [15:13] Oskuro (~jo...@nu...) joined #gstreamer. [15:14] <exdaix> lol [15:14] <Oskuro> Hi [15:14] <exdaix> gpl everything make it a law [15:14] <exdaix> ;) [15:14] <dolphy> BBB: i have been reading the mixer.c mixer.h code [15:14] <dolphy> BBB: it clearly inherits from a GInterface instead of a GObject [15:14] <wheels> exdaix : (i.e. Redhat/Fedora doesn't package mp3 decoders) [15:14] <Oskuro> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=210318 [15:14] <dolphy> BBB: and it adds a prerequisite on GST_TYPE_INTERFACE [15:14] <exdaix> oh crap... i forgot about hat [15:14] <Oskuro> Can anyone look at that and tell me if it's broken for everyone? [15:15] <exdaix> wheels: so I jsut gotta install lame and it should work? [15:15] <Uraeus> exdaix: you need to install mad and the gstreamer mad plugin for mp3 [15:15] <dolphy> BBB: but i don't see anywhere the connection betweeen the public virtual methods with real functions.. [15:15] <dolphy> BBB: where does that happens ? [15:16] <wheels> exdaix : No. (a) lame is an encoder and (b) even if you installed libmad you still wouldn't automatically have the gst plugin for it... [15:16] <Uraeus> exdaix: I think thomasvs has packaged them for fedora, so you probably just need to download them seperatly [15:17] <exdaix> libmad or madplay [15:17] <Uraeus> exdaix: you also need gstreamer-mad [15:17] <exdaix> INFO ( 3013: 0) Initializing GStreamer Core Library version 0.6.3 [15:17] <exdaix> INFO ( 3013: 0) CPU features: (c1c3f9ff) MMX SSE 3DNOW MMXEXT [15:17] <exdaix> INFO ( 3013: 0) registry: loaded global_registry in 0.066752 seconds [15:17] <exdaix> (/var/cache/gstreamer-0.6/registry.xml) [15:17] <exdaix> Factory Details: [15:18] <exdaix> Long name: Spider [15:18] <exdaix> Class: Generic [15:18] <exdaix> License: LGPL [15:18] <exdaix> Description: Automatically link sinks and sources [15:18] <exdaix> Version: 0.6.3 [15:18] <exdaix> Author(s): Benjamin Otte <in...@pu...> [15:18] <exdaix> Copyright: (C) 2002 [15:18] <exdaix> [15:18] <exdaix> GObject [15:18] <exdaix> +----GstObject [15:18] <exdaix> +----GstElement [15:18] <exdaix> +----GstBin [15:18] <exdaix> +----GstSpider [15:18] <exdaix> [15:18] <wheels> ugh [15:18] <exdaix> Pad Templates: [15:18] <exdaix> SRC template: 'src_%d' [15:18] <exdaix> Availability: On request [15:18] <exdaix> Has request_new_pad() function: gst_spider_request_new_pad [15:18] <exdaix> [15:18] Last message repeated 1 time(s). [15:18] <exdaix> Element Flags: [15:18] <exdaix> no flags set [15:18] <exdaix> [15:18] <exdaix> Bin Flags: [15:18] <exdaix> GST_BIN_FLAG_PREFER_COTHREADS [15:18] <exdaix> [15:19] <exdaix> Element Implementation: [15:19] <exdaix> No loopfunc(), must be chain-based or not configured yet [15:19] <exdaix> Has change_state() function: gst_bin_change_state [15:19] <exdaix> Has custom save_thyself() function: gst_bin_save_thyself [15:19] <exdaix> Has custom restore_thyself() function: gst_bin_restore_thyself [15:19] <exdaix> [15:19] <exdaix> Clocking Interaction: [15:19] <exdaix> none [15:19] <exdaix> [15:19] Action: wheels reaches for /ignore [15:19] <exdaix> Indexing capabilities: [15:19] <exdaix> element can do indexing [15:19] <exdaix> [15:19] <exdaix> Pads: [15:19] <exdaix> SINK: 'sink', ghost of real pad sink_ident:sink [15:19] <exdaix> Implementation: [15:19] <exdaix> Has bufferpoolfunc(): gst_spider_identity_get_bufferpool [15:19] <exdaix> Pad Template: 'sink' [15:19] <exdaix> [15:19] <exdaix> Element Arguments: [15:19] <exdaix> name : The name of the object [15:19] <exdaix> String. (Default "element") [15:19] <exdaix> factories : allowed factories for autoplugging [15:19] <exdaix> Unknown type 68 "gpointer" [15:19] <exdaix> [15:19] <Uraeus> exdaix: please stop... [15:19] <exdaix> Dynamic Parameters: [15:19] <exdaix> none [15:19] <exdaix> [15:20] <exdaix> Element Signals: [15:20] <exdaix> none [15:20] <exdaix> [15:20] <exdaix> Element Actions: [15:20] <exdaix> none [15:20] <exdaix> [15:20] <exdaix> Children: [15:20] <exdaix> sink_ident [15:20] <exdaix> [exdaix@localhost exdaix]$ [15:20] <exdaix> did you guys see that [15:20] <exdaix> if you did, my bad [15:20] <exdaix> stupid paste command [15:20] <exdaix> I really didn't mean to do that [15:20] <Uraeus> hrm :) [15:21] wheels (~sc...@ds...) left irc: "changing servers" [15:21] The_Company (~Company@pD958B701.dip.t-dialin.net) joined #gstreamer. [15:21] wheels (~sc...@ds...) joined #gstreamer. [15:26] kmaraas (~km...@18...) left irc: Remote closed the connection [15:37] Company (~Company@pD9E33AF2.dip.t-dialin.net) left irc: Read error: 110 (Connection timed out) [15:37] exdaix (~ex...@pc...) left irc: "Leaving" [15:38] <Uraeus> wheels: ok, you are now a gstreamer.org frontpage superstar :) [15:45] <thomasvs> argh [15:45] Rotty (~an...@ch...) left irc: Remote closed the connection [15:45] Action: thomasvs is getting sick of spending time on the phone with various social security agencies [15:47] <Uraeus> thomasvs: what do they want? or rather what do you want with them? [15:47] <Uraeus> thomasvs: getting stuff like pensions etc. in order before spain? [15:49] <thomasvs> no, getting stuff like my social identity solved [15:49] <thomasvs> yesterday they convinced me (one of the agencies) I should apply for unemployment benefit because otherwise my health care is not in order [15:49] <thomasvs> so I applied, but I called the health care today to check this, and they tell me that that's completely wrong. [15:50] <thomasvs> Of course, I had this old lady at the counter yesterday, and nobody knows who she is :) [15:50] <thomasvs> and now I need to get my application cancelled and so on... [15:50] <thomasvs> lots of wasted time [15:50] <Uraeus> hehe :) [15:51] <thomasvs> It is incredible how much the system is against people who want to and have work [15:51] <thomasvs> everyone assumes you're calling to profit from the system [15:52] <Uraeus> yup, sometimes wonder if the political system considers it a crime if you are a productive labourer [15:52] <dolphy> Uraeus: that might happen soon :) [15:53] kmaraas (~km...@18...) joined #gstreamer. [15:54] <thomasvs> I'm also getting the impression that it is very rare for people to take a few months off from work [15:56] <dolphy> indeed that's rare [15:56] Nick change: The_Company -> Company [15:56] <Uraeus> ok, gotta run some errands, bbl [15:56] Uraeus (~csc...@wp...) left irc: "Client exiting" [15:58] <dolphy> i m maybe totally misunderstanding it but interface does not really bring something new in a well subclassed object tree [16:00] <dolphy> from what i ve seen it's an empty object providing an API, public virtual methods connected to NULL [16:00] <dolphy> then another object will say i implement this interface and connect the public virtual methods to its functions [16:01] <dolphy> nothing that can't be done with correct subclassing and public virtual methods [16:02] <dolphy> the only point i see is that you could implement an interface from any object no matter where you are in the tree and then have multiple inheritance.. [16:07] Action: Oskuro tries again. [16:08] <Oskuro> Does anyone know if there's a problem with the jack plugin? [16:08] <Oskuro> There's a bug regarding that in the Debian bug tracker which I'd like to solve or at least lower its severity so it stops blocking lots of stuff. [16:11] <sublett> url to bug? [16:12] <dolphy> Oskuro: that bug looks like a bug in jack element itself not in the debian package [16:14] kmaraas (~km...@18...) left irc: "Leaving" [16:15] <Oskuro> sublett: sorry [16:15] <Oskuro> [15:14] > http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=210318 [16:15] <Oskuro> dolphy: what do you mean? [16:16] <dolphy> Oskuro: that bug seems to tell that the jaksink element can't be linked with mad in the editor [16:16] <dolphy> Oskuro: either this user does not know how to use jacksink [16:16] <dolphy> Oskuro: or jacksink is broken [16:16] <dolphy> Oskuro: not really a debian bug though [16:17] <Oskuro> dolphy: oh, right, but it's reported against the BTS, so now Debian has to care about it :) [16:17] <Oskuro> I guess it should be forwarded to bugzilla. [16:17] <Oskuro> Does anyone use that plugin? [16:18] <dolphy> Oskuro: i don't know jack at all [16:22] apoc__ (~ap...@dy...) joined #gstreamer. [16:29] foser (d0...@22...) joined #gstreamer. [16:31] <sublett> Oskuro: I'll set up jack later & see if I can reproduce [16:32] <thomasvs> Oskuro: wingo does [16:39] apoc_ (~ap...@dy...) left irc: Read error: 110 (Connection timed out) [16:48] <foser> thomasvs: the docs of gstreamer i still cant get to build/install [16:49] <Oskuro> sublett: excellent [16:49] <thomasvs> foser: that's vague [16:50] <foser> thomasvs: yeah some cp -r statement is fed with an empty HTML_DAT (?) string and fails.. don't have the exact problem present [16:55] Nick change: TD[gone] -> TD [16:56] murali (~Bala@202.54.13.34) left irc: "Client Exiting" [16:56] swentel (sw...@d5...) left irc: [17:00] yippi (~br...@nw...) joined #gstreamer. [17:03] <thomasvs> foser: I'll need more,file a bug [17:17] Oskuro (~jo...@nu...) left irc: "test" [17:18] <sublett> Oskuro: I've tested & reproduced the bug, something is broken in the jack plugin. Please file a bug [17:18] <sublett> doh! hehehe [17:32] BBB (~rb...@ph...) left irc: "Client exiting" [17:34] athom (~the...@so...) left irc: [18:19] Kaetzchen (All...@p5...) joined #gstreamer. [18:20] alley_cat (All...@p5...) left irc: Nick collision from services. [18:20] teuf (~te...@gr...) left irc: "Client exiting" [18:21] Nick change: Kaetzchen -> alley_cat [18:25] thomasvs (~th...@19...) left irc: Read error: 104 (Connection reset by peer) [18:26] Rotty (~an...@ch...) joined #gstreamer. [18:44] thomasvs (~th...@15...) joined #gstreamer. [18:47] abraar (~foo@AToulouse-105-1-14-172.w80-15.abo.wanadoo.fr) left irc: Read error: 104 (Connection reset by peer) [18:52] ChrHJW_log (~ch...@p5...) left irc: Read error: 60 (Operation timed out) [18:58] abraar (~foo@AToulouse-105-1-29-161.w81-51.abo.wanadoo.fr) joined #gstreamer. [19:07] <ds-work> crow [19:08] <Company> toot [19:21] <Company> we should at some point decide if we want to use macros are functions to access members of structs/objects [19:21] <Company> s/macros are/macros or/ [19:22] Action: Company votes for functions [19:23] <Company> and whatever we chose should be checked for completeness and documented [19:23] <ds-work> macros for public members, functions for private [19:23] <ds-work> or better, use -> [19:23] <ds-work> for public members [19:24] <Company> yeah [19:24] <alley_cat> how do i use ffdemux_avi in a gst-launch commandline? [19:24] <Company> though macros for public members are better [19:24] <Company> alley_cat: by saying ffdemux_avi :) [19:25] <alley_cat> if i use the same as with avidemux i get: (process:29895): GStreamer-WARNING **: push on peer of pad filesrc0:src but peer is not active [19:25] Nick change: apoc__ -> apoc [19:25] <Company> because that allows for a bit of flexibility when changing the struct members [19:25] <Company> fix ffdemux_avi :/ [19:26] <alley_cat> doh, i wanted to use it replacing avidemux, as that one's borked for some files :/ [19:26] <Company> ds-work: did you get my mail yestrerday? any comments? [19:26] <Company> better fix avidemux [19:28] <ds-work> Company: yeah. it took a while, since for some reason your mail was going to my spam mailbox [19:28] <alley_cat> i'd like to, but i have no idea what's going wrong in it [19:28] <ds-work> Company: why do we want macros for public members? [19:28] <Company> ds-work: not enough content? ;) [19:28] Nick change: harshy|lap -> harshy [19:29] <Company> ds-work: you can rename them more easily [19:29] <ds-work> Company: pattern matching on From:, I think. I never figured it out, but I deleted a bunch of old rules and reran the mail, and it passed [19:29] <Company> ds-work: or restructure stuff (with unions or so) [19:29] <ds-work> hrm, true [19:29] <ds-work> is this a big need, though [19:30] <Company> no, but it's a reason to keep macros :)O [19:31] <alley_cat> anything special i need to do to compile gst-player/totem with a gstreamer in a non standard prefix? i get undefined references to gst_play_set_visualisation_video_sink [19:32] <Company> the player is broken on hEAD [19:33] <Company> it's on hold waiting for the interfaces for video embedding to get defined [19:39] dolphy (~do...@po...) left irc: "Network down, IP Packets delivered via UPS" [19:55] Nick change: TD -> TD[out] [20:13] teuf (~te...@ln...) joined #gstreamer. [20:13] <teuf> hi [20:15] <Company> hi teuf [20:15] pb_ (~pb@2002:5160:45ef:0:2e0:7dff:fe74:8b87) joined #gstreamer. [20:25] BBB (~rbultje@213.160.215.2) joined #gstreamer. [20:25] <teuf> hmm, my shn plugin mostly work, except that the sound becomes choppy when the music gets loud, I don't know if this is caused by my plugin by itself, or by some problems with interacting with gstreamer, any hint how I could figure that out ? [20:28] <BBB> choppy? how? [20:29] Marsupilami23 (~Mar...@15...) joined #gstreamer. [20:29] <teuf> it's a bit hard to describe, especially in english, this sounds either as if there were very short skips during playback [20:30] <teuf> (at least I think it would sound like that if there were short skips very regularly) [20:30] Nick change: md` -> md``` [20:30] <teuf> I'm using a 2.6test2 kernel, I should try a 2.6test7 to see if the scheduling improvements help [20:31] <teuf> gst is unusable here to listen to mp3s since it keeps skipping [20:31] <Company> yeah, updating the kernel sounds like a good idea [20:31] <Company> another good idea would be to write a wav and then listen to that [20:32] <Company> ! wavenc ! filesink location=file.wav [20:32] <teuf> writing the wav and listening to it with mplayer is fine if I remeber correctlyu the tests I did yesterday [20:32] <teuf> except that it crashed in the end, but that's a different issue :) [20:32] m_wheels (~sc...@ds...) joined #gstreamer. [20:33] wheels (~sc...@ds...) left irc: "[BX] Time wasted: all of it" [20:33] Nick change: m_wheels -> wheels [20:36] <teuf> yeah works fine when converted to wav [20:36] <teuf> though the conversion is really slow, as if it was writing the wav file at 1x instead of writing it as fast as possible [20:39] <BBB> is the decoder sinking or clocking? [20:40] <teuf> hmm, what does that mean exactly ? [20:40] <teuf> I timestamp my buffers before using gst_pad_push [20:41] <BBB> hm, no... it means that you gst_clock_wait() [20:41] <teuf> oh no, I don't even now what this functio nis [20:41] <teuf> :) [20:42] <BBB> keep it that way ;) [20:42] <BBB> how's CPU load? [20:42] <apoc> BBB : where did you find asf format spec ? [20:43] <BBB> I didn't [20:43] <BBB> I reversely wrote the ASF demuxer, and copied some header code from FFMPEG [20:43] <BBB> that's all [20:43] <teuf> hmm, cpu is at 100% when I convert to wav [20:43] <apoc> BBB : oh ok [20:43] <BBB> teuf: well, there's your reason then [20:44] <BBB> find out why ;) [20:44] <teuf> yeah :) [20:44] <teuf> do I have something special to do in a _loop function when I need to wait for more data ? [20:44] <teuf> or will gst_pad_pull handle that by itself ? [20:44] <apoc> BBB : did you test audio in asf file ? [20:44] <BBB> no [20:44] <BBB> do you mean muxing or demuxing? [20:45] <apoc> demuxing [20:45] <BBB> then: no [20:45] <BBB> I only tested muxing [20:45] <BBB> I tested demuxing with one muxed file, and that one worked [20:45] <BBB> I didn't test any other [20:45] <BBB> if anything breaks, file a bug report [20:45] <BBB> I'm in for fixing issues [20:46] <apoc> I will [20:47] <apoc> I have a audio correlation error on wma files [20:47] <BBB> I have no clue what that means, but it sounds bad, so please fix it ;) [20:48] ChrHJW_log (~ch...@p5...) joined #gstreamer. [21:07] kmaraas (~km...@14...) joined #gstreamer. [21:11] Marsupilami23 (~Mar...@15...) left irc: Read error: 54 (Connection reset by peer) [21:17] steveb_ (~st...@21...) left irc: Remote closed the connection [21:33] <BBB> ds: da? [21:36] <ds-work> BBB: si? [21:38] Zeenix (~zak@203.135.60.239) joined #gstreamer. [21:45] <BBB> oh, nevermind, found it out myself [21:45] <BBB> did you read my reply, btw? [21:45] <Zeenix> hi [21:52] <ds-work> BBB: yes [21:54] ChristianHJW (~chr...@p5...) joined #gstreamer. [21:55] <BBB> root@develop:~/projects/mpeg-to-avi/debian# dpkg -i gstreamer-ds-0.7.1-1.deb [21:55] <BBB> (Reading database ... 28632 files and directories currently installed.) [21:55] <BBB> Unpacking gstreamer-ds (from gstreamer-ds-0.7.1-1.deb) ... [21:55] <BBB> dpkg: error processing gstreamer-ds-0.7.1-1.deb (--install): [21:55] <BBB> package control info rmdir of `usr' didn't say not a dir: Directory not empty [21:55] <BBB> Errors were encountered while processing: [21:55] <BBB> gstreamer-ds-0.7.1-1.deb [21:55] <BBB> root@develop:~/projects/mpeg-to-avi/debian# [21:55] <BBB> what does that mean? [21:55] Action: BBB hates debian already [21:56] <ds-work> 0.7.1? [21:57] <BBB> uh, it's a private package [21:58] <BBB> as you might know, we're using gstreamer in our company here ;) and I want to test 0.7.1 somewhere [21:58] <ds-work> and you're complaining that it's broken? [21:58] <BBB> 0.7.1 being current HEAD CVS [21:58] <BBB> no, I want to know what the error means [21:58] <ds-work> ah, don't know [21:58] <BBB> I did dpkg-deb -b usr bla.deb in debian/ with some files in usr/* [21:58] <BBB> to create a custom deb package [21:58] <BBB> and it doesn't work [21:58] <BBB> ;) [21:59] <ds-work> that's not how you create debian packages [21:59] <ds-work> anyway, /me goes to lunch [21:59] <BBB> hf ;) [22:01] <minddog> dpkg-build [22:11] md``` (ill...@md...) left irc: [22:11] walters (wa...@ve...) joined #gstreamer. [22:13] ChristianHJW (~chr...@p5...) left irc: Client Quit [22:13] dolphy (~do...@21...) joined #gstreamer. [22:14] <BBB> minddog: I don't want to build, I want to give it a list of files to make a deb package of [22:14] <BBB> I have the binaries [22:14] <BBB> I simply want it to make a .deb package out of it [22:14] teuf (~te...@ln...) left irc: Remote closed the connection [22:14] <dolphy> BBB: i found the right way to do signals in interfaces [22:15] <BBB> oh, cool! how? [22:15] <dolphy> BBB: gtk+ people pointed me to gtktreemodel.c [22:15] <dolphy> BBB: they create the signal in the base_init method of the interface [22:15] <dolphy> BBB: and provide methods to trigger the signals [22:16] <dolphy> BBB: i think that's the good way to do it [22:16] <dolphy> BBB: then subclassing is not needed [22:16] <dolphy> BBB: we trash properties, put signals in the interface [22:16] <dolphy> BBB: and we are done [22:17] <BBB> sounds good [22:17] <BBB> so an interface *can* have signals? [22:17] <BBB> cute! I need that! [22:17] <BBB> propose something please! :) [22:19] <dolphy> hehe :) [22:19] <dolphy> why did you say we should not set the size [22:19] <dolphy> ? [22:23] <dolphy> BBB: what about caps ? [22:23] <dolphy> BBB: should we define something like gst_video_overlay_get_caps [22:23] <dolphy> where caps are something like : CAN_DO_HW_SCALING, CAN_DO_INTERACTIVITY, etc.. [22:26] <BBB> er... not yet [22:26] <BBB> first, simply make an interface of an overlay that we can embed in a gtkwidget [22:26] <ds-work> not at all [22:26] <BBB> that's enougjh [22:26] <BBB> if we need more, we'll find out when we need it [22:26] <BBB> don't make it harder than it needs to be [22:26] <BBB> the app needs to be completely clueless and it should still work [22:27] <BBB> everything should be automatic [22:27] <BBB> that's the end goal [22:28] <Company> ds-work: if i wanted to remove a subdir from gst-plugins, i'd have to remove references to that dir from my build [22:28] LarsAC (~PM...@p5...) joined #gstreamer. [22:28] <ds-work> Company: eh? [22:28] <Company> ds-work: those references are only in the makefile of the above dir and in configure.ac, right? [22:28] <ds-work> Company: yes [22:28] <dolphy> BBB: and what about the set size ? [22:28] <ds-work> Company: except for gst-libs stuff, obviously [22:29] <Company> ds-work: my idea was to include switches in autogen.sh to remove those dirs [22:29] <Company> ds-work: like --enable-fedora or something [22:29] <ds-work> Company: automake will hate you if you try that [22:30] <Company> ds-work: well, i just need to grep -v configure.ac and do stuff to the makefile.am for every dir i want removed, that sounds like a reasonably easy hack [22:31] <BBB> dolphy: why would the widget care? [22:31] <Company> ds-work: and after that you could easily do make dist [22:31] <Company> and not have the files included that you don't want [22:31] <BBB> dolphy: if you want, then make a signal if capsnego is completed, have_size or so (doesn't xvideosink already have that?) and connect the widget to that signal [22:32] <Company> yes, xvideosink has it, but it should be an interface signal :) [22:32] <dolphy> BBB: and if i want to resize the video overlay ? [22:32] <dolphy> BBB: from the app ? [22:32] <Company> dolphy: resize the window it embeds in and call a function on the interface :) [22:34] <dolphy> Company: yes gst_video_overlay_set_geometry [22:34] <dolphy> Company: so we will have a set_size method [22:34] <Company> yeah [22:36] <BBB> dolphy: the video widget listens to the window, so it resizes automatically [22:36] <BBB> dolphy: in X, that's all automatic [22:36] <dolphy> BBB: but that works if the window is resized by the element [22:36] <dolphy> BBB: but if app is trying to zoom [22:36] <dolphy> BBB: what happens [22:37] <BBB> how do you mean? [22:37] <BBB> if the xwindow size changes [22:37] <BBB> then X will notice [22:37] <BBB> in v4lsrc, at least, the element will automatically notice and handle the resize [22:37] <BBB> there's no signals involved [22:38] <BBB> this is all internal to the X protocol [22:38] <dolphy> ok but the app has no pointer to the v4lsrc window [22:38] <dolphy> so how does the app double its size ? [22:40] <BBB> sure it does [22:40] <BBB> it gives the XID of the GdkWindow to v4lsrc [22:40] <BBB> so both have a XID pointer to the window [22:41] <dolphy> that works for X [22:41] <dolphy> not for dfb [22:42] <BBB> well, as I said, write a proposal and think of a way to do it - easily - in dfb, too [22:42] <BBB> in X, this is how it works [22:43] <BBB> there's no need to do it exactly the same for both cases. they'll be different plugins and the widget will have to contain separate code for both anyway [22:43] <BBB> so if the interface differs slightly for both, it doesn't matter at all [22:43] <BBB> just make it as easy as possible for both [22:43] teuf_ (~te...@ln...) joined #gstreamer. [22:43] Nick change: teuf_ -> teuf [22:43] <Company> v4lsrc does not check for an interface in xvideosink, does it? [22:45] <teuf> will gst_pad_pull properly suspend my element until there is data available, or will it start an active loop to poll if there is data ? [22:46] sjoerd (sj...@be...) left irc: Read error: 113 (No route to host) [22:46] <Company> gst_pad_pull will actively look for the data [22:46] <Company> which means it will query the next element for data and [22:46] <Company> so on, until it finds data [22:47] meck (~me...@45...) joined #gstreamer. [22:47] <meck> Hi guys [22:47] <Company> hi [22:47] <BBB> Company: of course not [22:48] <meck> anyone knows how is going the rtp ? [22:48] <BBB> wasn't ramon doing that? [22:48] <meck> BBB : i guess . [22:49] <meck> BBB: but i haven't any news about him :-/ [22:49] sjoerd (sjoerd@2001:888:1d84:0:201:2ff:fee1:4c19) joined #gstreamer. [22:50] <meck> BBB : i've been too busy to do anythung more :-/ but i hope i can commit the rtp core soon [22:50] <BBB> neither do I... I'm too busy with my gst-rec dev right now... I need to finish that [22:50] <BBB> I'm trying not to be online too much, so I'll actually do some work [22:51] <Company> BBB: how do v4lsrc and xvideosink communicate the xwindow? [22:51] <meck> BBB : sure , priorities rules [22:51] <Zeenix> hi meck [22:52] <meck> Zeenix, hey !!!! how're u ? [22:53] <Zeenix> fine it seems [22:53] <meck> Zeenix, cool ! [22:53] <meck> Zeenix, did you code anything about rtsp ? [22:54] <Zeenix> meck: shamefully nothing [22:54] <Zeenix> :( [22:55] <meck> Zeenix, too busy with other stuff i guess , bah ! you'll do it :-) [22:55] <Zeenix> meck: yes, but sucks the most is that i have too many interests and i am still a layman [22:56] <meck> Zeenix, How french people say " petit a petit " :-) [22:58] <BBB> Company: they don't [23:00] <teuf> hmm, the cpu seems to be hogged because of the call to gst_bytestream_read (which calls gst_pad_pull). Are there some things i should know before callin gst_pad_pull ? [23:02] <Company> teuf: no, it's supposed to work in every case i think [23:02] <ds-work> what is gst_pad_pull() returning? [23:03] <teuf> Company: well, it works, but it seems to hog the cpu :) [23:03] <Company> what pipeline are you running? [23:03] <wheels> heh -- nastly -- 0.6.4 plugins don't compile with GCC 2.95 either. ;-) [23:03] <teuf> ds-work: I dunno, it's all handled by gstbytestream [23:03] <teuf> Company: filesrc ! shnparse ! osssink [23:04] <teuf> I removed the filesrc and directly read a file from shnparse instead of pad_pulling, and cpu is at 5% [23:05] <Company> osssink is supposed to block the thread when it has enough data [23:05] <Company> teuf: your element is loopbased, right? [23:06] <teuf> yep [23:06] <teuf> loop based is upposed to roughly look like while (1) [ gst_pad_pull () ... gst_pad_push () }, right? [23:06] <Company> teuf: yep [23:07] <Company> chain-based elements are lighter though because they don't need their own cothreads, but both should work [23:07] <Company> ah, stoip [23:07] <Company> teuf: not the while (1) part [23:07] <teuf> ah ? [23:07] <Company> teuf: they should return after 1 iteration [23:08] <teuf> oops [23:08] <teuf> so after pushing I should return ? [23:08] <Company> yeah [23:08] <teuf> I suck :) [23:09] <Company> no, our docs or naming conventions do [23:09] <Company> everrybody does this the wrong way ;) [23:10] <teuf> I should write some docs about the problems I encountered, but I fear I won't do it :( [23:10] <Company> heh [23:19] sjoerd (sjoerd@2001:888:1d84:0:201:2ff:fee1:4c19) left irc: Read error: 113 (No route to host) [23:19] Uraeus (~csc...@wp...) joined #gstreamer. [23:20] <Uraeus> yo [23:20] <teuf> it still maxes the cpu when I remove my while (1) :( [23:20] <teuf> evening Uraeus [23:23] <meck> Hola Uraeus :-P [23:23] <ds-work> Uraeus: hey, could you update the gstreamer.net front page for 0.6.4? [23:23] <ds-work> er, nm [23:23] <Uraeus> ds-work: did so this morning [23:24] <Uraeus> ds-work: I am now just waiting to be allowed to update it for 0.7.1 :) [23:24] <Company> teuf: is that an 0.6 or HEAD plugin? [23:24] <teuf> Company: hea [23:24] <teuf> d [23:24] <Company> teuf: could you upload the C file and an shn so i can have a look? [23:25] <Company> we should rewrite the registry parsing to be more robust [23:25] <Company> it should be able to handle broken files without crashing [23:25] sjoerd (sj...@be...) joined #gstreamer. [23:25] <Zeenix> hi Uraeus [23:26] <Uraeus> hey Zeenix [23:28] <Zeenix> cool, MS thinks that i am an MS Customer and sends me a detailed email :) [23:32] Action: ds-work runs 'make check' with G_DEBUG=fatal_warnings [23:32] <Uraeus> Zeenix: sure it is not spam= [23:32] <Uraeus> s/=/?/ [23:33] <Zeenix> Uraeus: no, could be :) [23:33] <teuf> Company: it's all there http://cfergeau.free.fr/shn/ [23:33] <teuf> I didn't put the whole shn file since it was too big [23:41] <Company> np [23:41] Action: Company looks [23:41] LarsAC (~PM...@p5...) left irc: [23:43] <Company> teuf: some small stuff i noticed while glancing over the code: [23:44] <Company> teuf: setting caps of NULL (which happens on error) is a bit dangerous, you should gst_element_error out in that case [23:44] <Company> teuf: and you access the buffer after gst_pad_pushing it, which is not allowed [23:45] ain (~ia...@us...) joined #gstreamer. [23:45] <teuf> oh, I quickly readded the timestamping and didn't put it in the right palce :) [23:46] <teuf> and error handling is indeed mostly crap atm (ie it's not there at all) [23:47] foser (d0...@22...) left irc: "[ I want to believe ]" [23:47] <Company> k [23:49] <teuf> hmm, when can I get NULL and set caps on NULL ? [23:50] <teuf> ah ok, found it [23:51] <Company> teuf: i'm missing a shorten.h file [23:51] <teuf> yeah, sorry [23:51] <teuf> I added it at the same url [23:53] <ain> teuf; you've written a .shn decoder? [23:53] <ds-work> teuf: btw, use GST_CAPS_NONE and GST_CAPS_ANY instead of NULL [23:53] <ds-work> currently they are both mapped to NULL, but that will change soon [23:54] <teuf> ain: mostly, it can decode files (though it may crash at eos), but hogs the cpu [23:54] <teuf> and it's unfortunately based on some non free code :( [23:55] <ain> yeah, shorten the program has a sucky licence [23:55] <teuf> ain: I mailed softsound to ask if they agreed to relicense the code I used as gpl or lgpl, I don't know if they'll answer :) [23:56] <ain> hmm, doubt you'll get a response [23:56] <ain> they've kinda given up on shorten from what I can tell [23:57] <ain> some other guy has taken over maintainership/developing it [23:57] Nick change: TD[out] -> TD [23:57] <teuf> yeah, that was also my feeling, but that doesn't cost anything to ask [23:59] <teuf> if they don't answer, maybe I could rewrite the 2 files I ripped straight from shorten and licence the whole thing as gpl or lgpl, though it would be a bit questionable [00:00] --- Wed Oct 15 2003 [00:00] <ain> they hold patents on it I think too [00:00] <teuf> ah crap :( [00:01] <teuf> hmm, as far as I understood their compression algorithm, it doesn't look especially innovative [00:02] <ain> I'm not sure if they do have patents, I can't really remember [00:03] <ds-work> wheels: don't you have CVS access? [00:03] <wheels> ds-work: no [00:04] <wheels> ds-work: And amazing as it was -- SF's anonymous CVS actually worked... [00:07] Action: teuf was also amazed to be able to cvs update with no problems [00:07] <wheels> It was like fast even... [00:07] <ain> wheels: where is taglib found? [00:08] <wheels> ain: CVS, or? [00:08] dolphy (~do...@21...) left irc: "Network down, IP Packets delivered via UPS" [00:08] <ds-work> wheels: I'd add you, but it appears I'm not a project admin [00:09] <ain> wheels: just a tarball or something [00:09] <ds-work> wheels: that way, you'd eventually be grandfathered into a GNOME CVS account :) [00:09] <wheels> ds-work: So long as the address remains "wh...@kd...". :-) [00:09] <wheels> Let the subversion begin. :-) [00:10] <ain> wheels: I think you'd get a wh...@gn... which would redirect to wh...@kd... :) [00:10] <wheels> ain: The one that I have up is pretty out of date -- just a sec and I'll update it... [00:11] <wheels> Actually the kde addresses are just redirects too... [00:11] <wheels> So it would then go something like wh...@gn... -> wh...@kd... -> sc...@sl... [00:12] teuf (~te...@ln...) left irc: Remote closed the connection [00:12] Action: wheels was actually just looking -- it should be pretty darn easy to port Kaboodle (KDE's "simple" player) to GStreamer, which I might do with a little #ifdef hackery post 3.2... [00:16] <ds-work> JuK still uses arts by default, correct? [00:17] <Uraeus> wheels: you should get a wh...@gn... too, so... [truncated message content] |