[gst-devel] Daily IRC logs

[<wim...@ch...>]

[06:32] chillywilly (bau...@d1...) 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 (bau...@d1...) left #gstreamer.
[06:38] chillywilly (bau...@d1...) joined #gstreamer.
[06:39] <chillywilly> unltimate eh?
[06:55] Nick change: taaz -> taazzzz
[08:30] ajmitch (me...@p5...) left irc: http://www.freedevelopers.net
[09:18] chillywilly (bau...@d1...) left irc: [x]chat
[10:40] Wodi (wodin30@202.67.83.169) joined #gstreamer.
[10:40] <Wodi> hey yall
[10:54] Wodi (wodin30@202.67.83.169) left irc: 
[10:59] omega_ (om...@om...) left irc: [x]chat
[11:18] thomas (th...@ur...) joined #gstreamer.
[11:24] Action: thomas is away - Automatically set away. - messages will be saved.
[11:27] thomas (th...@ur...) left irc: I'm outta here!
[12:16] thomas (th...@ur...) 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 (da...@na...) 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 (da...@na...) 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 (an...@n5...) 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_ (om...@om...) 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@66.37.66.32) got netsplit.
[18:11] taaz (dlehn@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@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@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 (th...@ur...) left irc: Leaving
[19:32] z- (da...@ho...) 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 (th...@ur...) 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 (th...@ur...) 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 (th...@ur...) 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 (ha...@pc...) joined #gstreamer.
[20:30] <wtay> yo
[20:30] <hadess> yo wtay
[20:31] hadess (ha...@pc...) left irc: mooooh!
[20:32] hadess (ha...@pc...) joined #gstreamer.
[20:32] ...
 
[truncated message content]