IRC Logs

*******************************************************************
[03:09] Rounin ([email protected]) left irc: "Client exiting"
[03:10] <ds-work> ack
[03:10] Action: ds-work FINALLY has built DLLs with libtool
[03:10] ChrisHJW ([email protected]) left irc: Read error: 110 (Connection timed out)
[03:16] <Company> ds-work: how? how? how?
[03:16] <ds-work> if you give libtool the right options, it just works
[03:16] <ds-work> I have not been giving libtool the right magic options
[03:16] <Company> that sounds pretty much like you need to tell me ;)
[03:16] <Company> because configure --enable-shared doesn't work ;)
[03:16] <ds-work> in particular, --no-undefined != -no-undefined
[03:17] <ds-work> anyway, I'm fixing a bunch of gstreamer compile problems
[03:17] <ds-work> and building dlls will be one of them
[03:20] Action: Company goes implementing queues in entry
[03:22] <Company> i wonder why hadess is so impressed by usound
[03:23] <ds-work> because someone is actually working to solve a problem?
[03:23] Action: Company was not impressed anymore after reading it requires gnu pth
[03:23] <Company> why would you write a multithreaded sound server
[03:23] <Company> ?
[03:24] <Company> ok, that's a valid argument - people are often impressed when someone announces he'll do something ;)
[03:24] <ds-work> hint: pth stopped development in 1993
[03:25] <Company> isn't that just another reason to not be impressed?
[03:27] sublett ([email protected]) left irc: "I quit, therefore I was"
[03:36] <Company> "Pa_IsFormatSupported() when paUseHostApiSpecificDeviceSpecification or hostApiSpecificStreamInfo is used"
[03:36] <Company> someone suffers from ICantAbbreviateDoesntKMatterHowHardITry desease
[03:49] sub_pop ([email protected]) left irc: "Client exiting"
[03:50] sub_pop ([email protected]) joined #gstreamer.
[03:50] <Company> wow
[03:50] <Company> 10 lines
[03:57] <Misirlou> Company: woooooooooooooooo valgrindiness
[03:58] <Company> Misirlou: :)
[04:03] dholmes ([email protected]) joined #gstreamer.
[04:32] Action: ds-work hacks an m4 macro to work around libtool's DLL brokenness
[04:32] Rounin ([email protected]) joined #gstreamer.
[04:32] <Rounin> Lol
[04:32] <Rounin> I just wanted to announce that I've just made an MP3 player with gstreamer
[04:33] <Rounin> And it's 4:30
[04:33] <Rounin> http://home.no.net/david/temp.png
[04:36] <Company> as long as it works ;)
[04:45] <Company> ds-work: question: GST_UINT64_FORMAT is defined as "llu", not "%llu"
[04:45] <ds-work> yes
[04:45] <Company> ds-work: #define GST_TIME_FORMAT "%u:%02u:%02u:%09u"
[04:45] <ds-work> because that's what glib uses
[04:45] <Company> ds-work: shouldn't that be "u:%02u:%02u:%09u"
[04:46] <Company> or is that stupid?
[04:46] <ds-work> it's hard
[04:46] <ds-work> we should just name them differently
[04:46] <ds-work> and make some like glib, and others (like GST_FOURCC_FORMAT) with a %
[04:47] <ds-work> since it doesn't make sense to put a size modifier on a fourcc
[04:47] <ds-work> glib's style is so you can do "blah %-20.20" G_UINT64_FORMAT "\n"
[04:48] <Company> yeah
[04:48] <Company> understood
[04:49] arana ([email protected]) joined #gstreamer.
[04:50] <Company> so wadda we do there?
[04:50] <ds-work> different naming scheme
[04:51] <ds-work> we pretty much have to deal with the differences
[04:51] <ds-work> we could leave the % off all of them, to be consistent
[04:51] <ds-work> but it's slightly buggy
[04:52] <ds-work> maybe it's better, though.  It would feel more consistent in the code, and you wouldn't have to remember special rules
[04:52] <ds-work> 'not remembering special rules' is a compelling reason, probably
[04:53] <Company> yeah
[04:53] <Company> and it doesn't hurt
[04:53] <Company> though we can't change it for GST_FOURCC_FORMAT
[05:03] <Company> hm, how does oss work wrt file descriptors?
[05:03] <ds-work> huh?
[05:06] Action: Company has no clue about polling
[05:06] <Company> but i want the schedulers to use it
[05:06] <Company> so how does this work if osssink can't write to its fd?
[05:08] <ds-work> you send poll() a list of all the events you want to poll for
[05:08] <ds-work> so you'd send poll osssink's fd, with POLLOUT
[05:09] <ds-work> along with other stuff
[05:09] <Company> so if i wanted to tell the scheduler that i'm waiting on an fd, what would i do?
[05:09] <Company> s/do/use for a function prototype/
[05:09] <ds-work> dunno, I'd have to think carefully about it
[05:10] <ds-work> I'd look at g_io_channel to start
[05:10] sub_pop ([email protected]) left irc: Remote closed the connection
[05:11] sub_pop ([email protected]) joined #gstreamer.
[05:11] spyder482 ([email protected]) left irc: Read error: 110 (Connection timed out)
[05:11] <ds-work> g_io_channel_watch() and friends
[05:13] sub_pop ([email protected]) left irc: Remote closed the connection
[05:13] <Company> the idea i'm following here is to never wait inside an element
[05:14] Rounin ([email protected]) left irc: "Client exiting"
[05:14] sack ([email protected]) left #gstreamer ("Leaving").
[05:14] <Company> so instead of an operation that would block, we transfer control back to the scheduler
[05:14] sub_pop ([email protected]) joined #gstreamer.
[05:15] <Company> so far i've identified 3 reasons why an element would block: fd, clock and just plain block until another thread wakes it up
[05:15] <ds-work> those are the only ways you can block in unix
[05:16] <ds-work> on an fd, in usleep, or on a mutex
[05:16] <ds-work> you can also block on a signal, but we don't need to support that
[05:18] <Company> alsa blocks on signals i think, but what do i care
[05:18] <ds-work> given that you can't dynamically allocate signals, they have no place in a library
[05:18] <Company> ds-work: would an element ever need to block on more than one fd?
[05:18] <ds-work> yes
[05:19] <ds-work> a multi-socket input
[05:19] <ds-work> or a multi-socket output
[05:19] <Company> i'd argue that that might better be multiple elements, but oh well
[05:20] <ds-work> you'd definitely want to be able to block on multiple condition variables
[05:21] <Company> ds-work: how do you block on multiple condition variables? and why?
[05:21] <ds-work> some internet protocols specify the use of two socket connections
[05:22] <Company> we should have named the function gst_pad_poll
[05:22] <Company> instead of gst_pad_collect
[05:22] <ds-work> it doesn't poll pads
[05:23] <Company> it's fine with me anyway
[05:23] <ds-work> one possible implementation of ximagesink could use a condition variable to determine when new events have become available on the X connection
[05:24] <ds-work> I discussed implmenting rtpsrc using a select() loop on a fd and a condition variable
[05:24] <ds-work> with ramon
[05:24] <ds-work> I can't think of anything that would _require_ multiple condition variables, but it's possible
[05:25] Action: Company just decided it's not possible
[05:25] <Company> if it must be you can implement it in your element
[05:25] <Company> element->condition = 0; block (element);
[05:25] <Company> element->condition = CONDITION_TYPE; unblock (element);
[05:26] Action: ds-work wonders why we don't schedule elements based on an element->cond condition variable
[05:26] <Company> hu?
[05:27] <ds-work> just have a master 'runnable' status in each element
[05:27] <ds-work> when polling or waiting determines that ximagesink is ready to push an image, set runnable=TRUE
[05:28] <ds-work> scheduler calls the chain function
[05:28] <Company> that's what i'm doing in my scheduler
[05:29] Action: ds-work rocks with auto-fu
[05:30] <Company> so
[05:31] <ds-work> building DLL's now requires changes/additions to 6 lines in Makefile.am
[05:32] <ds-work> Company: so basically, as long as you can wait on at least one user-defined condition variable, the element can implement chaining of multiple cond variables onto the one
[05:32] <Company> gst_scheduler_block_object (GstScheduler *sched, GstObject *block_me, struct pollfd *ufds, gboolean cond, GstClockTime time)
[05:32] <ds-work> don't use struct pollfd
[05:32] <Company> (though we need to use something better than pollfds)
[05:33] <ds-work> and that should be GCond *cond
[05:33] <Company> no
[05:34] <Company> because the call to unblock would just be unblock (sched, element)
[05:34] <Company> so there's no cond involved
[05:34] <ds-work> ok
[05:34] <ds-work> that makes more sense, probably
[05:35] <Company> i'm not sure how we should handlethe fds
[05:35] <Company> wrapping them in GIOChannels externally looks like overkills
[05:36] <Company> someone writing osssink doesn't want to care anut such stuff
[05:36] <Company> about
[05:36] <ds-work> I've been severely underimpressed with g_io_channel
[05:36] <ds-work> however, g_io_channel is portable
[05:37] <ds-work> er, portable to non-posix systems
[05:38] <Company> hm
[05:38] <Company> you're writing plugins, too, what would you do?
[05:41] <ds-work> I'd want g_io_create_watch()
[05:41] <ds-work> specify a fd and condition
[05:41] <ds-work> and then attach it to the element
[05:42] <ds-work> ...
[05:42] Action: ds-work thinks
[05:42] Action: ds-work needs to think of something without races
[05:42] <Company> why races?
[05:43] <Company> you know what sounds simplest?
[05:43] <Company> gst_element_add_fd (element, fd);
[05:43] <ds-work> yeah
[05:44] <ds-work> you need the mode, though
[05:44] <ds-work> some devices are stupid
[05:44] <Company> and just do gst_scheduler_block_element (sched, element, gboolean poll_fds, gboolean cond, GstClockTime time)
[05:44] <ds-work> iirc, oss configured for output is always readable
[05:45] <Company> yeah, gst_element_add_fd (GstElement *, GPollFD *);
[05:45] <ds-work> I like that
[05:46] <ds-work> or (GstElement *, int fd, GIOCondition cond_mask)
[05:47] <Company> yeah, that sounds best
[05:48] <Company> the only thing that sucks is that we can't use a normal GMainLoop because we use non-system clocks
[05:51] <Company> ds-work: do you get issues if two threads poll the same fd?
[05:52] <ds-work> one of them gets woken up randomly
[05:52] <Company> that's fine with me
[05:53] <ds-work> otherwise, it's pretty standard
[05:53] <Company> the thing is that you can block pads and elements
[05:53] <Company> pads for decoupled elements, elements for normal elements
[05:53] <ds-work> it's not uncommon to create a fd pair with pipe(), and use both in the same app
[05:53] <Company> what should gst_scheduler_block_element return?
[05:53] <ds-work> one thread pushes a byte on the pipe, another pulls a byte
[05:54] <ds-work> dunno.  what all does it do?
[05:54] <Company> it blocks until one of the wakeup conditions is reached
[05:55] <ds-work> called by an element in the chain function?
[05:55] <ds-work> say ximagesink?
[05:55] <Company> or get or loop
[05:55] <Company> yeah
[05:55] <ds-work> the element probably wants to know what woke it
[05:56] <Company> correct
[05:56] <ds-work> which pad, which fd, etc
[05:56] <Company> which pad is not a question
[05:56] <ds-work> that's why it would be wise to have a GstThingToWaitFor
[05:56] <ds-work> why not which pad?
[05:57] <Company> good question
[05:57] <Company> so there's a 4th thing you could wait for
[05:57] <ds-work> ideally, we should switch to a model where get/loop/chain functions are replaced with an event handler function
[05:58] <Company> yeah, that's the next step
[05:58] <ds-work> any design decisions now should move us toward that goal, imo
[05:58] <Company> first step is to make all elements not block
[05:58] <Company> yeah
[05:58] <Company> so you should be able to wait for an fd in gst_pad_pull
[05:59] <ds-work> I don't think making elements not block is a good goal until we have event_handler
[05:59] <ds-work> since it's a lot easier to write non-blocking code in that model
[05:59] <Company> well
[05:59] <ds-work> and plus, we need to support blocking elements for another year
[06:00] <Company> supporting blocking elements is not hard
[06:00] <Company> you just block and get a jerky app ;)
[06:01] <Company> so, you can wait on pads, fds, wakeup calls and a time
[06:02] <Company> sinkpads only obviously
[06:03] <Company> or not?
[06:03] <ds-work> videotestsrc technically waits on its srcpad
[06:03] walters ([email protected]) joined #gstreamer.
[06:04] <ds-work> or its clock
[06:07] <Company> yeah
[06:07] <Company> right
[06:08] <Company> so let's design the event handler
[06:10] <Company> you need a enum GstWaitState { GST_WAIT_PAD = 1, GST_WAIT_FD = 2, GST_WAIT_WAKEUP = 4, GST_WAIT_CLOCK = 8 }
[06:11] <Company> the event handler can then return those or'd together so you know what to wait for
[06:13] <Company> you can setup fds with element_add_fd, you can do the same with gst_pad_set_is_waiting (GstPad *, gboolean); (that name sucks)
[06:13] <Company> wakeup doesn't need setup
[06:14] <ds-work> gst_myelement_event_handler (GstElement *element, GstElementEvent *event)
[06:14] <Company> haha :p
[06:14] <ds-work> it should probably not be called "event_handler"
[06:15] <ds-work> iterate
[06:15] <Company> yeah
[06:15] <Company> and you need it per pad and per element
[06:15] <ds-work> why per pad?
[06:15] <Company> decoupled
[06:16] <Company> or you must be aware that that function may be called multiple times at once
[06:16] <ds-work> with iterate elements, "decoupled" is no longer an interesting concept
[06:16] <Company> it is for thread boundaries
[06:16] <ds-work> thread boundaries should be fluid
[06:17] <ds-work> not application defined, as they are now
[06:17] <Company> you cannot change that
[06:17] <Company> because you have to keep API compat
[06:17] <ds-work> of course
[06:17] <ds-work> but eventually
[06:17] <Company> yeah
[06:18] <Company> you don't need threads anymore anyway
[06:18] <Company> at least when the scheduler controls stuff
[06:18] <ds-work> iterate functions should not block or take much time, so threads waiting on the iterate mutex should not be too much of a problem
[06:19] <Company> yeah, ideally
[06:20] <ds-work> at least in the case of queue
[06:20] <ds-work> do we have any other decoupled elements?
[06:20] <Company> pipeline
[06:20] <Company> bah
[06:20] <Company> pipefilter of course
[06:21] <ds-work> I somehow would not feel bad if pipefilter disappeared
[06:21] <Company> well, it would work if it were not decoupled
[06:21] <Company> and in that case it would be a really nice testbed
[06:27] <Company> ds-work: do we want 1 iterate function or multiple?
[06:27] <ds-work> why multiple?
[06:27] <Company> ds-work: it sounds kinda stupid to have only one, because an element will definitely want to do different stuff for different event types
[06:27] <ds-work> switch()
[06:27] <Company> ds-work: and it's kinda stupid to implement a switch () in every iterate function ;)
[06:28] <Company> i hate that with pad event handlers today
[06:28] <ds-work> we do that in every event_handler and set_property function
[06:28] <Company> yeah
[06:28] <Company> both suck
[06:29] <ds-work> lets just do one function now, and figure out how to do it better after it works
[06:29] <Company> it's much less code if you set different functions
[06:29] <Company> i'd prefer to do it right from the start ;)
[06:29] <ds-work> don't
[06:29] <ds-work> do it _simply_
[06:30] <Company> i hate that for pad events, too
[06:30] <ds-work> because you _will_ do it wrong, it's just a matter of how deep of a hole you dug yourself
[06:30] <Company> there should just be gst_pad_set_event_handler (pad, event, handler)
[06:31] <ds-work> in complex iterate functions, you'll want to understand the full state before deciding what to do
[06:32] <Company> no
[06:32] <Company> because if the case of the iteration is "here's a buffer, handle it" you will have to handle a buffer
[06:33] <Company> but it's fine with me to allow both
[06:33] <ds-work> we'll want to use subclassing significantly once we go to iterate, since many elements fit very well into the chain model
[06:33] <ds-work> we can replace the chain model with a GstChain subclass
[06:34] <Company> yeah
[06:34] <ds-work> imo, we can put the complexity there
[06:34] <ds-work> and in the elements that are naturally complex
[06:34] <Company> fine with me, too
[06:35] <ds-work> I'm a bit concerned with the complexity of adding/removing iterate functions in your model, w.r.t adding/removing pads, etc.
[06:35] <Company> nah
[06:35] <Company> in my model you'd just have an iterate function for every event type
[06:36] <Company> one for pads, one for fds, one for wakeups, ...
[06:37] Action: ds-work doesn't like it
[06:37] <Company> yeah, ok, fine, we'll do the switch thingy
[06:37] <Company> it'll end up as ugly as query functions :p
[06:37] <Company> but i can blame you then
[06:39] <Company> so, next question: how do we implement that?
[06:39] <Company> branch off?
[06:39] <ds-work> probably
[06:42] <Company> i wonder how fast that aproach is
[06:43] <Company> you have a lot of function calls there
[06:43] <Company> gut you don't have cothread switches...
[06:43] <Company> s/gut/but/
[06:45] <Company> so i'll probably branch tomorrow and start implementing that
[06:56] <ds-work> should the prototype of gst_tag_register() use const char *?
[06:57] <Company> i was wondering that, too
[06:57] <Company> it probably doesn't matter, so it'd be ok
[06:57] <Company> though it could result in memleaks
[07:02] <ds-work> the mingw compiler enforces string literals as const char *
[07:02] <Company> make it const
[07:02] <Company> it was meant to be const
[07:08] <Company> ds-work: i'll add a "reviewed by ds" to the GST_TIME_FORMAT change
[07:09] <ds-work> is that new since 0.8.0?
[07:09] <Company> ds-work: it's not even a day old
[07:28] bilboed__ ([email protected]) joined #gstreamer.
[07:29] bilboed_ ([email protected]) left irc: Read error: 110 (Connection timed out)
[07:33] <ds-work> woot
[07:34] Action: ds-work has complete DLL building working and tested
[07:36] Nick change: arana -> spyder482
[07:38] patrick77 ([email protected]) joined #gstreamer.
[07:45] patrick76 ([email protected]) left irc: Read error: 60 (Operation timed out)
[07:47] Nick change: mxpxpod -> mx|sleep
[07:48] walters ([email protected]) left irc: Remote closed the connection
[08:02] spyder482 ([email protected]) left irc: "Going back under my rock now..."
[08:03] ChrisHJW_log ([email protected]) left irc: Read error: 60 (Operation timed out)
[08:07] sub_pop ([email protected]) left irc: Remote closed the connection
[08:12] DBordello ([email protected]) joined #gstreamer.
[08:17] <DBordello> Whenever a mp3 is played through any gstreamer app it has popping.... nothing else on my system has this.  Any ideas
[08:21] pb_ (~pb@2002:3e03:42cc:1:20b:6aff:fe19:f290) joined #gstreamer.
[08:28] markey ([email protected]) joined #gstreamer.
[08:32] sub_pop ([email protected]) joined #gstreamer.
[08:46] pb_ (~pb@2002:3e03:42cc:1:20b:6aff:fe19:f290) left irc: "Client exiting"
[09:03] apoc_ ([email protected]) joined #gstreamer.
[09:03] markey ([email protected]) left irc: "leaving"
[09:19] apoc-zZz ([email protected]) left irc: Read error: 110 (Connection timed out)
[09:20] <DBordello> Whenever a mp3 is played through any gstreamer app it has popping.... nothing else on my system has this.  Any ideas
[09:30] sxpert_work ([email protected]) left irc: "Leaving"
[09:33] patrick77 ([email protected]) got netsplit.
[09:33] lilo ([email protected]) got netsplit.
[09:33] bilboed__ ([email protected]) got netsplit.
[09:33] Misirlou ([email protected]) got netsplit.
[09:33] taaz ([email protected]) got netsplit.
[09:33] wtay_ ([email protected]) got netsplit.
[09:33] dtm ([email protected]) got netsplit.
[09:33] apoc_ ([email protected]) got netsplit.
[09:33] sxpert ([email protected]) got netsplit.
[09:33] thomasvs ([email protected]) got netsplit.
[09:33] Rotund ([email protected]) got netsplit.
[09:33] Company ([email protected]) got netsplit.
[09:33] fbenites ([email protected]) got netsplit.
[09:33] ds ([email protected]) got netsplit.
[09:33] lilo_booter ([email protected]) got netsplit.
[09:33] md` ([email protected]) got netsplit.
[09:35] patrick77 ([email protected]) returned to #gstreamer.
[09:35] lilo ([email protected]) returned to #gstreamer.
[09:37] apoc_ ([email protected]) returned to #gstreamer.
[09:37] bilboed__ ([email protected]) returned to #gstreamer.
[09:37] Misirlou ([email protected]) returned to #gstreamer.
[09:37] thomasvs ([email protected]) returned to #gstreamer.
[09:37] Company ([email protected]) returned to #gstreamer.
[09:37] sxpert ([email protected]) returned to #gstreamer.
[09:37] fbenites ([email protected]) returned to #gstreamer.
[09:37] taaz ([email protected]) returned to #gstreamer.
[09:37] wtay_ ([email protected]) returned to #gstreamer.
[09:37] dtm ([email protected]) returned to #gstreamer.
[09:37] ds ([email protected]) returned to #gstreamer.
[09:37] lilo_booter ([email protected]) returned to #gstreamer.
[09:37] md` ([email protected]) returned to #gstreamer.
[09:37] Rotund ([email protected]) returned to #gstreamer.
[09:45] sxpert_work ([email protected]) joined #gstreamer.
[10:00] markey ([email protected]) joined #gstreamer.
[10:01] patrick77 ([email protected]) left irc: "Lost terminal"
[10:08] thomasvs ([email protected]) left irc: Read error: 110 (Connection timed out)
[10:20] dolphy ([email protected]) joined #gstreamer.
[10:23] jmmv ([email protected]) joined #gstreamer.
[10:23] <jmmv> hi
[10:25] LeRoutier ([email protected]) joined #gstreamer.
[10:25] <LeRoutier> good morning ppl
[10:26] <jmmv> hi LeRoutier
[10:32] thomasvs ([email protected]) joined #gstreamer.
[10:37] jdahlin ([email protected]) joined #gstreamer.
[10:38] Rotty ([email protected]) joined #gstreamer.
[10:40] <LeRoutier> hello spanish slave workers
[10:40] <LeRoutier> hi Rotty
[10:43] Nick change: harshyOut -> harshy
[10:52] <thomasvs> hi LeRoutier
[10:57] <LeRoutier> how much time gnome anon CVS is behind dev CVS ?
[10:57] <harshy> 24 hours iirc
[10:57] <LeRoutier> k, thx
[11:00] <bitshifter> LeRoutier: did you find an anoncvs mirror that works?
[11:04] sublett ([email protected]) joined #gstreamer.
[11:05] <LeRoutier> bitshifter, well, i can connect to them but they seems stalled to much longer than 24hours
[11:05] <bitshifter> yeah, mine are all 10 days old or so
[11:05] <LeRoutier> last totem change in anoncvs for example is 28/03 (in changelog)
[11:06] <LeRoutier> seems this service is not back yet
[11:06] <LeRoutier> not syncing anymore
[11:08] <Rotty> LeRoutier: hi
[11:08] Nick change: markey -> markey|afk
[11:15] thaytan ([email protected]) joined #gstreamer.
[11:21] teuf ([email protected]) joined #gstreamer.
[11:24] <teuf> thomasvs: is http://bugzilla.gnome.org/show_bug.cgi?id=139139 the same issue as the nautilus-media one you are trying to solve when there is no registry ?
[11:36] <thomasvs> teuf: not necessarily.
[11:36] <thomasvs> teuf: but that guy should really elaborate on how he installs/upgrades gst, because I'm pretty sure he does it from source.
[11:37] <teuf> hmm, right, on a (non broken) distro, this would be handled automatically
[11:37] <teuf> why isn't gst-register ran on make install btw ?
[11:40] <LeRoutier> it's better as a post-install step. and all packaging system i am aware of   have some sort of  post-install scripting available
[11:40] sxpert ([email protected]) left irc: Read error: 110 (Connection timed out)
[11:41] <thomasvs> teuf: same reason ldconfig isn't.
[11:41] <teuf> thomasvs: and why is it ? :)
[11:41] <thomasvs> teuf: because it's up to the admin to do it :)
[11:41] <LeRoutier> it modifies system files, make install should only install new ones/overwrite existing ones
[11:41] <teuf> LeRoutier: except that if you are installing from source, that means you don't care about packaging systems
[11:42] <thomasvs> teuf: packaging systems also install from source to package
[11:42] <teuf> thomasvs: yeah I know, but I don't care about packaging systems :)
[11:42] <LeRoutier> teuf, depends, under gentoo, i've got this in my ebuild : pkg_postinst() {gst-register-${PV_MAJ_MIN} }
[11:42] <teuf> gst-register only creates an xml file ?
[11:44] <teuf> I'd tend to handle the execution of gst-register a bit like the installation of gconf schemas
[11:44] <teuf> ie do it at make install unless explicitly disabled
[11:47] thaytan ([email protected]) left irc: "See y'all"
[11:48] Shoragan ([email protected]) joined #gstreamer.
[11:52] sublett ([email protected]) left irc: "I quit, therefore I was"
[12:01] <thomasvs> teuf: it really is more comparable to ldconfig.  it recreates a cache file, not installs a file that wasn't there before.
[12:01] <thomasvs> teuf: it's also similar to apt-get update for example
[12:06] <jmmv> teuf: if you don't care about packaging systems, then you should care manually about what needs to be done at postinstallation...
[12:08] <teuf> jmmv: what I meant was that I wouldn't consider as valid  arguments which mention packaging systems as a reason for not running gst-register
[12:08] <teuf> that's all :)
[12:09] <jmmv> heh
[12:19] bilboed__ ([email protected]) left irc: "Client exiting"
[12:26] Nick change: LeRoutier -> LeRaway
[12:27] Uraeus ([email protected]) joined #gstreamer.
[12:31] sublett ([email protected]) joined #gstreamer.
[12:32] <Uraeus> g'day
[12:34] <thomasvs> jmmv: could you subscribe to the mailing list please ?
[12:34] <thomasvs> Uraeus: hey
[12:34] <thomasvs> Uraeus: when do you leave on your trip
[12:34] <Uraeus> thomasvs: 1st of July
[12:37] jdahlin ([email protected]) left irc: "Leaving"
[12:38] <Uraeus> thomasvs: been thinking that I maybe should come down to Barcelona for a weekend soon, think I would like to discuss our latests mails in person with you guys
[12:40] jdahlin ([email protected]) joined #gstreamer.
[12:40] <jmmv> barcelona? are some developers from here?
[12:40] <Uraeus> jmmv: thomasvs, dolphy, jdahlin all live there
[12:41] <jmmv> oh
[12:42] <thomasvs> Uraeus: yeah, would help I think - but we have some preparation to do first anyway
[12:43] wheels ([email protected]) left irc: "using sirc version 2.211+KSIRC/1.3.9"
[12:50] Nick change: markey|afk -> markey
[13:01] <Uraeus> dolphy: /usr/bin/ld: cannot find -lgstinterfaces-0.8 <- getting this with CVS totem (and cvs gstreamer)
[13:03] <jdahlin> Uraeus: remove the directory and check out again
[13:03] <Uraeus> ah ok
[13:04] <jdahlin> Uraeus: where did you build gstreamer? /opt/gstreamer?
[13:04] <jdahlin> or hmm
[13:04] <Uraeus> jdahlin: no, I was making an rpm, so it build in /var/tmp
[13:05] <dolphy> Uraeus: i fixed your logo bug
[13:05] <dolphy> Uraeus: some changes in gtk2.4 triggered that issue
[13:06] <Uraeus> dolphy: yeah, got the bugzilla mail, thanks :)
[13:13] foser ([email protected]) joined #gstreamer.
[13:14] Nick change: mx|sleep -> mxpxpod
[13:24] smoke ([email protected]) joined #gstreamer.
[13:27] Action: sxpert_work is away: notaire :D
[13:32] <Uraeus> jdahlin: hmm, no getting a fresh checkout did not solve the issue
[13:36] <jdahlin> Uraeus: weird.
[13:41] <thomasvs> teuf: what's the right way of creating a playlist containing all files in a given path ?
[13:41] <teuf> thomasvs: with rhythmbox ?
[13:42] smoke ([email protected]) got netsplit.
[13:43] <thomasvs> teuf: yeah
[13:43] <thomasvs> teuf: I have three dirs, songs, albums, and download
[13:43] <thomasvs> I want to separate between them
[13:43] smoke ([email protected]) returned to #gstreamer.
[13:44] LeRaway ([email protected]) left irc: Read error: 60 (Operation timed out)
[13:44] <teuf> hmm, it's probably not doable from the UI. You could have a look at the xml format for playlists, but that's kind of sucky :-/
[13:45] <teuf> or create a playlist from xmms and import it :)
[13:46] <thomasvs> I made an .m3u file, but rhythmbox didn't import it.
[13:47] <thomasvs> hm
[13:47] <thomasvs> how does it in general handle volumes that can be mounted/unmounted ?
[13:47] <teuf> you imported it from the ui ?
[13:47] <thomasvs> say, I have an nfs share at home, but not at work ?
[13:47] <teuf> thomasvs: it doesn't handle it at all currently
[13:47] <teuf> someone sent a proposal on rhythmbox-devel to try to improve that
[13:47] <thomasvs> teuf: I chose playlist>from file
[13:47] <teuf> ah, I guess it should work then :-/
[13:47] <teuf> I don't use playlists at all
[13:48] <thomasvs> *gasp*
[13:48] <teuf> thomasvs: http://mail.gnome.org/archives/rhythmbox-devel/2004-March/msg00080.html 
[13:51] <thomasvs> gasp
[13:51] <thomasvs> colin saying nfs is not important
[13:51] Action: thomasvs thwacks walters
[13:51] <teuf> hehe
[13:52] <teuf> hmm, actually rhythmbox could try to detect when all the files on a given mount point have disappeared, and in such cases, only hide them instead of removing them from the library
[13:53] <teuf> this would probably solve 99% of the complaints about rb and removable medias handling
[13:53] <thomasvs> yeah, it's a good first start
[13:53] <thomasvs> but then you need to parse fstab
[13:53] <teuf> gnome-vfs has api to handle that I think
[13:53] <teuf> (gnome-vfs 2.6)
[13:54] dholmes ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[13:55] <bitshifter> couldn't you look at the filesystem type and make an 'educated guess' about the medium being removable or not (e.g. if ISO9660, NFS, etc.)
[13:56] <teuf> bitshifter: I'd consider NFS as non removable though and thomasvs would whine then ;)
[13:56] <thomasvs> all I want is a player that can recognize when I'm home and sees I have 15000 songs extra to play.
[13:57] <thomasvs> hm, let's make it slightly more problematic
[13:57] <teuf> thomasvs: rhythmbox handles 15000 song libraries well enough ?
[13:57] <thomasvs> some songs are the same on the nfs share as on my hd
[13:57] LeRaway ([email protected]) joined #gstreamer.
[13:57] <thomasvs> teuf: well, I'll try as soon as it doesn't break my db because it's unmountable :)
[13:57] <thomasvs> teuf: if you want me to give it a shot, I can
[13:58] <teuf> hmm, adding this mount point thing to rhythmdb would be interesting, but I fear I'll lack time :(-
[13:58] <teuf> as each time I leave for holidays, I'm thinking that I really should have a laptop :)
[13:59] Nick change: Uraeus -> Ura_out
[14:09] md` ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[14:11] <LeRaway> bbl
[14:11] LeRaway ([email protected]) left irc: "Leaving"
[14:11] dholmes ([email protected]) joined #gstreamer.
[14:24] sxpert ([email protected]) joined #gstreamer.
[14:28] <jdahlin> No accelerated IMDCT transform found
[14:29] <jdahlin> where is that message coming from?
[14:29] jimmy_dean ([email protected]) left irc: "Carrier Signal Lost"
[14:39] teuf ([email protected]) left irc: "Client exiting"
[14:48] Ura_out ([email protected]) left irc: Remote closed the connection
[15:02] markey ([email protected]) left irc: "bbl"
[15:33] md` ([email protected]) joined #gstreamer.
[15:34] md` ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[15:40] md` ([email protected]) joined #gstreamer.
[15:59] kmaraas ([email protected]) joined #gstreamer.
[16:04] sjoerd_ ([email protected]) left irc: Read error: 113 (No route to host)
[16:04] sjoerd ([email protected]) left irc: Read error: 113 (No route to host)
[16:06] typo ([email protected]) joined #gstreamer.
[16:06] markey ([email protected]) joined #gstreamer.
[16:06] mxpxpod ([email protected]) left irc: Read error: 113 (No route to host)
[16:07] <typo> Hi, I'm hearing cracks when using osssink in a simple "filesrc ! mad ! osssink" pipeline, playing with osssink's fragment size seams to help, is this a known bug?
[16:07] <typo> I'm running the debian unstable packages
[16:09] sjoerd ([email protected]) joined #gstreamer.
[16:12] <Company> typo: Debian unstable packages are this >< short before being updated to the recent 0.8 version
[16:12] <typo> Company: cool, is this fixed?
[16:12] <Company> typo: there's not many people caring about 0.6 anymore...
[16:13] <typo> couldn't find anything in bugzilla
[16:13] <typo> Company: I know
[16:13] <Company> typo: no idea if it's fixed, but i'd suggest hoping and coming back if not
[16:13] <typo> just trying to get rhythmbox to work
[16:13] <Company> but if fragmentsize helps, you can set it in your gconf key
[16:13] <typo> Company: tried it, didn't work for some reason
[16:14] <Company> i belong to the people not concerned with 0.6 anymore though ;)
[16:15] <typo> heh
[16:15] <typo> is alsasink working in 0.8?
[16:16] <Company> yes, i'm using it right now
[16:16] <typo> cool
[16:17] <typo> got to go
[16:17] <typo> thanks
[16:17] typo ([email protected]) left irc: "Client exiting"
[16:27] markey ([email protected]) left irc: "leaving"
[16:42] walters ([email protected]) joined #gstreamer.
[16:43] jmmv ([email protected]) left irc: "Leaving"
[16:43] kmaraas ([email protected]) left irc: Client Quit
[17:11] Toastie ([email protected]) joined #gstreamer.
[17:12] Toastie ([email protected]) left irc: Client Quit
[17:12] foser ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[17:14] foser ([email protected]) joined #gstreamer.
[17:20] trow ([email protected]) joined #gstreamer.
[17:27] yippi ([email protected]) joined #gstreamer.
[17:49] markey ([email protected]) joined #gstreamer.
[18:00] ChrisHJW ([email protected]) joined #gstreamer.
[18:15] sub_pop ([email protected]) left irc: "Client exiting"
[18:17] spyder482 ([email protected]) joined #gstreamer.
[18:23] mxpxpod ([email protected]) joined #gstreamer.
[18:27] ploum ([email protected]) joined #gstreamer.
[18:31] mxpxpod ([email protected]) left irc: "To quit or not to quit.. wait... was that a question?"
[18:37] ploum ([email protected]) left irc: "Leaving"
[18:43] sub_pop ([email protected]) joined #gstreamer.
[18:50] Rotty ([email protected]) left irc: Remote closed the connection
[18:54] mxpxpod ([email protected]) joined #gstreamer.
[18:58] LeRoutier ([email protected]) joined #gstreamer.
[18:58] <LeRoutier> re
[18:59] <LeRoutier> the module page on df.o/gstreamer  is wrong about gst-python version 
[18:59] Action: Company is extremely unimpressed by longhorn screenshots
[18:59] <jdahlin> LeRoutier: url?
[18:59] <LeRoutier> (i mean this one : http://gstreamer.freedesktop.org/modules/ : 0.1.0 instead of 0.91)
[19:00] <LeRoutier> 0.7.91, sorry
[19:00] <thomasvs> LeRoutier: yeah, almost done updating
[19:00] Nick change: markey -> markey|RUN
[19:00] <jdahlin> thomasvs: sorry, I already added
[19:01] <LeRoutier> ah, k, i'm in the middle of a site update
[19:03] <jdahlin> no, I just broke it :-)
[19:03] <thomasvs> done
[19:05] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[19:05] <LeRoutier> got a broken link in gst-recorder page : http://gstreamer.freedesktop.org/modules/gst-recorder.html
[19:05] <LeRoutier> it propose to go to download page but as there is only CVS for it ...
[19:07] <LeRoutier> also, tar.bz2 link for gst-python on homepage is broken too
[19:07] <LeRoutier> only the tar.gz is ok
[19:09] <thomasvs> jdahlin: make a bz2 too
[19:09] <thomasvs> LeRoutier: ok, gst-recorder link fixed, but empty :)
[19:10] <jdahlin> thomasvs: can't you, since you're going to upload it...
[19:11] <LeRoutier> thomasvs, that's ok for me as long as there is no HTTP error
[19:12] <LeRoutier> no one to try gurlchecker on the site (or any other tool) to find other mistakes ?
[19:13] jimmy_dean ([email protected]) joined #gstreamer.
[19:15] <LeRoutier> http://gstreamer.freedesktop.org/features/ : gst-editor link is dead
[19:15] <LeRoutier> same for gst-player link
[19:16] <LeRoutier> and same for bindings
[19:26] jdahlin ([email protected]) left irc: "Leaving"
[19:27] <thomasvs> LeRoutier: ok, all three fixed
[19:28] <LeRoutier> looking for others
[19:33] <LeRoutier> http://gstreamer.freedesktop.org/modules/  : gst-recorder "cvs only" link => 404
[19:45] thomasvs ([email protected]) left irc: Read error: 113 (No route to host)
[19:58] teuf ([email protected]) joined #gstreamer.
[20:03] <Company> booooring
[20:03] <Company> someone speed up valgrind please ;)
[20:03] thomasvs ([email protected]) joined #gstreamer.
[20:05] sublett ([email protected]) left irc: "I quit, therefore I was"
[20:05] Rounin ([email protected]) joined #gstreamer.
[20:05] <Rounin> Hi! I need some more help I'm afraid
[20:05] <Rounin> gst_element_query(myPipeline,GST_QUERY_POSITION,GST_FORMAT_TIME,myStreamPosition);
[20:05] <Rounin> What am I doing wrong. Using & doesn't work and not using & doesn't work either
[20:06] <Rounin> I've thought deeply about this, as you can see...
[20:07] <Company> you must use variables
[20:08] <Company> and &
[20:08] <Rounin> Hm, I did use &
[20:08] <Rounin> Let me try that again
[20:09] <Rounin> Yeah, now myStremPosition always seems to become 0, but otherwise it's OK
[20:09] <Rounin> No error messages or anything
[20:10] <Rounin> Actualy, I'll just printf that value to see that it's not always 0
[20:10] <Rounin> Oh, it is
[20:13] jdahlin ([email protected]) joined #gstreamer.
[20:13] <Company> check the return value
[20:13] <Company> queries aren't guaranteed to succeed
[20:14] yippi ([email protected]) left irc: "Client exiting"
[20:14] <Rounin> True
[20:14] <Rounin> No, I mean, I agree
[20:14] <Rounin> Not that it's true
[20:15] <Rounin> (gst_element_query): assertion `GST_IS_ELEMENT (element)' failed
[20:15] <Rounin> This appears to be the problem
[20:15] <Rounin> Perhaps I should have cast it?
[20:18] <Rounin> Oh wait, and I need to have a GstFormat pointer, that is simultaneously an enum value? This issue could definitely need some clarification...
[20:21] dolphy ([email protected]) joined #gstreamer.
[20:24] alley_cat ([email protected]) left irc: Read error: 60 (Operation timed out)
[20:24] Nick change: markey|RUN -> markey
[20:33] The_Company ([email protected]) joined #gstreamer.
[20:36] <jdahlin> are there debian packages for 0.8 yet?
[20:36] <jdahlin> (core, plugins, ffmpeg)
[20:37] <The_Company> no real ones
[20:37] <teuf> jdahlin: I think there are some available on their sourceforge like thing
[20:38] Company ([email protected]) left irc: Nick collision from services.
[20:41] <jdahlin> teuf: ok
[20:41] Nick change: The_Company -> Company
[20:49] thaytan ([email protected]) joined #gstreamer.
[20:49] <thaytan> hallo!
[20:49] <thaytan> who's awake?
[20:50] BBB ([email protected]) joined #gstreamer.
[20:50] <thaytan> hi Ronald
[20:50] <BBB> ola jan
[20:51] <LeRoutier> hello thaytan, ronald
[20:51] Action: BBB wonders what time it is in .au
[20:51] <thaytan> I found someone's factory settings wireless router in London
[20:51] <thaytan> BBB: I'm in London! :)
[20:51] <BBB> ola stef
[20:51] <BBB> oh!
[20:51] <BBB> that makes things clear ;)
[20:51] <Company> thaytan: how's europe?
[20:52] <thaytan> Company: good fun so far. Visiting Windsor Palace and friends in the last 2 days
[20:52] <thaytan> off to Paris in the morning
[20:52] <thaytan> day after, rather
[20:52] <Company> thaytan: still on australian time? or managed to adapt?
[20:52] <thaytan> we didn't have any trouble, actually
[20:53] <thaytan> oops, getting kicked out
[20:53] yippi ([email protected]) joined #gstreamer.
[20:53] <thaytan> cya later! :)
[20:53] thaytan ([email protected]) left irc: Client Quit
[20:53] <ds-work> ~
[20:54] <LeRoutier> BBB: had time to work a little on my not playing avis ?
[20:55] <Company> ds-work: decided to not hack on element iterations - it's not worth it because of compatibility
[20:59] ow3n ([email protected]) joined #gstreamer.
[20:59] sublett ([email protected]) joined #gstreamer.
[20:59] <ow3n> hi
[20:59] <LeRoutier> hi owen
[21:01] <Company> hm, how do i do this...
[21:01] <ds-work> Company: probably
[21:02] <Company> i want to know whenever a GstMad object is reffed or unreffed
[21:02] <Company> there's no way to get this other than hacking glib, right?
[21:03] <ds-work> it should be gst_object_ref() and unref(), which spits out a debug message
[21:03] <Company> it should be, but i'd bet it's not
[21:03] <jdahlin> easy to fix?
[21:05] <Company> jdahlin: not really - you can't just do a sed because there might be GObjects
[21:07] <jdahlin> Company: can't you do an evil define, to make g_object_unref do something else
[21:11] <Company> jdahlin: that's a great idea
[21:12] Action: jdahlin sighs
[21:29] <Company> strcmp is the most stupid funtion i've ever seen
[21:30] <Company> i want strequal
[21:30] <Company> that returns true if strings are equal
[21:30] <teuf> Company: libxml has it :)
[21:30] <jdahlin> GStrings? :)
[21:32] <bitshifter> Company: g_str_equal(s1,s2) 
[21:32] <Company> jdahlin: G_TYPE_STRING's
[21:33] <Company> g_str_equal exists?
[21:33] <bitshifter> sure
[21:33] <Company> though it's intended for hashtables, but i guess i just don't care ;)
[21:36] <ow3n> Does anyone have time to help me with something puzzling me in the G_BEING_DECLS of GstCaps?
[21:38] <teuf> ow3n: ask your question and you'll see if someone answers or not :)
[21:38] <ow3n> teuf: :)
[21:39] <Company> teuf: i think i got the huge memleak
[21:39] <ow3n> Well, in gstcaps.c, in gst_caps_get_type, gst_caps_type is set using g_boxed_type_register_static i.e. it's a boxed type...
[21:39] <teuf> Company: excellent! :)
[21:40] <teuf> fab! as would say the british I think
[21:40] <bitshifter> Company: cool! what was it?
[21:40] <ow3n> Yet, in gstcaps.h there's a #define GST_CAPS(object)
[21:40] <Company> teuf: i'm not sure, but it looks like it
[21:41] <ow3n> Surely the two are mutually exclusive.
[21:41] <teuf> Company: even if it's a small leak I'll be happy :)
[21:41] <ow3n> I only ask because I'm trying to get the Mono bindings working again and the gapi parser is getting confused.
[21:45] <ow3n> Yeah, OK. I'll assume the GST_CAPS was wrong, ditch it and submit it as a patch on the mailing list when I'm done so it can be discussed.
[21:51] <Company> hm, the leak was huge, but it wasn't as big as i had hoped
[21:51] <teuf> Company: is it in cvs ?
[21:52] <Company> teuf: yeah
[21:53] <Company> teuf: core and plugins both have fixes
[21:53] <teuf> oki
[21:53] <ow3n> ls
[21:53] <ow3n> oops.
[21:56] <jdahlin> WARNING **: xvimagesink was unable to obtain the X11 context.
[21:56] <jdahlin> What does that mean?
[21:57] <Company> that means someone needs to write a better error message
[21:57] <jdahlin> heh
[21:57] <Company> and it probably also means that it should be a GST_ERROR
[21:58] <Company> teuf: i think there must be a huge leak inside rb
[21:58] <Company> teuf: the example program from the bug report isn't growing very much
[21:59] <teuf> ok
[22:00] <Company> teuf: updating my library inside rb grew from 70 to 210 MB
[22:01] <Company> teuf: the test tool is still at 25 MB and running
[22:01] <teuf> I'm currently compiling gstreamer and gst-plugins, I'll tell you waht I get when it's done :)
[22:04] <bitshifter> aclocal: configure.ac: 28: macro `AM_PROG_LIBTOOL' not found in library
[22:05] <bitshifter> anyone know why I might be getting that all of a sudden? (debian sid)
[22:06] <bitshifter> (the stuff in the FAQ doesn't apply here, I should add)
[22:08] ow3n ([email protected]) left irc: "Leaving"
[22:10] <thomasvs> bitshifter: because you compiled one of the autotools by hand, but not all, and did not set ACLOCAL_FLAGS
[22:11] <bitshifter> thomasvs: yeah, that's what the FAQ says :)  But I haven't - it's all the standard packages
[22:13] <Rounin> Wow, lots of people here... Could anyone tell me how to get my current position of the stream? The only thing I know is that it's not the way I'm doing it
[22:13] <Rounin> I think I got as far as gst_element_query(&myPipeline,GST_QUERY_POSITION,&myStreamPositionFormat,&myStreamPosition);
[22:13] <Rounin> And then I just assigned it a random number every iteration
[22:14] <Rounin> Which is pretty cool of course
[22:20] J_P_ ([email protected]) joined #gstreamer.
[22:20] <J_P_> hi all
[22:20] <J_P_> jdahlin !!
[22:20] <jdahlin> hello J_P_
[22:29] wheels ([email protected]) joined #gstreamer.
[22:32] <Company> teuf: can confirm this now: refreshing the library in rb ate 140 MB while running my whole lib through scimport only took 50 MB
[22:32] <thomasvs> bitshifter: do both "which aclocal" and "locate libtool.m4" for me ?
[22:34] <Rounin> Do any of you not know, but have a fairly good idea?
[22:35] <Rounin> That could be a problem I guess.
[22:36] <Rounin> Wow, Misirlou... What are you doing here? :D
[22:36] <Misirlou> Gah, how did you find me!
[22:36] <bitshifter> thomasvs: /usr/bin/aclocal +  /usr/share/libtool/m4/libtool.m4  - got it to work by adding the latter to ACLOCAL_FLAGS
[22:36] <Rounin> What do you mean find you... You're like way up there on the userlist
[22:36] <Rounin> Someone should just go ahead and merge freenode and gimpnet already
[22:36] <Rounin> Brb
[22:36] <Misirlou> You must sort using the C locale. :P
[22:37] <Rounin> There's only one locale, Misirlou
[22:37] <Rounin> en_US.UTF-8
[22:37] <ds-work> odd, xchat is ignoring LC_COLLATE=C
[22:38] <Misirlou> Rounin: Heh, um, what client are you using?
[22:38] <Rounin> I think it was called Misirlou is my bitch, I don't remember
[22:38] <Rounin> The guy who sold it to me wore a weird hat
[22:39] <Rounin> X-Chat 2.0.8
[22:39] <Misirlou> Very funny. I already got the CTCP VERSION reply. :P
[22:39] <Rounin> Try XDCC list if it's still there
[22:40] <Rounin> So anyway
[22:41] <Rounin> What are up up to?
[22:42] <Misirlou> Not really up up to anything.
[22:42] Nick change: J_P_ -> J_P
[22:44] <Rounin> K..
[22:44] <Rounin> Not even yelling at ASCII zealots? =P
[22:48] <bitshifter> Rounin: &myPipeline looks wrong - don't you get assertion warnings. Is it GstElement *mypipeline; ?
[22:48] apoc_ ([email protected]) left irc: "Leaving"
[22:52] walters ([email protected]) left irc: Client Quit
[22:53] apoc ([email protected]) joined #gstreamer.
[22:56] alley_cat ([email protected]) joined #gstreamer.
[23:02] <Rounin> bitshifter: Yeah, actually I managed to fix it... However I haven't got a clue as to how to interpret the return value
[23:02] walters ([email protected]) joined #gstreamer.
[23:02] <Rounin> bitshifter: I'm getting a guint64 value, and I'm trying to use sprintf on it... No luck so far
[23:02] <Rounin> Oh hang on
[23:02] <Rounin> I'd defined it as gint64
[23:05] <Rounin> Working nicely
[23:05] <Rounin> I founnd some example code on the web... I guess the API reference just needs some example code for us idiots
[23:11] <LeRoutier> bbl
[23:11] LeRoutier ([email protected]) left irc: "Leaving"
[23:15] apoc ([email protected]) left irc: "Leaving"
[23:20] pb_ (~pb@2002:5160:4550:1:240:95ff:fe30:aa84) joined #gstreamer.
[23:26] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[23:29] Zeenix ([email protected]) joined #gstreamer.
[23:30] <Zeenix> hi
[23:30] <Zeenix> thomasvs: replying to your mail ATM..
[23:37] Shoragan ([email protected]) left irc: "Leaving"
[23:45] teuf ([email protected]) left irc: "Client exiting"
[23:46] <taaz> hmm.  LD_DEBUG=help  interesting.
[23:55] yippi ([email protected]) left irc: "Client exiting"
[23:57] markey ([email protected]) left irc: "leaving"
[23:59] <jdahlin> taaz: /lib/libc.so.6 is interesting too.
[00:00] --- Wed Apr  7 2004
[00:01] Lovechild ([email protected]) joined #gstreamer.
[00:04] <taaz> ?
[00:04] <jdahlin> taaz: *run* it
[00:04] <taaz> i had never seen LD_DEBUG before.  seems like it should be documented in ld.so
[00:05] <taaz> it's not executable
[00:05] <jdahlin> it is
[00:05] <jdahlin> $ /lib/libc.so.6
[00:05] <jdahlin> GNU C Library stable release version 2.3.2, by Roland McGrath et al.
[00:05] <jdahlin> [...]
[00:05] <taaz> $ /lib/libc.so.6
[00:05] <taaz> bash: /lib/libc.so.6: Permission denied
[00:05] <taaz> not on my box ;)
[00:05] <jdahlin> debian?
[00:05] mxpxpod ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[00:06] <jdahlin> chmod +x it :)
[00:07] <taaz> too much effort
[00:07] <jdahlin> it's just a big version splash anyway
[00:07] <jdahlin> but it's nice that libraries can actually be executable
[00:07] <taaz> that stuff is all voodoo
[00:08] <jdahlin> yap
[00:10] mxpxpod ([email protected]) joined #gstreamer.
[00:12] <Company> libgstreamer should be executable, too
[00:13] <jdahlin> I'm not so sure about that
[00:13] <Company> i want a version splash screen
[00:14] <Misirlou> jdahlin: What distro are you running?
[00:14] <jdahlin> Misirlou: FC1
[00:14] <jdahlin> Company: I think only libc can have that behavior
[00:14] <jdahlin> but I don't know the internals of the linker so I cannot tell why
[00:19] BBB ([email protected]) left #gstreamer.
[00:36] CompIBook ([email protected]) joined #gstreamer.
[00:40] foser ([email protected]) left irc: "[ I want to believe ]"
[00:47] spyder482 ([email protected]) left irc: "Leaving"
[00:53] Lovechild ([email protected]) left #gstreamer ("Leaving").
[00:53] sub_pop ([email protected]) left irc: "Client exiting"
[00:55] sub_pop ([email protected]) joined #gstreamer.
[00:57] trow ([email protected]) left irc: "Leaving"
[01:07] sublett ([email protected]) left irc: "I quit, therefore I was"
[01:07] <Company> ds-work: ping?
[01:08] <Company> ds-work: there's a serious leak somewhere with pad templates
[01:09] <Company> serious as  in leaking ~1 template per instantiated element
[01:09] <Company> i had 130000 or so missing at one point
[01:13] <Company> s/missing/live/
[01:13] J_P ([email protected]) left irc: Remote closed the connection
[01:21] iain ([email protected]) joined #gstreamer.
[01:28] <Company> ds-work: found it - GstPad doesn't sink templates
[01:28] <Company> s/doesn't/didn't/
[01:29] <Rounin> Anyone wanna help me with yet another GTK problem? I'm using a scrolled window, and when I turn off the shaddow, it's still shadowed. So I'm trying to get to the viewport that's between the scrolled window and the widget inside
[01:29] <Rounin> And get_parent doesn't work
[01:30] Action: Company has no clue about gtk
[01:31] <Company> that's not entirely true, but everytime i need to know something i read gtk source code, fix my problem and then forget what i just did :o
[01:31] <Rounin> Guess I
[01:31] <Rounin> I'd better do the same
[01:33] <jdahlin> Rounin: you mean the scrollbars?
[01:34] <Rounin> No, I'm not using scrollbars, but hang on
[01:34] <Rounin> I think I just made a mistake earlier
[01:36] <iain> gstmpeg2dec.c: In function `gst_mpeg2dec_negotiate_format':
[01:36] <iain> gstmpeg2dec.c:353: syntax error before '*' token
[01:37] pb_ (~pb@2002:5160:4550:1:240:95ff:fe30:aa84) left irc: "Client exiting"
[01:37] <Company> iain: had the same, wasn't sure if it's just me
[01:37] <Company> iain: just do s/mpeg_structure/structure/
[01:37] <Company> (or something similar)
[01:37] <ds-work> Company: hehehe, oops
[01:39] <Company> ds-work: do you get iain's issue, too?
[01:42] CompIBook ([email protected]) left irc: "Client exiting"
[01:44] <iain> Company: yey, that fixed it, thanks
[01:52] <walters> hmm.
[01:53] LeRoutier ([email protected]) joined #gstreamer.
[01:53] <LeRoutier> re
[01:53] <LeRoutier> i wasn't aware it was "mem-leak death-day" :)
[01:55] <Company> it isn't
[01:55] <Company> there's only one person doing that
[01:55] <LeRoutier> yep, and it seems it's you
[01:57] <Company> yeah
[01:58] <Company> i'm just chatting the whole day basically
[01:58] <Company> valgrind is sooooo slow
[01:59] <LeRoutier> well, perhaps some x86 asm magicians could speed it up
[02:00] <Company> yeah, but until then I can chat with you
[02:00] <Company> and read about how to add valgrind support to glib
[02:00] iain ([email protected]) left irc: "leaving"
[02:03] walters ([email protected]) left irc: "out"
[02:04] jimmy_dean ([email protected]) left irc: "Carrier Signal Lost"
[02:04] <Misirlou> Company: Do you compile with CFLAGS="-ggdb3" and --enable-debug?
[02:08] <Company> Misirlou: why should I use -ggdb3 instead of -g ?
[02:08] <Misirlou> Company: I think it's more verbose.
[02:08] <Misirlou> Company: I *still* need to get off of my ass and ask the GCC mailing list about that.
[02:09] <Misirlou> "Dear Compiler Dudes: What CFLAGS can I use to get the most verbose debugging symbols possible?"
[02:09] <LeRoutier> speaking of gdb, 0.6.1 just hit gentoo. i wonder what's new but the gcc 3.5 support
[02:09] jimmy_dean ([email protected]) joined #gstreamer.
[02:12] <LeRoutier> ok, mostly better amd64 and c++ support in gdb 6.1
[02:13] <Company> according to the manual, there is no ggdb3
[02:14] <Company> only ggdb
[02:14] <Company> and on linux g and ggdb are probably equal
[02:14] <LeRoutier> oh, gnome anon cvs is back on track
[02:15] <Misirlou> Company: There is ggdb3, but is never shown like so. Go down a little bit.
[02:15] <Misirlou> Company: Down to the part where it talks about levels.
[02:16] <Company> ah there
[02:16] <LeRoutier> bitshifter, are you around ?
[02:17] <bitshifter> LeRoutier: yep
[02:17] <LeRoutier> bitshifter, where you the other one (i was too) to complain about gnome anon cvs beeing stalled ?
[02:17] <bitshifter> yeah
[02:18] <LeRoutier> seems the problem is away
[02:19] <LeRoutier> (was able to update marlin and saw changes from yesterday night)
[02:19] <LeRoutier> same for totem
[02:19] <bitshifter> hmm
[02:20] <LeRoutier> (perhaps there are several anon cvs servers and not all are fixed)
[02:20] <bitshifter> yeah, I'll just try again tomorrow
[02:21] <LeRoutier> anoncvs.gnome.org.      3203    IN      A       138.100.8.6
[02:21] <LeRoutier> anoncvs.gnome.org.      3203    IN      A       130.239.18.151
[02:21] <LeRoutier> try with each one to see if it helps
[02:23] <bitshifter> LeRoutier: the second one worked - thanks! :)
[02:24] <Company> valgrind should be able to analyze core files
[02:24] <Company> _that_ would rock
[02:28] Zeenix ([email protected]) left irc: "The whole problem with the world is that fools and fanatics are always so certain of themselves, but wiser people so full of 
[02:30] <LeRoutier> Company, using addrcheck or memcheck ?
[02:31] <Company> LeRoutier: good question
[02:31] <LeRoutier> addrcheck is faster but doesn't see everything
[02:31] <LeRoutier> http://valgrind.kde.org/tools.html
[02:32] <LeRoutier> memcheck seems to be the default, better but slower
[02:32] <Company> LeRoutier: i'll see
[02:36] <LeRoutier> there's a "corecheck" in valgrind distrib but i don't know if it does what you want (and it does not seem finished)
[02:40] <LeRoutier> well, i need sleep. good luck and good night
[02:40] LeRoutier ([email protected]) left irc: "Leaving"
[02:46] <Company> weee
[02:47] <Company> i think i got a lot of leaks
[02:50] <bitshifter> Company: gst-plugins/gst-libs/gst/gconf/test-gconf.c  is missing a  g_type_init()  at the beginning of main() I believe
[02:52] <Company> bitshifter: i'll put a gst_init there
[02:55] <Company> done
[02:56] <bitshifter> :)
[02:59] <Company> it's kinda evil that just loading the registry takes 4MB RAM


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click