IRC Logs

*******************************************************************
[03:05] <bitshifter> hmm, if I have a custom sink element as part of my program, how do I register it with GStreamer without making it an external plugin/lib?
[03:05] <ds-work> bitshifter: look at gstreamer/testsuite/plugins
[03:05] hadley ([email protected]) joined #gstreamer.
[03:06] <ds-work> there's a statically linked element in there somewhere
[03:06] <ds-work> it's not hard
[03:06] <bitshifter> ds-work: thanks
[03:07] <ds-work> er, those aren't very transparent
[03:08] <ds-work> basically, you replace GST_PLUGIN_DEFINE() with GST_PLUGIN_DEFINE_STATIC()
[03:08] <ds-work> and link it into your app
[03:11] <Company> you can either run gst_element_register yourself or just work with the element without registering
[03:11] <Company> an element doesn't need to be registered to be used
[03:11] Company ([email protected]) left irc: "Duede, where's my question mark!"
[03:11] Company ([email protected]) joined #gstreamer.
[03:15] lilo ([email protected]) joined #gstreamer.
[03:19] <bitshifter> ds-work: great, works like a charm. Thanks again
[03:22] <ds-work> bitshifter: Company's idea is probably better, although equivalent
[03:24] <bitshifter> hmm, what I did now is that I have a GST_PLUGIN_DEFINE_STATIC() block, and then in the plugin_init() function call gst_element_register(). Does that sound alright?
[03:24] <ds-work> yeah
[03:25] <ds-work> but you can equivalently do the same gst_element_register() call from main()
[03:25] <ds-work> doing it with GST_PLUGIN_DEFINE_STATIC() gives you the option of easily splitting into a separate .so
[03:26] <bitshifter> I still have the problem that the sink only seems to receive data for the first element being created, but not for others (in new pipelines)
[03:26] <bitshifter> but that might just be something completely unrelated 
[03:26] <ds-work> probably
[03:26] <ds-work> that sounds like a global variable issue
[03:27] alley_cat ([email protected]) left irc: Read error: 60 (Operation timed out)
[03:30] <bitshifter> yeah. doesn't help much when the debugging statements are buggy. Works all fine now :)
[03:31] <ds-work> heh
[03:37] Company ([email protected]) left irc: Read error: 110 (Connection timed out)
[03:58] aldug_ ([email protected]) left irc: Operation timed out
[03:59] aldug ([email protected]) joined #gstreamer.
[04:16] taf2 ([email protected]) joined #gstreamer.
[04:17] <taf2> is gst-python still being maintained?
[04:21] <ds-work> it hasn't been updated in a while
[04:22] <ds-work> but the main developer is still mostly active, although busy
[04:26] <taf2> ds-work: thx
[04:26] <taf2> i'll check out cvs then
[04:33] <taf2> there are lot of warnnings in cvs too :( any idea how stable gst-python bindings are...
[04:35] <ds-work> dunno, ping taaz
[04:37] <taf2> taaz: ping
[04:40] Company ([email protected]) joined #gstreamer.
[04:48] ct_ ([email protected]) joined #gstreamer.
[05:09] water ([email protected]) joined #gstreamer.
[05:09] hadley ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[05:09] ct_ ([email protected]) left irc: "Client exiting"
[05:14] harshy ([email protected]) joined #gstreamer.
[05:16] water ([email protected]) left #gstreamer ("The water has parted.").
[05:41] walters ([email protected]) left irc: "brb"
[05:42] <taaz> taf2: ?
[05:44] <ds-work> what's the status of gst-python?
[05:49] Action: ds-work notes that it doesn't compile
[05:51] The_Company ([email protected]) joined #gstreamer.
[05:52] walters ([email protected]) joined #gstreamer.
[05:52] hadley ([email protected]) joined #gstreamer.
[06:02] <taf2> taaz: whats the status of gst-python?
[06:04] <taaz> it doesn't compile? hmm.
[06:07] <taaz> yeah, i guess it wouldn't.
[06:07] <taaz> i've got fixes for that
[06:09] Action: ds-work idly wonders when they'll be checked in
[06:10] Company ([email protected]) left irc: Read error: 110 (Connection timed out)
[06:10] <taaz> i'll do that now.
[06:11] <taaz> actually, they don't compile right now for me either ;)
[06:11] <taaz> some interface handling code is busted
[06:12] <ds-work> doesn't matter
[06:16] <taaz> eh... needs some changes to -plugins .pc files too
[06:16] <ds-work> such as?
[06:16] <ds-work> why?
[06:17] <taaz> to get include dirs
[06:17] <ds-work> what's wrong with it?
[06:19] <taaz> just a sec...
[06:21] danb ([email protected]) joined #gstreamer.
[06:24] <taf2> taaz: i got the lastest cvs to compile
[06:24] <taaz> if you try to get the includedir var from the uninstalled pc files you get the wrong path
[06:24] <taf2> just had to add a symbolic link to common
[06:24] <taf2> although i was unsuccessful in getting the examples to run because i don't think it generated any .py stubs
[06:27] <taaz> huh?
[06:27] <ds-work> oh, I don't run uninstalled
[06:28] <taf2> taaz: i compiled an installed gst-python from cvs but when i ran the examples they did not run because they couldn't import gstreamer
[06:28] <taf2> perhaps i'm misunderstanding something as i'm pretty new to python
[06:29] <taf2> but i thought a gstreamer.py file was needed
[06:29] <taf2> and i couldn't find one
[06:29] <taaz> it uses gstreamer/__init__.py
[06:29] <taf2> so assumed that was why import gstreamer did not work
[06:29] <taaz> if the build dir is in your python path it should work
[06:30] <taf2> just sec i'll try again
[06:30] <taaz> i really don't test installed so it might be broken
[06:31] <ds-work> http://www.schleef.org/~ds/gst-python.log
[06:32] desrt ([email protected]) joined #gstreamer.
[06:32] <desrt> is there a way to get fakesink to request a certain stream type?
[06:32] <desrt> (like audio/raw)
[06:32] <ds-work> desrt: use filtered caps
[06:33] <taaz> ds-work: yeah, i'm committing some fixes in a sec
[06:33] <ds-work>  ! audio/x-raw-int ! fakesink
[06:33] <desrt> how do i write that in C?
[06:33] <ds-work> desrt: gst_element_link_filtered(), iirc
[06:33] <desrt> (btw: i wrote functions to read metadata from vorbisfile... they're a bit hackish.  do you want them?)
[06:34] <ds-work> not really
[06:34] <desrt> i figured not :)
[06:34] <ds-work> we're switching to using oggdemux and vorbisdec
[06:34] <desrt> oh.  excellent.
[06:34] <desrt> and because of the fact that spider works again these days i don't need to know that :)
[06:34] <ds-work> but keep the patch, others may think it's more useful
[06:34] <desrt> well.. i'm using it myself right now, so it's not going anywhere
[06:35] Action: taf2 its late sleep time
[06:46] <desrt> hm.  not doing the right thing.
[06:48] <desrt> i'm trying to read metadata like this: src ! spider ! audio/x-raw-int ! fakesink
[06:48] <desrt> because without audio/x-raw-int, spider just picks the identity plugin
[06:49] <ds-work> er, you want application/x-gst-tags
[06:49] <walters> desrt: you could see how metadata/rb-metadata-gst.c does it...
[06:50] <desrt> rb does gst metadata these days?  cool.
[06:50] <walters> yep, in --0.7
[06:50] <desrt> ds-work; worked perfectly :)
[06:50] <desrt> why doesn't audio do the right thing, btw?
[06:50] <ds-work> probably picks the wrong element
[06:51] <taaz> ok, pushed my latest gst-python updates
[06:52] <taaz> might need to disable the interfaces dir for it to build though
[06:52] <taaz> some strange error with it trying to use GST_TYPE_*_TYPE symbols
[06:52] <ds-work> http://www.schleef.org/~ds/gst-python.log
[06:53] <ds-work> looks like missed #include
[06:53] <taaz> oh? i don't think those are real symbols
[06:54] <taaz> the _TYPE at the end shouldn't be there
[06:54] <ds-work> ah, yeah
[06:54] <taaz> it thinks those are constants or something... i'm not sure why it started doing that
[06:55] Action: desrt tries to remember tla
[06:55] Action: desrt uses cvs :)
[06:56] <taaz> that stuff used to build ok.  not that it really matters since the interface code is all bogus anyway.  pygtk doesn't support the way gst uses interfaces
[06:56] Action: taaz looks at jdahlin ;)
[06:58] harshy|lap ([email protected]) joined #gstreamer.
[06:58] harshy ([email protected]) left irc: Read error: 113 (No route to host)
[06:58] <desrt>        gst_element_link_filtered (spider, md->priv->sink,
[06:58] <desrt>                                    gst_caps_new_simple ("application/x-gst-tags", NULL));
[06:58] <desrt> pretty sure this leaks, walters
[07:01] <ds-work> it does
[07:01] <ds-work> that should use a GstStaticCaps
[07:02] <walters> does GST_STATIC_CAPS actually work?
[07:03] <taaz> #define GST_COLOR_BALANCE_TYPE(klass) (klass->balance_type)
[07:03] <taaz> that's what's confusing it.
[07:03] <taaz> dunno why...
[07:03] thaytoo ([email protected]) left irc: "hometime"
[07:04] <taaz> must be confusing the code parser.  hmm.
[07:06] <taaz> will i get yelled at for whining about code generators being too lame to handle symbols that end in _TYPE that have nothing to do with gtype system? ;)
[07:06] <walters> desrt: * committed [email protected]/rhythmbox--mainline--0.7--patch-180
[07:07] harshy|lap ([email protected]) left irc: "I quit for now"
[07:07] <desrt> :)
[07:07] <taaz> i think that GST_MIXER_TYPE(obj) = A_MIXER_TYPE; is kind of bogus C usage anyway
[07:07] <taaz> why not just gst_mixer_set_type(obj, type)?
[07:07] <ds-work> not really
[07:07] <desrt> heh
[07:08] <ds-work> I use "(void *)float_pointer += 100" all the time
[07:08] <desrt> my code looks like such a copy of the rhythmbox code :)
[07:08] <ds-work> I think we're going to get rid of the GST_OBJECT_SOME_MEMBER() in 0.9
[07:10] <taaz> 9 line diff to fix this.  i guess i should ask whoever wrote the code ;)
[07:16] <desrt> rock
[07:16] <desrt> you guys use your powers for awesome.
[07:16] <desrt> thanks ds/walters :)
[07:17] Action: bitshifter wonders what applications produce mp3 with a RIFF/WAVE header
[07:17] Action: desrt has exactly one mp3 like this downloaded from napster ages ago
[07:20] <taaz> maybe it's something else... hmm.  silly code scanners
[07:20] <desrt> oh.  one last thing.  is there (yet) a way to reuse the spider while switching media types?
[07:20] <desrt> or do i basically reconstruct my pipeline?
[07:22] <walters> you have to rebuild the pipeline currently
[07:22] <desrt> how do you handle it
[07:22] <desrt> just check if the extension has changed?
[07:24] Action: taaz gives up and takes a nap
[07:25] <walters> desrt: ah...not sure what you mean.  are you talking about a file "foo" that changes from mp3 to ogg or something?
[07:26] <desrt> well... what i do now on track transitions
[07:26] <desrt> i have my pipeline( vfs ! spider ! oss )
[07:26] <desrt> and you can do set_state( pipeline, READY )
[07:26] <desrt> set( vfs, "location", new_file );
[07:26] <desrt> set_State( pipeline, PLAYING )
[07:26] <desrt> and it starts playing the new file
[07:27] <desrt> without pauses due to reconstructing the pipeline
[07:27] <desrt> which is good
[07:27] <desrt> but it doesn't work if the new file is mp3 and the old one was ogg (or vice versa)
[07:27] <walters> right
[07:27] <walters> gst in general just doesn't handle that yet
[07:27] <desrt> well.. it's basically because the spider element *becomes* a vorbisfile element, right?
[07:28] <desrt> i wonder if i could put the decoder inside its own little pipeline and hotswap it in/out
[07:28] Action: desrt doesn't care for tonight
[07:29] <walters> well
[07:29] <walters> no...spider is a bin
[07:29] <walters> and it puts the elements inside itself
[07:29] <desrt> oh.  curious.
[07:29] <desrt> that makes a *lot* more sense
[07:29] <desrt> because i did a G_TYPE_NAME or whatever on the 'source' of the tag_found function and it said VorbisFile
[07:30] <desrt> and i was wondering how the heck a gobject could just redefine itself.. but i assumed that that's what had happened
[07:33] Action: dilinger decides to procrastinate by making some gst 0.7 debian packages
[07:39] KyleB ([email protected]) got netsplit.
[07:39] KyleB ([email protected]) returned to #gstreamer.
[07:41] <desrt> well
[07:41] <desrt> i had to try
[07:41] <desrt> emptying the bin doesn't work :)
[07:54] <Misirlou> dilinger: Don't we still need someone to NMU a new gstreamer-jack?
[07:55] <Misirlou> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=228784
[07:57] Action: desrt just recreates/relinks the spider to find that it works fine
[08:10] KyleB ([email protected]) got netsplit.
[08:11] KyleB ([email protected]) returned to #gstreamer.
[08:13] hadley ([email protected]) left irc: Read error: 110 (Connection timed out)
[08:16] <ds-gromit> score.  dory encapsulates elements now
[08:16] <ds-gromit> (dory is one of the prototype subclasses of GstPlug, the new autoplugger)
[08:16] harshy ([email protected]) joined #gstreamer.
[08:17] Nick change: harshy -> harshyZ
[08:18] <dilinger> Misirlou: why hasn't taaz uploaded?
[08:19] apoc_ ([email protected]) joined #gstreamer.
[08:19] <Misirlou> dilinger: He seems to be MIA; I've tried to contact him twice in the past week.
[08:20] <ds> he was here less than an hour ago
[08:20] <Misirlou> whoa
[08:21] Action: dilinger laughs
[08:21] <dilinger> configure: WARNING: Sissy ! By asking to not build the tests known to fail, you hereby waive your right to customer support.  If you do not agree with this EULA, please press Ctrl-C before the next line is printed.  By allowing the next line to be printed, you expressly acknowledge your acceptance of this EULA.
[08:21] <Misirlou> Hopefully he's back for good this time.
[08:21] <ds> arguably, that's not DFSG-free :)
[08:21] <ds> dude, taaz has never been gone
[08:22] <Misirlou> what?
[08:22] <Misirlou> He was gone the last few days, I know that.
[08:22] <ds> oh, that may be
[08:22] <ds> so was I
[08:30] AlexCONRAD ([email protected]) joined #gstreamer.
[08:30] Action: ds amuses himself by watching the cpu speed on his laptop go up/down in response to window resizing on videotestsrc ! warpTV ! ximagesink
[08:35] <Misirlou> ds: What's the speed range?
[08:35] <ds> 530 - 1895
[08:35] lilo ([email protected]) got netsplit.
[08:35] thaytan ([email protected]) joined #gstreamer.
[08:35] <Misirlou> wow
[08:36] <Misirlou> I didn't know that they were so large.
[08:36] <ds> I'm wondering if one can underclock or under power the CPU
[08:36] <ds> because I borrowed the tables for another processor
[08:36] apoc ([email protected]) left irc: Read error: 110 (Connection timed out)
[08:36] lilo ([email protected]) returned to #gstreamer.
[08:43] danb_ ([email protected]) joined #gstreamer.
[08:43] lilo ([email protected]) got netsplit.
[08:44] somex1 ([email protected]) joined #gstreamer.
[08:44] walters ([email protected]) left irc: "out"
[08:46] KoRnouille ([email protected]) left irc: Read error: 110 (Connection timed out)
[08:48] danb__ ([email protected]) joined #gstreamer.
[08:49] lilo ([email protected]) got lost in the net-split.
[08:49] Nick change: thomasvz -> thomasvs
[08:52] danb_ ([email protected]) left irc: Read error: 60 (Operation timed out)
[08:59] danb ([email protected]) left irc: Read error: 110 (Connection timed out)
[09:01] lilo ([email protected]) joined #gstreamer.
[09:01] Nick change: mathrick|sleep -> mathrick
[09:13] swentel ([email protected]) joined #gstreamer.
[09:16] rk ([email protected]) joined #gstreamer.
[09:29] Nick change: km_sleep -> kmaraas
[09:29] <bitshifter> Say I have a pipe   filesrc ! typefind ! spider ! application/x-gst-tags ! fakesink. Does anyone know how mp3s with an ID3v2.4 tag at the end of the file would get classified? ie. would it say app/x-id3 or mpeg/audio?  (I don't have any songs with an ID3v2.4.0 tag at the end unfortunately)
[09:30] <thomasvs> bitshifter: with company's changes, my money would be app/x-id3
[09:31] <bitshifter> great
[09:32] somex1 ([email protected]) left #gstreamer.
[09:35] <ds-gromit> anyone have more information about basicomega not working with NPTL?
[09:35] <ds-gromit> it works fine here, I think
[09:36] <thomasvs> ds-gromit: what sort of not working ? do we have a bug report about it ?
[09:37] <ds-gromit> vague recollections
[09:37] <thomasvs> ds-gromit: well, if you want me to try specific stuff, let me know
[09:38] <ds-gromit> I suppose just start using basicomega as your standard scheduler
[09:38] <ds-gromit> #104892
[09:41] <thomasvs> ok, will do
[09:41] <AlexCONRAD> good morning boyz
[09:58] kmaraas ([email protected]) left irc: "Leaving"
[10:12] thomasvs ([email protected]) left irc: Read error: 110 (Connection timed out)
[10:18] Shoragan ([email protected]) joined #gstreamer.
[10:23] <ds-gromit> night
[10:28] thomasvs ([email protected]) joined #gstreamer.
[10:34] dolphy ([email protected]) joined #gstreamer.
[10:49] wheels ([email protected]) left irc: "using sirc version 2.211+KSIRC/1.3.9"
[11:24] gheet ([email protected]) joined #gstreamer.
[11:30] The_Company ([email protected]) left irc: Remote closed the connection
[11:32] micampe ([email protected]) joined #gstreamer.
[11:32] <micampe> hello
[11:33] <micampe> can gst handle 3gpp?
[11:33] <micampe> I need a tool to convert/generate to 3GPP in linux
[11:44] Rotty ([email protected]) joined #gstreamer.
[11:55] alley_cat ([email protected]) joined #gstreamer.
[11:55] <sxpert_work> micampe: 3gpp is a form of mpg4, right ?
[11:55] <micampe> yes
[11:55] <micampe> looks like mencoder can do it, I'll have to test
[12:01] BBB ([email protected]) joined #gstreamer.
[12:03] <BBB> hi
[12:04] micampe ([email protected]) left irc: "leaving"
[12:07] <dolphy> BBB: yo
[12:08] <BBB> howdy
[12:08] Action: BBB has a lot of PWG work done
[12:08] <dolphy> BBB: http://newyork.craigslist.org/
[12:08] <dolphy> BBB: my friend in NYC told me to give you that url
[12:09] <dolphy> BBB: for apartments
[12:10] <BBB> whoa
[12:10] <BBB> $4000/mnth?
[12:10] Action: BBB checks his wallet
[12:12] <dolphy> well dude it costs :)
[12:13] teuf ([email protected]) joined #gstreamer.
[12:13] <teuf> hi
[12:13] Action: BBB just needs a room... ;)
[12:13] sublett ([email protected]) joined #gstreamer.
[12:15] <teuf> is the mixer not working on some setups a known issue ?
[12:17] <dolphy> hmm 
[12:17] <dolphy> oss one ?
[12:18] <teuf> dolphy: alsa+oss emulation
[12:18] <dolphy> worksforme
[12:19] <BBB> alsa+oss emu should work
[12:19] <BBB> alsa is broken itself, afaik
[12:20] <dolphy> BBB: http://newyork.craigslist.org/mnh/abo/23195595.html
[12:20] <teuf> any idea how I can investigate what's going on ?
[12:20] <dolphy> BBB: 1795$ that one seems good no ? :)
[12:22] <dolphy> BBB: lot of appartments available for 2000$ /month
[12:33] Company ([email protected]) joined #gstreamer.
[12:43] jeroen ([email protected]) joined #gstreamer.
[13:00] <BBB> dolphy: I have $600/mnth!
[13:01] <BBB> at best $800
[13:01] <BBB> but no $2000!
[13:01] <thaytan> hfs!
[13:01] <thaytan> <- $1300AU
[13:15] <dolphy> BBB: ah
[13:15] <dolphy> BBB: so go look for a bridge then :)
[13:15] <dolphy> BBB: or a shared appartment
[13:16] <BBB> room
[13:16] <BBB> apaprtment is far too expensive there
[13:16] <BBB> ;)
[13:18] <dolphy> yup
[13:18] <dolphy> well i was hoping my girlfriend there would offer you her room :)
[13:18] <dolphy> but apparently she has a boyfriend atm :)
[13:19] <dolphy> sorry :)
[13:19] <BBB> can't she break up? :p
[13:19] <BBB> better yet: is she pretty? [/evil]
[13:20] <BBB> j/k ;)
[13:20] iain ([email protected]) joined #gstreamer.
[13:21] <iain> hey all you multimedia kids
[13:21] <Company> hi Lene hid
[13:21] <Company> kid
[13:21] <iain> mmmlenemarlin
[13:21] Nick change: mathrick -> mathrick|Uni
[13:22] <thaytan> hiya
[13:22] <dolphy> BBB: well want to see a pic ?
[13:23] <dolphy> http://www.modelczech.com/photosF/full/mir_vrb4.jpg
[13:25] <thomasvs> dolphy: that's britney spears
[13:26] <dolphy> her name is mira :)
[13:26] <iain> http://www.modelczech.com/photosF/full/mir_vrb3.jpg
[13:26] <iain> and thats her doing shirley manson
[13:27] <thomasvs> heh, yeah :)
[13:28] <BBB> iain: anyone ever told you you're sick with your lene marlin madness? ;)
[13:28] <dolphy> you jalous guys :)
[13:28] <BBB> dolphy: somehow, I don't believe you... but if that's her, heck, when can I meet her? ;)
[13:28] <iain> BBB: I'm not that bad...its not like I've got my room filled with pictures
[13:29] <BBB> iain: yeah right :p
[13:29] <dolphy> BBB: you don't believe me ?
[13:29] <dolphy> BBB: wait a minute
[13:29] Action: dolphy crawls in photo albums
[13:29] <iain> BBB: who is this girl?
[13:30] <iain> dolphy: same question :)
[13:30] <BBB> iain: dolphy just told me he was gonna let me stay with her while I'm in NYC, but now I can't anymore *cries*
[13:30] <iain> BBB: ohh, nice
[13:31] <iain> ohh marlin's been translated into french
[13:31] <iain> cool
[13:31] <jdahlin> not lene marlin?
[13:31] <iain> no
[13:32] <BBB> Lienie Marlehn
[13:37] Action: BBB wonders how to do accents in X
[13:37] <BBB> (like deadkeys)
[13:37] KoRnouille ([email protected]) joined #gstreamer.
[13:37] <iain> usually alt-gr and ' is a deadkey
[13:38] <iain> but I think I broke it when I hacked my keymap to do å
[13:39] <iain> whats LANG supposed to be for french? fr or fr_FR?
[13:40] <BBB> not here... :/
[13:40] <teuf> iain: I use fr_FR, but fr should work I think
[13:41] <iain> hmm, fr_FR doesn't translate it, and fr tells me the locale isn't supported
[13:42] <iain> i18n confuses me so much
[13:42] <teuf> on debian you need to use dpkg-reconfigure locales before using a new locale
[13:42] AlexCONRAD ([email protected]) left irc: Read error: 60 (Operation timed out)
[13:43] Company ([email protected]) left irc: Remote closed the connection
[13:48] <iain> I'm on redhat
[13:48] <thomasvs> iain: try fr_FR.utf8 instead
[13:50] <iain> thomasvs: thats supported by the libc but not by xlib...which is a new error :)
[13:51] <teuf> iain: try fr_FR.UTF-8 ;)
[13:52] <iain> I think I did...
[13:52] Action: iain shrugs
[13:55] <iain> oh fr_FR.UTF-8 translates the GTK dialogs, but not marlin
[13:57] <thomasvs> iain: did you properly bindtextdomain and so on ?
[13:57] <thomasvs> iain: feel free to steal from autostars
[13:58] Company ([email protected]) joined #gstreamer.
[14:01] <teuf> iain: is marlin head compiling with gstreamer head ?
[14:01] <iain> yeah I think its all done properly
[14:01] <iain> teuf: it should be
[14:01] <teuf> I'm getting marlin-sample-element.c:743:73: macro "gst_element_error" requires 5 arguments, but only 2 given
[14:01] <teuf>  but I don't know if that's my gstreamer which is too old, or if it's marlin's fault
[14:01] <BBB> marlin's old
[14:01] <BBB> gst-rec did that too
[14:02] <iain> ohhh I never commited that fix
[14:02] <iain> I'll do that now
[14:04] <iain> hmm, bt downloads make cvs commits really really slow
[14:04] <iain> okay, commited
[14:04] <teuf> iain: cap your upload speed a bit if you haven't done so yet
[14:05] <iain> can you do that with btdownloadcurses?
[14:05] <teuf> --max_upload_rate iirc
[14:10] <Company> iain needs wondershaper
[14:13] <teuf> iain: there's something fishy going on with marlin and fr.po, I don't get it in french either
[14:13] <jeroen> iain: use this:  btlaunchmanycurses.py . --max_upload_rate 15
[14:13] <jeroen> iain: if you want a 15KB/s max upload per torrent
[14:14] <iain> jeroen: oh right, cool. I think I'll set it to 5, cos 10 seems to max out my upload
[14:20] Company ([email protected]) left irc: Remote closed the connection
[14:28] Action: BBB commits a new bunch of documentation add-ons
[14:40] <bitshifter> ** WARNING **: opt: unlink elements in same group: implement me. aborting....   -  any idea what the problem might me? I've got a custom filter element that currently does little but push data from the sink pad to the src pad, and a custom sink that worked fine before. I get this when the pipeline is unreffed
[14:42] <bitshifter> the pipeline looks like this:   filesrc ! oggdemux ! filter ! sink  and filter and sink are linked in in oggdemux's "new_pad" signal callback
[14:45] <dolphy> set your pipeline to READY before unref
[14:45] <teuf> iain: I can't get the french translation to work, still everything seems ok when looking at how i18n is set up
[14:49] jeroen ([email protected]) left irc: Nick collision from services.
[14:53] markey ([email protected]) joined #gstreamer.
[14:54] <markey> moin
[14:54] jeroen_ ([email protected]) joined #gstreamer.
[14:54] <bitshifter> dolphy: I'm setting it to NULL now, but READY does the same thing. I think i'm doing something dodgy with the pads. I'll have to have a look at some more plugins I guess
[14:56] <dolphy> bitshifter: this warning you get means you are unlinking 2 elements which are in the same scheduling group
[14:57] <BBB> you're in PLAYING while unlinking pads
[14:57] <BBB> I think you need to be in PAUSED or below
[14:57] <BBB> (but I do it in PLAYING too, and elements work fine...)
[14:57] <bitshifter> I set it to NULL before I unref the pipeline
[15:02] <BBB> not unref
[15:02] <BBB> unlink
[15:02] <BBB> if you aren't specifically unlinking anything (or you don't know what I'm talking about), then this doesn't apply ;)
[15:02] <bitshifter> I'm not unlinking anything as far as I'm aware
[15:02] <BBB> hm, right
[15:02] <BBB> can you provide code?
[15:03] <BBB> (via email, or bugzilla, or ...)
[15:03] <bitshifter> sure, one sec
[15:07] <bitshifter> http://sceptic.centricular.net/code.tar.bz2
[15:08] <bitshifter> you'll need an .ogg file to test it
[15:08] <bitshifter> and please be gentle, I've only started playing with gst two days ago ;)
[15:12] <BBB> seems to work fine here
[15:12] <BBB> [rbultje@shrek detect]$ ./detect /media/clips/locke_20.asf scentric-hash-sink: 0x805a950 scentric-hash-sink
[15:12] <BBB> scentric-tag-filter: 0x805c018 scentric-tag-filter
[15:12] <BBB> video/x-ms-asf       - /media/clips/locke_20.asf                                                                                 
[15:12] <BBB> Elapsed: 0.7 seconds for 1 files = 0.7 seconds/file
[15:12] <BBB> [rbultje@shrek detect]$
[15:12] <bitshifter> nah, it will only be triggered by an ogg file
[15:12] <BBB> hm
[15:13] <BBB> received 1010 kB
[15:13] <BBB> is that normal?
[15:13] <bitshifter> yeah
[15:13] <BBB> ok
[15:13] Action: BBB does grep -v received
[15:13] <bitshifter> it should output loads of those, and then after the EOS it should abort
[15:14] <BBB> before... 
[15:15] <BBB> ** ERROR **: file detect.c: line 210 (hash_ogg): assertion failed: (1==2)
[15:15] <BBB> aborting...
[15:15] <BBB> in gst_scentric_tag_filter_change_state
[15:15] <BBB> out gst_scentric_tag_filter_change_state
[15:15] <BBB> *** EOS
[15:15] wingo ([email protected]) joined #gstreamer.
[15:16] <BBB> oh crap, gdb really likes me
[15:16] <bitshifter> funny, the 1==2 assertion is not even triggered here
[15:16] Action: BBB cannot get gdb to stop on the warning
[15:16] Action: BBB kicks gd
[15:16] <BBB> I'm sure wingo can help you ;)
[15:17] <BBB> no, seriously
[15:17] <bitshifter> export G_DEBUG=fatal_warnings    should do the trick before running gdb
[15:17] <BBB> I think it's just a warning... don't pay too much attention to it, we'll probably fix it sometime when we know what's wrong
[15:17] <BBB> aha
[15:17] <bitshifter> k
[15:17] Action: BBB tries that
[15:18] <bitshifter> well, I think it's more because I'm doing something horribly stupid somewhere
[15:18] <BBB> I don't think so... I'm seeing the error too quite often
[15:18] <BBB> warning
[15:18] Action: bitshifter bangs head against wall
[15:19] <bitshifter> d'oh. Of course it only aborts because I have the environment variable set
[15:19] <bitshifter> I didn't even realise it was 'just' a warning. I thought it was something really evil
[15:19] Action: bitshifter hides
[15:20] <bitshifter> sorry for wasting your time BBB
[15:20] <BBB> *g*
[15:20] <BBB> no prob... like writing documentation is so useful
[15:21] <BBB> ohwell, maybe it si
[15:21] <BBB> ...
[15:21] Action: BBB guesses so
[15:23] <wingo> hi folks
[15:24] <BBB> howdy andy
[15:24] <BBB> I'll soon join you as an outlander
[15:24] jeroen__ ([email protected]) joined #gstreamer.
[15:25] <dolphy> hi wingo
[15:25] <dolphy> BBB: many outlanders in that channel btw :)
[15:25] <wingo> and g'day to you BBB. anyone know how to get a web space on www.gnome.org? thomasvs maybe? I want to host an arch archive there accessible by read-only http and read-write sftp or secure rsync
[15:25] <wingo> hi dolphy
[15:25] <wingo> who would I talk to to get that together?
[15:25] <wingo> (it's for guile-gnome)
[15:26] <dolphy> wingo: probably jdub on #gnome
[15:27] mathrick|Uni ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[15:30] <taaz> hey wingo 
[15:31] <wingo> oh hey taaz. how's life treating you these days?
[15:31] <wingo> btw I'm going to beat you to best-updated (gst-hosted) language binding soon :)
[15:32] <taaz> grr ;)
[15:32] <taaz> can you handle interfaces?
[15:34] <wingo> yup
[15:34] <wingo> as multiple-inherited classes :)
[15:34] <taaz> that won't work will it?
[15:34] <taaz> or, rather, it's hard to do it that way
[15:34] <wingo> that's what interfaces are meant to solve
[15:34] <taaz> like GstNavigation and such
[15:34] <wingo> it's easy in guile's oo layer
[15:35] <wingo> no, it's just that an instance of GtkEntry is also an instance of GtkEditable, for example
[15:35] <wingo> and so methods of GtkEditable will apply to an entry instance
[15:35] <wingo> it's not that hard of a problem
[15:36] <taaz> for code that in java would look like: if (obj instanceof GstInterface) {  ((GstInterface)obj).someNavMethod() }
[15:36] <taaz> ie, not the code where you know what interfaces are supported, but the code where you don't know
[15:36] <wingo> that's poorly-designed code; methods should dispatch on type, not within a function
[15:37] <taaz> well, that's how all our code works now
[15:37] <taaz> as i see it
[15:37] <wingo> are there cases where some instances of a class implement an interface and others don't?
[15:37] <taaz> sort of... here's what i see happening:
[15:38] <taaz> you are going to create an instance with some high level function like gst_element_factory_create ("xvideosink")
[15:38] jeroen_ ([email protected]) left irc: Read error: 110 (Connection timed out)
[15:39] <taaz> you'll just get back a GstElement
[15:39] <taaz> so you don't know at the binding level that it supports various interfaces
[15:39] <taaz> well, i guess you do know
[15:39] <taaz> but in python at least you can't start adding multiple inheritance to GstElement since that would add it to all GstElements not just the one instance you want
[15:40] <taaz> i dunno... it seems a bit tricky when you don't know the subclass
[15:40] <taaz> since the binding code is likely to just create an instance of the superclass for you.
[15:40] <wingo> you do know, it's an instance of whatever class it is, not just gstelement
[15:41] <wingo> it shouldn't work that way.
[15:41] <wingo> have you tried it? :)
[15:41] <taaz> sort of.  the python bindings, i think, will just consider it a GstElement since that's what the function signature says
[15:41] <taaz> i know it's actually a subclass of course
[15:42] <taaz> hmm.  maybe the solution is just a bit harder at the binding level
[15:43] <taaz> like for -every- object you create you have to check it's true class and create one of those which will auto detect the supported interfaces and add them via MI or whatever is appropriate
[15:44] <taaz> and just to be evil, don't forget this stuff is dynamic at the GObject level ;)  i hope no one uses that ability though
[15:45] <taaz> hmm...  i'm not sure if interfaces are added per class or per instance?
[15:47] <wingo> per class.
[15:47] <wingo> they're added in the get_type function.
[15:48] <wingo> really, are you sure sure sure that pygtk gives you exactly what the function says it's returning?
[15:49] <taaz> hmm... i thought so
[15:50] <taaz> how do i check? ;)
[15:51] <wingo> get a child from a gtkwindow, it should give you whatever you put in
[15:51] <wingo> anyhoo, i gotta run.
[15:51] <wingo> cheerio!
[15:51] wingo ([email protected]) left irc: "I like core dumps"
[15:52] LeRoutier ([email protected]) joined #gstreamer.
[15:52] <LeRoutier> hello
[15:52] <taaz> aw.. he left.  oh well
[15:52] <taaz> looks like it returns whatever the api specified
[15:52] <LeRoutier> isn't there a problem with gstreamer versionning scheme in .pc files laterly ?
[15:53] <taaz> which kind of makes sense because you can't return a class you didn't actually wrap.  like any of the plugin subclasses direct
[15:53] <LeRoutier> gstreamer-0.7 & gstreamer-control-0.7 have version 4.1.2 where the -0.6 had  0.6.4
[15:54] <BBB> libtool version?
[15:54] <BBB> that's normal, I think
[15:54] <LeRoutier> 1.4.3
[15:55] <LeRoutier> well, gst-plugins .pc files have a version of 0.7.3.1 which seems more normal
[16:00] <BBB> no, I mean, 4.1.2 might be the gst-lib's libtool versions
[16:00] <BBB> ;()
[16:00] <BBB> ;)
[16:02] <LeRoutier> well, that's possible. but won't this break detection in configure scripts of gst users ?
[16:02] <BBB> I don't really know
[16:02] <LeRoutier> i thought you were an autotools master :)
[16:03] <BBB> me? oh my, not the least... thomasvs is our build master... I just copypaste what thomasvs designs
[16:03] <LeRoutier> k.
[16:05] <LeRoutier> have to work a bit, going off-line. bbl
[16:05] LeRoutier ([email protected]) left irc: "Leaving"
[16:05] markey ([email protected]) left irc: "leaving"
[16:14] Company ([email protected]) joined #gstreamer.
[16:14] <jdahlin> taaz, what do you actually need from the GInterface bindings in pygtk?
[16:19] CompIBook ([email protected]) joined #gstreamer.
[16:19] Company ([email protected]) left irc: Nick collision from services.
[16:19] Nick change: CompIBook -> Company
[16:24] sublett ([email protected]) left irc: Read error: 113 (No route to host)
[16:27] <taaz> jdahlin: i think just the ability to 'cast' a object to an interface
[16:27] <taaz> and also check if a object supports an interface
[16:27] <jdahlin> taaz, you don't need to implement methods of an interface?
[16:27] <taaz> that code should work now though, i think
[16:27] <taaz> well, yeah, that too ;)
[16:28] <jdahlin> why do you need to cast it?
[16:28] <taaz> but the current pygtk code does make a wrapper thingy now
[16:28] <taaz> how else can it be used?
[16:28] <jdahlin> use it and file bugs if somethings missing?
[16:28] <taaz> huh?
[16:28] <jdahlin> the wrappers?
[16:29] <jdahlin> I'm not sure if they're committed, there are some code in bugzilla though
[16:29] <taaz> what wrappers?
[16:30] <jdahlin> <taaz> but the current pygtk code does make a wrapper thingy now
[16:30] <dolphy> Company: ping
[16:31] <taaz> jdahlin: ok, but how to i turn a object that pygtk thinks is a GstElement into an object that supports the, for insance, GstNavigation interface?
[16:31] <taaz> for instance too
[16:31] <taaz> ie, a cast
[16:32] <jdahlin> dunno :)
[16:33] <jdahlin> why should pygtk care?
[16:33] <Company> dolphy: pong
[16:36] Nick change: md` -> morehaste
[16:36] <dolphy> Company: check your mails :)
[16:36] <taaz> what do you mean care?  i don't know how to do it at all.  i don't think the ability exists in current pygtk code.
[16:36] <taaz> it was designed so you could support known interfaces with multiple inheiritance
[16:36] <BBB> Company: wanna comment on my states documentation?
[16:37] <taaz> not for casting.  which, i think, isn't too hard to add.  just need to allow the creation of ''interface'' objects of some sort.  similar to casting i guess
[16:45] Action: jdahlin runs away
[16:45] Action: taaz wonders if he's the only one that understands the problem or is just very very confused ;)
[16:48] <Company> taaz: just write an example app that tries to embed an xvideosink somewhere to show what doesn't work and you know who's confused :)
[16:50] Action: BBB just wrote a description of the basic & opt scheduler in the PWG
[16:56] jeroen__ ([email protected]) left irc: "Client exiting"
[16:56] swentel ([email protected]) left irc: 
[16:58] Nick change: morehaste -> md`
[17:01] Action: thomasvs tries to untangle the mess Uraeus made of the tasks
[17:05] <BBB> ?
[17:09] <BBB> thomasvs: did you look at the new PWG? do you like it?
[17:09] Action: BBB wants more comments
[17:11] <taaz> any progress towards a current, correct, and complete pwg is excellent ;)
[17:11] <BBB> d'oh
[17:11] <BBB> any progress towards a zillion ¬ on my bank account is excellent, too
[17:14] <dolphy> Company: i m trying to plug audio first now :)
[17:18] <taaz> heh ;)
[17:20] <thomasvs> BBB: still slavering over the crap website we have
[17:22] Nick change: harshyZ -> harshy
[17:23] <BBB> :/
[17:23] <BBB> we're all doign painful work right now, I guess
[17:23] <BBB> you website, me docs, ds/company autoplugger...
[17:23] <BBB> what's julien's painful-task-of-the-day?
[17:24] Company ([email protected]) left irc: "Client exiting"
[17:24] Company ([email protected]) joined #gstreamer.
[17:27] <dolphy> BBB: spider :)
[17:34] <dolphy> WEEHHHEEHEEEEE fixed
[17:34] <dolphy> tagged mp3 plays 
[17:34] Action: BBB cheers
[17:35] Action: dolphy hugs Company
[17:35] Action: dolphy kicks spider
[17:35] Action: BBB is documenting how to write muxers/switches and demuxers...
[17:35] hallibaby ([email protected]) joined #gstreamer.
[17:36] <Company> BBB: it's hard
[17:36] <Company> BBB: start with that
[17:36] <BBB> what's hard?
[17:37] <BBB> oh, muxers/demuxers?
[17:37] <BBB> that's why it's in 'advanced'
[17:37] <BBB> and it's not at all intended to be complete
[17:37] <Company> yeah
[17:37] <BBB> rather, it's supposed to be a good introduction
[17:37] <BBB> so people can start and find out the rest themselves
[17:37] <Company> writing muxers is the hardest part of element writing
[17:37] <BBB> especially discontinuities
[17:37] <BBB> that's why I'm leaving that... :X
[17:37] <Company> stream demuxers is a close second
[17:37] Action: Company looks at his oggdemux code
[17:38] Action: BBB knows that matroskademux/avidemux aren't stream-capable
[17:38] <BBB> they only operate on files
[17:38] <thomasvs> BBB: why ?
[17:38] <BBB> (as in: they require seekability)
[17:38] <thomasvs> ah
[17:38] <BBB> simply because I didn't fix non-seeking yet
[17:38] <BBB> they're mostly ok with it... but there's probably bugs
[17:39] <BBB> and I don't feel like fixing it since nobody in the world will ever play networked avis
[17:39] <thomasvs> what exactly was the problem again with having a seek_possible boolean for streams ?
[17:39] <Company> well, if i write oggdemux without seeking, i have 2 weeks until some rb guy figures out that his favorite radio station doesn't work ;)
[17:39] <thomasvs> BBB: dunno, http should work fine
[17:39] <BBB> you can replug and then the value makes no sense anymore
[17:39] <BBB> Company: true
[17:39] <Company> thomasvs: we need QoS someday, bot not now
[17:39] <BBB> Company: mpegdemux can handle streams
[17:39] <BBB> that's good enough for now
[17:40] <Company> thomasvs: and seekability is more than can seek/can't seek
[17:40] <taaz> does gst have any video sinks that work over X?
[17:40] <Company> thomasvs: mms can maybe only seek forwards, seeks might be cheap or expensive, stuff like that
[17:40] <BBB> taaz: ximagesink?
[17:40] <taaz> err, over remote X
[17:40] Action: BBB goes home
[17:40] <Company> taaz: ximagesink has a display property i think
[17:40] <BBB> bbl!
[17:41] BBB ([email protected]) left irc: "Client exiting"
[17:41] <Company> taaz: stresstesting your network?
[17:41] <taaz> Company: nah, i develop on my headless fast machine.  i don't know how to test anything though.
[17:44] <taaz> ah, aasink does remote X just fine ;)
[17:45] Action: taaz amused that the only element that can open a x window remotely is a text based one ;)
[17:45] <taaz> i'm just testing 0.6.4 debs before uploading them
[17:45] <Company> ximagesink doesn'T work?
[17:45] <taaz> that's not in 0.6.4
[17:45] <Company> xvideosink even
[17:45] <taaz> nope, xshm errors
[17:45] <Company> ah
[17:46] <taaz> X Error of failed request:  BadAccess (attempt to access private resource denied)
[17:46] <taaz>   Major opcode of failed request:  146 (MIT-SHM)
[17:46] <taaz>   Minor opcode of failed request:  1 (X_ShmAttach)
[17:46] <taaz>   Serial number of failed request:  16
[17:46] <taaz>   Current serial number in output stream:  17
[17:46] Action: Company wonders if ximagesink runs over the network
[17:46] <taaz> i assume this is a bug?
[17:46] <Company> yeah
[17:46] <taaz> it really should work...  it actually used to at some point
[17:46] <taaz> not for many moons though
[17:49] <taaz> hmm.  i don't know how to upload debs anymore ;)
[17:51] hallibaby ([email protected]) left irc: "Bye bye"
[17:56] Action: Company thinks shm over tcp should just work
[17:58] <dolphy> x[v]imagesink work on remote displays
[17:58] <dolphy> i tested/implemented that
[17:58] <dolphy> without Shm though
[17:59] <dolphy> i don't thing the shm extension is available on a remote display
[17:59] <taaz> shouldn't it work by default?
[17:59] <taaz> i just tried and it failed
[18:02] <dolphy> tried what?
[18:04] <Company> it doesn't work
[18:04] <taaz> ssh -X host, $ ./d-0.7/tools/gst-launch filesrc location=~/projects/media/AlienSong.mpg ! mpegdemux ! { queue ! mpeg2dec ! ximagesink }
[18:04] <taaz> X Error of failed request:  BadAccess (attempt to access private resource denied)
[18:04] <taaz>   Major opcode of failed request:  146 (MIT-SHM)
[18:04] <taaz>   Minor opcode of failed request:  1 (X_ShmAttach)
[18:04] <taaz>   Serial number of failed request:  14
[18:04] <taaz>   Current serial number in output stream:  15
[18:05] Nick change: harshy -> harshyWork
[18:05] <taaz> same thing if i set the display property explicitly
[18:10] Action: Company tries to fix it
[18:17] <Misirlou> Yo, taaz!
[18:18] <Misirlou> Are you working on gstreamer-jack?
[18:22] <dolphy> hey dudes calm down
[18:22] <dolphy> i tried it and it works
[18:22] <dolphy> videotestsrc ! ximagesink display="192.168.2.1:0" works just fine
[18:23] <dolphy> taaz: try with display property please
[18:26] <Company> dolphy: doesn't work
[18:26] <dolphy> Company: huh
[18:26] <dolphy> Company: that worked just fine
[18:27] <Company> in that case you either have SHM over tcp or something else I don'T have :)
[18:29] <dolphy> what's the error ?
[18:29] <Company> same as taaz' above
[18:30] <dolphy> that would mean the remote display report having SHM
[18:30] <dolphy> hmm
[18:30] <dolphy> Company: gst_element_set_state (GST_ELEMENT (bvw->priv->play), GST_STATE_READY);
[18:30] <dolphy> Company: will that block until threads have changed their state ?
[18:33] <Company> yes, if they change their state
[18:34] <dolphy> Company: because in totem i have a weird behaviour
[18:34] <dolphy> Company: when switching very quickly from one media to another
[18:34] <dolphy> Company: means set READY and then immediatly open a new media
[18:35] <dolphy> Company: and i m suspecting that gst_element_set_state is returning while the pipeline is not completely READY yet
[18:35] <dolphy> Company: for the remote x thing can you please gst-debug-level=5 |grep -e "using XShm extension"
[18:35] <Company> you can check the return value
[18:36] <dolphy> Company: while return value is not success then set_state READY ?
[18:36] <taaz> Misirlou: nope, i've even tried jack. ;)
[18:36] <Misirlou> taaz: Huh?
[18:37] <taaz> Misirlou: huh huh?
[18:37] <Company> dolphy: i dunno, ther's probably a reason why it failed and it'll therefore fail again - though normally it shouldn't
[18:37] <Misirlou> taaz: I'm confused. :)
[18:37] <Company> dolphy: you'can use --gst-debug=GST_STATES:5 to check
[18:38] <Company> dolphy: apropos debugging - you should get used to adding your own categories, solves the problem of needing to grep
[18:39] <dolphy> Company: yup
[18:39] Rotty ([email protected]) left irc: Remote closed the connection
[18:39] <Misirlou> taaz: The last time that I checked, the gstreamer-jack package still had broken depends.
[18:39] <taaz> oh, yeah, i fixed that
[18:40] <taaz> i'll upload it today
[18:41] hadley ([email protected]) joined #gstreamer.
[18:42] vivlachaga ([email protected]) joined #gstreamer.
[18:42] <vivlachaga> is easy compile gstreamer for powerpc?
[18:42] <dolphy> Company: so what gives the grep ?
[18:42] <vivlachaga> my soundjuicer don' t encode to mp3
[18:42] <vivlachaga> in debian
[18:43] <thomasvs> vivlachaga: get the right packages
[18:43] <thomasvs> vivlachaga: you don't need to compile manually
[18:43] <vivlachaga> what libraries i need before start compile gstreamer 
[18:43] <thomasvs> vivlachaga: you don't need to compile manually
[18:43] <vivlachaga> but debian dont support official packages for encode mp3 
[18:43] <thomasvs> vivlachaga: that doesn't mean there aren't packages for it
[18:44] <thomasvs> anyway, you should encode to ogg :)
[18:44] <vivlachaga> yep
[18:44] <vivlachaga> but
[18:44] <Company> dolphy: it's using shm
[18:44] <vivlachaga> soundjuicer hangup when start
[18:44] <vivlachaga> sound-juicer stay in this step: (/var/lib/gstreamer/0.6/registry.xml)
[18:45] <vivlachaga> any idea?
[18:45] <taaz> Misirlou: ok, i just uploaded 0.6.4-3.  i think.  i haven't uploaded anything since before debian servers got attached so i hope i did it right ;)
[18:45] teuf ([email protected]) left irc: "Client exiting"
[18:46] <vivlachaga> there is any way to regenerate this file?
[18:46] <Misirlou> taaz: hehe
[18:46] mathrick ([email protected]) joined #gstreamer.
[18:46] <dolphy> Company: weird...
[18:46] <dolphy> Company: i ll look into that tonight
[18:47] <mathrick> yo
[18:47] <vivlachaga> tu
[18:48] Misirlou ([email protected]) left irc: Remote closed the connection
[18:49] Misirlou ([email protected]) joined #gstreamer.
[18:52] <dolphy> Company: hmm found
[18:53] <dolphy> Company: other libraries are trying to create an image
[18:53] <dolphy> Company: with an error handler
[18:53] <dolphy> Company: to know if Xshm is usable
[18:53] <dolphy> Company: that sucks hard
[18:54] <dolphy> Company: i thought X might be clever enough to tell that SHM extension is not available for a remote display
[18:54] rk ([email protected]) left irc: "leaving"
[18:56] gheet ([email protected]) left irc: "Download Gaim [http://gaim.sourceforge.net/]"
[18:59] jimmy_dean ([email protected]) left irc: Read error: 110 (Connection timed out)
[18:59] Action: thomasvs is seriously considering keeping php around for the website instead of the xml/xslt combination
[19:01] <taaz> you could do both
[19:01] <thomasvs> taaz: yeah, I thought hard about that too
[19:02] <thomasvs> taaz: on the one hand, php has xslt extensions, but not many servers have those turned on
[19:02] <thomasvs> taaz: on the other hand, I could generate php from xsl
[19:02] <thomasvs> taaz: both suck :)
[19:02] <thomasvs> I am probably making this way too complicated anyway.  our website should just be framebased :)
[19:03] <Company> not framebased
[19:03] <Company> that breaks my usermodel...
[19:03] <thomasvs> usermodel ?
[19:03] <Company> copy/paste from location bar
[19:03] <thomasvs> not following
[19:03] <thomasvs> but any framebased site can be made to have proper locations
[19:03] <thomasvs> argh, anyway
[19:03] <thomasvs> n/m
[19:04] <Company> why can'T we just use static handcoded html pages?
[19:04] <thomasvs> I'll just plow through, and then I'll think about it again in a few month's time
[19:04] <thomasvs> Company: because then they don't get updated
[19:04] <Company> it's not that much useful information anyway...
[19:04] <thomasvs> Company: that's the point - it needs to be more useful, not less
[19:05] <Company> it needs to be correct first...
[19:05] <Company> but if you did some dead simple xsl
[19:06] <Company> like <gst-webpage-header>put html of contents here</gst-webpage>
[19:06] <Company> that should be good enough, anybody interested enough can then start writing xsl for news, releases and whatnot
[19:09] <thomasvs> already done
[19:09] <thomasvs> but it's not as easy as that
[19:09] <thomasvs> ie, having different xml files as source to be mixed, with different xsl stylesheets, and so on
[19:09] <thomasvs> but n/m
[19:09] markey ([email protected]) joined #gstreamer.
[19:12] hadley ([email protected]) left irc: Read error: 110 (Connection timed out)
[19:15] hadley ([email protected]) joined #gstreamer.
[19:32] The_Company ([email protected]) joined #gstreamer.
[19:35] The_Company ([email protected]) left irc: Client Quit
[19:35] Company ([email protected]) left irc: "Duede, where's my question mark!"
[19:36] Company ([email protected]) joined #gstreamer.
[19:38] sublett ([email protected]) joined #gstreamer.
[19:52] <dolphy> Company: how to get current position for time sliders
[19:52] <dolphy> Company: query on position ?
[19:52] earthworm ([email protected]) joined #gstreamer.
[19:52] <dolphy> Company: i tried and that gives me the current time of my machine
[19:53] <earthworm> hey lads, just wondering if i can add realAudio streams as radio stations in Rhythmbox, can gstreamer 0.6.x series handle real audio?
[19:56] <mathrick> dolphy: cool, one more use for gst ;)
[20:00] <KoRnouille> thomasvs, let me know when you need me
[20:00] <dolphy> Company: gst_element_query (osssink, GST_QUERY_POSITION, GST_FORMAT_TIME, &value) is broken
[20:00] <dolphy> Company: osssink converts from gst_clock_get_time
[20:00] <dolphy> Company: which is completely wrong
[20:00] <dolphy> Company: so it gives me my machine time
[20:00] <dolphy> Company: i guess that's broken since you clocking changes
[20:01] <thomasvs> earthworm: nope - could be that it works in head though
[20:02] <earthworm> thats a shame
[20:02] <earthworm> is there much cooperation between you guys and the folks working on the Helix stuff?
[20:03] <earthworm> or are the two things totally opposed
[20:03] <dolphy> earthworm: well nothing is still something in the end :)
[20:04] ChrisHJW ([email protected]) joined #gstreamer.
[20:04] vivlachaga ([email protected]) left #gstreamer ("Leaving").
[20:04] <thomasvs> earthworm: we'll see - but the helix stuff doesn't really solve the patent/license problem
[20:05] <earthworm> oh right, i thought that was part of their aim since helix is reputedly open source
[20:06] <earthworm> even though i hear there are 10,00000 terms and conditions to agree to
[20:06] <thomasvs> earthworm: opinions differ on how open source helix is :)
[20:06] <thomasvs> earthworm: it will probably not surprise you to learn that we tend to not agree with them on that point :)
[20:07] <earthworm> the too things are pretty much opposed then
[20:07] pb_ ([email protected]) joined #gstreamer.
[20:08] <earthworm> i only care because all the BBC radio streams are in real audio
[20:08] <thomasvs> earthworm: well, they have strong commercial goals, and they leverage that advantage
[20:08] <thomasvs> earthworm: yeah, I know
[20:08] <thomasvs> earthworm: but basically, we will be able to play them if we test well enough with ffmpeg
[20:09] <earthworm> still would be nice if the beeb would use ogg streams though eh
[20:12] <thomasvs> yeah
[20:12] <thomasvs> I believe their engineer who did those tests was asked to stop them
[20:12] <thomasvs> don't know why
[20:12] <earthworm> buggeration
[20:13] trow ([email protected]) joined #gstreamer.
[20:13] md` ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[20:13] <earthworm> hows other things on plannet gstreamer? 0.7.0 looking ok? move to freedesktop going well? KDE embracing the project yet?
[20:19] <earthworm> lol - you are probably sick off all those quesions by now  :)
[20:22] <mathrick> earthworm: no, we're just testing your endurance ;)
[20:22] <mathrick> earthworm: move to fdo - completed, succesfull except for not yet finished new website
[20:23] <mathrick> earthworm: 0.7.0 - whoa, that's ancient, I don't think anyone who used it is still alive ;)
[20:23] md` ([email protected]) joined #gstreamer.
[20:24] <earthworm> lol - this is the treatment i get for showing an interest
[20:24] <mathrick> earthworm: KDE - hard to say, but there an some article on dot.kde about gst, and number of KDE guys in here surely increased recently
[20:25] <earthworm> thats good news
[20:25] <earthworm> i meant 0.8.0 btw, but you knew that  :)
[20:25] <mathrick> s/an/was an/
[20:26] Phiend ([email protected]) joined #gstreamer.
[20:26] <mathrick> earthworm: I believe thomasvs is preparing 0.7.4 to release, and that's the freeze point too
[20:27] KoRnouille ([email protected]) left irc: "Leaving"
[20:27] <mathrick> earthworm: still some issues to be resolved, but it progresses rather nicely overall
[20:35] Action: ds-work suggests filing a bug
[20:40] pb_ ([email protected]) left irc: "Client exiting"
[20:41] Kurosu ([email protected]) joined #gstreamer.
[20:42] <mathrick> ds-work: what exactly do you suggest filing on? "Gst is not perfect yet"? ;)
[20:49] <earthworm> you gonna make it into gnome 2.6 with rhythmbox and/or totem?
[20:51] <mathrick> earthworm: RB has been withdrawn from module proposal, but AFAIK is intented to land around 2.6 release nevertheless. And totem is under heavy work to make it into 2.6
[20:52] <ds-work> dunno.  I'm sure there's a bug that could be filed :)
[20:54] <mathrick> ds-work: I try to file bugs when they arise, but my statement was general one, not about something specific :)
[20:54] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[20:55] <earthworm> is totem as good as xine for video now then in the 0.7.x series?
[20:56] <earthworm> totem-streamer vs totem-xine i mean ...
[20:56] <ds-work> so was mine :)
[20:58] <thomasvs> later
[21:03] earthworm ([email protected]) got netsplit.
[21:03] danb__ ([email protected]) got netsplit.
[21:03] Marsupilami23 ([email protected]) got netsplit.
[21:03] lilo_booter ([email protected]) got netsplit.
[21:05] danb_ ([email protected]) joined #gstreamer.
[21:08] earthworm ([email protected]) returned to #gstreamer.
[21:08] danb__ ([email protected]) returned to #gstreamer.
[21:08] lilo_booter ([email protected]) returned to #gstreamer.
[21:08] Marsupilami23 ([email protected]) returned to #gstreamer.
[21:08] earthworm ([email protected]) left #gstreamer (""I allege that SCO is full of it." - Linus Torvalds").
[21:11] <taaz> ChrisHJW: ping?
[21:15] thomasvs ([email protected]) left irc: Read error: 113 (No route to host)
[21:16] <ds-work> anyone mind if I force esdsink to always use 44100,16,2?
[21:16] <mathrick> ds-work: does esd convert automagically if rates don't match?
[21:17] <ds-work> poorly
[21:17] trow ([email protected]) left irc: "Leaving"
[21:17] <ds-work> the problem is that esd doesn't have a very powerful negotiation mechanism
[21:17] <mathrick> ds-work: then anybody having doubtful joy of using esd together with 48kHz only card will be certainly angered
[21:18] <ds-work> esd is only tenuously useful with GStreamer anyway.  it's not possible to get a/v sync
[21:20] danb__ ([email protected]) left irc: No route to host
[21:20] <mathrick> ds-work: what is the cause? usual esd's tendency to cache samples regardless of wether that's needed or not? Or something else?
[21:21] <ds-work> esd has no mechanism for determining which sample is going out the speakers at any given time
[21:22] <mathrick> ds-work: btw, what is the word for field used for military weapon training? OneLook revsearch isn't too helpful on that one...
[21:22] <ds-work> proving ground
[21:22] <ds-work> or artillery range
[21:22] <mathrick> ds-work: ahh, thx, it was proving ground
[21:23] hadley ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[21:23] <mathrick> ds-work: I wonder why was esd chosen by gnome in the first place. It sucks so hard :\
[21:24] <Company> because it was chosen years ago
[21:25] <Company> and nobody touched it since then
[21:25] <Company> it's like chosing Linux 2.0 as the official kernel ;)
[21:28] <ds-work> ugh, esd's resampling sounds so horrible
[21:28] <Company> gnome will gladly accept patches i bet
[21:29] <mathrick> Company: yeah, but during all these years, gnome could have switched it three times and still have time to adopt. Esd's deficiencies are so stark, I can't understand why it wasn't thrown out at the next release
[21:29] <ds-work> I'm _not_ hacking on esd
[21:29] <Company> mathrick: switch to what?
[21:29] <ds-work> it's a dead horse
[21:29] <ds-work> it needs to be beaten, not medicated
[21:29] <mathrick> Company: aren't there *any* better sound servers?
[21:30] Action: ds-work points to nnss
[21:30] <mathrick> btw, wasn't esd originally used ny enlightenment?
[21:30] <mathrick> s/ny/by/
[21:30] <Company> mathrick: i don't run one for a reason
[21:30] <Company> yes, gnome used a lot of E code in its early days
[21:30] <Company> like imlib for example
[21:30] <mathrick> Company: one == esd or sound server in general?
[21:31] <mathrick> Company: yeah, imlib was also hated after it got adopted enough
[21:31] <Company> sound server in general
[21:31] <mathrick> Company: and what is that reason?
[21:31] <Company> all sound servers i know suck
[21:32] <mathrick> ds-work: what is nnss? "New Network Sound Server" or something?
[21:32] <ds-work> no-name sound server
[21:32] <ds-work> it's a hack I put together a while ago
[21:33] thomasvs ([email protected]) joined #gstreamer.
[21:33] <mathrick> ds-work: it's that X Pixmap thing of yours?
[21:33] <ds-work> yeah
[21:33] <ds-work> but I stopped doing that and started using d-bus
[21:33] Action: mathrick can't understand why the hell weren't any sound server capabilities incorporated into kernel yet
[21:33] <Company> because the kernel is not a sound server
[21:34] <ds-work> whatever
[21:34] <Company> there's 2 things that suck about drivers in Linux: the graphics cards drivers suck and the sound people didn't get a server right
[21:34] <ds-work> the kernel should abstract the hardware, including multiple processes acecssing the device at the same time
[21:35] <mathrick> Company: but why apps should even care if card is capable of mixing or not, local or remote and all those things? I see win32 coping with that pretty gracefully
[21:35] robUx4 ([email protected]) joined #gstreamer.
[21:35] <robUx4> lo
[21:35] <mathrick> ds-work: yep, probably that's even better than sound specific solution
[21:35] <mathrick> lo robUx4
[21:35] <ds-work> however, not everyone uses Linux
[21:35] <Company> the kernel should not allow writing to a ressource twice that can only be written to once
[21:36] <mathrick> ds-work: heh, then Gnome should drop any HAL work
[21:36] <ds-work> not everyone uses Linux
[21:36] <Company> nah, Sun is free to implement event notification in Solaris and use d-bus
[21:37] <mathrick> Company: no, if it makes sense (and in case of sound card it does), then kernel should transparently provide for missing hw capabilities
[21:37] <Company> mathrick: so X should be a klernel thing?
[21:37] <Company> kernel thing, too?
[21:38] <mathrick> Company: no, but X is more than just opening /dev/screen ;)
[21:38] <Company> it's a sound server for video
[21:39] <mathrick> Company: give me one reason why there shouldn't be architecture for transparently implementing (by userspace of course) mixing in sw when there's no hw one?
[21:39] <Company> it "mixes" access to the monitor by different apps at the same time
[21:39] <Company> well, that's what a sound server does, isn'T it?
[21:40] Action: mathrick notes that there's already similar work for video in kernel
[21:40] <ds-work> X is significantly more complicated than a sound mixer
[21:40] <mathrick> Company: no, it doesn't do that _transparently_
[21:40] <Company> what do you mean "transparently" ?
[21:40] pb_ ([email protected]) joined #gstreamer.
[21:41] <Company> graphics access doesn't work transparently either
[21:42] <mathrick> Company: my app opens /dev/dsp, and shouldn't have slightest idea about wether my card lacks mixer, or I wan't to redirect everything by net, or something. It just opens /dev/dsp, everything else is OS job
[21:42] <Company> mathrick: I don'T think I open /dev/monitor
[21:43] <mathrick> Company: mind you that graphics (where graphics == "GUI") isn't simple "grab whole screen, paint something" process
[21:43] <Company> mathrick: yes it is
[21:43] <Company> mathrick: as far as the app cares, it grabs the whole screen and paints
[21:43] Action: ds-work comments that X is both a multiplexer and a driver
[21:43] <mathrick> Company: hmm, but we're not talking about DOS, are we?
[21:43] hadley ([email protected]) joined #gstreamer.
[21:43] <Company> yes, X being a driver is seriously stupid, because everytime it crashes I can't see a thing
[21:44] <Company> mathrick: it's the job of the X server to give the app a rectangular space that it can use as its screen
[21:44] <Company> mathrick: as far as the app cares it's just a screen in some size
[21:45] Action: ds-work idly wonders if esd works between big-endian and little-endian machines
[21:45] <mathrick> Company: anyway, sound access is just dead simple with that scheme - open /dev/dsp and _nothing_ more. Why shouldn't kernel provide for that?
[21:46] <Company> mathrick: i dunno, why doesn't an app open /dev/screen but uses xlibs?
[21:47] <mathrick> Company: because graphics inherently exposes it to much more guts than sound access?
[21:47] <Company> mathrick: you think?
[21:47] hadley ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[21:48] <Company> mathrick: the X stuff could easily be done using ioctls
[21:48] <mathrick> Company: do you seriously think that apps having to choose one, and only one sound server, or having to worry about all kinds of /dev/dsp access problems is good thing?
[21:48] <Company> mathrick: i seriously think that the only reason why there is no sound server is that noone of the people who could do one cares
[21:48] Uraeus ([email protected]) joined #gstreamer.
[21:49] <mathrick> Company: probably you could use ioctls, but everything is already well established in X, and doesn't show so serious and obvious shortcomings as whole explicit sound servers thing does
[21:49] <Uraeus> aloha
[21:49] <mathrick> yo Uraeus
[21:50] <Company> mathrick: there's a whole lot of super clever people working on the graphics server end
[21:51] <Company> mathrick: imagine people like keith packard or owen taylor writing a sound server (and give them 5-20 years experience with sound servers)
[21:51] <mathrick> Company: hmm, ok, but I can't understand why ALSA introduces one more mechanism for that (dmix) instead of doing that once for all? They certainly have resources to do that, just they reasons stay unknown for me
[21:51] <Company> mathrick: i do think everyone would use that sound server and noone would even argue about writing another one
[21:52] <mathrick> Company: nah, did you ever hear about sound server on win32?
[21:52] <Company> mathrick: yes, it's called DirectSound and is like everything in windows part of the kernel
[21:52] <mathrick> Company: and I tell you, it uses the same crappy hardware that linux uses too
[21:53] <Company> mathrick: I remember the time where you had to explicitly use DIrectSound in Winamp because mmsystem would block
[21:53] <Company> mathrick: yes, that proves my point - the reason there is no sound server is that noone of the good people cares enough to write one
[21:54] <mathrick> Company: ok, but why not *allow* doing that transparently in kernel? I don't want to *implement* it in kernelspace, I just want apps to stop worrying about such stupid choice as which sound server is better
[21:54] <Company> mathrick: 1) kernelspace means you'Re forced to use that particular kernel
[21:54] <Company> mathrick: 2) kernelspace means crashes are more fatal
[21:55] <mathrick> Company: mebbe, ALSA guys did wrote Lisp machine for config after all, so they aren't probably that good ;)
[21:55] <Company> mathrick: 3) it's just an API
[21:55] <Company> mathrick: I hate using ioctls and read/write
[21:55] <mathrick> Company: 3) No, it's hundreds of different APIs and libs
[21:56] m_wheels ([email protected]) joined #gstreamer.
[21:56] <Company> mathrick: one sound server is one API
[21:56] <Company> mathrick: like Xlibs
[21:57] <mathrick> Company: no, Xlibs are more than just sound server equivalent
[21:57] <Company> they're an API, just like ioctls are
[21:58] <Company> and I'll take writing alsalib code over writing oss code any day
[21:58] <Company> even though alsalib is an overengineered undocumented pos
[21:59] jdahlin ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[21:59] thomasvs ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[21:59] Action: Company notices that it feels good to rant about sound servers
[21:59] <Company> i should do that more often when i'm arguing with thomas
[21:59] <mathrick> Company: ok, and if I just suddenly want to use your smartass ALSA using app over net, then what?
[22:00] <mathrick> Company: why should I care about what apps are net-enabled?
[22:00] <Company> mathrick: then you set the ALSADRIVER env var (there probably is something like that) to use soundserver:192.168.0.1:0
[22:01] <mathrick> Company: are you sure there is mechanism for that, or are just speculating?
[22:02] <Company> i dunno if there's a mechanism for changing the output
[22:02] <Company> via env vars at least
[22:02] <Company> but you can use alsasink device=dmix and off you go
[22:02] <Company> alsalib is a pluggable framework
[22:03] <Company> in fact plugging is so complicated that parsing the config file requires a lisp language
[22:03] <ds-work> requires?
[22:03] <mathrick> Company: Why not do it for every sound using apps, not just alsa ones? And why not set it once, not for every app separate?
[22:03] <Company> ds-work: at least the devs think it does or they wouldn't put lisp in alsalib ;)
[22:04] <mathrick> Company: and why not change it one-the-fly, not at app startup?
[22:04] <mathrick> s/one/on/
[22:04] <Company> mathrick: given their lisp engine that should probably already be possible
[22:04] <Company> really, alsalib does everything you want
[22:05] <Company> you have a .asoundrc that defines the dwefault audio device
[22:05] <mathrick> Company: hmm, are you able to take arbitrary gst app that happens to use alsasink, and change it's output on the fly?
[22:05] <mathrick> s/it's/its/
[22:05] <Company> mathrick: dunno, that never occurred to me ;)
[22:06] <Company> mathrick: but you could just write an alsalib plugin that allows that
[22:06] <Company> if that's not possible
[22:06] Action: mathrick is generally pissed by Linux inability to change things on the fly
[22:06] <Company> uhm
[22:06] <Company> changing things on the fly is one of the hardest parts
[22:07] <Company> creating something is easy
[22:07] <Company> properly removing it is hard
[22:07] <mathrick> i mean, it's neato to just change resolv.conf and have it working, but being unable to change XIM while running is driving me crazy
[22:07] <Company> but changing it on the fly is a hell of a job
[22:07] <Company> best example: gstreamer
[22:07] <taf2> is there sample code that shows how to use gstreamer to determine say the number of seconds in a particular mp3/ogg file?
[22:08] <taf2> or can someone explain it briefly?
[22:08] <Company> gst_element_query (sink_element, GST_QUERY_TOTAL, GST_FORMAT_TIME, &value);
[22:08] <Company> or something like that
[22:08] <Company> gstplay does that
[22:08] dolphy ([email protected]) joined #gstreamer.
[22:09] <Company> dolphy: i fixed osssink, it should now return the correct time
[22:09] <mathrick> Company: yeah, but partly I mean something like in windoze, when you're able to run some CJK viewer app, and have every text rendering magically being Japanese capable
[22:10] <dolphy> Company: great thx ! :)
[22:10] <mathrick> Company: and yeah, I know it has its price, too
[22:10] <Company> you can change a lot of stuff on the fly in Linux
[22:10] <dolphy> Company: what about the READY issue and time of elements ?
[22:10] <Company> like gtk themes
[22:10] <taf2> Company: thx
[22:10] <Company> dolphy: READY issue?
[22:11] <dolphy> Company: in my mail i m explaining that when setting the pipeline to READY in the middle of playback and then opening another media
[22:12] <dolphy> Company: the time of elements is probably wrong
[22:12] <mathrick> Company: I know, but all that requires special consideration beforehand. And lot could be done by allowing overriding of symbols in running binaries, ie like LD_PRELOAD, just not PRE ;)
[22:12] <Company> mathrick: ugh
[22:12] <mathrick> Company: OTOH, it makes removing running binaries possible...
[22:13] <Company> mathrick: you never know what you break there
[22:13] <Company> dolphy: shouldn't happen - give me an easy way to reproduce :)
[22:14] <Company> s/reproduce/reproduce reliably/ ;)
[22:14] <dolphy> Company: open gst-player with matrix.avi
[22:15] <dolphy> Company: toggle repeat in the playlist and press next :)
[22:15] <mathrick> Company: anyway, my point is i see no sense in _not_ enhancing apps transparently when it's possible, which is the case with current sound support in Linux
[22:16] thaytan ([email protected]) left irc: No route to host
[22:16] <Company> mathrick: i very much see the point of not using the kernel as a layer and API provider between sound server and apps
[22:17] <mathrick> Company: so you apparently fail to explain it, because I see no such reason
[22:17] jdahlin ([email protected]) joined #gstreamer.
[22:17] <mathrick> yo jdahlin
[22:17] thomasvs ([email protected]) joined #gstreamer.
[22:18] <Company> mathrick: you don't want to wait for a new kernel revision to allow a new function call between app and sound server
[22:18] hyriand ([email protected]) left irc: "foop"
[22:18] <Company> mathrick: you don't want to limit your sound server to one kernel
[22:18] <mathrick> Company: huh? how would that limit anything?
[22:19] <mathrick> thomasvs: where can be patched site seen? It's not at freedesktop.org/~gstreamer
[22:19] <dolphy> Company: ok your fix for osssink is ok but still alsasink is working differently
[22:19] <dolphy> Company: can you fix it the same way ?
[22:20] <mathrick> Company: and  how do apps currently opening /dev/dsp benefit from not being enabled to use sound server transparently?
[22:21] <Company> mathrick: I can use alsalib on windows
[22:22] <Company> mathrick: I can't use /dev/dsp there
[22:22] Action: ds-work gets sync with esdsink by using magic values from esd internals
[22:22] <mathrick> Company: ok, but take any app that uses /dev/dsp *right now*? how does it benefit?
[22:23] <thomasvs> mathrick: yeah, fixing up some things
[22:23] <mathrick> thomasvs: ah, ok
[22:25] <Company> ds-work: http://www.lynch-mob.net/killakitten.jpg
[22:25] <Company> mathrick: it doesn't
[22:25] <ds-work> I want to "click here to play" but I can't
[22:26] <Company> mathrick: my X10 apps don't work anymore either
[22:26] <ds-work> Company: where was that quote from?
[22:26] <mathrick> Company: so, what is the point in _not_ enabling that? You have explained why probably it wasn't done, but I don't see why you're so much against it
[22:26] <mathrick> Company: huh? what do you mean by that?
[22:27] <Company> ds-work: you can play here: http://www.lynch-mob.net/games.html ;)
[22:27] ChriHJW ([email protected]) joined #gstreamer.
[22:27] <Company> mathrick: there's progress and app have to update
[22:27] ChrisHJW ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[22:27] hadley ([email protected]) joined #gstreamer.
[22:27] <Company> ds-work: the original quote came from stuff like http://i.xanga.com/staque/t/kill%20kitten.jpg
[22:28] <mathrick> Company: yep, so we have some common views actually ;). Doing that will only ease going with progress, not hinder it
[22:29] <Company> yeah, you could actually write an driver for a sound card that calls functions from a sound server that uses alsalib to output sound to the network
[22:29] <Company> that'd work
[22:30] <ds-work> alsalib does network audio?
[22:30] <ds-work> that's gross
[22:30] <Company> no
[22:30] <ds-work> oh, ok
[22:30] <Company> alsalib is a pluggable framework
[22:31] <ds-work> so you _could_
[22:31] <Company> yeah
[22:31] <Company> you could write a gst driver for alsalib and then the possibilities are endless
[22:31] <Company> that way you could even output to goom!
[22:31] <dolphy> Company: so here is the issue
[22:31] <dolphy> Company: on my computer here i can see it better
[22:32] <dolphy> Company: when setting the pipeline to READY the current time stays in the elements some how
[22:32] <dolphy> Company: and when i set a new location to the pipeline 
[22:32] <dolphy> Company: even with a new autoplugger
[22:32] <dolphy> Company: audio sink and video sink are running like crazy to reach the time they were on the previous media
[22:32] <dolphy> Company: am i clear ?
[22:33] <dolphy> Company: so if you are in the middle of a movie and load another one
[22:33] <dolphy> Company: you CPU will work 100 cpu trying to go to the middle of the media
[22:33] <dolphy> Company: just running very very very fast
[22:33] <Company> understood
[22:33] <Company> i'll look at it
[22:34] <Company> but not right now
[22:35] <dolphy> approximate delay please ?
[22:36] <Company> no idea, i'm going to watch a movie now :)
[22:37] <dolphy> enjoy then :)
[22:37] <dolphy> but that's one of the biggest regression ever 
[22:37] <dolphy> so keep it in memory
[22:37] <dolphy> :)
[22:42] <Company> i'll keep it in mind
[22:42] mxpxpod ([email protected]) joined #gstreamer.
[22:43] <mxpxpod> is ffmpeg supposed to be built?
[22:43] <mxpxpod> in gst-plugins
[22:43] <Misirlou> no
[22:43] <Misirlou> everything is supposed to not work
[22:44] <thomasvs> mxpxpod: if it doesn't, please mail the list, so I get some buy-in to take out hte ffmpeg stuff :)
[22:44] hadley ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[22:44] Misirlou ([email protected]) left irc: "asdf"
[22:45] <mxpxpod> thomasvs: it gets to the ffmpeg config option and instead of trying to d/l it, it just says that it won't be built
[22:45] <thomasvs> mxpxpod: I'd love to fix it, but I'm not going to as long as it's part of the bigass plugin tarball
[22:45] <mxpxpod> thomasvs: no, this is cvs head
[22:46] <thomasvs> mxpxpod: I know
[22:46] <mxpxpod> oh, ok
[22:46] <mathrick> mxpxpod: just co ffmpeg manually, it should help
[22:46] <ds-work> thomasvs: I'm looking for your opinion for liboil-lite
[22:46] <mxpxpod> mathrick: where from?
[22:46] <ds-work> should I make it an entire autotools project, or just a directory with a Makefile.am?
[22:47] <ds-work> or both
[22:47] <thomasvs> ds-work: well, I don't really know what liboil-lite is
[22:47] <thomasvs> ds-work: so feel free to share so I can give an informed opinion
[22:47] <ds-work> the purpose being that people will add the entire tarball into, say, GStreamer
[22:47] <ds-work> liboil-lite is a portable version of liboil
[22:47] <ds-work> liboil is a library of optimized inner loops
[22:47] <thomasvs> ah, cool name
[22:47] <thomasvs> :)
[22:48] <thomasvs> drop the lib though :)
[22:48] <ds-work> I like the liboil-lite, myself :)
[22:48] <thomasvs> ok, so you want the tarball to both build, but also be integratable in another tarball ?
[22:48] <thomasvs> ie, you want people to actually put your tarball in theirs ?
[22:48] <ds-work> liboil will contain both liboil and liboil-lite
[22:48] <mathrick> mxpxpod: go to gst-libs/ext/ffmpeg/, and do it like Makefile is supposed to do. So after that, you should have checkout in gst-libs/ext/ffmpeg/ffmpeg
[22:49] <ds-work> liboil-lite is never installed, i.e., a noinst_LTLIBRARY
[22:49] <mxpxpod> mathrick: should I build cvs with --disable-plugin-builddir?
[22:49] <ds-work> projects such as GStreamer will add the liboil-lite directory to their tarball
[22:50] <mathrick> mxpxpod: no, just run ./configure manually after ./autogen.sh
[22:50] <ds-work> and use that as a backup if the system doesn't have liboil
[22:50] <mathrick> mxpxpod: cd gst-libs/ext/ffmpeg/ && cvs -d:pserver:[email protected]:/cvsroot/ffmpeg co ffmpeg
[22:50] <mathrick> mxpxpod: hmm, wait
[22:50] <ds-work> because liboil uses GCC extensions heavily
[22:52] ChriHJW ([email protected]) left irc: Client Quit
[22:52] <mathrick> mxpxpod: cd gst-libs/ext/ffmpeg/ && cvs -d:pserver:[email protected]:/cvsroot/ffmpeg co -D $((cat Tag)) ffmpeg
[22:53] <mathrick> mxpxpod: that should work
[22:58] <mxpxpod> thanks
[22:59] hyriand ([email protected]) joined #gstreamer.
[22:59] <mathrick> lo hyriand
[23:02] <dolphy> hmmm catching the XErrors in x[v]imagesink is a pita
[23:02] <dolphy> i don't see how to handle the remote display with XShm issue
[23:03] <taaz> can you just steal code from gdkimage?
[23:05] <dolphy> well i know how to catch an XError
[23:05] <thomasvs> ds-work: and liboil-lite would contain less, but with the same API ?
[23:05] <dolphy> my issue is that i would like to fail nicely on NULL_TO_READY
[23:05] Action: thomasvs is a bit confused
[23:06] <dolphy> if XShm is not possible on the screen because it has the extension but won't work (remote display) mostly
[23:06] <dolphy> so i call a function trying to create an image with XShm
[23:06] <dolphy> setting an error handler
[23:06] <dolphy> but the issue is there
[23:07] <mathrick> thomasvs: no, -lite would contain unoptimized inner loops (so it would be libunoil then ;) I think
[23:07] <dolphy> the error handler gets called but can't tell the plugin that it was calle
[23:07] <dolphy> called
[23:07] <dolphy> xvideosink does that with a static global var
[23:07] <dolphy> that's ugly
[23:07] <dolphy> and won't work with multiple video sinks
[23:08] <thomasvs> mathrick: http://www.freedesktop.org/~gstreamer/
[23:08] <pb_> it'll work with multiple sinks unless they are all being initialised simultaneously.
[23:08] <thomasvs> mathrick: still need to fix up lots of links though
[23:08] <pb_> and on a modern machine I guess you could fix that with __thread.
[23:08] <thomasvs> but at least, it now seems to work when committing stuff
[23:08] <thomasvs> Uraeus: btw, you didn't fix any of the locations for the tasks :)
[23:08] <thomasvs> Uraeus: where you planning on doing that ?
[23:08] <ds-work> thomasvs: same API, different ABI, most features limited
[23:09] <thomasvs> ds-work: so why go through this special setup ?
[23:09] <thomasvs> ds-work: why not just let projects require liboil, period ?
[23:09] <mathrick> ds-work: but it will actually do the same work, just not as fast?
[23:09] <ds-work> because liboil is GCC-specific
[23:09] <dolphy> pb_: well relying on the fact that they won't initialize simultaneously is not a solution
[23:10] <pb_> dolphy: you could serialize them with a mutex.
[23:10] <ds-work> mathrick: yeah
[23:10] <mathrick> pb_: why simultanous init matters?
[23:10] <thomasvs> ds-work: guess you still have me a little confused at the point :) would liboil also use liboil-lite as the fallback ?
[23:10] <mathrick> pb_: ahh, n/m
[23:10] <pb_> dolphy: unless you use a different X binding library, I don't think there is any other real solution.
[23:10] <thomasvs> mathrick: now that you asked about it yourself, I do expect you to go check and comment of course
[23:10] <mathrick> thomasvs: ok :)
[23:11] <ds-work> thomasvs: no.  liboil-lite is packaged with liboil so that I can test that it passes the same regression tests
[23:11] <mathrick> thomasvs: but my net isn't behaving all that nicely now, so it'll take some time
[23:11] <thomasvs> ds-work: ok - so how are you laying out your cvs module ?
[23:11] <thomasvs> ds-work: since I'm assuming you have two configures then ?
[23:11] <taaz> dolphy: it's the lack of userdata field in x callbacks right?
[23:11] <dolphy> yeaahhh
[23:11] <dolphy> exactly
[23:12] <thomasvs> ds-work: or is liboil-lite so small and does it use so little configure stuff that you just expect projects to do that themself ?
[23:12] <mathrick> thomasvs: "Recent older news:" <-- i still think it's kinda funny :)
[23:12] <ds-work> thomasvs: that's the issue.  I want to know what is most useful for downstream developers
[23:12] <thomasvs> mathrick: yeah, suggestions welcome
[23:12] <ds-work> liboil-lite should depend only on a C compiler
[23:12] <thomasvs> ds-work: well, as you probably know you can run another configure from configure
[23:12] <pb_> dolphy: actually, come to think of it, any particular X display is always going to be either local or remote, so perhaps the concurrency thing isn't such a big deal.
[23:12] <ds-work> thomasvs: yeah
[23:12] <thomasvs> ds-work: hm, but I haven't checked if that plays nice in all cases, including nonsrcdir builds and distchecks
[23:12] <mathrick> dolphy: x callbacks don't have userdata? how does one use them for anything useful then?
[23:13] <ds-work> thomasvs: liboil-lite does need to get equivalents for stdint.h
[23:13] <dolphy> mathrick: hey why you ask me :)
[23:13] <dolphy> mathrick: the error handler callback has no user data
[23:13] <thomasvs> ds-work: yeah, but that can be put inside a LIBOIL .m4
[23:13] <dolphy> mathrick: that's a bit stupid
[23:13] <mathrick> dolphy: so other ones do?
[23:13] <mathrick> dolphy: not just a bit ;)
[23:13] <dolphy> mathrick: haven't seen much callbacks there
[23:13] <pb_> well, it's not really the lack of user data that's a problem, it's the fact that you don't have any real way of tying up requests and errors.
[23:14] hadley ([email protected]) joined #gstreamer.
[23:14] <thomasvs> ds-work: so does liboil live somewhere ? I'm having a hard time figuring out why they need to be separate and how you want projects to use it
[23:14] <thomasvs> so I'd like to look at it
[23:14] hadley ([email protected]) left irc: Client Quit
[23:14] <ds-work> it's in Comedi CVS
[23:14] <pb_> the only way that a user-data field would be useful here would be if you passed the user data in with every request that could possibly generate an error.
[23:15] <ds-work> thomasvs: I want GStreamer to put a tarball of liboil-lite in gst-libs/ext/
[23:15] <dolphy> pb_: user data would be usefull
[23:15] <ds-work> thomasvs: and use it as a backup if liboil isn't found
[23:15] <pb_> dolphy: in what way?
[23:15] <dolphy> pb_: because you could at least have a pointer to a struct containing a status and the error message
[23:15] <ds-work> thomasvs: _especially_ for platforms where liboil won't work
[23:15] <thomasvs> ds-work: right - but why is the fallback not just part of liboil anyway ?
[23:16] <thomasvs> ds-work: is it just the fact that people will complain about a dependancy ?
[23:16] <pb_> dolphy: right, but where would the user data be set?  You can't do it with XSetErrorHandler(), because error handlers are not per thread.
[23:16] <ds-work> thomasvs: partially
[23:16] <ds-work> thomasvs: also because they have different ABIs
[23:16] <ds-work> thomasvs: also, because I want to be able to do API churn easily
[23:17] <dolphy> pb_: well at each call of XSetErrorHandler
[23:17] <pb_> dolphy: like I just said, I don't think that would work.
[23:18] <dolphy> well ok
[23:18] <dolphy> i think it might be better to have a use_shm property
[23:18] <pb_> is it such a big deal to put a mutex around your shm operations?
[23:19] <Company> dolphy: the best solution is to try to create an image on context setup and put a global mutex around that
[23:19] <dolphy> i have a mutex already
[23:19] <thomasvs> ds-work: basically, to me the easiest would seem something like this
[23:19] <dolphy> but it s not global to the class
[23:19] <dolphy> it's per instance
[23:19] <thomasvs> a) in the liboil module, you have a liboil-lite subdir
[23:19] <thomasvs> b) in the root, an .m4 that handles all liboil-lite checking
[23:20] <thomasvs> c) the liboil-lite Makefile.am would be the same for projects including it as for the source location
[23:20] <pb_> dolphy: ok.  so, if you add a global mutex as well that just guards the call to XShmCreateImage() and the associated error handling goop, you can use a static global in your error handler and the problem goes away.
[23:20] <thomasvs> d) a project would just copy the liboil-lite subtree from a tarball release or cvs and put it in local cvs in a subdir
[23:20] <thomasvs> all it has to do is copy the subtree, copy the m4 in its m4 dir, and put one call in configure.in
[23:20] <pb_> and you could provide a __thread-based implementation as well for NPTL-using h4x0rs.
[23:20] <thomasvs> as well as make sure that the subdir it's put in is part of a SUBDIRS somewhere
[23:21] hallibaby ([email protected]) joined #gstreamer.
[23:21] <Company> i still don't get why you would need a libsomething-lite
[23:21] <ds-work> dunno, maybe it's a bad idea
[23:21] hallibaby ([email protected]) left irc: Client Quit
[23:21] <thomasvs> Company: because the name is cool
[23:21] <thomasvs> ds-work: I'm not completely convinced yet either
[23:21] <dolphy> pb_: hmm could work
[23:21] <ds-work> I just have no intention of making liboil portable
[23:22] <Company> ds-work: that will happen automatically if it's good
[23:22] <thomasvs> ds-work: to me it sounds like you could just do liboil as a lib, and have gst put it in ext libs for now
[23:22] <Company> nah
[23:22] <dolphy> pb_: do you know if that error callback from X will just be run instead of the X call and then execution continues after the X call ?
[23:22] <thomasvs> ds-work: so is this at all related to omega's corecodec ideas ?
[23:22] <Company> putting stuff in ext that could be done as a seperate thing is kinda stupid
[23:22] <ds-work> somewhat
[23:22] <Company> we already hate ffmpeg ;)
[23:22] <ds-work> I plan to be a better upstream than ffmpeg
[23:22] <pb_> dolphy: yeah.  since XShmCreateImage() returns a result, it will implicitly XSync().  so, if the error is going to happen, it will happen inside that function call.
[23:23] <Company> no it won't
[23:23] <Company> the error happens on XShmAttach
[23:23] <thomasvs> anyone know how to make cvs stop complaining on a subdir not in cvs when doing cvs commit ?
[23:23] <ds-work> thomasvs: this is my project doing it my way, because omega never actually had working code
[23:23] <dolphy> Company: only?
[23:23] <pb_> oh, does it?  whoops.  in that case, you might need an explicit sync.
[23:23] <robUx4> bye
[23:23] robUx4 ([email protected]) left irc: "Baby wants to bleep"
[23:24] <dolphy> pb_: so the error might happen in the XSync then
[23:24] <Company> dolphy: look at gdk - every other failure produces a g_warning
[23:24] <thomasvs> argh
[23:24] <pb_> dolphy: right.
[23:24] Action: thomasvs kicks ronald for not even trying to build the docs he writes
[23:25] <Company> which proves two points: a) we don't write quality code b) doc builds suck ;)
[23:26] <thomasvs> you completely lost me on a)
[23:26] <Company> quality code (and docs are code) always compiles and has tests attached to it
[23:27] <Company> we all fail there :)
[23:28] <mathrick> thomasvs: somehow on task page encoding is set wrong, ie. it's not UTF-8, which gives  between links to tasks. I don't know if it isn't http server lying and Mozilla preferring it over META though
[23:28] <mathrick> thomasvs: it looks like recent mozillas started to like server encoding info more than META one
[23:30] <thomasvs> mathrick: hm. will check that
[23:30] <thomasvs> mathrick: but not sure if I can influence the server encoding on freedesktop
[23:31] <mathrick> thomasvs: yeah, that sucks. Can't really understand why Mozilla does that, but AFAICT it got changed somewhere above 1.3
[23:31] Nick change: harshyWork -> harshy
[23:31] m_wheels ([email protected]) left irc: "using sirc version 2.211+KSIRC/1.3.9"
[23:32] <mathrick> thomasvs: it's especially visible on Japanese pages that often start to break badly :\
[23:32] wheels ([email protected]) joined #gstreamer.
[23:32] Action: dolphy got another idea
[23:33] <thomasvs> mathrick: hm. well, the result from xsltproc on the fdo server is different from locally
[23:33] <thomasvs> mathrick: but not sure yet why
[23:34] <thomasvs> hm
[23:34] <thomasvs> maybe because the locale isn't set properly when doing xsltproc
[23:35] <mathrick> thomasvs: hmm, META is correct, and manually setting encoding to UTF-8 works
[23:36] <thomasvs> mathrick: hm, I'm confused now
[23:36] <thomasvs> mathrick: it looks to me like fdo server doesn't have utf8 locales
[23:36] <thomasvs> which would suck
[23:36] <mathrick> thomasvs: do you happen to have japanese fonts installed? then you could try http://tcp.com/~doi/index.html , the text in parens on first sentence. It's the same thing I think
[23:36] <mathrick> thomasvs: that used to work on Mozilla 1.3
[23:37] <thomasvs> for me it's square symbol square symbol square
[23:39] <mathrick> thomasvs: anyway, for me it's lotsa trash, and should be proper Japanese, as encoding is specified in meta. But it looks like server is set incorrectly, and Mozilla prefers it over META, which is strange
[23:39] Marsupilami23 ([email protected]) 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!"
[23:43] yippi ([email protected]) joined #gstreamer.
[23:44] <thomasvs> mathrick: can you check the tasks again ?
[23:44] <thomasvs> i twiddled my browser so I'm not usre it's correct now
[23:45] Marsupilami23 ([email protected]) joined #gstreamer.
[23:46] Marsupilami23 ([email protected]) left irc: Client Quit
[23:46] <mathrick> thomasvs: looks like it's ok now. But Konqueror did it right from beginning, so I should probably bug mozilla guys as well
[23:48] hyriand ([email protected]) left irc: "Lost terminal"
[23:49] markey ([email protected]) left irc: "nite"
[23:50] <Company> we need a graphics artist to tune the page ;)
[23:50] <mathrick> thomasvs: what exactly did you change?
[23:50] <mathrick> Company: true ;)
[23:50] <Company> and if you care: ds is the qtdemux guy, not BBB
[23:51] sublett ([email protected]) left irc: "I like food, food is good!"
[23:51] <thomasvs> mathrick: make .htaccess serve it as utf8
[23:51] <mathrick> thomasvs: probably you'll change that, but that gst-player "thumbnail" (which is actually full image scale down - not very nice) looks also kinda out of place
[23:52] <mathrick> thomasvs: ah, but that's really Mozilla bug i think
[23:52] <mathrick> thomasvs: I don't think it should ever prefer http hints over explicit META info
[23:53] <thomasvs> mathrick: yeah, well, not our call :)
[23:53] Action: mathrick files Mozilla bug for that
[23:56] <thomasvs> mathrick: yeah, looking with mozilla it seems that indeed fixed it
[23:56] <thomasvs> mathrick: kind of sucks to need htaccess for that though
[00:00] --- Wed Jan 28 2004
[00:00] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[00:02] <Uraeus> ok, time for me to sleep also, night everyone
[00:02] Uraeus ([email protected]) left irc: "Client exiting"
[00:03] dolphy ([email protected]) joined #gstreamer.
[00:05] Company ([email protected]) left irc: Remote closed the connection
[00:06] yippi ([email protected]) left irc: Remote closed the connection
[00:08] Phiend ([email protected]) left irc: 
[00:22] <dolphy> hmm sweet
[00:23] <dolphy> XvQueryAdaptors blocks forever when querying on a remote displa
[00:23] <dolphy> display
[00:26] <mathrick> dolphy: this is the call used to grab Xv port?
[00:27] <dolphy> yupo
[00:27] <dolphy> not to grab
[00:27] <dolphy> just to query
[00:27] <dolphy> if xv port available
[00:27] <dolphy> that blocks 
[00:27] water ([email protected]) joined #gstreamer.
[00:27] Shoragan ([email protected]) left irc: "Leaving"
[00:28] <mathrick> dolphy: so Xv extension is reported to be available, but any try to actually use it will block? Kewl
[00:30] <mathrick> dolphy: I wonder what genius designed it that way, and if he heard of X being network transparent :\
[00:31] <dolphy> mathrick: it's full of stuff like that
[00:31] <dolphy> mathrick: same for XShm
[00:31] water ([email protected]) left #gstreamer ("The water has parted.").
[00:31] <dolphy> mathrick: you query the extension. it tells it's available
[00:31] <ds-work> X extensions are, in general, complete crap
[00:31] <dolphy> mathrick: you use it and boom
[00:31] <dolphy> mathrick: i m now having a hard time
[00:31] <dolphy> mathrick: because of that shit
[00:32] Rotty ([email protected]) joined #gstreamer.
[00:32] <mathrick> ds-work: inherently, or just the ones that are around?
[00:34] <ds-work> mathrick: the ones that are around
[00:35] mxpxpod ([email protected]) left irc: "Guns kill people as much as spoons made Rosie O'Donnell fat.."
[00:36] ryanpg ([email protected]) joined #gstreamer.
[00:39] <dolphy> ok think i found a solution :)
[00:41] <dolphy> ah no :-(
[00:41] Action: dolphy kicks XFree86
[00:46] thaytoo ([email protected]) joined #gstreamer.
[00:49] <mathrick> yo thaytoo
[00:50] <thaytoo> yo yo
[00:57] ryanpg ([email protected]) left #gstreamer ("Leaving").
[01:08] Action: mathrick needs to grab some sleep
[01:08] <mathrick> nite
[01:08] Nick change: mathrick -> mathrick|sleep
[01:11] Marsupilami23 ([email protected]) joined #gstreamer.
[01:15] jimmy_dean ([email protected]) joined #gstreamer.
[01:16] iain ([email protected]) left irc: "leaving"
[01:16] <dolphy> k it works for ximagesink at least
[01:17] <dolphy> ximagesink detects that XShm calls are failing silently and disable XShm usage automatically
[01:17] <dolphy> xvimagesink tries to do the same but XvQueryAdaptors is blocking for ever with a remote display (looks like a XFree86 bug)
[01:18] <dolphy> and anyway xvimagesink will never work on a remote display
[01:18] <ds-work> dolphy: have you thought about plugging/unplugging visualizers on the fly?
[01:23] <dolphy> ds-work: visualizers ?
[01:23] <dolphy> ds-work: what's that
[01:25] <ds-work> goom
[01:25] <ds-work> synasthesia
[01:28] <dolphy> ds-work: it works normally
[01:28] <dolphy> ds-work: gst_play_set_visualization is just unpluging repluging the vis_element in vis_bin
[01:28] <dolphy> ds-work: so just setting the pipeline to pause unlink/relink and set to PLAYING again
[01:28] <dolphy> ds-work: should work
[01:29] <ds-work> i see
[01:29] <dolphy> ds-work: and then gst_play_connect_visualization put the vis_bin in the play pipeline
[01:29] <dolphy> ds-work: connecting to identity handoff for a single shot warning that video is available
[01:29] <dolphy> ds-work: which disconnects visualization then
[01:35] pb_ ([email protected]) left irc: "Client exiting"
[01:35] <dolphy> k off to bed
[01:35] <dolphy> night
[01:36] <dolphy> taaz: please test ximagesink with the display
[01:36] <dolphy> taaz: it works here
[01:37] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[01:51] bitshifter ([email protected]) left irc: Read error: 110 (Connection timed out)
[01:51] bitshifter ([email protected]) joined #gstreamer.
[02:03] walters ([email protected]) joined #gstreamer.
[02:17] Action: taf2 gstreamer needs better documentation
[02:18] Action: taf2 spent half of day trying to figure out how to determine the length in seconds of my mp3 using gstreamer interface still no success
[02:19] Action: taf2 still trying...
[02:19] Action: sxpert is away: time to go to bed ... good night, talk to you later :D
[02:22] <taf2> is gstplay still active?
[02:23] <ds-work> it's what gst-player uses
[02:24] earthworm ([email protected]) joined #gstreamer.
[02:24] <taf2> i'm looking through cvs.sf.net/viewcvs.py/gstreamer and most files there haven't been modified since 2002 for gstplay
[02:24] <earthworm> would it ever be possible to port gstreamer to windows?
[02:24] <ds-work> yes, just compile it and fix the comile failures
[02:25] <ds-work> and write sources and sinks applicable for windows
[02:25] <earthworm> would there be any point?
[02:25] <ds-work> taf2: we don't use sourceforge
[02:25] <taf2> ds-work: stubled on it via google freedesktop.org now right 
[02:26] Rotty ([email protected]) left irc: Remote closed the connection
[02:26] Nick change: Jara[zZ] -> Jaramir
[02:29] sub_pop ([email protected]) joined #gstreamer.
[02:42] Nick change: Jaramir -> Jara[zZ]
[02:55] Nick change: sub_pop -> sub_away
[02:59] harshy ([email protected]) left irc: "I quit for now"
[02:59] smoke_ ([email protected]) joined #gstreamer.


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn