[gst-devel] Daily IRC logs

[wim.taymans at chello.be]

[06:32] chillywilly (baumannd at d19.as7.nwbl0.wi.voyager.net) joined #gstreamer.
[06:32] <chillywilly> ajmitch: you suck man
[06:32] <ajmitch> chillywilly: stop annoying me
[06:34] <chillywilly> whatever, sheep boy
[06:34] chillywilly (baumannd at d19.as7.nwbl0.wi.voyager.net) left #gstreamer.
[06:38] chillywilly (baumannd at d19.as7.nwbl0.wi.voyager.net) joined #gstreamer.
[06:39] <chillywilly> unltimate eh?
[06:55] Nick change: taaz -> taazzzz
[08:30] ajmitch (me at p52-max1.bal.ihug.co.nz) left irc: http://www.freedevelopers.net
[09:18] chillywilly (baumannd at d19.as7.nwbl0.wi.voyager.net) left irc: [x]chat
[10:40] Wodi (wodin30 at 202.67.83.169) joined #gstreamer.
[10:40] <Wodi> hey yall
[10:54] Wodi (wodin30 at 202.67.83.169) left irc: 
[10:59] omega_ (omega at omegacs.net) left irc: [x]chat
[11:18] thomas (thomas at urgent.rug.ac.be) joined #gstreamer.
[11:24] Action: thomas is away - Automatically set away. - messages will be saved.
[11:27] thomas (thomas at urgent.rug.ac.be) left irc: I'm outta here!
[12:16] thomas (thomas at urgent.rug.ac.be) joined #gstreamer.
[12:17] Nick change: wtay-sleeping -> wtay
[12:17] <wtay> yo
[12:21] Action: thomas is away - Automatically set away. - messages will be saved.
[12:22] <thomas> waky waky
[12:22] <thomas> I just cleaned the plugin some more and wrote an example program
[12:22] <wtay> aha
[12:22] <thomas> showing the envelope registration
[12:22] <thomas> and it seems to work
[12:22] <thomas> say, the helloworld2 example doesn't do anything for me
[12:22] <thomas> it should play audio, right ?
[12:22] <wtay> hmm
[12:22] <wtay> sec..
[12:22] <thomas> thanks for the esdsink btw
[12:22] <thomas> now I don't have to turn off xmms
[12:23] <wtay> hmm helloworld2 is broken...
[12:27] <thomas> so I was wondering about a mixing plugin...
[12:27] <thomas> but I'm not sure if it should be a plugin at all.
[12:27] <wtay> oh?
[12:27] <thomas> where do I draw the line between plugin and app ?
[12:27] <thomas> it seems it would be more logical to make a dynamic pipeline
[12:27] <wtay> good question
[12:27] <thomas> have bits of diskrc -> parse -> volenv
[12:28] <thomas> have the app start these, and mix them
[12:28] <thomas> and hand them out to an output thread
[12:28] <wtay> you should have a plugin for the mixer too
[12:28] <thomas> why ?
[12:28] <thomas> all it would do is add sample values
[12:28] <wtay> well it's more then that
[12:29] <wtay> it needs to merge buffers etc
[12:29] <thomas> and some signaling maybe to say that there is new stuff
[12:29] <thomas> yeah...
[12:29] <thomas> uhm... buffers are probably allowed to have different sizes from each other, right ?
[12:29] <wtay> it might be pull based
[12:29] <wtay> and timestamps
[12:29] <thomas> unfortunately the plugin doc is limited
[12:29] <wtay> very
[12:30] <thomas> can a plugin also do some sort of dynamic srcpad creation ?
[12:30] <wtay> sure
[12:30] <wtay> in your case you'll need request pads
[12:30] <thomas> so the app says "mixer, take this buffer and add it to your src"
[12:30] <wtay> like, "mixer create a new pad wher I can hand you buffers of type X"
[12:31] <thomas> ok... so what's the best way to learn about timestamps and pull based ?
[12:31] <wtay> the mpeg2dec plugin uses pulls
[12:31] <wtay> vorbisdec too
[12:31] <wtay> mad too
[12:31] <thomas> could you tell me what the basic difference is between push and pull ?
[12:31] <thomas> it seems like decoders are more logical for pull
[12:32] <thomas> or am i wrong
[12:32] <wtay> in the push based setup, the plugin is entered in the _chain function
[12:32] <wtay> in the pull based setup, the plugin enters a loop and performs gst_pad_pull on it's sink pads
[12:32] <wtay> some decoder are better with pull based implementations, yes
[12:33] <thomas> ok, so for a mixer it would make more sense to get as much as possible from it's inputs
[12:33] <thomas> and add as much as it can
[12:33] <thomas> and push it back out
[12:33] <wtay> yup, pull a buffer from all the sink pads, mix, push them out
[12:33] <thomas> so you probably can only do a pull on inputs that have a push ?
[12:34] <wtay> nope
[12:34] <wtay> pull can be done on all sorts of sink pads
[12:34] <thomas> ok...
[12:34] <wtay> this is when cothreads come into play
[12:34] <thomas> I think I should start by trying to add two signals from the start
[12:35] <thomas> just see how that works
[12:35] <thomas> I don't know if I'll need timestamps...
[12:35] <thomas> isn't the app responsible for that ?
[12:35] <wtay> plugins are
[12:36] <wtay> if then know the timestamp of the buffer, they should add it
[12:36] <thomas> and by timestamp, you mean "current run time at start of this new buffer in seconds ?"
[12:37] <wtay> in milliseconds, yes
[12:37] <thomas> as seen from the app's point of view, or from the source thread ?
[12:37] <wtay> hmm, source thread
[12:37] <thomas> source thread as in "the thread created to get from disk and hand to the mixer"
[12:38] <wtay> it's not implemented very well yet so you might leave it for now
[12:38] <thomas> ok...
[12:38] <wtay> yup
[12:38] <thomas> I'll start by doing a simple mix then
[12:38] <thomas> so the app says : "mixer, create a pad"
[12:39] <thomas> the mixer tries to pull it's sink pads
[12:39] <thomas> and adds as much as possible
[12:39] <wtay> be carefull...
[12:39] <wtay> you can't request pads at runtime yet...
[12:39] <thomas> meaning ? dynamic pipelines don't work yet ?
[12:39] <wtay> the scheduling will break
[12:40] <wtay> you can get away with it if you use threads
[12:40] <thomas> you're going to fast for me
[12:40] <wtay> omega is hacking like hell to get his dynamic scheduler ready
[12:40] <wtay> so for now:
[12:40] <thomas> so I should base on helloworld2 ?
[12:41] <wtay> create, say 2 disksrc -> decode ->volenv, request 2 pads from the mixer, etc and then run the thing
[12:41] <thomas> yes, that's a first.
[12:41] <thomas> but you're saying : the app can't say after five minutes, create a new pad please ?
[12:41] <wtay> don't add new decoder chains and request new pads from the mixer at runtime for now
[12:42] <wtay> thomas: very unlikely it'll work
[12:42] <thomas> wtay: you mean the runtime part, not the fixed part ?
[12:42] <wtay> the runtime part
[12:42] <wtay> fixed is no prob
[12:42] <thomas> ok... starting on it...
[12:43] <thomas> oh... is it hard to make something like this not depend on if the input is mono or stereo ?
[12:43] <wtay> not hard
[12:44] <thomas> just put a list of allowed channel values in the caps ?
[12:44] <thomas> or is there more to it ?
[12:47] <wtay> you still need to get the caps and get the number of channels from it
[12:47] <wtay> the padtemplates are used to describe the types you can accept
[12:50] <thomas> so in the main app...
[12:50] <thomas> the thing to do would be :
[12:50] <thomas> put one set of disksrc/parse/decode/volenv in bin 1
[12:50] <thomas> another in bin 2
[12:50] <wtay> yup
[12:50] <thomas> add ghost pads to both bins to create an exit
[12:50] <thomas> connect that ghost src pad to the plugin
[12:50] <thomas> connect the plugin to a final bin getting it out ?
[12:50] <wtay> perfect
[12:55] <wtay> we should create an xslt trnasform to transform the editor xml files to c code...
[12:55] <thomas> does that editor work ?
[12:55] <thomas> I should try it
[12:55] <wtay> sorta yes
[12:56] <thomas> now that I'm manually doing this, it seems like it'll be hard to have multiple allowed channels
[12:57] <thomas> do I add the ghost pad to the bin at the last element ?
[12:57] <wtay> yup
[12:58] <wtay> you should also look at tests/tee.c
[12:58] <thomas> ok... like this then :
[12:58] <thomas>   gst_element_add_ghost_pad (bin1, gst_element_get_pad (volenv1, "src"));
[12:58] <thomas> ?
[12:58] <wtay> yup, that's ok
[12:58] <wtay> tee.c has an example of request pads
[12:59] <thomas> what does tee do ? copy one input to more outputs ?
[12:59] <wtay> yup
[13:00] <thomas> uhm... did add_ghost_pad change ? compiler says "too few arguments"
[13:00] <wtay> hmm
[13:01] <wtay> you need to name the new pad too
[13:01] <wtay> arg3
[13:04] <thomas> ok... created input bins with ghost pads
[13:05] <thomas> now do I create a large bin
[13:05] <thomas> put in those two, the mixer and the output element ?
[13:05] <wtay> yup
[13:07] <thomas> ok... now it's got everything except for the plugin
[13:07] <thomas> I'll take a look at the tee first
[13:07] <thomas> while eating
[13:08] <wtay> if you want, add your project description to http://gstreamer.net/wiki/GstApplications
[13:17] <thomas> should I look at "element" tee or "test" tee ?
[13:17] <wtay> both :)
[13:19] <thomas> ok... I think I get it...
[13:19] <wtay> ./gstreamer-inspect volenv
[13:20] <thomas> in the chain, tee loops over all of the srcpads
[13:20] <thomas> and pushes the input buffer on the output
[13:20] <wtay> tee, is push based though
[13:20] <thomas> so what happens there if the outputs have different buffer sizes ?
[13:20] <thomas> does the pad_push do that automatically ?
[13:20] <wtay> you'll have to loop over the sink pads and pull a buffer from them
[13:21] <wtay> yup
[13:21] <thomas> ok... I'll take a shower and think about that
[13:21] <thomas> there should be more easter mondays
[13:21] <wtay> hehe
[14:03] <thomas> ok...
[14:03] <thomas> I checked tee
[14:03] <thomas> I want to make an adder
[14:03] <thomas> where should I put it in the source tree ?
[14:03] <wtay> hmm
[14:04] <wtay> filters
[14:04] <thomas> why are the elements all called gst... and all in the same directory ?
[14:04] <wtay> they are core elements
[14:04] <wtay> dunno
[14:05] <thomas> ok, filters it is then
[14:09] <thomas> so the adder doesn't need a chain function, right ?
[14:09] <thomas> it should be loop based ?
[14:09] <wtay> yup
[14:23] <thomas> ok... i'm writing gst_adder_loop (GstElement *element) now...
[14:23] <thomas> is it just "get a pointer to the data from the src pad"
[14:23] <thomas> "write to that data" ?
[14:23] <wtay> yes
[14:24] <wtay> GstBuffer *buf = gst_pad_pull (element->sinkpad);
[14:26] <thomas> and I have to declare and init that *buf first ?
[14:27] <wtay> nope
[14:27] <wtay> you get a buffer from the peer element
[14:30] dam|foo (daniel at nas-cbv-2-23-83.dial.proxad.net) joined #gstreamer.
[14:30] <dam|foo> hi
[14:30] <thomas> hi
[14:30] <thomas> wtay: when I create an output buffer...
[14:30] <thomas> wtay: do I have to set DATA and SIZE, or do they default ?
[14:31] <dam|foo> just a question : is there a prebuilt debian package ?
[14:32] <wtay> hi
[14:32] <dam|foo> i've seen the debian directory in gstreamer-0.1.1.tar.gz
[14:32] <wtay> thomas: you'll have to set data and size
[14:32] <wtay> dam|foo: nope
[14:32] <dam|foo> but the compilation failed
[14:32] <dam|foo> it didn't find the rule for all in a subdirectory
[14:33] <dam|foo> i mean make rule
[14:33] <wtay> dam|foo: hmm
[14:33] <wtay> in what dir?
[14:33] <dam|foo> hmm i must recompile it i've deleted the sources
[14:33] <dam|foo> just wait a few minutes
[14:34] <wtay> ok
[14:34] <wtay> sure
[14:34] <thomas> so I just take a guess on how big I want it to be ?
[14:35] <thomas> ok... there probably isn't a good way to test this adder with gstreamer-launch ?
[14:35] <thomas> just to see if i'm on the right track
[14:36] <wtay> hmm no
[14:37] <thomas> ok... i'll try the example then
[14:41] <thomas> hmm... I made an "adder" plugin
[14:41] <thomas> but gstreamer-register can't find it
[14:41] <thomas> also... it complains :
[14:41] <thomas> ** CRITICAL **: file volenv.c: line 385 (plugin_init): assertion `plugin != NUL$
[14:41] <thomas> so I did something wrong somewhere
[14:41] <wtay> it is loaded twice
[14:42] <thomas> yes, indeed...
[14:42] <thomas> get rid of the old one
[14:42] <wtay> is the name of the plugin changed in gst_plugin_new ?
[14:43] <thomas> oops... no plugin_new
[14:43] <thomas> I copied it from tee
[14:43] <thomas> not a good idea
[14:43] <thomas> ok adding...
[14:48] <thomas> pftt this is complicated...
[14:48] <wtay> ?
[14:49] <thomas> something with src and sink templates
[14:49] <wtay> oh yeah
[14:49] <thomas> different use in tee and stereo2mono
[14:50] <thomas> I have this in my plugin_init now :
[14:50] <thomas>   gst_elementfactory_add_padtemplate (factory, adder_sink_template_factory ());
[14:50] <thomas>   gst_elementfactory_add_padtemplate (factory, adder_src_template_factory ());
[14:50] <thomas> but since the plugin only has a fixed src
[14:50] <thomas> and variable slinks
[14:50] <thomas> (sinks)
[14:50] <thomas> I probably should drop the adder_sink
[14:50] <wtay> no
[14:50] <wtay> the adder sink has to have the GST_PAD_REQUEST type
[14:51] <thomas> and is this set in adder_sink_template_factory ?
[14:51] <wtay> yup
[14:51] <wtay> like the tee
[14:51] <thomas> but the adder doesn't have sinks at startup ?
[14:51] <wtay> no, the padtemplate says that the pad are created on request
[14:52] <thomas> so then why does the tee not have a gst_tee_sink_template ?
[14:53] <wtay> it can accept everything, so it's not really needed
[14:53] <wtay> the template is only needed to narrow the media types the pad can accept
[14:53] <thomas> ok... so in conclusion, the adder needs both kinds of templates ?
[14:53] <wtay> yup
[14:55] <thomas> ok... so I actually copy both adder_src_template_factory and adder_sink_template_factory from volenv, for example ?
[14:55] <wtay> that would be a good start, yes
[14:56] <wtay> then you change the pad presence of the sink pad from GST_PAD_ALWAYS to GST_PAD_REQUEST
[14:56] <wtay> meaning that the pad is not always there but only on request
[14:59] <thomas> ok... adder registered
[14:59] <thomas> wonder what it does now ;)
[15:00] <wtay> you can use -inspect to see if the element is correctly registered...
[15:00] <thomas> it seems ok... anything to watch for ?
[15:01] <wtay> Exists: Request
[15:01] <thomas> that's ok...
[15:01] <thomas> my mixer example fails though
[15:01] <thomas> ***** GStreamer ERROR ***** in file gstscheduler.c at gst_bin_schedule_func:431
[15:01] <thomas> Element: /bin/bin/volume1.src
[15:01] <thomas> Error: peer is null!
[15:01] <thomas> of course I don't know if I did it right
[15:03] <wtay> you didn't connect the volume src pad...
[15:03] <thomas> right ;)
[15:03] <thomas> didn't even put the adder plugin yet
[15:03] <thomas> too hasty
[15:03] <wtay> heh
[15:05] <thomas> ok... so how do I connect my bin_in1 ghost src pad to my adder sink pad ?
[15:05] <thomas> normal way ?
[15:05] <wtay> tests/tee.c has an example
[15:05] <thomas> or something else ?
[15:06] <thomas> ok... checkin
[15:06] <wtay> first request the pad, then connect
[15:06] <dam|foo> so it's finished
[15:06] <wtay> hmm ok, it doesn't whos how you connect it but that's obvious
[15:07] <wtay> dam|foo: no errors?
[15:07] <dam|foo> make[4]: Entering directory `/home/daniel/src/gstreamer-0.1.1/docs/plugins'
[15:07] <dam|foo> make[4]: *** No rule to make target `gstreamer-plugins.hierarchy', needed by `all-am'.  Stop.
[15:07] <dam|foo> make[4]: Leaving directory `/home/daniel/src/gstreamer-0.1.1/docs/plugins'
[15:07] <dam|foo> make[3]: *** [all-recursive] Error 1
[15:07] <dam|foo> make[3]: Leaving directory `/home/daniel/src/gstreamer-0.1.1/docs'
[15:07] <dam|foo> make[2]: *** [all-recursive] Error 1
[15:07] <dam|foo> make[2]: Leaving directory `/home/daniel/src/gstreamer-0.1.1'
[15:07] <dam|foo> make[1]: *** [all-recursive-am] Error 2
[15:07] <dam|foo> make[1]: Leaving directory `/home/daniel/src/gstreamer-0.1.1'
[15:07] <dam|foo> make: *** [build-stamp] Error 2
[15:07] <wtay> dam|foo: ok, that's the docs...
[15:07] <dam|foo> yes
[15:07] <wtay> dam|foo: you can ignore it...
[15:08] <wtay> dam|foo: or use ./configure --disable-docs-build
[15:08] <dam|foo> but then i can't have .deb
[15:08] <wtay> dam|foo: why not?
[15:09] <dam|foo> hmmm, no okay
[15:09] <wtay> dam|foo: you can also type make html in that dir, then it should work
[15:10] <dam|foo> arg
[15:11] <dam|foo> how do i transmit --disable-docs-build trough dpkg-buildpackage ?
[15:11] <wtay> no idea...
[15:11] <wtay> debian/rules had a ./configure command in it...
[15:12] <wtay> s/had/has
[15:12] <wtay> it even has --disable-plugin-docs in it..
[15:14] <dam|foo> hmm i see configure but not --disable-plugin-docs
[15:14] <dam|foo> what version are you using ?
[15:14] <wtay> CVS
[15:14] <dam|foo> no
[15:14] <dam|foo> okay
[15:15] <dam|foo> i've got --enable-docs-build
[15:15] <dam|foo> i'll change this
[15:15] <wtay> ok
[15:16] <dam|foo> there were also lots of problem when compiling .sgml
[15:17] <wtay> dam|foo: yup, ignore them too :)
[15:17] <wtay> docbook/gtkdoc issues
[15:18] <dam|foo> it's recompiling everything :(
[15:18] <dam|foo> it's really a long process
[15:20] <wtay> I know the feeling :)
[15:20] <dam|foo> thanks, i will be able to test gstreamer now
[15:20] <dam|foo> it seems to be great
[15:20] <dam|foo> bye
[15:21] dam|foo (daniel at nas-cbv-2-23-83.dial.proxad.net) left irc: Meuh
[15:30] <thomas> wtay, still there ?
[15:31] <thomas> another problem...
[15:31] <wtay> yeah
[15:31] <thomas> ** CRITICAL **: file gstelement.c: line 551 (gst_element_request_pad_by_name): assertion `templ != NULL' failed.
[15:31] <thomas> ** CRITICAL **: file gstpad.c: line 312 (gst_pad_get_name): assertion `pad != NULL' failed.
[15:31] <thomas> new pad (null)
[15:31] <thomas> twice...
[15:31] <thomas> so I'm doing something else wrong now
[15:31] <thomas> here's the request code :
[15:31] <thomas>   pad = gst_element_request_pad_by_name (adder, "src%d");
[15:31] <thomas>   g_print ("new pad %s\n", gst_pad_get_name (pad));
[15:31] <thomas>   gst_pad_connect (gst_element_get_pad (bin_in1, "src"), pad);
[15:32] <wtay> looks good
[15:32] <thomas> oh wait... it's probably "sink%d"...
[15:32] <thomas> damn
[15:32] <wtay> yes
[15:34] <thomas> still doesn't work... same error...
[15:34] <thomas> ok, what happens in request_pad_by_name ?
[15:34] <wtay> hmm
[15:35] <wtay> the padtemplates of the elements are enumerated and the one with the requested name is returned
[15:36] <wtay> you do have a request function in adder too?
[15:38] <thomas> sorry, was on the phone... checking now...
[15:39] <thomas> static GstPad*  gst_adder_request_new_pad (GstElement *element, GstPadTemplate $
[15:39] <thomas> and so on...
[15:39] <thomas> and it's filled in
[15:39] <wtay> ok, and you add it in the class_init method
[15:40] <thomas> yes...   gstelement_class->request_new_pad = gst_adder_request_new_pad;
[15:40] <wtay> can I see the padtemplate factory?
[15:40] <thomas> which one is that ?
[15:40] <wtay> the sink%d one
[15:41] <thomas> the whole function ?
[15:41] <thomas> oh wait, should it read "sink%d" instead of "sink" ?
[15:41] <wtay> yeah
[15:42] <thomas> ok... new errors, that's good.
[15:43] <thomas> I put this in request_new_pad...
[15:43] <thomas>   if (templ->direction != GST_PAD_SINK) {
[15:43] <thomas>     g_warning ("gstadder: request new pad that is not a SINK pad\n");
[15:43] <thomas>     return NULL;
[15:43] <thomas> this is where it complains
[15:43] <thomas> I reversed it from tee
[15:43] <thomas> in the mixer.c I have
[15:43] <thomas>   pad = gst_element_request_pad_by_name (adder, "sink%d");
[15:44] <thomas> how does it know that it's not a sink ?
[15:44] <wtay> and the padtemplate has a GST_PAD_SINK right?
[15:44] <thomas> or why does it think so ?
[15:44] <thomas> oops... inspect shows two SRC templates
[15:45] <thomas> hmmm... fix one.
[15:45] <wtay> well
[15:45] <thomas> ok now it creates the pads, one more thing wrong.
[15:46] <thomas> ok this is what's failing :
[15:46] <thomas>   gst_pad_connect (gst_element_get_pad (bin_in1, "src"), pad);
[15:46] <thomas> where bin_in1 should have ghost pad
[15:47] <wtay> you added the ghostpad how?
[15:47] <thomas>   gst_element_add_ghost_pad (bin_in1, gst_element_get_pad (volenv1,
[15:47] <thomas> "src"), "channel1");
[15:47] <thomas> I don't know if the name is right
[15:47] <thomas> should it be "sink1" ?
[15:47] <wtay> the ghost pad is called channel1 so
[15:47] <wtay>  gst_pad_connect (gst_element_get_pad (bin_in1, "channel1"), pad);
[15:48] <thomas> ok one more error to go
[15:48] <wtay> if you create a ghost pad called "channel1", you get it back with _get_pad (.., "channel1"); :-)
[15:49] <thomas> ** CRITICAL **: file gstpad.c: line 579 (gst_pad_connect): assertion `(GST_RPAD_DIRECTION(realsrc) == GST_PAD_SRC) && (GST_RPAD_DIRECTION(realsink) == GST_PAD_SINK)' failed.
[15:49] <wtay> on which connect?
[15:50] <thomas> I think
[15:50] <thomas>   gst_pad_connect(gst_element_get_pad(adder,"src"),
[15:50] <thomas>                   gst_element_get_pad(audiosink,"sink")); 
[15:50] <thomas> because it's the first one after the previous errors
[15:50] <wtay> check if the added src pad really is GST_PAD_SRC
[15:50] <wtay> s/added/adder
[15:50] <thomas> inspect shows this :
[15:50] <thomas> Pads:
[15:50] <thomas>   SINK: 'src'
[15:50] <thomas>     Implementation:
[15:50] <thomas>       Has eosfunc(): 0x400311ec
[15:51] <thomas> that doesn't look right does it ?
[15:51] <wtay> nope
[15:51] <wtay> check the padtemplate of the src pad...
[15:52] <thomas> is that in adder_src_tpl_fac ?
[15:52] <wtay> probably
[15:52] <thomas> it looks good...
[15:52] <thomas>   if (!template) {
[15:52] <thomas>     template = gst_padtemplate_new (
[15:52] <thomas>       "src",
[15:52] <thomas>       GST_PAD_SRC,
[15:52] <thomas>       GST_PAD_ALWAYS,
[15:52] <wtay> how do you create the src pad?
[15:53] <thomas> is that in the adder plugin ?
[15:53] <wtay> yup
[15:53] <thomas> (man I shouldn't have stayed up so late)
[15:53] <wtay> you should have slep a little loner :)
[15:53] <wtay> s/slep/slept
[15:53] <thomas> yeah, didn't work
[15:53] <thomas> is that in plugin_init or in adder_init ?
[15:54] <wtay> adder_init
[15:54] <thomas> ok, that one was wrongg, fixed.
[15:54] <wtay> did you create if from the template?
[15:54] <thomas> I think so...
[15:54] <thomas> anyway, the thing is iterating
[15:54] <wtay> or just gst_pad_new ()
[15:54] <thomas> so something is working
[15:55] <wtay> ok
[15:55] <wtay> is it mixing?
[15:55] <thomas> no, I haven't even begun adding samples yet !
[15:55] <thomas> I don't know how I'll manage to have different input sizes of buffers
[15:55] <thomas> so I just want it to interleave them for now
[15:55] <thomas> in a random fashion ;)
[15:55] <wtay> yeah, you'll need to buffer and stuff...
[15:56] <wtay> or scale the buffers...
[15:56] <thomas> can you do that with queues ?
[15:56] <wtay> nope
[15:56] <thomas> or some sort of buffer_rescale plugin ?
[15:57] <wtay> yeah, but not yet...
[15:57] <wtay> a generic mixer really needs to check the timestamps and align buffers/scale them etc...
[15:58] <wtay> just pretent the buffers are equally sized for now
[15:59] <thomas> if I get a new output buffer and g_malloc it, is it zero-filled automatically ?
[15:59] <thomas> if not, I'll get a lot of noise... ;)
[15:59] <thomas> and I should probably make my output buffer the same size as the input buffers for the moment...
[16:00] <wtay> use g_malloc0 instead
[16:00] <wtay> yeah
[16:00] <thomas> this is getting more difficult than I thought it would
[16:00] <thomas> what was the standard size again ?
[16:00] <wtay> 4096
[16:01] <wtay> but since you're getting the input from mpg123, the size is actually the size of one mp3 output frame
[16:01] <thomas> damn...
[16:01] <thomas> i'll stick with 4096 right now and see what it does
[16:01] <wtay> just pretend they have an equal size for now
[16:01] <wtay> output size == input size
[16:03] <thomas> how do I clear the output buffer at the end ?
[16:03] <wtay> clear?
[16:03] <wtay> memset?
[16:03] <thomas> no, just free
[16:03] <wtay> gst_buffer_unref
[16:03] <thomas> after you push it, you should probably release it ?
[16:03] <thomas> ok
[16:04] <wtay> thomas: not when you push it
[16:04] anthos (anthos at n50-c209-c149-c55.bs.xlate.ufl.edu) joined #gstreamer.
[16:04] <thomas> when ?
[16:04] <anthos> hmm 
[16:04] <wtay> when you pull it, you should free
[16:04] <wtay> hi
[16:04] <thomas> hi
[16:04] <thomas> wtay: so you free your input buffers, not your output ?
[16:04] <wtay> yup
[16:05] <wtay> btw: I gotta take a bath now, back in 40 mins or so...
[16:06] <thomas> wtay: does g_malloc0 (value) malloc value bytes or value (sizeof(type of buf))
[16:06] <thomas> ?
[16:06] <thomas> till later
[16:37] <wtay> back
[16:38] <wtay> malloc0 is bytes
[16:42] Nick change: taazzzz -> taaz
[16:42] <wtay> 'morning
[16:42] <taaz> hey
[16:42] <thomas> hi
[16:42] <taaz> i've always thought it easier just to use those g_new macros
[16:42] <wtay> true
[16:42] <thomas> which are ?
[16:42] <thomas> god I have to learn a lot
[16:42] <thomas> I thought I knew my C
[16:43] <thomas> but it's rusty
[16:43] <taaz> g_new(MyType, count).. just does type casting and sizeof stuff for you
[16:43] <taaz> look at the docs
[16:44] <thomas> WOOHOO
[16:44] <thomas> getting some sort of audio that resembles one of the two input s treams
[16:45] Action: wtay like success stories
[16:45] <wtay> s/like/likes
[16:45] <thomas> guess I should check that buffer size stuff
[16:46] <thomas> WOOHOO !!
[16:46] <wtay> taaz: implementing a bufferpool in mpeg2dec now
[16:46] <thomas> now I get the same bad audio
[16:46] <thomas> but from both streams, mixed !
[16:46] <wtay> cool
[16:46] <thomas> sorry, I'm getting carried away
[16:47] <wtay> :)
[16:47] <taaz> cool... how are you doing it?
[16:47] <thomas> I'm writing a mixer plugin
[16:47] <thomas> right now it's a simple adder
[16:47] <thomas> putting two channels together
[16:47] <wtay> thomas: are you doing this for an assignment?
[16:47] <thomas> and the program has a volume envelope in front of that
[16:48] <thomas> assignment as in school ?
[16:48] <wtay> yup
[16:48] <thomas> no... I graduated already
[16:48] <taaz> wtay: cool... how are you doing it?
[16:48] <thomas> assignment as in 'product under development'
[16:48] <wtay> just for fun then? :)
[16:48] <thomas> and also for fun
[16:48] <wtay> cool
[16:48] <thomas> this is what my thesis did two years ago
[16:48] <wtay> taaz: request a bufferpool from the peer element and use that to allocate an ouput buffer
[16:50] <taaz> hmm... how does that work if the frame size changes?  that was why i didn't do the buffering
[16:50] <wtay> taaz: mpeg2dec should be able to write directly into XSHM...
[16:51] <taaz> yeah... but keep in mind that it needs to read out of predictive frames too... you'd want those as local as possible.
[16:51] <wtay> taaz: yeah
[16:52] <wtay> taaz: I might be able to pass an xvimage to mpeg2dec.. I dunno if I can create multiple Xv images though..
[17:01] Action: taaz runs off for a bit
[17:01] Nick change: taaz -> taaz-away
[17:07] <thomas> hmmm...
[17:07] <thomas> the extra noise on only on one of the two channels
[17:07] <thomas> the second one is fine
[17:07] <thomas> there must be something wrong
[17:08] <wtay> hmm
[17:09] <thomas> if I skip the first sinkpad, the audio comes out fine as one of the two input channels
[17:09] <thomas> maybe I should have three channels
[17:09] <thomas> and see if it's on two of the three or on one
[17:10] <thomas> does this look ok to you :
[17:10] <thomas>       sinkpad = GST_PAD (sinkpads->data);   
[17:10] <thomas>       buf_in = gst_pad_pull (sinkpad);
[17:10] <thomas>       data_in = (guint16 *) GST_BUFFER_DATA (buf_in);
[17:10] <thomas>       if (data_in == NULL)
[17:10] <thomas>         printf ("ERROR : could not get input buffer !\n");
[17:11] <thomas> in my while (sinkpads) loop ?
[17:11] <wtay> looks good
[17:11] <wtay> you should check for buf_in != NULL
[17:20] omega_ (omega at omegacs.net) joined #gstreamer.
[17:20] <wtay> 'morning
[17:20] <omega_> yo
[17:21] Action: omega_ starts downloading rh7.1
[17:22] Action: omega_ wishes the world would figure out that push mirroring is a requirement
[17:30] <thomas> *sigh*
[17:30] <thomas> I wish I knew what it was doing wrong now
[17:30] <thomas> that's the hard part about audio filters
[17:30] <thomas> it's almost right but not quite
[17:30] <omega_> heh
[17:30] <thomas> and it sounds like shit anyway
[17:31] <thomas> anyone want to listen ?
[17:31] <omega_> to which?
[17:31] <thomas> to the mixer example and two mp3's of your choice ;)
[17:31] <omega_> hehehe
[17:31] <wtay> yeah lemme see it
[17:32] <omega_> yay.  mirror of rh7.1iso1 gives me <1KB/sec
[17:33] <wtay> cool
[17:34] <wtay> not :(
[17:34] <thomas> wtay: it's at http://urgent.rug.ac.be/thomas/gst/
[17:34] <thomas> mix.tar.gz
[17:34] <thomas> contains adder plugin and mixer example
[17:34] <wtay> ok
[17:34] <thomas> type mixer (file1) (file2)
[17:34] <thomas> getting something to drink
[17:34] <omega_> adn you used the autoplugger, so he can mix an mp3 and a vorbis, right? ;-)
[17:35] <wtay> omega_: later, later :)
[17:35] <thomas> heh...
[17:35] <omega_> hmm, 'sustaining' 1.47KB/sec now
[17:35] <thomas> shouldn't be a problem
[17:35] <thomas> the hard parts first
[17:36] <thomas> so, is there a way I can check if I'm doing my buffer allocation and clearing right ?
[17:36] Action: omega_ is now doing the HEAD->INCSCHED1 merge
[17:36] <wtay> thomas: looking at top?
[17:36] <wtay> omega_: whoohoo!
[17:37] <thomas> looking at memory leaking, you mean ?
[17:37] <omega_> wtay: but it doesn't work yet, I'm not merging down until it does
[17:37] <wtay> thomas: one thing: I don't see you propagating the caps from sink to src...
[17:37] <thomas> is that a bad thing ? ;)
[17:37] <thomas> wtay: where do I do that ?
[17:37] <omega_> just getting all the latest HEAD stuff to reduce the number of unknowns in the ROOT for INCSCHED1
[17:38] <wtay> omega_: autoplug actually doesn't work here because the disksrc scheduling is not reseted correctly after typedetection...
[17:38] <omega_> hmm
[17:39] <thomas> wtay : my mem % is going up on the lt-mixer process ;)
[17:39] <thomas> so be sure to abort it before your kernel sinks
[17:39] <omega_> use memprof
[17:40] Nick change: taaz-away -> taaz
[17:41] <omega_> anyone know of another rh7.1iso mirror that works?
[17:41] <wtay> omega_: isn't there a list somewhere with mirrors?
[17:42] <omega_> no, a mirror that actually *has* the iso
[17:42] <thomas> omega_: you really need it today ?
[17:42] <omega_> redhat stupidly doesn't seem to give the mirrors first crack at it
[17:42] <omega_> thomas: no, but I'd like to get it ASAP
[17:42] <omega_> because it should have xf4.0.3, which I need to do Xv on my laptop
[17:43] <thomas> omega: I'm using memprof now
[17:43] <thomas> omega: don't know if it's good or not ...
[17:43] <thomas> omega: ... but memprof seems stable in it's number of allocations
[17:44] <thomas> omega: ... still my mem % as listed in top is going up
[17:44] <omega_> ok, then you're probably just seeing the mmap()ed pages going up
[17:44] <omega_> we need to rework the disksrc to do mmap() a region at a time, and free them up
[17:44] <thomas> yeah, the cached value is rising
[17:44] <omega_> as per the fwd'd mail in the list archives from Buck Krasic
[17:44] <thomas> so that means it's just caching the whole mp3 while it's reading ?
[17:44] <omega_> yes
[17:44] <omega_> well, the kernel bufcache is holding it
[17:45] <thomas> too bad...
[17:45] <thomas> I was hoping I made a mistake there
[17:45] <omega_> heh
[17:45] <thomas> now I'll have to look harder
[17:45] <omega_> um, why?
[17:45] <omega_> (hoping for a mistake, that is)
[17:45] <thomas> well... if the mistake was my fucking up the buffer alloc/clearing...
[17:45] <omega_> ah
[17:45] <thomas> ... then fixing that could have fixed the audio
[17:45] <thomas> cause it sounds like it's dropping samples in between
[17:45] <thomas> on one of the two channels
[17:46] <omega_> hmm
[17:46] <thomas> wtay: can you get it to work ?
[17:46] <wtay> yup, works kinda well,
[17:47] <wtay> some distortion
[17:47] <thomas> do you also have that strange distortion
[17:47] <thomas> yeah ok
[17:47] <thomas> if you swap the files on the input line
[17:47] <wtay> yup, caps nego is not happening with the audoosink though
[17:47] <thomas> you'll notice the distortion is on the other channel
[17:47] <thomas> could that be it ?
[17:47] <wtay> dunno
[17:47] <wtay> unlikely
[17:47] <thomas> don't think so either
[17:47] <thomas> well let's fix it anyway
[17:47] <wtay> 10 cothreads :)
[17:47] <thomas> what did I do wrong
[17:47] <thomas> 10 cothreads ? is that normal ?
[17:47] <wtay> looking
[17:47] <thomas> I don't even know how to use them and I got 10 already ;)
[17:48] <wtay> yeah
[17:48] <omega_> cothreads are completely hidden within the scheduling system, you should never even know they exist ;-)
[17:48] <thomas> btw I changed volenv a bit; the default settings were wrong ;)
[17:48] <thomas> omega_: that's a good thing.  You should hide more internals from people like me ;)
[17:48] <omega_> hehehe
[17:51] <wtay> you divide by four...
[17:51] <thomas> wtay: that's just for testin
[17:51] <omega_> 4?
[17:51] <thomas> means 6dB level down
[17:51] <thomas> you can drop it if you want
[17:51] <thomas> I should get a new "G" key
[17:52] <thomas> (it makes me look ten years younger if I keep typing testin instead of testing)
[17:52] <wtay> ooops, I think I got something
[17:53] <thomas> wtay: tell me !
[17:53] <wtay> you should have a way to exit the loop
[17:53] Action: thomas looks stumped
[17:53] <wtay> hmm, sorry you do...
[17:53] <wtay> ignore
[17:54] <thomas> printf ("%p" should work to print a pointer address, right ?
[17:54] <wtay> yup
[17:54] <thomas> is it coincidence that it allocates the same output buffer address every time ?
[17:54] <omega_> now that I finally got into ftp.redhat.com, I'm sustaining 22+KB/sec
[17:55] <omega_> thomas: probably
[17:55] <wtay> omega_: it's using a g_mem_chunk so yes
[17:55] <thomas> omega_: you should have it in 10 hours' time then
[17:55] <thomas> ;)
[17:56] <thomas> ok... but it doesn't look logical that is has the same data_in pointer...
[17:56] <thomas> for both channels
[17:56] <omega_> 9, for the first disk
[17:56] <omega_> oops
[17:57] <wtay> thomas: it does
[17:57] <thomas> why ?
[17:57] <wtay> thomas: coincidency, and you do free the buffer before you pull the other one so...
[17:58] <omega_> hmmmm
[17:58] <omega_> waitasec
[17:58] <omega_> are you getting hte data pointer, unrefing the buffer, the pulling the next?
[17:58] <thomas> yes
[17:58] <omega_> oops
[17:58] <omega_> you must not unref until you're *done* with the buffer
[17:58] <thomas> well I do this :
[17:58] <thomas> get pointer
[17:58] <omega_> including the data pointer and its contents
[17:59] <thomas> add all of the buffer to out buffer
[17:59] <thomas> unref in buffer
[17:59] <omega_> ok
[17:59] <thomas> pull next in buffer
[17:59] <wtay> it looks ok to me...
[17:59] <wtay> meybe thread issues in mpg123...
[17:59] <thomas> wtay: I also tried pushing the buffer instead of actually adding it, so that you interleave blocks of each track
[18:00] <thomas> wtay: had same effect
[18:00] <thomas> wtay: but speed / 2
[18:00] <thomas> wtay: it could be thread issues
[18:00] <thomas> wtay: what if mpg123 uses a static array to keep track of the previous frame data ?
[18:00] <thomas> hmm..
[18:00] <wtay> thomas: I don't think so...
[18:00] <omega_> afaik I did a complete threadsafe mod to mpg123
[18:00] <thomas> I remember having htat problem in my thesis with the ISO code
[18:00] <omega_> the ISO code sucks
[18:01] <thomas> but it does sound like it
[18:01] <omega_> maybe try mad ?
[18:01] <wtay> You do have the infinite while loop prob though.. fixing...
[18:01] <thomas> yeah it does, but at that time that's about all there was
[18:01] <thomas> anyway, switching to mad to try it
[18:01] <thomas> you still need a parser right ?
[18:02] <wtay> thomas: nope
[18:02] <thomas> should've used autoplugging from the start ;)
[18:02] Action: omega_ just had an idea
[18:03] <omega_> when we add merit to plugins, we should have some way to store system and user-level overrides or 'bumps' of the merit values for given filters
[18:03] <omega_> so you can force mpg123's merit to 0 if you want
[18:03] <thomas> "merit" as in "picking a likewise capable plugin over another" ?
[18:03] <wtay> omega_: I've been thinking about that too actually..
[18:04] <wtay> omega_: you'd probably need a way to override the autoplug connection weights...
[18:04] <omega_> that too
[18:05] <wtay> but also in a query like gst_elementfactory_get_by_type ("Audio/Decoder/mp3"); or somesuch
[18:06] <omega_> yup
[18:06] <omega_> well, that's simple linear merit
[18:06] <wtay> we should have an oaf-like query mechanism...
[18:06] <omega_> though I wonder if the autoplugger shoudln't provide that functionality instead
[18:06] <omega_> so you ask for a decoder, and it gives you a autoplug bin that finds the best that matches
[18:09] <wtay> I wonder how usefull the element factories still are...
[18:09] <wtay> bingo
[18:09] <omega_> they're still the only way to get the gtktype...
[18:10] <wtay> mpg123 sucks
[18:11] <wtay> now I only add the samples from the second buffer and I can still hear the first mp3
[18:11] <omega_> howso?
[18:11] <omega_> oops
[18:11] <omega_> btw, how clean is the MAD API ?
[18:11] taaz (dlehn at 66.37.66.32) got netsplit.
[18:11] taaz (dlehn at 66.37.66.32) returned to #gstreamer.
[18:11] <wtay> very nice...
[18:11] <omega_> hmm, ok, I'll have to look at the mad plugin
[18:11] <wtay> does thinks with a callback function though
[18:12] <wtay> but at least there is a way to add a void* pointer to it
[18:12] <wtay> thomas: did you try with mad?
[18:12] <omega_> heh, good
[18:12] <thomas> wtay: not yet... have to download it first
[18:12] <wtay> ok I'll try
[18:12] <thomas> do I need the player or some sort of libmad
[18:13] <thomas> ok i'll let you do it
[18:13] taaz (dlehn at 66.37.66.32) left irc: Read error to taaz[66.37.66.32]: EOF from client
[18:13] <thomas> I just got company
[18:13] <omega_> ok, /me just finished the hand merge of head into incsched1, now to build it
[18:14] taaz (dlehn at 66.37.66.32) joined #gstreamer.
[18:14] <omega_> only 500min ETA on rh7.1iso1
[18:14] <wtay> whooho, mad works perfect!
[18:14] <omega_> cool
[18:14] Action: omega_ goes to read gstmad code
[18:14] <omega_> and did you figure out what the deal was with compilation on my end?
[18:15] <omega_> header->sfreq DNE
[18:15] <thomas> wtay: you mean "mad makes it sound perfect" ?
[18:15] <wtay> thomas: yup
[18:15] <thomas> OH GREAT !
[18:16] <thomas> ok where can I get it
[18:16] <wtay> omega_: version issues I gues
[18:16] <omega_> wtay: I wonder, is it possible to go back to the less verbose padfactory style declaration, but have it expand internally to the new function-based approach?
[18:16] <wtay> omega_: yeah, I thought about a little macro
[18:16] <wtay> thomas: just a sec.. checking it in now...
[18:16] <omega_> work back towards the tighther declaration, in anticipation of a real FilterFactory
[18:17] <wtay> omega_: will try something soon
[18:17] <omega_> oh great
[18:17] <omega_> I forgot the -dP on my merge
[18:18] <thomas> wtay: do I need to download madplayer ?
[18:18] <wtay> thomas: nope
[18:19] <omega_> wtay: what version of mad were you using again?
[18:20] <wtay> sec...
[18:20] <wtay>  libmad0                     0.12.5b-1              
[18:21] <omega_> probably should figure out what the diff is and have a ver check in configure.in
[18:21] Action: omega_ installs 0.12.5b-1 now
[18:21] <wtay> yeah
[18:22] <omega_> the point about converting the mad author to gstreamer should be followed up
[18:23] <omega_> I got very very lost in all the junk floating around in madplay
[18:23] <thomas> wtay: what do I need then to get it working ?
[18:23] Action: thomas wants to HEAR the mix
[18:23] <wtay> thomas: sec.. checking in...
[18:24] <wtay> thomas: remove the parser and add mad instead of mpg123
[18:24] <omega_> we do need to make sure that mp3parse doesn't kill mad
[18:24] <omega_> because mp3parse will be doing the seek handling later
[18:25] <wtay> omega_: mad cannot handle unframed data and it doesn't play with framed data (very weird)
[18:25] <wtay> omega_: you have to handle it exactly like it wants it
[18:25] <omega_> huh? that means that it doesn't work
[18:25] <wtay> omega_: ie with a memmove etc..
[18:25] <wtay> omega_: not unless we find a way
[18:26] <wtay> omega_: I think it needs at least two frames to work..
[18:26] <omega_> then IMO we should try to work with the MAD author to fix mad
[18:26] <wtay> yes
[18:26] <omega_> he's on the right track, but there are more things that need doing
[18:26] <omega_> if we can work up a list of things that are good and bad, and how we'd change things, we can present it to him
[18:27] <wtay> thomas: all is checked in, do cvs update -dP in the gstreamer root dir
[18:28] <wtay> omega_: just the "one frame doesn't work" issues is bad...
[18:28] <omega_> yup
[18:29] <wtay> and the sync doesn't work either...
[18:29] <omega_> but IMO we should put significant work into mad, if we feel that's the right direction to go
[18:29] <omega_> because a good solid mp3 decoder is going to be *the* most used filter in gstreamer, period
[18:29] <wtay> omega_: it's already pretty fast for not having asm optimisations IMO
[18:30] <omega_> yeah, it clocked about 10-15% faster than mpg123 in my simple test
[18:30] <wtay> oh, you're lucky then
[18:30] <omega_> oh?
[18:30] <wtay> sienap reported it being slower
[18:30] <omega_> hmm
[18:30] <omega_> depends on the proc probably
[18:31] <wtay> yeah, looking at top isn't very usefull
[18:31] <omega_> I used time
[18:31] <omega_> came in a 8sec user to mpg123's 9sec
[18:31] <wtay> hmm ok
[18:32] <omega_> um, this is screwed
[18:32] <omega_> I have an incsched working copy
[18:32] <wtay> time gstreamer-launch disksrc location=.. ! mad ! fakesink silent=true
[18:32] <omega_> I need to merge in HEAD, which has all sorts of new directories
[18:32] <wtay> does it work with gstmediaplay yet?
[18:33] <omega_> but I can't get these directories to be created and populated in my incsched copy
[18:33] <wtay> hmm
[18:33] <omega_> oooh, mad works
[18:33] <thomas> wtay: will it overwrite my modification
[18:33] <omega_> neat, mp3parse kills the pipeline dea
[18:33] <wtay> thomas: move you mod aside
[18:33] <omega_> s/dea/dead/
[18:33] <thomas> wtay: btw if mad doesn't use threads, that's probably why it seems slower
[18:33] <thomas> mpg123 uses two threads
[18:34] <thomas> so top doesn't show
[18:34] <wtay> hmm
[18:34] <wtay> true
[18:34] <omega_> silent=true ?
[18:35] <wtay> ;)
[18:36] <omega_> hmm, ok, I get 15.720sec for mad and 14.420sec for mpg123, with -launch
[18:39] <omega_> fyi, plugins/mulaw is in configure.in twice
[18:39] <thomas> wtay: if I don't have Makefile but I do have Makefile.am...
[18:40] <thomas> how do I get makefile ?
[18:40] <omega_> you have to run autogen.sh again
[18:40] <thomas> but then I have to recompile everythin !
[18:40] <omega_> nope
[18:40] <thomas> ah ok
[18:40] <thomas> autogen in the root ?
[18:40] <wtay> brb
[18:40] <omega_> you only have to recompile if you changed something config-wise
[18:41] <omega_> there are still cases where make isn't smart enough, autoconf doesn't help in that regard
[18:44] <thomas> omega_ : where is mad.h
[18:44] <omega_> in libmad
[18:44] <thomas> where can I get libmad ?
[18:44] <omega_> www.mars.org/home/rob/proj/mpeg/
[18:45] Action: thomas is off for some food
[18:45] <wtay> back
[18:47] <wtay> hmm, mad: 7.9 user, mp3parse/mpg123: 4.7 user
[18:48] <omega_> on athlon
[18:48] <wtay> yes
[18:48] <wtay> which should be fast with int math
[18:48] <omega_> depends
[18:48] <omega_> there are more factors than just int math
[18:48] <wtay> and mp3parse/mpg123 isn't the fastest combination either
[18:49] <omega_> what is?
[18:49] <wtay> omega_: true
[18:49] <wtay> lots of subbuffers/allocs etc...
[18:49] <wtay> splicing and copying etc..
[18:49] <omega_> right
[18:50] <omega_> try adding bytesperread=65536 or somesuch to disksrc
[18:51] <wtay> uhm mad segfaults...
[18:51] <wtay> and I know why...
[18:51] <omega_> yup, here too
[18:52] <wtay> I have to use a temp buffer and that one certainly isn't 64k :)
[18:52] <omega_> oops
[18:52] <omega_> http://www.mars.org/mailman/public/mad-dev/2001-February/000225.html
[18:52] <omega_> hadess isn't gonna like that
[18:53] <wtay> nope :(
[18:53] <omega_> though the project seems a little stillborn
[18:55] <wtay>  
[18:55] <wtay> Latest News
[18:55] <wtay> Still Alive, but brainstorming
[18:55] <wtay>     coplan - 2001-04-12 21:04
[18:55] <omega_> yup
[18:55] <wtay> it's more like for small embeded devices...
[18:56] <wtay> "It will feature support for VFD and LCD displays"
[18:56] <omega_> afaict they're create in effect a distrib for people to put on a floppy on a cheap old PC in their stereo
[18:56] <omega_> which everyone else and their dog has already done
[18:56] <wtay> hehe
[18:56] <omega_> woof!
[18:56] <wtay> :)
[18:57] <omega_> http://www.mars.org/mailman/public/mad-dev/2001-January/000183.html
[18:57] <omega_> see bottom
[18:57] <wtay> pff, now I need to realloc the mad temp buffer...
[18:57] <omega_> they aren't entirely happy with the API, which is a good thing
[18:57] <thomas> so when I installed mad...
[18:57] Action: omega_ signs onto the mad-dev list
[18:58] <thomas> ... do I need to recompile everything or just try it in mad dir ?
[18:58] <wtay> just the mad dir
[18:58] <omega_> just mad dir for now
[18:58] <wtay> omega_: looks like they need some kind of framework :)
[18:58] <thomas> did you also get the sfreq error ?
[18:59] <omega_> wtay: ya think?
[18:59] <wtay> thomas: nope, can you take a look at the header file and tell me what you have?
[18:59] <thomas> wtay: what header ? mad.h or gstmad.h ?
[18:59] <wtay> mad.h
[18:59] <omega_> mad.h
[19:00] <wtay> thomas: we can try to #define a way around version incompatibilities
[19:00] <thomas> what do you want to know from the header ?
[19:00] <omega_> I see unsigned int samplerate;
[19:00] <omega_> instead of sfreq
[19:00] <omega_> sfreq is an ISO-ism
[19:00] <thomas> me too
[19:01] <wtay> ok
[19:01] <omega_> lots of other header changes too
[19:01] <thomas> I got the latest version
[19:01] <omega_> ;-(
[19:01] <thomas> so what version should I've gotten ?
[19:01] <wtay> 0.12.5b
[19:01] Action: omega_ thinks that future mad versions will deviate *heavily*, so we need to have a compat layer in place soon
[19:01] <wtay> damn
[19:01] Action: thomas doesn't care at this point, he just wants to hear something good SOON
[19:02] <thomas> btw I do think that mpg123 needs checking then...
[19:02] <omega_> wtay: if we're going to make mad the ultimate decoder for gst, there will have to be changes
[19:02] <thomas> it really does sound as if buffer leftovers from previous frame are shared between instances of the plugin
[19:02] <wtay> thomas: it has thousands of other issues with mpg123
[19:02] <omega_> I can check into that
[19:02] <thomas> esp. since wtay you just said that if you turned off one channel you could still hear both
[19:02] <wtay> omega_: what changes?
[19:03] <wtay> thomas: yup, I suspect something like that too
[19:03] <wtay> mpg123 is a mess
[19:03] <thomas> wtay: and I seem to remember hearing close to the same thing the first time my thesis was "feature-complete"
[19:03] <wtay> it doesn't work in big endian machines either
[19:03] <thomas> I spent two weeks tracking down the error
[19:03] <wtay> thomas: and?
[19:04] <thomas> the error eventually lay in the fact that the ISO code used some sort of bitstream package...
[19:04] <thomas> which had some small errors...
[19:04] <thomas> and the fact that the iso code used one bitstream buffer...
[19:04] <wtay> thomas: hmm, we don't use that anymore
[19:04] <thomas> for the previous leftover frame data...
[19:04] <thomas> and it wrapped new similar bitstream functions around that...
[19:04] <wtay> thomas: that one should also be private to the instance...
[19:04] <thomas> so there were two sets of buffers and functions
[19:04] <thomas> ... and I only copied one of both...
[19:05] <thomas> I'm just conjecturing here of course
[19:05] <thomas> I wish any brave warrior treading his toes in that mire the best of luck
[19:05] <omega_> reference code from ISO/IEC is always crap
[19:05] <thomas> and they make you pay for the docs as well
[19:05] <omega_> I know of no exceptions
[19:06] <thomas> yes, well, getting paid kinda takes the edge off
[19:06] <thomas> plus they have to do meetings
[19:06] <omega_> awww..
[19:07] <thomas> tried making...
[19:07] <thomas> tmp/ccFEWhbF.i: No space left on device
[19:07] <thomas> guess I should clean my disks
[19:07] <omega_> um, yeah
[19:09] Action: thomas thinks gstreamer is BIG
[19:09] <thomas> ok mad compiled
[19:09] <omega_> the core is only about 15k lines right now
[19:09] <thomas> wtay: did you change the mixer example as well ?
[19:09] <thomas> omega_: yes, but there should be an easy way to only include audio only stuff
[19:09] <thomas> maybe a pre-compile option list
[19:09] <omega_> yeah
[19:10] <omega_> yup
[19:10] Action: thomas wonders where all the disks have gone
[19:11] Nick change: wtay -> wtay-eating
[19:11] <wtay-eating> thomas: yup, some cleanup, I couldn't resist :)
[19:11] <thomas> wtay: is it in CVS ?
[19:14] <omega_> fyi, mad is the *only* decoder to successfully do free format mp3;s
[19:18] <thomas> YEAH BABY !
[19:18] <thomas> wtay is right... mad works perfectly
[19:18] <thomas> a crystal clean mix
[19:18] <thomas> half a day wasted on a bug that wasn't mine
[19:19] <thomas> CPU time does fly up though ;(
[19:21] <omega_> oh?
[19:21] <thomas> meaning : constant but more than with mpg123
[19:21] <omega_> ok
[19:22] <omega_> what'd be cool would be to build mad on top of libcodec ;-)
[19:22] <thomas> what's libcodec ?
[19:22] <omega_> another project of mine
[19:22] <omega_> see codecs.org
[19:31] <thomas> I hadd a  sxs
[19:31] thomas (thomas at urgent.rug.ac.be) left irc: Leaving
[19:32] z- (dave at host213-122-140-14.btinternet.com) joined #gstreamer.
[19:34] Nick change: wtay-eating -> wtay
[19:34] <wtay> yo
[19:35] <z-> yo wtay
[19:35] Action: omega_ tracks a segfault in the merged code
[19:35] <omega_> ;-(
[19:36] <wtay> :(
[19:38] Action: wtay is going to try to make a padfactory macro
[19:39] thomas (thomas at urgent.rug.ac.be) joined #gstreamer.
[19:39] <thomas> sorry omega_
[19:39] <omega_> ?
[19:39] <thomas> adsl slowed down to a crawl
[19:39] <omega_> heh
[19:39] <thomas> I was trying to ask you something
[19:40] <wtay> sxs?
[19:40] <thomas> did that come through ?
[19:40] <thomas> heh...
[19:40] <omega_> nope
[19:40] <omega_> grrrr, something in incsched broke
[19:40] <thomas> So I had a wild idea two years ago which I was thinking on doing a master's thesis on
[19:40] <z-> heh
[19:40] Action: z- plays syndicate in bochs
[19:40] <thomas> and your libcodec reminded me of that
[19:40] <thomas> I wanted to do basically the same thing
[19:40] <omega_> up oh <g>
[19:40] <thomas> build a library of typical audio components
[19:40] <thomas> filter banks, stuff like that
[19:41] <omega_> libcodec is 100% video at the moment....
[19:41] <thomas> omega_: well I was thinking about audio
[19:41] <thomas> since a doctorate can be four years... 
[19:41] <thomas> I had all sorts of ideas
[19:41] <omega_> one thing is that the name libcodec implies that it's only for code-related stuff...
[19:41] <thomas> omega_ : you can rename it later on
[19:41] <omega_> might want to change the name to something else if it has all sorts of kernels
[19:42] <thomas> what I wanted was this :
[19:42] <thomas> since a lot of numerical algorithms aren't patented...
[19:42] <thomas> but the combination of them to make for example a real audio codec is
[19:42] <thomas> ...
[19:42] <omega_> yup
[19:42] <thomas> the idea was to make the algorithms and assign byte values or something
[19:42] <omega_> same idea behind libmpeg
[19:42] <thomas> then construct a working realaudio codec using a short string of bytes
[19:42] <omega_> oh, some kind of high-level algorithm plugger?
[19:42] <omega_> hehehe
[19:43] <thomas> it's easy to put the string of bytes on a t-shirt or whatever
[19:43] <omega_> hehehehe
[19:43] <thomas> so the distribution of the algorithm is legal
[19:43] <thomas> the key probably isn't
[19:43] <thomas> but can't be stopped
[19:43] <anthos> is Gstreamer in any way on FreeBSD?
[19:43] <thomas> then the next idea was :
[19:43] <thomas> would it be possible to get a higher level architecture
[19:43] <thomas> get a REAL encoder
[19:43] <omega_> anthos: I hear that cothreads and freebsd threads disagree with each other ;-(
[19:43] <wtay> anthos: some people reported problems with cothreads and user space threads
[19:43] <thomas> and try all sorts of combinations of building blocks
[19:44] <thomas> with an AI algorithm
[19:44] <thomas> and find the one that matches best
[19:44] <thomas> based on some clues
[19:44] <omega_> thomas: that could take a while... <g>
[19:44] <thomas> yeah I know
[19:44] <thomas> I was dreaming
[19:44] <thomas> plus there were four years
[19:44] <omega_> hah!
[19:44] <thomas> maybe it will be possible
[19:44] <wtay> thomas: genetic algotihms
[19:44] <thomas> depends on how you chose your signals I guess
[19:44] <z-> i can play mp3s with gstreamer-launch in freebsd
[19:44] <omega_> start simple, work you
[19:44] <thomas> wtay: yeah, that's what I was thinking
[19:44] <anthos> thanks peops ... maybe I should just jump to debian :)  I love FBSD though 
[19:44] <omega_> er, work up
[19:44] <z-> just i can't use gstmediaplay, for some reason
[19:44] <thomas> wtay: I actually got some studying done into that back then
[19:44] <omega_> anthos: try out the linuxthreads port, it might work
[19:45] <z-> the cothreads problem mysteriously disappeared heh
[19:45] <wtay> anthos: I think the kernel threads work
[19:45] <thomas> would be great if it worked though
[19:45] <wtay> omega_: echo :)
[19:49] <thomas> I changed volenv a bit... can I add it to CVS in an easy way ?
[19:49] <wtay> thomas: read my thesis about GAs? :)
[19:49] <omega_> wtay: we should decide who's gonna field questions at any given time, so we don't duplicate efforts <g>
[19:49] <thomas> wtay: not sure
[19:49] <thomas> wtay: I guess not
[19:49] <wtay> omega_: can you give the man CVS access..
[19:49] <anthos> ah .. linuxthreads port, then get gstreamer, and do my thing ... let's see
[19:49] <wtay> thomas: I doubt it :)
[19:49] <thomas> wtay: my best friend did work on it in a medical application
[19:49] <omega_> thomas: what's your sf user id?
[19:49] <thomas> sf ?
[19:49] <omega_> sourceforge
[19:49] <z-> anthos, i tried linuxthreads, but i think you have to recompile glib(libgthread) aswell
[19:49] <thomas> oops...
[19:49] <thomas> better get registered then...
[19:49] Action: thomas blushes
[19:49] <omega_> yup
[19:49] <wtay> thomas: I used GAs to solve AI problems (also medical related, proteins and stuff..)
[19:49] <omega_> you'll also have to get a new working copy once you have write access, and move your changed files across before you can commit
[19:49] <thomas> wtay: my friend did it for epileptic seizure analysis on brain scans
[19:49] <thomas> wtay: :)
[19:49] _gst_newt_ joined #gstreamer.
[19:49] <z-> yeh
[19:49] <wtay> ahah
[19:49] <z-> anthos, i havent tried yet, but when i just linked gstmediaplay against linuxthreads it didnt work...
[19:50] <anthos> I see ... this isn't life and death though ... just would be nice to check this out ...
[19:50] <z-> hehe :)
[19:51] thomas (thomas at urgent.rug.ac.be) left irc: I'm outta here!
[19:51] <omega_> it would be good if someone can figure out what in cothreads is failing with freebsd threads, so we can fix cothreads.[ch]
[19:51] <z-> omega_, it stopped randomly segfaulting in the cothreads routines
[19:51] <z-> er
[19:51] <omega_> sounds right
[19:52] <z-> except when i play avis
[19:52] <z-> it gives some error about longjmp()ing between thread contexts
[19:52] thomas (thomas at urgent.rug.ac.be) joined #gstreamer.
[19:52] <omega_> odd
[19:52] <thomas> omega_: my sf user name is thomasvs
[19:53] <omega_> done
[19:53] <thomas> wtay: do you also get this : ** CRITICAL **: file adder.c: line 234 (plugin_init): assertion `plugin != NULL' failed ?
[19:53] <thomas> when you run the mixer ?
[19:53] <thomas> hmmm... didn't get that before
[19:54] <wtay> thomas: that's because you renamed to old plugin dir.. 
[19:54] <wtay> thomas: it still finds the old plugin with the same name
[19:55] Action: wtay is working on his clairvoyant skils
[19:55] Action: thomas should try to be less obvious about cleaning habits
[19:56] <omega_> http://cvs.sourceforge.net/cgi-bin/cvsweb.cgi/Fresco/contrib/cothreads-1.0.1/src/co.c?rev=1.1.1.1&content-type=text/x-cvsweb-markup&cvsroot=berlin
[19:56] <wtay> ooh
[19:58] <omega_> implements a complete threading library, which is OK, but that's what pthreads are for
[19:58] <thomas> omega_ : so I should first move all my changes OUT of the tree, then CVS-update my tree, then put my changes back in ?
[19:58] <omega_> not sure if it's at all pthread-safe either
[19:58] <omega_> nope, you need a completely new working copy
[19:58] <wtay> thomas: follow the instruction on the sf page
[19:58] <thomas> so how does a regular CVS user handle his /usr/local/src dir ?
[19:58] <thomas> wtay: ok I'll check
[19:58] <omega_> um
[19:59] <omega_> examples/autoplug is creating a toplevel bin, not a toplevel pipeline
[19:59] <omega_> we need to have a better check against that somehow
[19:59] <wtay> omega_:  is that not permitted?
[19:59] <omega_> now it faults somewhere else
[19:59] <omega_> no, because a Bin doesn't have a scheduler
[20:00] <wtay> oh
[20:00] <wtay> hmm
[20:00] <wtay> so gstpipeline got some functionality now :)
[20:00] <omega_> yup
[20:00] <omega_> well, sorta
[20:01] <omega_> the *only* change is that it creates a scheduler object and stores it
[20:01] Action: omega_ loves inheritance and polymorphism
[20:01] <wtay> gstmediaplay doesn't do that either...
[20:01] <omega_> all other changes are to the Bin
[20:01] <omega_> oops
[20:01] <wtay> use the pipeline I mean..
[20:01] <wtay> hmm, and the examples...
[20:01] <omega_> grrr
[20:01] Action: thomas is reading the CVS FAQ and wondering if he should get involved in all of that
[20:02] <omega_> hehee
[20:02] <anthos> z-: hey ... I did a default ./configure, and gmake 
[20:03] <wtay> thomas: just follow the gstreamer CVS page
[20:03] <z-> anthos, and ?
[20:03] <thomas> omega_: I tried ssh'ing into cvs.gstreamer.sourceforge.net, according to the FAQ...
[20:03] <thomas> ... but do I need a password ?
[20:03] <omega_> examples/autoplug doesn't use xvideosink?
[20:03] <wtay> http://sourceforge.net/cvs/?group_id=1936
[20:03] <anthos> and gstreamer-0.1.1 stopped because it can't find byteswap.h ... ever had that happen?
[20:03] <wtay> omega_: current CVS does
[20:03] <z-> yeh...try checking out CVS
[20:03] <omega_> I should have current CVS....
[20:04] <wtay> omega_: as of Date:	16 Apr 2001 09:34:16 -0700
[20:04] <omega_> um, yeah
[20:05] <wtay> checking...
[20:05] <omega_> it does
[20:05] <omega_> that means I have to figure out the sanest way to remerge
[20:06] <thomas> wtay: I can check out without password...
[20:06] <thomas> wtay: but checking in should require one, no ?
[20:06] <omega_> have you set up to do ssh with agent stuff?
[20:07] <thomas> as in export CVS_RSH ? yes.
[20:07] <wtay> thomas: hum..
[20:08] Action: thomas is going to eat something first before burning his hands on CVS
[20:13] Action: thomas is away - Automatically set away. - messages will be saved.
[20:21] <z-> hm
[20:21] <z-> should cothreads be switching between pthread contexts?
[20:21] <wtay> z-: never
[20:21] <z-> that's what it appears to be doing...
[20:21] <z-> > gstreamer-launch disksrc location=heh.avi ! avidecoder
[20:22] <z-> Fatal error 'longjmp()ing between thread contexts is undefined by POSIX 1003.1' at line ? in file /usr/src/lib/libc_r/uthread/uthread_jmp.c (errno = ?)
[20:22] <z-> gah :)
[20:22] <omega_> there aren't any threads in that pipeline anyway..... hmmm
[20:22] <z-> perhaps longjmp is broken
[20:23] <wtay> z-: it doesn't happen here...
[20:23] <wtay> z-: does it also happen with mpeg1?
[20:23] <z-> i havent tried...
[20:23] <wtay> avidec is kinda evil...
[20:23] <z-> i dont have any mpegs handy
[20:24] <wtay> gstreamer.net/media/AlienSong.mpg
[20:24] <z-> ah, cool
[20:24] <wtay> I think
[20:25] <z-> yup
[20:25] Action: z- goes to find something to eat while it downloads
[20:30] hadess (hadess at pc213-gui2.cable.ntl.com) joined #gstreamer.
[20:30] <wtay> yo
[20:30] <hadess> yo wtay
[20:31] hadess (hadess at pc213-gui2.cable.ntl.com) left irc: mooooh!
[20:32] hadess (hadess at pc213-gui2.cable.ntl.com) joined #gstreamer.
[20:32] <z-> wtay, what's the plugin to decode an mpg?
[20:32] <omega_> http://www.mars.org/mailman/public/mad-dev/2001-January/000183.html
[20:32] <hadess> there is more than one
[20:32] <wtay> mad or mp3parse/mpg123
[20:33] <hadess> omega_: what is that 
[20:33] <omega_> read it
[20:33] <z-> video i mean
[20:33] <omega_> mpeg_play
[20:33] <z-> thx
[20:34] <wtay> GST_PADTEMPLATE_FACTORY (testcaps,
[20:34] <wtay>   "src",
[20:34] <wtay>   GST_PAD_SRC,
[20:34] <wtay>   GST_PAD_ALWAYS,
[20:34] <wtay>   GST_CAPS_NEW (
[20:34] <wtay>     "mycaps",
[20:34] <hadess> omega_: you want to dive in, don't you =)
[20:34] <wtay>     "audio/raw",
[20:34] <wtay>       "format", GST_PROPS_INT (55),
[20:34] <wtay>       "foo",    GST_PROPS_STRING ("bar")
[20:34] <wtay>   ),
[20:34] <wtay>   GST_CAPS_NEW (
[20:34] <wtay>     "mycaps2",
[20:34] <wtay>     "audio/float",
[20:34] <wtay>       "format", GST_PROPS_INT (7),
[20:34] <wtay>       "baz",    GST_PROPS_STRING ("toe")
[20:34] <wtay>   )
[20:34] <wtay> );
[20:34] <omega_> hadess: huh?
[20:35] <wtay> omega_: show him the right link :)
[20:35] <hadess> omega_: gstreamer is the kinda stuff they're looking for, isn't it ?
[20:35] <omega_> oh
[20:35] <omega_> yes
[20:36] <hadess> wtay: what is the right link ?
[20:36] <omega_> http://www.mars.org/mailman/public/mad-dev/2001-February/000225.html
[20:36] <hadess> FUCK !!!!!!!!
[20:37] <wtay> omega_: is that acceptable for a padtemplate factory definition?
[20:37] <omega_> EAGAIN
[20:37] <omega_> wtay: yeah, that's roughly what we had before, and a lot cleaner than what we have now
[20:38] <wtay> omega_: it translates to a static GstPadtemplate* with code to generate a template if it's NULL...
[20:38] <omega_> cool
[20:39] <omega_> wow.
[20:39] <omega_> see gst-dev
[20:39] <wtay> should I add #define GST_PADTEMPLATE_GET(fact) (fact)() 
[20:39] <omega_> huh?
[20:39] <z-> mpeg_play: This is not an MPEG video stream. (000001ba)
[20:39] <wtay> whoohoo
[20:39] <omega_> you have to run it through the program stream decoder first to get just the video stream
[20:40] <z-> hm ok
[20:40] Action: z- is a total newbie
[20:40] <wtay> cool
[20:40] <wtay> LGPL rules!
[20:40] Action: wtay ducks
[20:40] <omega_> eh?
[20:41] <wtay> 3ivx
[20:41] <omega_> is it lgpl'd?
[20:41] <wtay> better than nothing...
[20:41] <wtay> nope but since gst is they can do this
[20:41] <omega_> ah
[20:42] Action: omega_ hasn't heard a peep from hadess since he looked at that mail
[20:42] Action: thomas is back and has 22 minutes left before gf starts complaining
[20:42] <hadess> omega_: i'm mailing the guys
[20:42] <wtay> heh
[20:42] <hadess> omega_: well, trying to, evo doesn't me to write emails today it seems :/
[20:42] <thomas> omega_: I checked out cvs code... should I put in my changes now ?
[20:43] Action: omega_ is trying to make sense of all the debug output from autoplug
[20:43] <omega_> thomas: yes, move your changes over, then commit
[20:43] <wtay> thomas: yup
[20:43] Action: omega_ had an idea:
[20:43] <z-> what should the commandline look like for playing mpgs?
[20:43] <wtay> thomas: you should subscribe to gstreamer-cvs if you didn't do that yet..
[20:43] <thomas> omega_: you're sure I can't do anything terribly wrong later on ?
[20:43] <omega_> what kind of mpegs?
[20:43] <z-> or just testing playback
[20:44] <wtay> z-: can't do it from the command line
[20:44] <omega_> thomas: depends on which files you touch
[20:44] <omega_> z-: the -launch syntax isn't sufficient yet
[20:44] <z-> not even in an xterm?
[20:44] <z-> omega_, like AlienSong.mpg :)
[20:44] <z-> oh ok
[20:44] <omega_> -launch can't do it
[20:44] <omega_> if you have any ideas on syntax improvements for -launch, send them to the list, there are plenty to be made
[20:45] <omega_> the problem is that the stream parser doesn't create output pads until data is flowing
[20:45] <wtay> thomas: you can screw everything up now.. just don't do it :)
[20:45] <thomas> wtay: ok, just changing the volenv then
[20:46] <wtay> thomas: we always have everything nicely versioned so don't worry
[20:46] <thomas> wtay: ... said he before a new user inadvertently found the command to clear out the whole cvs database by accident
[20:47] <omega_> <g>
[20:47] <wtay> heehe
[20:48] <thomas> wtay: did you change stuff in the adder plugin ?
[20:48] <thomas> wtay: because I don't intend to keep it anyway ;)
[20:48] <thomas> wtay: the plugin I mean, not your changes
[20:48] <wtay> thomas: just moved some code around
[20:48] <wtay> thomas: throw away whatever you don't like
[20:49] <thomas> wtay: then I'll have to re-do it...
[20:49] <thomas> hmmm...
[20:49] <thomas> i'll keep yours, your changes are bound to be more useful ;)
[20:50] <thomas> ok... so I only changed volenv
[20:50] <thomas> how do I put it in ?
[20:50] <wtay> cvs commit in the volenv dir
[20:51] <wtay> or cvs commit volenv.c if you only want to commit that file
[20:51] <wtay> generally cvs commit would do
[20:51] <thomas> wtay: great, now it opens vi ! Now I have to admit to all of you that I actually use pico !
[20:51] <omega_> hah, a kindred spirit!
[20:51] <hadess> i sent a message to the guys @ soundbox
[20:51] <wtay> thomas: join the club
[20:52] <omega_> hadess: what kind of message?
[20:52] Action: thomas thought it was forbidden to use pico in programming ;)
[20:52] <wtay> pff pico users reunion
[20:52] <thomas> so can I quit safely ?
[20:52] <thomas> and set my visual ?
[20:52] <omega_> visual? you mean EDITOR ?
[20:52] <thomas> yeah.
[20:52] <omega_> hit 'dd'
[20:52] <hadess> omega_: neat
[20:52] <omega_> then 'ESC :q<enter>'
[20:52] <omega_> hadess: huh?
[20:53] <hadess> omega_: asking them if they could change their name as their project is still in planning
[20:53] <omega_> thomas: that should cause the commit to fail
[20:53] <omega_> heh
[20:53] <hadess> omega_: otherwise there will be 2 sounbox projects
[20:53] <omega_> quite
[20:53] <thomas> omega_: dd deletes lines and ESC :q tells me "No write since last change"
[20:54] <thomas> can't I just ctrl-c it ?
[20:54] <omega_> :q!
[20:54] <omega_> er
[20:54] <omega_> :wq!
[20:54] <z-> dont u want :wq
[20:54] <omega_> yeah, if cvs see no lines except CVS:, it will abort
[20:54] <thomas> ok, commit aborted
[20:54] <omega_> then setenv EDITOR=pico in .bashrc or somesuch, rerun
[20:54] <thomas> ok... what should I put in the file ?
[20:54] <wtay> thomas: no vi knowledge at all?
[20:55] <thomas> yes, I know how to exit.
[20:55] <wtay> ok
[20:55] <omega_> in the commit log? an explanation of what the change is all about
[20:55] <thomas> I just don't know how that affects CVS
[20:55] <thomas> omega_: so just put my comments underneath the whole standard box ?
[20:55] <thomas> wtay: I also learned how to delete lines recently
[20:55] <omega_> above or below,  yeah
[20:55] <omega_> thomas: hehehehe
[20:56] <omega_> I just start typing, it gives you a blank line to start with
[20:56] <omega_> hence the 'dd' in vi before quitting
[20:56] <wtay> vi is K001
[20:56] <thomas> cvs [server aborted]: "commit" requires write access to the repository
[20:56] <wtay> :q! actually works too
[20:56] <hadess> vi is l33t
[20:57] <thomas> are you sure I don't need a password ?
[20:57] <wtay> thomas: you did check out with your userid, did you?
[20:57] <omega_> it depends on if you set up ssh to need a password or not
[20:57] Action: thomas is puzzled.
[20:57] <omega_>  -d thomasvs at cvs.gstreamer.sourceforge.net:/cvsroot/gstreamer ?
[20:57] <wtay> thomas: did you copy the CVS dir too?
[20:57] <omega_> http://gstreamer.net/guadec-pics2/dscn0024.jpg
[20:57] <thomas> okay, one thing at a time.  I tried following the CVS FAQ...
[20:58] <thomas> ... the first thing it told me was that I should first have shell access to cvs.gstreamer.sourceforge.net
[20:58] <omega_> well, sorta
[20:58] <thomas> I tried ssh-ing but of course it needs a password
[20:58] <omega_> which is your login password
[20:58] <thomas> ... so I checked out anonymously
[20:58] <omega_> nope
[20:58] <omega_> you *must* log in to check out a working copy under your name in order to commit
[20:59] <thomas> omega_: what do you mean by "which is your login password" ?
[20:59] <omega_> ignore the CVS FAQ, just follow the instructions on the gstreamer CVS page
[20:59] <omega_> your sourceforge password
[21:00] <wtay> thomas: the CVS FAQ is way too complicated...
[21:00] Action: thomas is retrying
[21:00] Action: thomas is also warned by his girlfriend that there are about 8 mins left
[21:02] <thomas> ok, got it ! you should first ssh in, give your sf password, then you can check out
[21:02] <thomas> ok, changing now
[21:02] <omega_> did you set your CVS_RSH to ssh ?
[21:02] <wtay> thomas: uhm?
[21:02] <thomas> yeah
[21:02] <thomas> If you don't ssh in first, you don't have a home dir there.
[21:02] <omega_> huh?
[21:02] <thomas> But I'm guessing you all don't know that (anymore) since you've been on sf for ages, no ?
[21:03] <omega_> I suppose
[21:03] anthos (anthos at n50-c209-c149-c55.bs.xlate.ufl.edu) left #gstreamer (Client Exiting).
[21:04] <thomas> ok, committed.
[21:04] <thomas> thanks for teaching me the ropes !
[21:04] <omega_> just don't hang yourself with them <g>
[21:04] <thomas> heh
[21:04] <thomas> so do you need a full download each time you want to commit ?
[21:04] <thomas> or is that just the first time ?
[21:05] <omega_> no
[21:05] <omega_> CVS is incremental
[21:05] <omega_> once you have a proper working copy, everything is fast
[21:05] <thomas> so does everyone keep a personal devel tree and a CVS tree on their machine ?
[21:05] <wtay> I work in the CVS tree
[21:05] <omega_> you always work in the working copy, hence the name ;-)
[21:06] <omega_> though I have about a half-dozen different working copies on different branches and such
[21:06] <wtay> I occasionally check out other branches/copies as a reference
[21:06] <thomas> so how do you organize them all ?
[21:06] <omega_> gst.*
[21:06] <wtay> I check out and rename to gstreamer-HEAD/gstreamer-INCSCHED1 etc...
[21:07] <omega_> I use gst.incsched1, etc.
[21:07] <thomas> and am I stupid for putting them in /usr/local/src ? ;)
[21:07] <omega_> probably <g>
[21:07] <omega_> I have ~/work/gstreamer/gst.*
[21:07] <omega_> with symlinks at ~/gst.* for commonly used branches
[21:07] <wtay> I have /opt/src/sourceforge/*
[21:08] <thomas> so now I suppose if I check it out at work...
[21:08] <thomas> ... and check back in before I go home...
[21:08] <wtay> I prefer to leave /usr untouched
[21:08] <thomas> ... I can check back out at home and keep working ?
[21:08] <omega_> yup
[21:08] <wtay> sure
[21:08] <omega_> that's the whole idea, whether you're one person with two copies or two people with one each
[21:08] <thomas> great.  I was wondering how I was going to get it to work tomorrow.
[21:09] <omega_> just remember not to use HEAD as a dumping ground, since that's what everyone grabs
[21:09] <thomas> I once printed the whole CVS guide and then decided it wasn't worth the effort when I learned how difficult it was to move files accross directories ;)
[21:09] <omega_> if you have something in progress on one machine and need to work on it from another, use another means of bringing it between copies
[21:09] <thomas> omega_: what does that mean : use HEAD as dumping ground ?
[21:09] <omega_> when you check out without extra options, you get the HEAD branch
[21:10] <thomas> omega_: I'd just tar.gz my differences, I'm ashamed already my plugins are in CVS for all to see.
[21:10] <omega_> that should compile the majority of the time, so don't commit non-compiling stuff unless you're going to fix in a few minutes later
[21:10] <hadess> i hate CVS...
[21:10] <thomas> how many branches are there then ?
[21:10] <omega_> thomas: just make sure you don't overwrite your local changes in each copy when you do that
[21:10] <omega_> and don't include the CVS/ directory from your copy in that tarball
[21:10] <omega_> right now there are three
[21:10] <omega_> INCSCHED1, AUTOPLUG1, and CAPSNEGO1
[21:11] <omega_> only INCSCHED1 is live, the other two are 'finished'
[21:11] <omega_> and INCSCHED1 should be finished today or tomorrow, depending on how long it takes for me to fix the current issues
[21:14] <omega_> DEBUG(11774:2)gst_pad_renegotiate:1162: pads aggreed on caps :)
[21:14] <omega_> um, sure <g>
[21:14] <wtay> not?
[21:14] <omega_> ;-)
[21:14] <omega_> er, ':)'
[21:14] <wtay> hehehe
[21:14] <omega_> and here's an interesting problem....
[21:15] <omega_> in bin_iterate of a pipeline..
[21:15] <omega_> mpeg1parse gets a new audio stream, I respond to the new_pad signal by pausing the pipeline and adding the mp3parse element
[21:15] <wtay> ?
[21:15] <omega_> as soon as that finishes, it pops back into bin_iterate and finishes a complete iteration
[21:15] <omega_> that's a problem
[21:16] <omega_> we need to a) halt the current iteration somehow, and b) have a better API than just the true/false return from bin_iterate()
[21:16] <wtay> hmm
[21:16] <thomas> one more CVS question: if you build gstreamer in your downloaded CVS dir, and you would commit, then you would upload your binaries as well I suppose... so it's not a good idea to build your CVS tree then ?
[21:17] <wtay> thomas: nope
[21:17] <wtay> thomas: only files added with cvs add are versioned 
[21:17] <thomas> wtay: so you actually build in your current CVS tree ?
[21:17] <omega_> yes
[21:17] <wtay> sure
[21:18] <wtay> when you add a file locally you'll have to manually do cvs add to get them into cvs
[21:18] <thomas> ok...
[21:18] <wtay> als .cvsignore contains files that CVS will not try to version
[21:18] <wtay> s/als/also
[21:19] <thomas> wtay: about the input buffers not being equally large...
[21:19] <thomas> wtay: ... that seems to be a difficult problem when I think about it.
[21:19] Nick change: omega_ -> omega-lunch
[21:19] <wtay> ?
[21:19] <thomas> wtay: did someone already try something like it in gstreamer ?
[21:19] <wtay> nope
[21:20] <thomas> wtay: then I won't start today...
[21:20] <thomas> wtay: clean up some of the mixing example ...
[21:20] <thomas> wtay: and call it a day
[21:20] <wtay> ok
[21:20] <thomas> wtay: does it make sense to write a readme for the mixer example and the volenv ?
[21:20] <thomas> wtay: I should also check the volume filter that's there already...
[21:20] <wtay> if you want to, sure
[21:20] <thomas> wtay: and see if it's similar
[21:21] <thomas> wtay: cause volenv isn't a good name for it
[21:21] <wtay> thomas: true, and so is adder
[21:21] <thomas> wtay: adder wasn't meant to go in cvs ;) I didn't want to call it mixer because it's not yet.
[21:22] <wtay> wtay: sorry 'about that :)
[21:22] <thomas> wtay: all the more reason to get it finished
[21:23] <wtay> yeah
[21:30] sienap (synap at ipc379c047.dial.wxs.nl) joined #gstreamer.
[21:30] <sienap> boe
[21:30] <sienap> hi all :)
[21:30] <thomas> hi sienap
[21:30] <sienap> hej thomas!
[21:30] <sienap> how is stuff going ?
[21:30] <sienap> rdj awake ??
[21:31] <hadess> hey sienap
[21:31] <sienap> hej hadess!
[21:31] <wtay> hi sienap
[21:32] <sienap> wtay!
[21:32] <sienap> someone done today?
[21:33] <wtay> sienap: you should subscribe to gstreamer-cvs :)
[21:34] <thomas> ok... I committed a cleaner adder and a nicer mixer envelop
[21:34] <thomas> someone want to test it ?
[21:34] <wtay> I am :)
[21:34] <thomas> wtay: btw how can I test the case where one of the buffers has a different length ?
[21:34] <thomas> wtay: boy I got my work cut out...
[21:35] <wtay> thomas: try an mpeg layer2 and a layer3 song...
[21:35] <thomas> wtay: ok, that's for tomorrow...
[21:35] <thomas> wtay: thanks for the mad, it saved my day
[21:35] <thomas> wtay: I was getting frustrated
[21:35] <sienap> wtay he :)
[21:36] z- (dave at host213-122-140-14.btinternet.com) left irc: .
[21:36] <thomas> is someone here tomorrow during the day ?
[21:36] <wtay> hehe
[21:36] <wtay> not me
[21:36] <thomas> btw can you register plugins when you're not root ?
[21:37] <wtay> thomas: only when you added a flag to configure
[21:37] <thomas> wtay: I'll try some other day.  have to go.
[21:37] <thomas> bye everyone and thanks for the help
[21:37] thomas (thomas at urgent.rug.ac.be) left irc: I'm outta here!
[21:39] sienap (synap at ipc379c047.dial.wxs.nl) left irc: sienap has no reason
[21:51] Nick change: omega-lunch -> omega_
[21:52] <omega_> so wtay, any ideas on the state change issue?
[21:53] <wtay> hmm, rereading
[21:53] <wtay> oh yes, the halt problem
[21:53] <omega_> strictly speaking it's kindof irrelevant
[21:53] <omega_> because as long as you go back to PLAYING before dropping out of the signal handler, no one notices
[21:53] <wtay> you should
[21:53] <omega_> the only thing that matters is that threads in the pipeline pause and restart during he change
[21:54] <wtay> what exactly is the problem with going to PAUSE, add, go to PLAYING?
[21:55] <omega_> nothing, but if you PAUSE during a handler and want to stay PAUSED, you've got a problem
[21:55] <wtay> oh
[21:55] <wtay> why?
[21:56] <omega_> because as soon as you return from the handler, you go right back into the middle of an iterate(), which has no idea the state has changed
[21:56] <omega_> so it finishes the iteration
[21:56] <wtay> true
[21:57] <wtay> should we wait until the iteration is finished before we proceed?
[21:57] <omega_> proceed with what?
[21:57] <wtay> with the pipeline modification
[21:57] <omega_> how?
[21:58] <wtay> hmm, can't be done
[21:58] <wtay> problems only arise on a push/pull, right?
[21:59] <omega_> huh?
[21:59] <omega_> probably
[21:59] <omega_> but I'm not about to add another check to push_pull....
[22:00] <wtay> in the dynamic pad case, suppose the mew_pad handler doesn't set the pipeline back to PLAYING...
[22:00] <wtay> s/mew/new
[22:00] <wtay> when the handler returns, the mpeg1 parse will try to push a buffer out of its src pad...
[22:00] <omega_> it'll finish with that iteration of the pipeline, which could mean creating a new video_ pad
[22:01] <omega_> that too, yeah
[22:01] <wtay> so the PAUSE state will not occur immediatly..
[22:01] <omega_> right
[22:01] <omega_> but...
[22:01] <wtay> only after that final iteration
[22:01] <omega_> the elements will already be PAUSED, which could seriously confuse them
[22:02] <wtay> yup
[22:02] <omega_> one option would be to somewhere do a cothread_switch(0)
[22:02] <omega_> just like in the thread interrupt case
[22:03] <wtay> you mean, kill the plugin?
[22:03] <wtay> you'll never return to that cothread
[22:03] <omega_> no, just switch out of it and let the iterator halt mid-iteration
[22:03] <omega_> why?
[22:03] <omega_> an element never gets killed, it just never gets switched back into
[22:03] <wtay> if you then go to NULL, the stack frame is never reactivated, right?
[22:03] <omega_> but that's not relevant here anyway
[22:04] <wtay> ok
[22:04] <omega_> right
[22:04] <wtay> that's also a check in push/pull
[22:04] <omega_> here, you assume that PLAYING is the next state, which the iterator just switches back to where it was interrupted at
[22:04] <omega_> check for what?
[22:04] <wtay> for the state?
[22:04] <omega_> nope
[22:05] <omega_> why would you want to do that?
[22:05] <wtay> how are you going to decide you'll never switch to the stack frame then?
[22:05] <omega_> huh?
[22:05] <wtay> ok...
[22:06] <wtay> you say: on the next push/pull, we do a cothread switch to somewhere else (assuming the pause state)
[22:06] <omega_> brb
[22:06] <wtay> where are you going to switch to?
[22:20] <omega_> cothread 0
[22:20] <wtay> what's cothread 0?
[22:20] <omega_> the iterate() function
[22:20] <omega_> as always
[22:21] <wtay> cool
[22:21] <omega_> this does put some restrictions on the scheduler, in that it always has to use cothreads
[22:21] <omega_> though it could use pthreads too
[22:21] <wtay> yes
[22:21] <omega_> sorta
[22:21] <wtay> can it still use chains were appropriate?
[22:21] <omega_> yes
[22:21] <omega_> but there would always be two cothreads at least
[22:22] <omega_> iterate() and the chained elements
[22:22] <wtay> ok
[22:23] <wtay> in tha pause state, the interate() would just wait then?
[22:24] <omega_> no, it would return
[22:24] <omega_> it can't wait, since it doesn't own the context
[22:24] <wtay> ah, hence the return value...
[22:25] <omega_> right
[22:25] Action: wtay is slowly getting it..
[22:26] <wtay> so how do you decide to switch to cothread 0?
[22:26] <omega_> that's the problem
[22:27] <wtay> right
[22:27] <wtay> you'll need a check in the push/pull handler...
[22:28] <omega_> not necessarily
[22:28] <omega_> this is only an issue in signal handlers that change the state, but the switch has to be done at the end of the signal handler
[22:28] <omega_> so perhaps a wrapper around emit()
[22:29] <wtay> uhm
[22:29] <wtay> you'll set a flag then at the end of the emit() when the state has changed?
[22:30] <wtay> uhm, or just do the switch altogether..
[22:30] <omega_> no, right after gtk_signal_emit, check for pending_state != NONE
[22:31] <wtay> and if it isn't, switch to cothread 0
[22:31] <omega_> yup
[22:31] <wtay> pretty cool
[22:31] <wtay> have to make sure only signals can be fires from the plugin
[22:31] <wtay> s/fires/fired
[22:32] <omega_> eh?
[22:32] <wtay> like callbacks...
[22:32] <omega_> hmmm
[22:32] <omega_> ick
[22:33] <wtay> not allowed
[22:34] <omega_> hmmmm
[22:34] <wtay> hmm, is the stack frame of the plugin ever going to be reactivated in case of a state change?
[22:34] <omega_> depends on the next state change
[22:34] <wtay> in case of NULL it won't, with a possible leak...
[22:35] <wtay> depending on what the plugin does after the push/pull
[22:35] <omega_> remember, the rule is that a filter should always store volatile (allocated) stuff in the object, not on the stack
[22:36] <wtay> in the case of a buffer pull, the buffer won't be unreffed
[22:36] <omega_> hmmmm
[22:36] <wtay> uhm, but then again the pull won't do anything...
[22:36] <omega_> when?
[22:37] <wtay> when the signal is emited after the plugin did a pull, the buffer won't be unreffed if the app changes the state to NULL
[22:38] <omega_> right
[22:38] <wtay> when the buffer is about to push a buffer, a signal is fired before the push,  the buffer is unreffed
[22:39] <omega_> then maybe the buffer pointer needs to be stored in the object, and freed during change_state ?
[22:39] <wtay> first buffer = plugin
[22:39] <wtay> or maybe the buffer can be unreffed from the bufpen
[22:40] <omega_> how?
[22:40] <wtay> hmm yeah
[22:40] <wtay> it's not even in the bufen
[22:41] <wtay> a clear rule would be the order of the day: no signals after allocated data on the stack..
[22:42] <omega_> rather, no signals while data is 'live'
[22:42] <wtay> no signal when only an pointer on the stack has a reference to the allocated data
[22:43] <omega_> right
[22:44] <wtay> I can live with that
[22:44] <wtay> I like the switch to cothread 0 and the emit wrapper
[22:44] <omega_> I wonder if there's some fundamental change we can make to avoid all these checks ?
[22:45] <wtay> which checks? you mean in the emit wrapper?
[22:45] <omega_> yeah, and others
[22:45] <omega_> things are getting a little hackish
[22:46] <wtay> well, you're trying to break out of runnin code after all...
[22:46] <omega_> right...
[22:46] <omega_> but are we trying to hold onto some fundamental assumption that isn't really relevant, and if dropped could save a lot of this hassle?
[22:47] <wtay> we assume signals must be real time..
[22:47] <wtay> we assume a state change is real-time
[22:47] <omega_> but that's how they are with g[tk]object, so...
[22:48] <omega_> what would change if we didn't assume a state change was immediate?
[22:48] <wtay> you could also queue them and emit them when out of the plugin code...
[22:48] <omega_> what about the mpeg1parse case...
[22:48] <omega_> what if you really have a good reason to create the audio pipeline before video ?
[22:49] <wtay> I think signals should be real time
[22:49] <omega_> ditto
[22:49] <omega_> the advantage to doing everything synchronously is that we avoid a lot of syncronization work
[22:49] <wtay> they typically occur right before the element is about to push a buffer and you really want to make a connection to that pad first
[22:49] <omega_> obviously at the expense of other complexities
[22:50] <omega_> that too
[22:50] <wtay> if the state change is not immediate, lag could occur
[22:50] <omega_> right
[22:51] <wtay> which is not good either IMO
[22:51] <omega_> yup
[22:51] <omega_> well, pipeline changes have to be made at certain points, otherwise a lot of applications will be impossible
[22:52] <wtay> this would also imply that a state change blocks until really done..
[22:52] <omega_> yes
[22:53] <wtay> suppose the following:
[22:53] <wtay> I have a plugin that signals right before pushing a buffer
[22:54] <wtay> I catch the signal, disconnect the pad and set the state to NULL
[22:54] <wtay> the state change has to be immediate
[22:55] <wtay> which means cothread_switch(0) in the emit wrapper...
[22:55] <omega_> right
[22:55] <omega_> NULL ?
[22:56] <wtay> for examlpe
[22:56] <omega_> set what to NULL?
[22:56] <wtay> the bin?
[22:57] <omega_> that's not a very interesting case
[22:57] <omega_> the interesting case is where you get the signal, set to PAUSED, disconnect the peer, connect a new one, and restart
[22:58] <wtay> uhm
[22:58] <omega_> hmm, and the post emit() check isn't for pending != NONE, it's for state != PLAYING
[22:58] <wtay> I was thinking about how a non immediate state change would break stuff
[22:58] <omega_> hmmm
[22:58] <omega_> well, the above case is a perfect example of that
[22:59] <wtay> also yes
[23:00] <wtay> state != PLAYING... you assume signals are only emited in the PLAYING state
[23:01] <omega_> the element code only runs in PLAYING, so yes
[23:01] <omega_> well...
[23:01] <omega_> hmm
[23:01] <wtay> what about a plugin that has a timer and fires something when ready?
[23:01] <omega_> I guess we need a better handle on where someone might fire a state chang
[23:01] <omega_> timer?
[23:02] <wtay> like a cdsrc element that fires a signal when a disk is inserted?
[23:02] <omega_> hmmm, that's a different problem
[23:02] <wtay> in the handler you change the state to playing..
[23:02] <wtay> ok
[23:02] <omega_> I think the app is gonna be responsible for that insert notification
[23:03] <wtay> hmm, yeah and the plugin won't be in a cothread loop enyway...
[23:03] <omega_> but there are other places where state change could happen...
[23:03] <omega_> we need more use cases
[23:03] <wtay> in the caps nego...
[23:04] <wtay> let's assume the mpeg1parse...
[23:05] <wtay> it fires a signal (in the plugin loop) when a new pad is created...
[23:05] <wtay> the handler doesn't set the state back to playing...
[23:05] <omega_> what state does it set it to? PAUSED ?
[23:06] <wtay> does it matter?
[23:06] <omega_> I suppose not
[23:06] <wtay> I don't think so...
[23:06] <wtay> let's assume PAUSE first
[23:07] <omega_> ok
[23:07] <wtay> the emit wrapper detects it's not in PLAYING anymore and does cothread switch 0
[23:07] <wtay> the _iterate function returns GST_BIN_PAUSED
[23:07] <wtay> or GST_ITERATE_PAUSED
[23:08] <omega_> or GST_ITERATE_READY, but only if we don't swap PLAYING and PAUSED
[23:08] <wtay> we should swap them
[23:09] <omega_> agreed
[23:09] <omega_> so only one transition is relevant: to/from PLAYING
[23:09] <wtay> on a state change to playin, the bin does the cothread switch to where it left off
[23:09] <omega_> that should simplify a lot of things
[23:09] <omega_> though then I have to rework the thread interlock code again
[23:09] <wtay> hmm
[23:11] <wtay> assume we go to the READY state...
[23:11] <omega_> that means we pass through PAUSED
[23:11] <wtay> oh ok
[23:11] <wtay> cool
[23:12] <wtay> what does _iterate return then?
[23:12] <omega_> what you suggested
[23:12] <wtay> GST_ITERATE_READY?
[23:12] matth (matth at qwest.dsplinux.net) joined #gstreamer.
[23:12] <wtay> hi
[23:12] <matth> greetings!
[23:12] <omega_> yo
[23:12] <matth> nice pics
[23:13] <omega_> heh
[23:13] <hadess> hi
[23:14] <matth> i've been out of it for a while (doing other stuff)... what's new?
[23:14] <matth> omega_: did you merge INCSCHED?
[23:14] Action: hadess needs to replace his desktop by a laptop, badly
[23:14] <omega_> matth: working on it right now, actually
[23:14] <matth> cool...
[23:14] <wtay> trying to figure out signals that change state...
[23:14] <omega_> I've done a merge from HEAD into INCSCHED1, I need to commit that, actually
[23:15] <matth> wtay: what do you mean?
[23:15] <omega_> for instance...
[23:15] <omega_> if you have mpeg1parse with a new stream, it fires a new_pad signal for a new audio_00 or video_00 pad
[23:15] <omega_> in that signal handler, you need to PAUSE the pipeline to add the new chunks onto it
[23:15] <omega_> and presumably, go back to PLAYING right away
[23:16] <omega_> but what if you change state to PAUSED and not back to PLAYING, in a signal handler?
[23:16] <matth> notify the app?
[23:16] <omega_> right now, it returns to the iterate() function and finishes off the current iteration, even though everyone is set to PAUSED state
[23:16] <omega_> you == app
[23:18] <wtay> since the signal is fired from inside the plugins loop, the loop has to be exited (probably with a cothread switch)
[23:18] <matth> hmm...
[23:18] <omega_> otherwise the PAUSED state is ignored for the remainder of the iteration, and bad things might happen
[23:19] <wtay> or else, the plugin could still try to push a buffer anyway...
[23:19] <omega_> so the solution we're working on now (conceptually) is to wrap the signal_emit() function
[23:19] <omega_> after emit(), we check to see if the state is still PLAYING
[23:19] <omega_> if it's not, we switch to cothread 0, which is iterate()
[23:19] <omega_> it returns from iterate() after saving the return state, for when things go PLAYING again
[23:20] <omega_> return state == element we just switched out of
[23:20] Action: matth digests
[23:20] <matth> it's okay to add elements when you're paused?
[23:21] <omega_> that's what incsched is all about
[23:21] <matth> for me, incsched is all about thread safety
[23:21] <omega_> hmm
[23:21] <hadess> wtay: could you try something out ?
[23:21] <wtay> omega_: in the thread case, the thread goes waiting for a mutex when iterate returns READY?
[23:21] <omega_> that's a side effect of it, yes
[23:21] <wtay> hadess: yeah?
[23:22] <matth> omega_: that explains the name...  ;-)
[23:22] <omega_> matth: yup <g>
[23:22] <hadess> http://hadess.net/files/patches/mp3mad.c
[23:22] <wtay> side effect == opportunity to do it right this time
[23:22] <omega_> heh
[23:22] <hadess> mp3 test for mad
[23:22] <wtay> sec..
[23:22] <hadess> i think it works...
[23:22] <omega_> if we swap PAUSED and PLAYING, I have to rework the interlocking code again, slightl
[23:22] <omega_> er, slightly
[23:23] <wtay> hadess: want me to add it to cvs?
[23:23] <hadess> wtay: test to see if it works, and add it
[23:24] <wtay> hadess: okie, remember that -launch disksrc location=.. ! mad ! osssink is 100% the same...
[23:25] <matth> omega_: in cothread case you described, couldn't you set pending state to PAUSED and do a switch(0)?
[23:25] <omega_> when/where ?
[23:26] <hadess> wtay: i know, but it's easier to test out with some C code and go from there
[23:26] <matth> sorry... you==signal handler for new stream (which adds new elements, sets pending=PAUSED, and does switch(0))
[23:26] <wtay> hadess: commited
[23:27] <hadess> wtay: you evil, you didn't even test it, did you :P
[23:27] <omega_> no, because it has to set PAUSED first, then do stuff, then return
[23:27] <omega_> it's at return time that the switch(0) is necessary
[23:27] <wtay> hadess: I did, I even adjusted it slightly
[23:27] <omega_> it's always at return time, but it depends on whether the state is != PLAYING, nothing else
[23:28] <omega_> hence an emit() wrapper
[23:28] <wtay> hadess: you think I'm *that* slow? :)
[23:29] <hadess> wtay: that was fast then =)
[23:30] <matth> omega_: ahh, now i understand what you mean by wrapper
[23:31] <wtay> I don't see other problems except for the caps functions that can also fire signals...
[23:31] <matth> wtay: might such signal handlers change the state?
[23:31] <wtay> matth: gst_signal_emit() which is always a good idea anyway
[23:32] <omega_> matth: definitely
[23:32] <wtay> matth: depends on what the app does, typically yes
[23:33] <matth> basic rule of thumb: if you do something that might change state, you need to check if it changed
[23:33] <omega_> exactly
[23:33] <matth> wrapper is good way to ensure it gets checked
[23:34] <wtay> the prob with the switch is that stuff might still be allocated by the plugin and the only handle to it is on the plugins stack
[23:35] <omega_> which is probably solvable only be policy
[23:35] <omega_> s/be/by/
[23:35] <omega_> incoming on -cvs
[23:37] <matth> wtay: yes... the plugin *should* save such pointers in static data so it can free memory during its change_state()
[23:37] <omega_> <thwack>
[23:38] <matth> caveat coder
[23:38] <wtay> hmm :)
[23:39] <matth> it'd be nice if there was some easy way to detect "bad" plugins and flag them as such
[23:39] <omega_> hah, and thomas just signed onto -cvs
[23:39] <matth> i can't immediately think of a way
[23:39] <omega_> he gets mp3mad.c and the merge from hell, in the first hour <g>
[23:39] <wtay> now that I think of it, I should stop commiting for a while until insched is merged...
[23:39] <omega_> 1337 ?
[23:39] <omega_> hmmm
[23:39] <wtay> I have no other name for it :-)
[23:39] <omega_> I have to do another merge up anyway, so don't slow down
[23:40] Action: omega_ hides
[23:40] <wtay> hehe
[23:42] <wtay> Xv doesn't barf on multiple XvImage allocations, it simply doesn't work...
[23:42] <omega_> neat
[23:42] <omega_> you saw my update to gstmad.c ?
[23:43] <wtay> not yet..
[23:43] <omega_> on -cvs
[23:43] <wtay> nope
[23:43] <omega_> just deals with the 0.12.5b to 0.13.0 differences
[23:43] <wtay> oh yes I saw it :-)
[23:44] <wtay> nice when people have a version in the headers...
[23:44] <omega_> yup
[23:44] <omega_> do we?
[23:44] <wtay> I was just looking :-)
[23:44] <omega_> I don't think we do
[23:44] <wtay> nope 
[23:46] <wtay> hmm and the version string isn't very usefull for that
[23:46] <omega_> but there are plenty of macros to go around
[23:46] <omega_> we just need to have a gst.h.in
[23:46] <wtay> oh, we define the VERSION twice in config.h
[23:46] <omega_> but config.h is not relevant
[23:47] <wtay> or a version.h.in would be better IMO
[23:47] <omega_> could be
[23:47] <omega_> I'll do that
[23:48] <wtay> cool
[23:50] <omega_> I need to finally go through and change all the STREAMER_* to GSTREAMER_*
[23:50] <omega_> that means touching most Makefile.am's
[23:51] <wtay> uh? where are those STREAMER_* references?
[23:51] <omega_> all the versions are missing the prefix G
[23:52] rdj (rdj at a37030.upc-a.chello.nl) left irc: Read error to rdj[a37030.upc-a.chello.nl]: EOF from client
[23:52] <omega_> so all the libtool lines....
[23:53] <wtay> hmm I didn't notice that before...
[23:53] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[23:53] <omega_> actually, only a few do, it seems
[23:54] <wtay> it's only the configure.in file that needs changes, no?
[23:54] <omega_> not entirely
[23:54] <omega_> should I shorten them to GST_* ?
[23:54] <wtay> yes, I suppose
[23:56] <wtay> 124Mb when compiled
[23:59] <wtay> hmm, I should send another mail to -devel soon about the changes to the padtemplates. I don't want to piss off the 3ivx guys...
[23:59] <omega_> yes
[23:59] <omega_> you didn't remove anything in the last change, did you?
[00:00] --- Tue Apr 17 2001
[00:00] <wtay> define remove?
[00:00] <wtay> I removed the GstPadFactory +code
[00:00] <omega_> well, you only added a new factory setup, right?
[00:00] <omega_> hmm, ok
[00:00] <omega_> well then, yes
[00:00] Action: wtay ducks
[00:01] <wtay> oh well.. it's just another syntax
[00:01] <omega_> great.  the time remaining on my rh7.1iso1 download does nothing by creep up a second at a time
[00:01] <omega_> it's *supposed* to count *down*
[00:02] <wtay> great
[00:02] Action: wtay is satisfied with the caps code now
[00:02] <rdj> omega_: they're still adding stuff ;)
[00:03] Action: wtay is !satisfied with capsnego code
[00:03] <omega_> rdj: um, it's an iso image
[00:03] <rdj> duh :P
[00:05] _gst_newt_0 joined #gstreamer.
[00:06] Nick change: _gst_newt_0 -> _gst_newt_
[00:07] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[00:07] iGN_ (ign at login1.simplemente.net) joined #gstreamer.
[00:07] omega_ (omega at omegacs.net) joined #gstreamer.
[00:07] matth (matth at qwest.dsplinux.net) joined #gstreamer.
[00:07] hadess (hadess at pc213-gui2.cable.ntl.com) joined #gstreamer.
[00:07] taaz (dlehn at 66.37.66.32) joined #gstreamer.
[00:08] <omega_> um
[00:08] <omega_> let's try that again... <g>
[00:09] <wtay> pff Xv sucks
[00:09] <omega_> you're just now figuring that out?
[00:09] Action: omega_ used DirectShow for several months, knows what kind of stuff is necessary
[00:10] <omega_> s/Show/Draw/
[00:10] Action: omega_ shudders
[00:10] <wtay> at least it should be possible to allocate N XvImages...
[00:11] <wtay> only the last one allocated seems to actually show something when XvShmPutImage'ed...
[00:12] <hadess> why don't you tell the ppl @ xfree ?
[00:12] <omega_> I will
[00:12] <wtay> 'cause complaining is easier...
[00:12] <omega_> hey, my download counter is going down again <g>
[00:12] <omega_> er
[00:12] <omega_> not
[00:12] Action: hadess bangs wtay on the head
[00:13] <wtay> It wraps to 0 when greater than 2^32 you know :-)
[00:13] <matth> omega_: i tried to build from INCSCHED... autoconf tries to make gst/autoplug/Makefile from .in but there is no gst/autoplug/Makefile.in... ???
[00:14] <omega_> hmmm
[00:14] <omega_> there shouldn't be a .in, just a .am in cvs
[00:14] <omega_> checking
[00:14] Action: wtay has not a good attitude to get things fixed that are out of his control
[00:14] <omega_> ack!
[00:15] <omega_> no idea what's happened to CVS
[00:16] <omega_> um
[00:17] <matth> ?
[00:17] <omega_> cvs incsched1 is screwed up
[00:21] <wtay> what happened?
[00:21] <omega_> no idea
[00:22] <omega_> the problem is that all the directories that were added to HEAD are not in INCSCHED1
[00:22] <omega_> and I don't know how to get them there
[00:23] <matth> cvs import them?
[00:23] <omega_> nope
[00:23] <matth> why not?
[00:23] <omega_> that's not the problem
[00:23] <matth> ?
[00:23] <omega_> I'm still figuring out exactly what the problem is
[00:25] <omega_> according to cvsweb there's still pending changes in CAPSNEGO1 ?
[00:25] <wtay> uh?
[00:26] <omega_> gst/autoplug/Makefile.am has 1.2.2.1 on CAPSNEGO1 modified 4 days after the downward merge into HEAD
[00:26] <wtay> oh
[00:27] <wtay> what now?
[00:27] <omega_> hmm, no actual change, just oddities in cvs
[00:27] <omega_> not a big deal
[00:27] Action: omega_ still tries to figure out what on earth is going on with cvs incsched1
[00:37] Action: omega_ is conducting an experiment with a junk repo
[00:45] Action: omega_ gets a headache from CVS
[00:52] <hadess> anybody seen zaheer lately ?
[00:52] <omega_> nope
[00:52] <omega_> wtay: still awake?
[00:52] <wtay> sorta
[00:52] <omega_> is it possible to shove the IRC logs on gstreamer.net as well as email?
[00:53] <wtay> I guess so...
[00:53] <omega_> then richardb can make them searchable, or taaz, or whoever it was that claimed to have ways with search engines
[00:54] <wtay> If I can put the password on the cmd line for scp...
[00:54] <wtay> of try to figure out how scp works without a password..
[00:54] <omega_> why?  set up the agent
[00:54] <wtay> yes
[00:55] <wtay> will try that tomorrow
[00:55] <omega_> cool
[00:55] Action: wtay got plain x images working with a bufferpool
[00:55] <omega_> then we can do neat things like irc stats
[00:56] <omega_> bytes per nick, last seen, new nicks per day, etc.
[00:56] <wtay> hehe, richardb can do a search engine :)
[00:58] Action: hadess wonders how much time he'll have to wait to buy a lappy
[00:58] <wtay> hmm only 5% faster with bufferpools...
[00:58] <hadess> that kills me when i think that i'm still paying for the old one :/
[00:58] <hadess> wtay: that's good stuff
[00:58] <omega_> wtay: *only* 5% faster/
[00:59] <wtay> just a memcpy less
[00:59] <omega_> s/\//?/
[00:59] <omega_> some people kill for 5%
[00:59] <wtay> pff
[00:59] <wtay> rough guess though
[01:00] <wtay> now if Xv wouldn't suck that much...
[01:00] <omega_> heh
[01:01] <omega_> btw, I'd like to put together a GUADEC report from the GStreamer point of view
[01:01] <omega_> that means everyone that was there should submit comments to join into a single report
[01:01] <omega_> since a lot of people talked to a lot of people that I haven't even heard of yet
[01:01] <wtay> cool
[01:01] <omega_> I'll post to the list
[01:10] <taaz> bufferpool's working?
[01:10] <hadess> hi taaz
[01:10] <taaz> 5% sounds good...
[01:10] <matth> i'm out of here - gotta go for a ride.  cya tomorrow.
[01:10] Nick change: matth -> matth-ride
[01:10] <omega_> ok, l8r
[01:10] <taaz> hey... 
[01:10] <wtay> taaz: not sure about the exact number
[01:11] <taaz> you all talk alot.  i can't keep up when i'm working on other stuff during the day ;)
[01:11] <wtay> anyway I just commited the stuff..
[01:11] <wtay> cya matth-ride
[01:11] <omega_> hmmmm
[01:12] <omega_> there's a difference between checking out with -j and -r
[01:12] <wtay> ?
[01:12] <omega_> checking..
[01:13] <omega_> -r grabs the relevant rcs rev directly
[01:13] <omega_> -j grabs the base x.y rev and then does an update to the x.y.z.a
[01:13] <omega_> they don't yield the same size working copy
[01:14] <wtay> hmm
[01:14] <omega_> I get different working copies
[01:14] <omega_> wonderful
[01:16] <omega_> I have no idea what the difference is
[01:17] <omega_> the -j one seems to not have the tag
[01:17] <wtay> I have to sleep... cya all
[01:17] <omega_> it does have all the code though
[01:17] Action: omega_ is very confused
[01:17] <omega_> ok, l8r
[01:17] Nick change: wtay -> wtay-sleeping
[01:17] <wtay-sleeping> very odd..
[01:17] <hadess> cya wtay-sleeping
[01:18] <wtay-sleeping> is it the same code?
[01:18] <wtay-sleeping> hadess: cya
[01:18] <omega_> checking
[01:18] <omega_> the gstscheduler.c code is the same in both
[01:19] <omega_> the -j one seems to have all the files missing from the incsched1 branch
[01:19] <omega_> but they don't have the sticky tag
[01:19] <omega_> so the -j copy should build (config.status is working fine now)
[01:19] <omega_> but the actual branch itself doesn't have all the new files
[01:19] <omega_> but I know how to fix that now
[01:19] <omega_> see -cvs
[01:21] <omega_> then again...
[01:21] <omega_> so does the -r, even though it's missing many files
[01:21] Action: omega_ is very confused
[01:22] <omega_> oh
[01:22] <omega_> for every file that had a difference between HEAD and INCSCHED1, it moved the HEAD file to .#filename.rev
[01:22] <omega_> and merged in the changes to the branch into the real filanem
[01:23] <omega_> that accounts for all the extra files
[01:23] <omega_> but doesn't account for what matth saw
[01:28] <wtay-sleeping> hmm
[01:28] <omega_> it builds now though, with a fresh -r checkout
[01:28] <wtay-sleeping> how hard would it be to render directly into the audio DMA buffer?
[01:28] <omega_> so maybe the autoplug dir was the only one I missed
[01:29] <omega_> dunno, never done OSS dma output
[01:29] <omega_> I should write a standalone test program
[01:30] <wtay-sleeping> I'm really gone now.. l8r
[01:30] <omega_> ok
[02:40] hadess (hadess at pc213-gui2.cable.ntl.com) left irc: sleep
[03:41] rdj (rdj at a37030.upc-a.chello.nl) left irc: Ping timeout for rdj[a37030.upc-a.chello.nl]
[04:54] ajmitch (me at 203-79-80-247.ipn9.paradise.net.nz) joined #gstreamer.
[05:33] <taaz> time to try wtay's bufferpool stuff
[05:57] <taaz> anyone awake?
[05:59] <ajmitch> nope
[05:59] <taaz> darn
[06:00] <taaz> libtool: link: CURRENT `cothreads.lo' is not a nonnegative integer
[06:00] <taaz> libtool: link: `cothreads.lo' is not valid version information
[06:00] <taaz> what does that mean? ;)
[06:00] <ajmitch> sorry
[06:01] <taaz> apt-get update time ;)
[06:02] <ajmitch> wha?? ;)
[06:02] <ajmitch> hehe, hail apt-get
[06:06] <taaz> you look bored... write me a tv player app in gstreamer that cuts the volume to 0 on commercials, thanks.
[06:07] <taaz> ha... the docs build didnt work either! its not just me
[06:09] <ajmitch> hehe