From: IRC <wt...@us...> - 2003-04-27 05:41:50
|
******************************************************************* [03:03] ChrisHJW (~chr...@p5...) joined #gstreamer. [03:14] Marsupilami23 (~Mar...@15...) joined #gstreamer. [03:18] rcaskey (~rc...@c-...) joined #gstreamer. [03:26] hadley (~hadley@65.112.179.158) joined #gstreamer. [03:33] gort (~jg...@cs...) joined #gstreamer. [03:46] foser (d0...@22...) left irc: Remote closed the connection [04:02] ct_ (~Chr...@th...) joined #gstreamer. [04:14] ChrisHJW (~chr...@p5...) left irc: [04:19] ct (~Chr...@th...) left irc: Read error: 110 (Connection timed out) [04:22] Company (~Company@pD958BAB1.dip.t-dialin.net) left irc: Read error: 60 (Operation timed out) [04:34] hadley (~hadley@65.112.179.158) left irc: Read error: 60 (Operation timed out) [04:34] seth__ (~hadley@65.112.179.130) joined #gstreamer. [04:35] 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!" [04:35] Marsupilami23 (~Mar...@15...) joined #gstreamer. [04:55] Marsupilami23 (~Mar...@15...) left irc: Remote closed the connection [05:06] seth__ (~hadley@65.112.179.130) left irc: "Client exiting" [05:18] rcaskey (~rc...@c-...) left irc: "Client exiting" [05:22] Marsupilami23 (~Mar...@15...) joined #gstreamer. [05:22] gort (~jg...@cs...) left irc: "Client exiting" [05:38] rcaskey (~rc...@c-...) joined #gstreamer. [05:48] thomasvs_ (~thomas@217.136.120.171) joined #gstreamer. [06:03] 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!" [06:05] thomasvs (~th...@12...) left irc: Read error: 110 (Connection timed out) [06:35] rcaskey (~rc...@c-...) left irc: Remote closed the connection [06:44] rcaskey (~rc...@c-...) joined #gstreamer. [06:45] walters (wa...@ve...) joined #gstreamer. [06:50] <rcaskey> how do I tell gstreamer that I want it to use esd and not oss? [06:50] <rcaskey> all my gstreamer apps seem to insist on oss [06:55] <walters> rcaskey: fire up gconf-editor and change /system/gstreamer/default/audiosink [06:55] <rcaskey> ok, thanks [06:59] <rcaskey> do I need to do something to restart gstreamer or something, its still trying osssink [06:59] <walters> you will probably have to restart most gstreamer-using apps right now yes [06:59] <walters> that needs to be fixed. [07:03] rcaskey (~rc...@c-...) left irc: "Client exiting" [07:10] ct_ (~Chr...@th...) left irc: "Client exiting" [07:14] rcaskey (~rc...@c-...) joined #gstreamer. [07:33] chrisime (~chrisime@pD9E8C82D.dip0.t-ipconnect.de) left irc: Read error: 110 (Connection timed out) [07:36] ChrisHJW (~chr...@p5...) joined #gstreamer. [08:16] Action: walters chuckles at idiottest.mk [08:37] rcaskey (~rc...@c-...) left irc: Remote closed the connection [08:53] vishnu (~joshua@61.11.23.245) joined #gstreamer. [08:54] <vishnu> where can i get the library for the new divx plugin? [09:01] joshua_ (~joshua@61.11.23.245) joined #gstreamer. [09:01] vishnu (~joshua@61.11.23.245) left irc: Read error: 104 (Connection reset by peer) [09:08] joshua__ (~joshua@61.11.23.245) joined #gstreamer. [09:08] joshua_ (~joshua@61.11.23.245) left irc: Read error: 104 (Connection reset by peer) [09:08] Nick change: joshua__ -> vishnu [09:08] <vishnu> ping? [09:19] vishnu (~joshua@61.11.23.245) left irc: "Client Exiting" [09:57] <walters> what do people think about having GError * in the api? [09:58] <walters> ah, nevermind, i see there's a few already. [09:58] <walters> i'll just continue the nascent trend :) [10:02] BBB (~rb...@01...) joined #gstreamer. [10:28] vishnu (~joshua@61.11.23.245) joined #gstreamer. [10:29] <vishnu> ping [10:33] walters (wa...@ve...) left irc: "I like core dumps" [11:10] <vishnu> ping [11:18] <harshy> ping [11:23] Last message repeated 4 time(s). [11:23] <steveb> PING [11:23] <harshy> hehe [11:23] <harshy> glad to see gst is alive this saturday morning [11:26] <vishnu> ping [11:26] harshy (~ha...@dh...) left irc: "I quit for now" [11:27] harshy (~ha...@dh...) joined #gstreamer. [11:32] sethn (~se...@be...) joined #gstreamer. [11:34] foser (d0...@22...) joined #gstreamer. [11:34] chrisime (~chrisime@pD9E8C8A3.dip0.t-ipconnect.de) joined #gstreamer. [11:39] sethn (~se...@be...) left irc: Connection reset by peer [11:50] kz (~Keizi@211.183.209.126) joined #gstreamer. [11:50] <kz> how to exec gst-launch, to test gsttextoverlay? [11:50] <kz> gst-launch filesrc location="wasabi.avi" ! avidemux ! textoverlay ! xvideosink [11:50] <kz> don't work. [12:03] BBB (~rb...@01...) left irc: "Client Exiting" [12:05] BBB (~rb...@01...) joined #gstreamer. [12:09] kz (~Keizi@211.183.209.126) left irc: "In an open world, who needs windows and gates?" [12:10] gernot (~ge...@a2...) joined #gstreamer. [12:10] <gernot> yo ! Let's have some fun with timesync and seeking today ;) [12:10] foser (d0...@22...) left irc: Remote closed the connection [12:10] <gernot> (well, me at least ;) ) [12:12] <steveb> thomasvs_: here? [12:13] <steveb> thomasvs_: i'm going to bed now, but i'd like your opinion on this... [12:15] <steveb> I've changed all the *.uninstalled.pc.in files to not point to the .la files - like this: [12:15] <steveb> -Libs: ${libdir}/gst/libgstreamer-@GST_MAJORMINOR@.la [12:15] <steveb> +Libs: -L${libdir}/gst -lgstreamer-@GST_MAJORMINOR@ [12:16] chrisime (~chrisime@pD9E8C8A3.dip0.t-ipconnect.de) left irc: "Client exiting" [12:16] <steveb> i've found a lot less weird shit happens when I build against uninstalled gstreamer, and i'd like to commit the changes [12:16] <gernot> looks reasonable, I'd say, but I'm not involved very much with GStreamer dev :-) [12:16] <BBB> no, that's bad, steveb [12:16] <BBB> I'd rather see it the other way around [12:17] <BBB> using uninstalled gstreamer is a pita already, but your changes *require* it to be installed [12:17] <steveb> poo [12:17] <BBB> .la is horrible, but there's nothing better for uninstalled gstreamer [12:17] <steveb> but I can build against uninstalled with these changes [12:17] <BBB> can you? [12:17] <BBB> I've tried that (with mjpegtools ;) ) once, it didn't work for me [12:17] <BBB> I had to point to the .la files [12:17] <steveb> well, gst-player i can. totem i can't but that was choking on the .la files anyway [12:17] <BBB> -l... to uninstalled files didn't work [12:18] <BBB> can you put the patch on bugzilla so I can test it out? [12:18] <BBB> I'd be interested in getting uninstalled gst to work fully [12:18] <BBB> which currently doesn't work here [12:18] Action: BBB hates build issues ;) [12:18] <vishnu> yah, i haven't had problems building against uninstalled pkgs [12:19] <steveb> ok. i should revert the changes and post the weird shit I was getting [12:19] <vishnu> i was only doing this: export PKG_CONFIG_PATH=/home/joshua/gst/gstreamer:/home/joshua/gst/gst-plugins [12:19] <steveb> sleep time [12:19] <vishnu> and it was ok [12:20] Nick change: steveb -> stevebZ [12:22] <vishnu> BBB: what about avimux? looked at it yet? [12:23] <BBB> yes, but what's the issue? [12:24] <vishnu> BBB: i have some patches for ffmpeg sitting in bugzilla. apply them then try to transcode mpeg->avi. then investigate why the result doesn't playback with mplayer [12:25] <vishnu> BBB: is divxenc good for anything yet? (can anything playback the output?) [12:26] <BBB> there already is a gstffmpegcodecmap.h, isn't there? [12:26] <vishnu> no [12:27] <vishnu> that's why i added it. there is one function signature to export [12:27] <BBB> gstffmpegcodecmap.h [12:27] <BBB> it is here [12:27] <vishnu> eh? [12:28] <vishnu> server: I know nothing about gstffmpegcodecmap.h [12:28] <vishnu> dunno, i'm diffing against HEAD [12:28] <vishnu> cat the file [12:28] <vishnu> do you see the prototype for gst_ffmpegcodec_codec_context_to_caps? [12:29] <BBB> no [12:29] <vishnu> yah .. so .. [12:30] <BBB> GstCaps * [12:30] <BBB> gst_ffmpeg_codecid_to_caps (enum CodecID codec_id, [12:30] <BBB> AVCodecContext *context); [12:30] <BBB> [12:30] <BBB> enum CodecID [12:30] <BBB> gst_ffmpeg_caps_to_codecid (GstCaps *caps, [12:30] <BBB> AVCodecContext *context); [12:30] <BBB> apparently, it's a weird stuff here [12:30] <BBB> ohwell [12:30] <vishnu> that's the other .h file [12:30] <vishnu> there are two similarly named files [12:30] <BBB> yes [12:30] <BBB> one is for my temporary fixup [12:30] <BBB> (I want to remove it in the long term) [12:30] <vishnu> gstffmpegallcodecmap.h & gstffmpegcodecmap.h [12:30] <BBB> they're the same here [12:30] <BBB> ohwell [12:30] <BBB> whatever [12:31] <BBB> anyway, shower first [12:31] <gernot> öh, what is g_signal_connect (pipeline, "deep_notify", G_CALLBACK (gst_element_default_deep_notify), NULL); [12:31] <gernot> [12:31] <vishnu> k [12:31] <BBB> I'll look at the patches after that [12:32] <BBB> oh, and joshua... I do think that my gstffmpegallcodecmap.c is a *lot* better than gstffmpegcodecmap.c - even when we'll go back to using ffenc_* and ffdec_* (I prefer that), I'd like to use my codecmapper [12:32] <BBB> (just personal opinion) [12:32] <vishnu> BBB: yah, whatever [12:32] <vishnu> BBB: i'm results oriented. if it works i'm happy. [12:33] <BBB> Yeah, so is wtay... I'd rather see things being implemented in a good way [12:33] <BBB> I'm not a professional coder, I like style and stuff ;) [12:33] <BBB> anyway, showertime [12:33] <BBB> brb [12:34] Action: vishnu thinks wtay is an optimization freak [12:34] Action: vishnu shudders thinking about wtay's early code [12:35] sxpert (~sx...@sx...) left irc: "Client exiting" [12:43] ChrisHJW (~chr...@p5...) left irc: Read error: 104 (Connection reset by peer) [12:43] ChrisHJW (~chr...@p5...) joined #gstreamer. [12:52] <gernot> vishnu: Early optimization is the death of all code development, I agree ;) [12:52] <gernot> Ok, found out what deep_notify is [12:53] <vishnu> gernot: yup, fortunately wtay isn't the only hardcode gstreamer developer anymore [12:53] <vishnu> hardcore, i mean [12:53] Company (~Company@pD958BA17.dip.t-dialin.net) joined #gstreamer. [12:55] <gernot> Hi Company ! Hope I didn't scare you away yesterday with my overscholarly comments ? ;) [12:55] <gernot> I just picked them up from Google, so it hasn't been growing on my dung, to phrase it the Austrian way ;) [12:56] <Company> i know that you took them from google [12:56] <gernot> vishnu: yes, it's always good to have a good mixture of coders [12:56] <Company> i got used to people that have no clue pasting links [12:56] <Company> :p [12:56] <gernot> wheee, wait a minute - wasn't it relevant ? [12:57] <Company> nope [12:57] <gernot> But it was about gint64 being casted the wrong way, right ? [12:57] <gernot> I mean, that implies that you always have to cast 0 to (gint64) [12:57] <Company> i went into the #c channel and asked people there :) [12:57] <Company> yep [12:58] <gernot> well, that was basically what I wanted to imply with that info, too [12:58] <Company> but the links were about NULL being casted wrong on 64bits machines and some such [12:58] <gernot> I didn't hear anything from you anymore, so I couldn't discuss it with you :-) [12:58] <Company> i didn't solve that problem tho [12:58] <Company> you still have to cast your 0 to int64 [12:59] <gernot> Company: well, I guess you basically _can't_ solve that prob [12:59] <gernot> it's a restriction of the language [12:59] <Company> i'd like to have a compiler directive telling the compiler what variables to expect and warnbing you if they are wrong [13:00] <Company> just like it checks printf [13:00] <gernot> Right, I see what you mean ... then you need to talk to the gcc guys ;) [13:01] <Company> i'll probably do so [13:03] Action: vishnu is happy with i386 [13:04] <Company> vishnu: that was a compiler problem on i386 :p [13:04] <Company> vishnu: btw - i've updated the gst-launch manpage in cvs HEAD [13:05] <vishnu> Company: yah, i saw that commit. thanks!! [13:05] <vishnu> Company: now you'll really get good feedback from happy users [13:06] <Company> well, pleasing users is my primary goal atm :) [13:06] <gernot> perfect ! That one had caused me some confusion in the beginning :-) [13:06] <gernot> I would like to ask what the difference between _element_ seeking and _pad_ seeking is ? [13:06] <Company> the bugreports from users are the reason why 0.6.1 is so much more stable than 0.6.0 [13:07] <BBB> gernot: good coding requires a good schema before actually starting... first make drawings, only then start the framework, and then the implementation :) [13:07] <BBB> gernot: I've rewritten lavrec, for example ;) [13:07] <Company> gernot: apps are supposed to seek on elements, while the element implementation decides what to do and seeks on the desired pad then [13:07] <BBB> (well, I'm at 50% or so) [13:08] <vishnu> Company: i'm still waiting for 0.6.1 debs ... [13:08] <gernot> BBB: lavrec was a _hack_ already from the beginning, and I deny _all_ responsibility for it - it was _Rainer's_ code ! :] [13:08] <Company> BBB: good coding requires working code, not design docs [13:08] <Company> vishnu: i don't package stuff, bug taaz for debian [13:08] <vishnu> yah [13:09] <Company> BBB: if you have working code that is better than a good design doc _all_ of the time [13:09] <BBB> Company: I think it requires design, then framework, then implementation [13:09] <Company> BBB: that was what owen and me disagreed about in norway [13:09] <BBB> I know [13:09] <BBB> I agreed with Owen ;) [13:09] <gernot> Company: did you beat up ? ;) [13:09] <Company> no, if you have working code you can then use that as requirement and guide when reimplementing it [13:09] Action: gernot wants to see a clean coder fight over such issues one time [13:09] <BBB> gernot: I've rewritten it... I'll hopefully send a mail to mjpeg-developer in one or two weeks - it works really cool now [13:10] Action: gernot a physical one, of course [13:10] <Company> that's better than docs, because docs don't work ;) [13:10] <BBB> docs won't work, I know [13:10] <Company> no, we did not beat up each other - it was too cold, we were frozen in our seats [13:10] <BBB> but they can be a guide to making the actual code [13:10] <gernot> BBB: that's _great_ ! lavrec was in _great_ need of a fix ;) [13:10] <BBB> gernot: I know :P I worked with it from 1.4->1.6 [13:10] <Company> yeah, but code is a better guide than docs [13:10] <BBB> and it was horrible! [13:11] <BBB> Company: if the code speaks for itself, yes [13:11] <BBB> and in the case of lavrec (or gst-rec :X), that wasn't the case [13:11] <gernot> Company: was it _that_ cold ? Now we have 22 degrees outside ;) [13:11] <BBB> that's why I'm rewriting them so slowly [13:11] <Company> gernot: -5 inside [13:11] <BBB> it was fun, though ;) [13:11] <Company> yeah :) [13:11] Action: gernot laughs out loudly [13:11] <BBB> took us a day to heat up the second appartment :P [13:12] <BBB> gernot: I can upload two .h files for you, so you have an idea how it'll work now [13:12] <Company> i like working code better than docs [13:12] <gernot> but you both that we have _heated appartments_ here in Scandinavia, too, I hope ? ;) ;) [13:12] <Company> that was how i fixed GstThread and pipeline parsing [13:12] <Company> and it was actually _fast_ to do it [13:12] <gernot> BBB: yes, I can have a look at it [13:13] <gernot> for the seeking stuff: so element seeking sounds more intelligent, is it that what's used nowadays ? [13:13] <BBB> http://213.197.11.65/ronald/liblavrec.h [13:13] <BBB> http://213.197.11.65/ronald/liblavrec_plug.h [13:13] <Company> <Company> gernot: apps are supposed to seek on elements, while the element implementation decides what to do and seeks on the desired pad then [13:13] <BBB> the first is the app API, the second is the backend API [13:13] <BBB> backend API should actually be dymanically loadable libraries [13:13] <Company> what is lavrec btw? [13:13] <BBB> but I didn't do that yet [13:14] <BBB> Company: the predecessor of gst-rec [13:14] <BBB> a commandline recording tool [13:14] <gernot> Company: belongs to mjpeg.sf.net, it's the core recorder [13:14] <gernot> Company: that's how BBB dragged me here, BTW ;) [13:14] <BBB> the only tool that can record hardware MJPEG, apart from gst-launch v4lmjpegsrc ! filesink ;) [13:15] <Company> oh, video recording stuff - what a surprise ;) [13:15] <BBB> d'oh :P [13:15] <gernot> Company: yes, I got that, but I saw that there was a #define PAD_SEEK in seeking.c, so only one of them is active at a time [13:15] <Company> huh? [13:16] chrisime (~chrisime@pD9E8C8A3.dip0.t-ipconnect.de) joined #gstreamer. [13:16] <gernot> /usr/src/gst-plugins/examples/seeking/seek.c [13:16] <Company> BBB: you may btw use alsasrc now - it works complete with clocking and stuff [13:16] <gernot> static gboolean [13:16] <gernot> stop_seek (GtkWidget *widget, GdkEventButton *event, gpointer user_data) [13:16] <gernot> { [13:16] <Company> gernot: ouch, examples [13:16] <BBB> Company: that's extremely cool! :) [13:16] <gernot> Company: maaan, way to go ! [13:16] <Company> gernot: better look at gstplay [13:17] <Company> gernot: i don'T think somebody keeps our examples up to date [13:17] <BBB> we used to use that tool (lavrec) in the company I work for... after they wanted some more adapations, I decided it was time to trash all code, it was too hard to maintain... So I started empty, and rewrote it in 4 evenings :) - the whole code works so much better know... and it's more stable, too [13:17] <gernot> Company: seek still works, though, so your API seems to be stable ;) [13:18] <gernot> BBB: Real clean header files, maybe a bit too many structs for my taste, but if they're needed, they're needed [13:18] <Company> well, the API is not the problem, the code using that example is [13:18] <Company> flacenc was broken because of a missing cast [13:18] <gernot> Company: you said something about broken seeking, BTW; where does that occur ? [13:19] Action: gernot will try to avoid that version in the next time [13:19] <BBB> gernot: I dislike the structs too... but encoders, sources and files need different structs, hence the stuff ;) [13:19] <gernot> BBB: So you go - nice, nice ! :) [13:19] <BBB> mjpeg recording isn't implemented yet [13:19] <BBB> but v4l recording is, including all threading and so on [13:19] <BBB> it was stable from day one :) [13:19] <gernot> BBB: Which NV_pixel_data_range, I'm now up at 30 FPS for DVD-rez video in OpenGL !! :) [13:20] <BBB> which is pretty impressive if you remember all the mess [13:20] <BBB> 30fps GL? woohoo! [13:20] <gernot> BBB: pixel_data_range is about blitting directly to the graphics card, without an extra copy in video mem [13:20] Action: BBB wants to watch DVDs in Quake ;) [13:20] <gernot> BBB: Maan, you can consider yourself the new generation V4L-MJPEG guru then ;) [13:21] <BBB> imagine a cinema level where you've got to kill other players while watching movies :P [13:21] <gernot> BBB: Cause I'm an old man at it now [13:21] <BBB> gernot: well, I'm only a few years younger :o [13:21] <BBB> and gerd still needs to send the driver to linus [13:21] <BBB> (he's slow) [13:21] <BBB> from that point on, I'll be happy ;) [13:22] <gernot> BBB: yes, that's possible with the new cards - but bear in mind that this is _only_ for 400 polys, Quake needs some more CPU power ;) [13:22] Action: vishnu giggles about DVD in quake [13:22] <gernot> BBB: On the other side I only have an Athlon with 1.1 GHz [13:22] <gernot> BBB: The main problem for the moment is that Y, U, V planes can't be uploaded directly [13:23] <Company> yeah, use a webcam to record your sister and put that imagine in quake [13:23] <Company> loads of fun [13:23] <gernot> BBB: They have removed support for blitting 8-bit textures directly [13:23] <BBB> Company: 'kill, kill, kill'? :D [13:23] <Company> :D [13:23] <vishnu> :-) [13:23] <BBB> vishnu: well, it'd be cool [13:24] <gernot> well, you dislike your sister that much - put 2200 kms between you and her and you feel sooo much lighter :-} [13:24] <BBB> better than the lousy textures of grass in doom1 ;) [13:26] <Company> ok, i'm going to rewrite monkey-media now and implement proper metadata handling on the way [13:26] <gernot> And I will explore the wonders of seeking ;) [13:27] <gernot> BBB: Which gerd, BTW ? [13:34] <BBB> knorr [13:34] <BBB> (v4l/bttv/cx88x/saa7134/xawtv/streamer) [13:34] <BBB> the suse guy ;) [13:35] <gernot> BBB: Oh, he's employed by Suse ? [13:35] ^iain^ (~ia...@us...) joined #gstreamer. [13:36] Action: gernot is away: mat-food-Ässn [13:37] <BBB> iirc, yes [13:57] md` (~ill...@p5...) left irc: "Client exiting" [13:57] md` (~ill...@p5...) joined #gstreamer. [14:15] Action: gernot is back (gone 00:39:22) [14:15] <gernot> sorry, have to go now, StarCraft's calling :) [14:15] gernot (~ge...@a2...) left irc: "Client exiting" [14:38] gort (~jg...@cs...) joined #gstreamer. [14:47] BBB (~rb...@01...) left irc: "Client Exiting" [14:50] vishnu (~joshua@61.11.23.245) left irc: "Client Exiting" [15:24] gernot (~ge...@a2...) joined #gstreamer. [15:25] <gernot> Yo ! just checked what happens if I deactivate PAD_SEEK in gst-plugins/examples/seeking/seeking.c [15:25] <gernot> doesn't work to seek, just to let you know (so: element seeking didn't work in that example anymore) [15:26] <gernot> but I don't use the latest CVS yet [15:28] Nick change: wtay-zZz -> wtay [15:28] <wtay> yo [15:29] <Company> hi [15:41] <gernot> A question: How do I know which pads I have to tell to seek ? [15:42] <gernot> If e.g. I have filesrc->mpeg2dec->fakesink, which pad is the one I should tell to seek ? E.g. filesrc->src ? [15:43] <wtay> gernot: always on the sink element [15:44] <Company> and you should tell the element to seek [15:44] <wtay> yes [15:44] <gernot> aha, so pad seeking is no good ? [15:44] <wtay> not for what you want :) [15:45] <gernot> because .... it's too complicated ? [15:45] <wtay> because a seek event should pass all elements ideally [15:46] <wtay> sending it to the sink ensures that [15:46] <gernot> But if I have two sinks, I need to send it to both in that case, right ? [15:46] <wtay> yes [15:46] <gernot> and it propagates over thread boundaries ? [15:46] <wtay> it's equivalent to sending a pad seek to the src pad connected to the sink in most cases [15:46] <Company> sure [15:47] <wtay> gernot: the pipeline must be PAUSED to perform a seek [15:47] <gernot> wtay: jupp, saw that:-) [15:47] <wtay> Company: still getting segfaults in parse with threads [15:48] <wtay> gst-launch -v --gst-mask=-1 { fakesrc num_buffers=5 ! identity error_after=3 ! fakesink } [15:51] <gernot> Oh, with that info I could fix gst-plugins/examples/seeking/seeking.c again ! :-) [15:51] <gernot> I will update CVS and then send you a patch [15:54] <Company> wtay: one of my stupid oversights because i don't run with --gst-mask=-1 often enough [15:54] <wtay> Company: is it a debugging statement that causes a segfault? [15:55] <Company> wtay: fix is commited [15:55] <wtay> GST_ELEMENT_NAME (gst_thread_get_current())? [15:56] <Company> yup [15:56] <Company> gst_thread_current might be NULL [15:56] <wtay> got the state change... [15:56] <wtay> (process:21712): GStreamer-WARNING **: element thread0 claimed state-change success,but state didn't change to PAUSED. State is READY (NONE_PENDING pending), fix the element [15:56] <wtay> (process:21638): GStreamer-WARNING **: inconsistent state information, fix threading please [15:56] <Company> if the current thread is the main pipeline [15:56] <Company> yup [15:56] <Company> there's a comment in the source file [15:57] <wtay> for the warning? [15:57] <Company> which references a bug where i explained the problem [15:57] <Company> yes [15:57] <Company> the inconsistent state information warning [16:01] <wtay> do we need to lock the bin to protect the variables? [16:02] <gernot> is pad seeking still something the user should learn, or should it be removed completely/marked as deprecated in seeking.c [16:02] <wtay> gernot: it's still needed [16:02] <gernot> in which cases ? Or just in case ? [16:02] <wtay> gernot: if you don't have a sink for example [16:03] <gernot> wtay: So I see - will put that info in the code while I'm already at it :-) [16:03] <wtay> gernot: wasn't there a switch to use pad or element seeking? [16:03] <gernot> The thing was that all the muxed formats still used the demuxer as the seekable element [16:03] <gernot> wtay: yes, there is, but no docs for it [16:05] <Company> wtay: i don't know a good way to solve this problem - that's why i did the workaround and made it emit the warning [16:05] <wtay> ok [16:06] <wtay> should remove the \n from the GST_DEBUG strings, for some reason it's not needed [16:08] <^iain^> if it uses g_warning then a \n is added [16:09] <^iain^> wtay: opt scheduler is going into an infinite loop for me [16:09] <^iain^> wtay; http://discomachinegun.prettypeople.org/~iain/log.gz is the log [16:10] kris (~kr...@84...) joined #gstreamer. [16:10] <^iain^> hey kris [16:10] <^iain^> I found out how Soundforge does markers [16:10] <kris> hey iain [16:10] <kris> oh, cool [16:11] <kris> I ended up using amadeus on mac os x for what I wanted to do [16:11] <kris> it was a little slow, but it worked [16:11] <^iain^> well, I figured you'd not wait for marlin, but I want to have markers into 0.1 when its released [16:11] <kris> cool [16:12] <kris> also saving a section between two given markers is a really useful option [16:12] <^iain^> *nod* [16:13] <gernot> wtay: How do I do this with elements: gst_pad_query (pad, GST_QUERY_TOTAL, &format, &duration); [16:13] <wtay> ^iain^: marlin-sample-sink is scheduled but it doesn't produce any data [16:13] <wtay> gernot: s/pad/element/ [16:13] <^iain^> wtay; okay, how do I stop it being scheduled? [16:13] <wtay> gernot: with the element as first arg [16:14] <wtay> ^iain^: make marlin-sample-sink create and EOS event when it's done? [16:14] <gernot> wtay: ok, easy ! [16:14] <^iain^> wtay; hmm, okay. I thought I was doing that. Thanks [16:17] <wtay> Company: the problem seems to be very specific to gst-launch [16:18] <wtay> Company: as it uses gst_element_wait_state_change which is triggered right in the middle of the state change function [16:21] Uraeus (~csc...@wp...) joined #gstreamer. [16:21] <Company> wtay: you can imagine context switches in other programs at the time this is triggered, so its definitely not threadsafe [16:21] <Company> wtay: but it works on uniprocessors, yes [16:21] <Uraeus> ello' [16:22] <wtay> Company: notifying the parent of the state change is certainly not thread safe [16:23] <Uraeus> wtay: http://bugzilla.gnome.org/show_bug.cgi?id=104840 <- do we have a reply to alex on this one? [16:23] <Uraeus> gernot: around? [16:23] <wtay> Company: but this warning in -launch is because we signal the cond variable at the wrong time [16:23] <gernot> gernot: yes ! :) [16:23] Action: gernot brightens up [16:24] <wtay> Uraeus: his explanation doesn't fit with my observations.. [16:25] <Uraeus> wtay: what about the posix api question? you know the answer to that? [16:26] <Uraeus> gernot: I get this build error: main.c:8:21: Cg/cgGL.h: No such file or directory [16:26] <Uraeus> gernot: and afaict there is no Cg dir in the tarball you sent me [16:26] <wtay> Uraeus: lseek returns -1 if the seek failed, they should return an error then [16:26] <gernot> gah, just got a problem compiling CVS: make[2]: *** No rule to make target `alaw-conversion.c', needed by `libgstalaw_la-alaw-conversion.lo'. Stop. [16:26] <wtay> Uraeus: I'll write a reply [16:26] <Uraeus> wtay: ok, thanks [16:28] <gernot> Uraeus: you need to download the Cg compiler from http://developer.nvidia.com/view.asp?PAGE=cg_main [16:28] <gernot> Uraeus: got a recent graphics card ? [16:28] <Uraeus> gernot: got a Ti200 or something [16:28] <gernot> Uraeus: just great ! [16:28] <gernot> Uraeus: let's kick its butt with this soft ;) [16:29] gort (~jg...@cs...) left irc: "Client exiting" [16:29] <gernot> Uraeus: there is a new release on www.geofront.se/gstsert.tar.gz [16:29] <gernot> Uraeus: 'guess I will set up a CVS soon - want an account ? [16:30] <Uraeus> gernot: well why not put it into gstreamer cvs as a separate module? [16:30] <gernot> to the compile error: haven't redone with autogen.sh yet [16:31] <Uraeus> gernot: I can give you CVS access to gst CVS right away if you want [16:31] <gernot> Uraeus: I won't be able to maintain it, my development will diverge very soon [16:31] <gernot> Uraeus: let's have a look at it together and we'll talk about it afterwards :-) [16:31] <Uraeus> gernot: ok, sure :) [16:33] <gernot> Uraeus: so you're download the Cg libs ? [16:33] <Uraeus> gernot: and installed them, unpacking your new version now :) [16:33] <gernot> Uraeus: efficient. [16:33] <gernot> Uraeus: ;) [16:36] <gernot> Uraeus: good, you see main.c ? that's the prog [16:36] <Uraeus> gernot: /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libglut.so: undefined reference to `glXBindChannelToWindowSGIX' [16:36] <Uraeus> /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libglut.so: undefined reference to `XGetExtensionVersion' [16:36] <Uraeus> /usr/lib/gcc-lib/i386-redhat-linux/3.2.2/../../../libglut.so: undefined reference to `XFreeDeviceList' [16:36] <gernot> Uraeus: you can _only_ feed it with MJPEG streams [16:36] <Uraeus> gernot: do I need some other special stuff? [16:36] <gernot> Uraeus: MPEG video streams, I mean [16:37] <gernot> Uraeus: huh ? hmmm ... [16:37] <gernot> have you ever compiled GLUT apps on your system ? [16:37] <Uraeus> gernot: not since latest re-install no [16:38] <gernot> Uraeus: otherwise I suggest to download a new GLUT version, non-rpm [16:38] <gernot> Uraeus: http://www.sgi.com/software/opengl/glut.html [16:39] <Uraeus> ok, I do that [16:39] <wtay> Company: I move the g_cond_signal to set_state so that the waiting threads are not unlocked in the middle of the state change function [16:40] <Uraeus> wtay: managed to look into this one yet? http://bugzilla.gnome.org/show_bug.cgi?id=111198 [16:40] <wtay> Company: not quite correct but... [16:41] <gernot> Uraeus: wait ! :) libXi [16:42] <wtay> Uraeus: that's tricky as GObject refcounting is not threadsafe and we cannot implement a wrapper for it [16:42] <gernot> Uraeus: add -lXi in the libs [16:42] <gernot> Uraeus: yepp, that's the one ! [16:43] <wtay> Uraeus: but I'll see if it's really that problem [16:43] <Uraeus> wtay: ok, if not I guess we need to come up with a workaround right? [16:43] <Uraeus> gernot: ok [16:44] <gernot> Uraeus: now, generate MPEG video only with mplayer -dumpvideo abc.mpeg; mv stream.dump abc.m2v [16:44] <Uraeus> gernot: please let me compile first :) [16:44] <gernot> Uraeus: sure ! [16:45] <gernot> Uraeus: which CPU do you have ? [16:45] <Uraeus> gernot: Athlon 650 [16:55] Uraeus (~csc...@wp...) left irc: "Client exiting" [16:58] dolphy (~do...@21...) joined #gstreamer. [17:04] Uraeus (~csc...@wp...) joined #gstreamer. [17:05] Vakor (ms...@c1...) left irc: Remote closed the connection [17:05] Vakor (ms...@c1...) joined #gstreamer. [17:17] Nick change: wtay -> wtay-shwr [17:28] <gernot> my compiler problem was solved with ./autogen.sh [17:35] meiker (55...@mo...) joined #gstreamer. [17:41] <Company> yay [17:41] <Company> i have installed a working cvs server [17:41] <thaytan> pserver or ssh? [17:42] <Company> pserver [17:43] <thaytan> coolo [17:44] <Company> it's not even difficult [17:44] <Company> i figured i need a way to backup and manage my code and that was easiest [17:45] <thaytan> *nod* [17:46] <thaytan> just remember pserver passwords are sent cleartext [17:47] <Company> doesn't matter, it's local [17:47] pb_ (~pb...@pc...) got netsplit. [17:48] <Company> though it should work remote, too [17:48] <thaytan> I just have a local cvs repository and use SSH for access [17:49] <thomasvs_> I never quite understood why people want pserver cvs when ssh is so easy to set up [17:49] <thaytan> so no pserver, and the auth is SSH based [17:49] <thaytan> thomasvs_: I can only understand it for anon ro accounts [17:51] pb_ (~pb...@pc...) returned to #gstreamer. [17:51] pb_ (~pb...@pc...) left irc: Remote closed the connection [17:51] <Company> well i just used pserver because the docs were for pserver [17:57] Uraeus (~csc...@wp...) left irc: "Client exiting" [17:58] pb_ (~pb...@pc...) joined #gstreamer. [17:59] ericdfields (~er...@bg...) joined #gstreamer. [17:59] <ericdfields> I get this error message when i try to run net-rhythmbox: [17:59] <ericdfields> Failed to create the player: Failed to create gnomevfssrc input element; check your installation [17:59] <ericdfields> any suggestions? [18:02] <Company> i know it's a common error, but i don't know the solution [18:02] Nick change: wtay-shwr -> wtay [18:02] <ericdfields> Company: this may have something to do with it... i can't play a file using gst-launch or gst-launch-ext [18:03] <wtay> ericdfields: what does "gst-inspect gnomevfssrc" say? [18:03] <ericdfields> wtay: no such element or plugin 'gnomevfssrc' [18:03] <wtay> ericdfields: do you have the gnomevfssrc plugin installed? [18:04] <ericdfields> ....... [18:04] <ericdfields> now i do :) [18:05] <ericdfields> wtay: now i'm getting something about a "volume element" not being present [18:05] kris (~kr...@84...) got netsplit. [18:05] gernot (~ge...@a2...) got netsplit. [18:05] thaytan (ja...@ad...) got netsplit. [18:05] <wtay> ericdfields: you need another plugin, I think something with audio elements [18:05] BBB (~rb...@a8...) joined #gstreamer. [18:05] <ericdfields> wtay: audio-effects? [18:07] kris (~kr...@84...) returned to #gstreamer. [18:07] gernot (~ge...@a2...) returned to #gstreamer. [18:07] thaytan (ja...@ad...) returned to #gstreamer. [18:07] <wtay> dunno, try it :) [18:07] <Company> it's called volume [18:07] pb_ (~pb...@pc...) got netsplit. [18:08] <Company> or gstvolume [18:08] <ericdfields> wtay: alright. i got net-rhythmbox working, but it segfaults. it probably has to do with the fact that i've been unable to launch media w/ gst-launch. i get this every time i try: "ERROR: pipeline could not be constructed: Invalid syntax" [18:08] <Company> and someone had the same problem yesterday with an installed gnomevfssrc [18:09] <Company> ericdfields: what pipelines have you tried with gst-launch? [18:09] <ericdfields> Company: um.... [18:09] <ericdfields> i give up [18:09] <ericdfields> (no clue) [18:10] <wtay> ericdfields: is this with CVS or 0.6.1 gstreamer? [18:10] <ericdfields> 6.1 [18:11] <ericdfields> from their apt-repository [18:11] <BBB> 'their'? [18:11] <Company> you can't just run "gst-launch" without any arguments [18:11] <BBB> you mean 'our'? [18:11] <Company> you should try reading the manpage :) [18:11] <ericdfields> Company: "gst-launch hello.mp3" yeilds the error [18:11] <ericdfields> :-p [18:11] <wtay> ericdfields: try gst-launch -v fakesrc ! fakesink [18:12] <ericdfields> BBB: sorry :) [18:12] <BBB> gst-launch bla.mp3 is not a valid pipeline [18:12] <BBB> read the manpage ;) [18:12] <wtay> gst-launch-ext bla.mp3 shoud work though [18:12] <ericdfields> wtay: its doin stuff [18:13] pb_ (~pb...@pc...) got lost in the net-split. [18:13] <wtay> ericdfields: gst-launch -v filesrc location=bla.mp3 ! mad ! osssink then [18:13] <ericdfields> wtay: yeah, that doesn't work either [18:13] <wtay> ericdfields: gst-inspect mad [18:13] <BBB> 'doesn't work' is not really helpful [18:13] <BBB> what's the error? [18:13] <BBB> etc. [18:13] <ericdfields> BBB scroll up? [18:14] <Company> i guess you're missing a lot of plugins [18:14] <Company> like the mad plugin for example [18:14] <BBB> it should say 'plugin not found: mad' then [18:14] <ericdfields> BBB it do [18:14] <BBB> ? [18:14] <BBB> then install the mad RPM...? [18:15] <ericdfields> ...all works now. [18:15] <BBB> or we need netRB to require the mad RPMs, although that's not really what 'Requires:' is used for normally [18:16] <BBB> or can we say 'Suggested: gstreamer-mad'? [18:16] <ericdfields> i think it should be made clear somewhere on the apt page about installing all these various plugins, especially if people keep getting the same kind of errors due to a lack of plugins. [18:16] <Company> BBB: net-rb should say "failed to create 'mad' plugin" and some such, but not require it [18:16] Nick change: wtay -> wtay-brb [18:16] <BBB> ok... [18:17] <Company> ideally it should say "Error finding decoder. Are you sure you have GStreamer plugins installed that can play $mimetype?" [18:17] <Company> but it doesn't use spider ;) [18:19] harshy (~ha...@dh...) left irc: "driver update" [18:19] <BBB> yes... [18:19] <BBB> I do agree there, but that's a netRB issue [18:19] <BBB> gst-launch has clear output, imho [18:22] pb_ (~pb...@pc...) joined #gstreamer. [18:23] <Company> yes, gst-launch has quite clear output [18:24] <BBB> thomasvs_: fix the apt thing please! sound-juicer, gst-editor, gst-player, netRB, libmusicbrainz, monkeymedia, *everything* is being automatically destroyed in there [18:24] <Company> though i should possibly implement a better error in HEAD for empty pipelines [18:24] <BBB> there's no use in me fixing it, because your sync scripts destroys everything, that's useless [18:25] <BBB> please make this more generically usable or make it otherwise fixed, but this is no use [18:28] ericdfields (~er...@bg...) left irc: "Client exiting" [18:30] <BBB> (talking about fubar) [18:35] <Company> BBB: could you look at vishnu's segfault mail if it isn't fixed already? [18:35] <Company> "divxenc testing" [18:36] <BBB> divxenc isn't for generic use yet [18:36] <BBB> and my mail is broken since two days [18:36] <Company> oh [18:36] <Company> might be in the archives tho [18:37] <Company> and avimux doesn't take divx yet :) [18:38] <BBB> I know, I've said that a million times [18:38] <BBB> the mimetypes don't match [18:38] <BBB> and I'll fix the mimetypes in gst in general [18:39] <Company> ah right, i remember [18:40] <BBB> in general, if divxenc segfaults, I wouldn't be surprised if he had header/lib incompatibility... that happens quite a lot if you've got multiple versions of divx4linux and co installed... xvid used to provide such headers too ("compatibility layer" - layer my ass, didn't work), etc. [18:40] <Company> i'm just telling you what happens on -devel :) [18:40] <BBB> ok, thnx ;) [18:40] <BBB> I can't reply [18:40] <BBB> :) [18:40] <Company> well, vishnu is lever enough to ask here [18:41] <Company> ... and should be shot for using divx and not xvid anyway [18:41] Action: Company is proud owner of a gnome cvs account now [18:44] <BBB> hm... tell the 95% of the people that uses divx rather than xvid [18:44] Action: BBB is not a purist [18:45] <BBB> if he wants to use divx, that's perfectly fine with me... I'm using divx too, I don't see any reason not to [18:46] <Company> it's closed source [18:46] <Company> i can't debug his segfaults [18:46] <BBB> true... I'm guessing his system is fubar'ed [18:47] <BBB> normally, if you have xvid's encoder/decoder headers installed on RH73 or so with the libs from divx4linux, or if you use gcc296 anyway, the stack will get smashes [18:47] <BBB> it's undebuggable [18:51] gernot (~ge...@a2...) got netsplit. [18:51] thaytan (ja...@ad...) got netsplit. [18:51] kris (~kr...@84...) got netsplit. [18:54] kris (~kr...@84...) returned to #gstreamer. [18:54] gernot (~ge...@a2...) returned to #gstreamer. [18:54] thaytan (ja...@ad...) returned to #gstreamer. [18:54] kris_ (~kr...@84...) joined #gstreamer. [18:54] kris (~kr...@84...) left irc: Read error: 104 (Connection reset by peer) [18:54] vishnu (~joshua@61.11.23.245) joined #gstreamer. [18:56] <Company> BBB, wtay-brb: http://bugzilla.gnome.org/show_bug.cgi?id=111634 is NOTABUG, right? [18:56] <meiker> whois dmwaters [18:57] <BBB> Company: I'll check [18:58] <BBB> what's his problem? [18:58] <BBB> I don't get it at all [18:58] kris_ (~kr...@84...) got netsplit. [18:58] gernot (~ge...@a2...) got netsplit. [18:58] thaytan (ja...@ad...) got netsplit. [18:58] <vishnu> heh, tell him to stop single quoting his launch lines [18:59] kris (~kr...@84...) joined #gstreamer. [19:01] <BBB> vishnu: what system do you run? RH73? [19:01] gernot (~ge...@a2...) returned to #gstreamer. [19:01] thaytan (ja...@ad...) returned to #gstreamer. [19:01] gernot (~ge...@a2...) got netsplit. [19:01] thaytan (ja...@ad...) got netsplit. [19:01] <vishnu> BBB: debian i386 (& transmeta) [19:01] gernot (~ge...@a2...) returned to #gstreamer. [19:01] thaytan (ja...@ad...) returned to #gstreamer. [19:02] <BBB> hm... [19:02] <vishnu> BBB: i'm foolishing running 2.5.66 now, but i should switch back to 2.4.x [19:02] <BBB> I'd say so, yes [19:02] <BBB> for the divx bugreport, please make a bugzilla thing and point me to it [19:02] <BBB> I'm not reading email currently (broken again... *argh*) [19:02] <vishnu> BBB: but that doesn't explain why divenc can't connect to avimux [19:02] <BBB> mimetypes differ [19:03] <BBB> I'll fix that later [19:03] <vishnu> BBB: the pads aren't compatible at all [19:03] <BBB> I know [19:03] <vishnu> ya [19:03] <vishnu> k [19:03] <BBB> they're not supposed to be (yet) ;) [19:03] <BBB> video/avi is plain wrong - I want to fix that later on in HEAD [19:03] <vishnu> BBB: i'm really excited -- we'll have two divx encoders (ffmpeg & divx) and two avi muxers (yours and ffmpeg) [19:04] kris_ (~kr...@84...) got lost in the net-split. [19:04] <BBB> we'll have xvid too [19:04] <BBB> :) [19:04] <vishnu> BBB: what is xvid? [19:04] <BBB> opensource divx sort of thing [19:04] <BBB> ISO MPEG4 compatible, just like divx [19:05] <BBB> is supposed to be slightly better than divx5 [19:05] <vishnu> BBB: another one?! wow, that's crazy [19:05] <BBB> yeah ;) [19:05] <vishnu> better than divx5? wow, gotta check it out [19:06] <BBB> as opposed to opendivx, 3ivx and all these, xvid actually got out of alpha and is used by many people [19:06] <BBB> xvid is quite nice [19:06] <BBB> 3ivx/opendivx are dead anyway [19:06] <vishnu> d/l 0.9.1 xvid now [19:07] Action: vishnu hears his modem make a slurping sound [19:07] Action: nDuff tries to remember the name of the codec the Ogg folks adopted [19:07] <nDuff> (err, video codec) [19:08] <kris> theora? [19:09] <Company> tarkin? [19:09] <Company> tanotherunfinishedoggcodec? [19:09] <Vakor> nDuff: theora. [19:10] hadess (~ha...@pc...) joined #gstreamer. [19:10] <hadess> hey [19:10] <hadess> dolphy: j'ai fixe la playlist [19:10] <Company> hi [19:10] <hadess> hi Company [19:10] <BBB> vp3 [19:10] <Company> ha, that's wrong french, the e should be an ? [19:11] <hadess> Company: yeah, but i have a uk kbd, and i can't be fucked [19:11] <Company> and vera does print no difference for ' and ' [19:12] <Company> oh, vous ?tes excus? [19:12] <Company> or something [19:12] <hadess> dolphy: and i'm going to break the api by changing the "changed" signal [19:17] <dolphy> hadess: rahh [19:18] BBB (~rb...@a8...) left irc: Read error: 104 (Connection reset by peer) [19:18] <hadess> dolphy: hmm, en fait, non, yen a pas besoin... [19:18] <dolphy> hadess: comment ca va ? [19:18] <hadess> dolphy: ca va, je suis claque, mais ca va [19:18] BBB (~rb...@a8...) joined #gstreamer. [19:19] <dolphy> hadess: c t quoi la playlist ? [19:19] <hadess> dolphy: j'oubliais de mettre a jour le treepath pour ->current [19:20] <hadess> dolphy: comme le treepath changeait, ca changeait aussi l'item en court [19:21] <hadess> dolphy: ca corrige le probleme 1) ca changeait d'item quand tu bougeais le movie qui jouait 2) ca laissait l'icone en place [19:23] <thaytan> woohoo! [19:23] <thaytan> I can play an mp3 with a resurrected xmms plugin [19:23] <thaytan> still needs a bit of work tho [19:23] <dolphy> hadess: yep ca marchait pas top :) [19:23] <hadess> dolphy: tu peux tester maintenant ? [19:23] <dolphy> hadess: j'update mon repository [19:24] <hadess> dolphy: je suis en train de corriger http://bugzilla.gnome.org/show_bug.cgi?id=111239 [19:25] <dolphy> hadess: dans gst-player c ce que je faisais [19:25] <hadess> dolphy: quoi ? [19:27] <dolphy> hadess: #111239 [19:27] <dolphy> hadess: le fait d un current-removed qui provoque un play_next [19:28] <hadess> dolphy: oh [19:28] <hadess> dolphy: et ca marchait ? [19:28] <dolphy> hadess: ben ouais [19:28] <dolphy> hadess: la playlist marche tip top now [19:29] Uraeus (~csc...@wp...) joined #gstreamer. [19:31] <Uraeus> gernot: why is the video image upside down? [19:31] <gernot> Uraeus: ah, don't care, that can be fixed easily .-) [19:34] <hadess> dolphy: au fait, t'as tjrs pas repondu a mon mail, a propos du lockup XInitThreads [19:36] <Company> yeah, he just needs to turn his monitor around [19:38] <dolphy> hadess: yep [19:39] <dolphy> hadess: je reteste [19:39] Marsupilami24 (~Mar...@15...) joined #gstreamer. [19:39] <gernot> Company: don't be so sarcastic ;) ... in OpenGL, you just need to reverse the texture coordinates, or turn the model ;) [19:40] <dolphy> hadess: j ai installe le package [19:40] <gernot> I have big trouble with the seeking; seeking.c works, without PAD_SEEK (so seeking onelements) [19:40] <dolphy> hadess: je change le if 0 [19:40] <dolphy> hadess: et je reessaye [19:40] <gernot> But every time I want to do a seek, the player doesn't hand me any frames anymore [19:40] <gernot> same for xvideosink, without any handoff [19:43] Nick change: thomasvs_ -> thomasvs [19:44] <gernot> Do I need a queue when I do seeking ? [19:44] vishnu (~joshua@61.11.23.245) left irc: Read error: 104 (Connection reset by peer) [19:45] vishnu (~joshua@61.11.23.245) joined #gstreamer. [19:53] vishnu (~joshua@61.11.23.245) left irc: "Client Exiting" [19:54] Action: Company shuts up, because he has no idea how apps are supposed to seek - he only fixes elements ;) [19:54] <gernot> OK - maybe it has to do with threads ( have none such, but seeking.c has), will continue debugging later on [19:54] pb_ (~pb...@pc...) left irc: Remote closed the connection [19:55] <gernot> ah well, later ! See ya all ! :-) [19:55] gernot (~ge...@a2...) left irc: "Client exiting" [19:56] gernot (~ge...@a2...) joined #gstreamer. [19:56] Action: gernot is away: just listening whilst I'm away [19:56] pb_ (~pb...@pc...) joined #gstreamer. [20:00] chrisime (~chrisime@pD9E8C8A3.dip0.t-ipconnect.de) left irc: "leggets mich ;)" [20:14] <dolphy> Company: i m adding a gst_element_set_state (vis_video_thread, gst_element_get_state (pipeline)); [20:14] <dolphy> Company: in gst_play_connect_visualisation [20:15] <dolphy> Company: so that if the vis video thread was not connected when pipeline playback started [20:15] <dolphy> Company: and it gets connected later it needs to be set to PLAYING [20:18] <dolphy> Company: but it seems to make some troubles. [20:19] <Company> 0.6.1 or HEAD? [20:19] <Company> and what trouble? [20:20] <dolphy> Company: HEAD [20:20] <dolphy> Company: when i do that i get (gst-player:10702): GLib-GObject-WARNING **: gsignal.c:2535: invalid unclassed param spec pointer for value type `GParam' [20:20] <dolphy> Company: and then nothing happens [20:20] <dolphy> Company: the pipeline stop playing [20:21] <dolphy> Company: a backtrace shows that it s waiting in gst_thread_main_loop [20:22] <Company> hm [20:22] <Company> i'd check where that warning comes from first [20:23] <Company> and if that isn't the cause you will have to commit that code so i can debug it [20:44] <thaytan> grrr [20:44] <thaytan> this is shitting me [20:44] <thaytan> I can't figure out where this c file is finding a particular function defn [20:44] <thaytan> but it isn't complaining about an implicit defn, so it must be SOMEWHERE [20:44] <thaytan> grepping practically my whole HD has turned up nothing tho [20:44] <thaytan> is there some way it might be implicitly defined WITHOUT the warning? [20:45] Nick change: wtay-brb -> wtay-away [20:52] <thaytan> no takers? [20:58] <thaytan> g'night, all [20:59] <thomasvs> thaytan: in a header ? [20:59] <thomasvs> thaytan: any include can bring it in, basically [20:59] <thaytan> yeah, but I can't find the header [20:59] <thaytan> I've grepped my little hard drive to bits :) [20:59] <BBB> thomasvs: the apt repository is heavily broken, please fix your sync script or turn it off [21:00] <thaytan> anyway, apart from a few plugins which use symbols which they shouldn't, I have the xmms plugin working again well enough to use xmms input and effects plugins [21:00] <thaytan> I'll work on visualisations tomorrow :) [21:01] <BBB> that's cool [21:01] <BBB> xmms-glib1? [21:02] <thaytan> I'll work on visualisations tomorrow :) [21:02] <thaytan> grr [21:02] <thaytan> yes, xmms plugins are glib-1.2 [21:02] <thaytan> I hadn't actually noticed that [21:03] <thaytan> it seems to work with simple pipes tho [21:03] <BBB> yes it does [21:03] <BBB> it's just not nice :( [21:03] <Company> uh oh ah [21:03] <Company> syymbol clashes on masse [21:04] <Company> and it only works as long as the functions are somehat compatible [21:04] <BBB> not if you use pipes [21:04] <BBB> :) [21:04] <Company> out of process xmms plugin wrappers? [21:04] <Company> that sounds extremely fast [21:05] <Company> i'm gonna switch from filesrc [21:05] <BBB> lol :D [21:08] <Company> we should maybe add another priority for autplugging [21:08] <Company> like #define GST_PRIORITY_OOP_GLIB (-G_MAXINT-1) [21:08] <Company> or #define GST_PRIORITY_OOP_GLIB_V1 (-G_MAXINT-1) [21:09] <BBB> G_MININT? [21:09] <BBB> ;) [21:09] <Company> does that exist? [21:09] <BBB> yes [21:09] <Company> hm, something didn't exist from those types [21:09] <Company> G_MINUINT for example ;) [21:11] <BBB> G_MINUINT is 0 by definition [21:11] <BBB> so there's no symbol for that [21:11] <Company> :p [21:11] <Company> G_MAXINT32 isn't defined [21:11] <BBB> G_MININT depends on the size of int [21:11] <BBB> hm, it isn't?... [21:11] <BBB> weird... [21:11] <BBB> ohwell [21:11] <Company> no [21:11] <Company> you can just use 0x7FFFFFFF [21:12] <Company> but it's not defined [21:12] <Company> only for 64bit types [21:12] <BBB> hmk... [21:13] <BBB> maybe because G_MAXINT is always G_MAXINT32? [21:13] <Company> nope [21:13] <Company> on 64bit machines that's definitely not true [21:13] <Company> because gint is the samew size as gpointer [21:14] hadess (~ha...@pc...) left irc: "swootchie bootchies" [21:15] <BBB> Company: ? [21:15] <BBB> Company: no! [21:15] <BBB> long is the same size as gpoitner [21:15] <BBB> int is always 32bit [21:15] <Company> huh? [21:15] <BBB> int is always 32, long and gpointer are the size of the arch [21:16] <Company> http://developer.gnome.org/doc/API/2.0/glib/glib-Type-Conversion-Macros.html [21:16] <Company> and the c spec says int >= 16bit, long >= 32 bit [21:16] <BBB> yes, yes, but that's the C spec [21:17] <BBB> in modern OSes on normal archs, long is the size of the arch and int is 32 bit [21:17] <Company> they probably did that for compatibility reasons [21:17] <BBB> and then I mean win2k, linux 2.4 (glibc-2.2/2.3), etc. [21:17] <Company> because everybody assumes int=32bit [21:17] <BBB> yes [21:17] <BBB> and if that's reality, then why bother? [21:17] <Company> well [21:18] <Company> because those type conversion macros don't work then? [21:18] <BBB> lol :) [21:18] <BBB> trye [21:18] <BBB> s/y/u/ [21:18] <BBB> anyway, they do work on normal archs, and that's all we care about for now [21:18] <BBB> it's not our problem anyway [21:18] <Company> oh [21:18] <BBB> ;) [21:18] <Company> ok [21:18] <Company> Remember, YOU MAY NOT STORE POINTERS IN INTEGERS. THIS IS NOT PORTABLE IN ANY WAY SHAPE OR FORM. [21:18] <BBB> I know :) [21:18] <BBB> wouldn't work anyway [21:18] <BBB> you'd need to use uints :P [21:19] <Company> they should call it GINT_FROM_POINTER then and not GPOINTER_TO_INT [21:19] <Company> compatibility sucks [21:20] <Company> it's gonna take 5 more years when we all use 64bit and everybody will assume long is always 64 bits [21:25] <BBB> that'll suck [21:26] <Company> it sucks already when sizeof(int) != sizeof(void *) [21:31] <Company> somebody should just for fun redefine in to be 64bits and try compiling and running everything and file bug reports :( [21:32] rb (~rlb@66.37.237.141) joined #gstreamer. [21:42] hadley (~hadley@65.112.179.161) joined #gstreamer. [21:52] rcaskey (~rc...@c-...) joined #gstreamer. [21:58] cschalle_ (~csc...@wp...) joined #gstreamer. [22:07] rb (~rlb@66.37.237.141) left #gstreamer ("Client exiting"). [22:08] Nick change: taazzzz -> taaz [22:09] ChrHJW_log (~cwi...@p5...) joined #gstreamer. [22:14] <Company> taaz: morning [22:14] <Company> taaz: what ETA do i tell people who want 0.6.1 in sid? [22:16] Uraeus (~csc...@wp...) left irc: Read error: 110 (Connection timed out) [22:24] Marsupilami24 (~Mar...@15...) left irc: Read error: 60 (Operation timed out) [22:26] walters (wa...@ve...) joined #gstreamer. [22:27] <walters> taaz: nag nag nag ;) [22:30] <Company> walters: fix my net-rb bugs please :) [22:31] <walters> mmm [22:31] <walters> what are your bugs? [22:31] <Company> 111655 [22:31] <walters> keep in mind i have no access to the rhythmbox bugzilla [22:32] <walters> in fact jorn doesn't want netrb bugs there. [22:32] <Company> just look at the bug [22:32] <walters> i need to get a bugzilla component [22:32] <Company> i'm pretty sure it's a rb bug too anyway [22:33] <Company> and i get 4 netRhythmbox-CRITICAL **: file rb-node.c: line 470 (rb_node_unref): assertion `RB_IS_NODE (node)' failed everytime i close net-rb [22:33] <walters> i've gotten those occasionally [22:33] <walters> it's really frustrating [22:33] <walters> i think it's a race condition in the node code [22:33] <walters> although i'm not sure honestly [22:33] <Company> i get them everytime [22:33] <walters> right [22:33] <walters> it means the node db got corrupted [22:34] <Company> nice [22:34] <walters> i hate the node code honestly :) [22:34] <Company> so you need better code there [22:34] <walters> i want to rip it out and replace it with a real database [22:34] <walters> the code is good...i just think it tries to do too much [22:34] <Company> i don't think it's good [22:34] <Company> everything refs every other thing [22:35] <walters> yeah [22:35] <walters> with all sorts of interleaved locking going on [22:35] <Company> i didn't even understand it [22:35] <walters> and these special cases [22:35] <walters> i don't either [22:35] <Company> oh, i have a fix for cd warnings on startup (i have no /dev/cdrom) [22:36] <walters> Company: do you have commit access to gnome cvs yet? [22:36] <Company> yep [22:36] <Company> since today [22:36] <walters> Company: please commit at will [22:36] <Company> :) [22:36] <Company> thx [22:36] <walters> Company: as long as it's not a really intrusive patch or anything :) [22:36] <walters> just please do make ChangeLog entries [22:36] <Company> yeah, i'll just commit the mm -> libparty switch without telling <you ;) [22:36] <walters> heh [22:37] <Company> do changelogs have some specific format? [22:37] <walters> Company: we use the GNU/GNOME style changelog entries [22:38] <Company> is this documented somehow or do i just look at it and figure it out? [22:38] <walters> well [22:38] <walters> in emacs i hit C-x 4 a [22:38] <walters> i think there are other tools to do it in different editors [22:38] <Company> ok, so i'm officially f*cked :) [22:39] <walters> like there's a cvs2cl script floating about that takes your cvs commit messages and generates GNU-style ChangeLog entries i think [22:39] <Company> gedit and anjuta don't seem to have that ;) [22:39] <walters> there's a debian package of cvs2cl at least [22:40] <walters> also http://www.red-bean.com/cvs2cl/ [22:40] <walters> woah [22:40] <walters> it was just updated 4 days ago [22:41] Action: taaz hides [22:41] Action: walters pounches [22:41] <walters> er [22:41] Action: walters pounces too [22:42] <taaz> i'll definately have time for this stuff after tuesday afternoon [22:42] <walters> ok [22:42] <taaz> school stuff taking quite a bit of my time... slowly getting the bugs cleared up though [22:43] <walters> Company: were you getting those node errors with cvs or with 0.4.7.1? [22:43] <Company> walters: they're quite old [22:43] <BBB> Company: gedit is not an IDE [22:43] <BBB> :P [22:43] <Company> walters: i already got them when i fixed the buffering stuff [22:45] <Company> hm, we should use cvs2cl in gstreamer [22:45] <thomasvs> BBB: it'd be less broken if it didn't got crap injected at some point :) [22:45] <thomasvs> BBB: and concrete examples are better than general comments [22:45] <Company> but it parses only committed stuff [22:45] <walters> Company: yeah, i think so [22:45] Action: walters likes ChangeLogs [22:45] <Company> i hate the way changelogs need to be done [22:46] <Company> i'm used to going into gst-plugins/ext/alsa and do cvs ci -m ther [22:46] <BBB> thomasvs: apt-get install gstreamer-a52dec doesn't work? [22:46] <Company> i'll never have a changewlog included that way [22:46] <BBB> thomasvs: sound-juicer, net-rhythmbox, gstreamer-player, gst-editor RPMs aren't there [22:46] <thomasvs> BBB: because you are mixing repositories [22:46] <thomasvs> BBB: because I'm slowly properly rebuilding those [22:47] <BBB> uhm... right :D [22:47] Action: walters listens to Evanescence - Tourniquet really loud [22:49] <dolphy> thomasvs: i ve got one user complaining that building gst-player makes ld crash [22:50] <thomasvs> dolphy: bug report ? [22:50] <dolphy> thomasvs: no not yet [22:50] <walters> dolphy: are they using debian unstable as of like a week or so ago? [22:50] <dolphy> walters: no home built system [22:50] <walters> ok, nm then. [22:50] <dolphy> walters: he told the whole gnome build with no pbs [22:51] <dolphy> walters: even gstreamer but gst-player makes ld segfault [22:51] <dolphy> that sounds really weird to me [22:52] <thomasvs> BBB: for example, this snippet from net-rhythmbox is broken [22:52] <thomasvs> %post -p /sbin/ldconfig [22:52] <thomasvs> export GCONF_CONFIG_SOURCE=`gconftool-2 --ge... [truncated message content] |