[gst-devel] Daily IRC logs

[wim.taymans at chello.be]

[07:04] rdj (rdj at a37030.upc-a.chello.nl) got netsplit.
[07:15] rdj (rdj at a37030.upc-a.chello.nl) got lost in the net-split.
[07:18] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[07:25] taaz (dlehn at 66.37.66.32) got netsplit.
[07:26] taaz (dlehn at 66.37.66.32) returned to #gstreamer.
[07:38] hjames (hjames at proxy4.cc.stevens-tech.edu) got netsplit.
[07:38] hjames (hjames at proxy4.cc.stevens-tech.edu) returned to #gstreamer.
[07:43] hjames (hjames at proxy4.cc.stevens-tech.edu) got netsplit.
[07:43] taaz (dlehn at 66.37.66.32) got netsplit.
[07:43] rdj (rdj at a37030.upc-a.chello.nl) got netsplit.
[07:44] rdj (rdj at a37030.upc-a.chello.nl) returned to #gstreamer.
[07:44] taaz (dlehn at 66.37.66.32) returned to #gstreamer.
[07:44] hjames (hjames at proxy4.cc.stevens-tech.edu) returned to #gstreamer.
[08:19] Nick change: taaz -> taazzzz
[09:17] steveb (chatzilla at 212186169160.chello.com) joined #gstreamer.
[10:24] steveb (chatzilla at 212186169160.chello.com) left irc: ChatZilla 0.8 [Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; 0.8.1) Gecko/20010323]
[12:23] thomas (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[12:24] <thomas> hi
[12:59] richardb (richard at ixion.tartarus.org) joined #gstreamer.
[13:19] Action: richardb tries to catch up on everything that's been happening to GStreamer...
[13:49] thomas (thomas at 212-100-172-175.adsl.easynet.be) left irc: [x]chat
[13:51] thomas (thomas at 212.100.172.175) joined #gstreamer.
[13:51] <thomas> richardb: Can I ask you something ?
[13:52] <richardb> Yeah, but I may not have a useful answer.
[13:52] <thomas> I added a disksink element and made it work on my machine...
[13:52] <thomas> ... but I also have to update a Makefile...
[13:53] <thomas> but ... where should I do that ?
[13:53] <richardb> How familiar with automake are you?
[13:53] <thomas> not too much...
[13:53] <thomas> I suppose I have to put it in Makefile.am ?
[13:54] <thomas> that's how I did it on my system
[13:54] <richardb> Yes.
[13:54] <thomas> I just added the .c and .h file
[13:54] <thomas> ok, so it's safe to commit it then ?
[13:54] <richardb> Um, is this in the CVS tree for gstreamer?
[13:54] <thomas> yes
[13:54] <richardb> Which dir?
[13:54] <thomas> gst/elements
[13:54] <richardb> Good. :)
[13:55] <thomas> ok, thanks
[13:55] <thomas> btw are you planning on updating the plugin manual ?
[13:55] <richardb> Yeah, just add the .c and .h to the Makefile.am
[13:55] <richardb> PWG?
[13:55] <thomas> yes
[13:55] <richardb> I've got very out of touch with what's going on with GStreamer, is the main problem.
[13:55] <richardb> Lots of bits I don't understand now.
[13:56] <thomas> well me neither... I'm learning though
[13:56] <richardb> I'm going to try and make a list of things which need explaining in there; will do it in wiki I think.
[13:57] <richardb> Not today though, since I'm just trying to catch up on the last 3/4 weeks of work that I've not really followed...
[13:57] <richardb> Anyone who has time should feel free to add stuff to PWG.
[13:58] <richardb> (Easier to edit something that to wite from scratch.)
[13:58] <thomas> ok, maybe I will...
[13:58] <richardb> disksink should be useful for testsuite purposes...
[13:59] <richardb> Can run pipelines and store the output, and do a diff to check it against the expected output.
[14:00] <thomas> well... it seems to work.  if you copy a file the diff's ok
[14:00] <thomas> I probably forgot to check/add some things though
[14:00] <thomas> I don't know what you need to put in to make an element be right
[14:00] <richardb> Me neither... ;(
[14:01] <richardb> I'm definitely not up to speed on the caps negotiation stuff, for a start.
[14:01] <thomas> what ? you mean that's recent stuff as in this month ?
[14:01] <thomas> when did gstreamer start being a multi-people project anyway ?
[14:01] <richardb> Or exactly how to deal with  state transitions.
[14:01] <richardb> Been about 3 people until January.
[14:02] <richardb> Growing fast since then.
[14:02] <thomas> that's a good thing... I like gstreamer a lot
[14:04] <thomas> ok thanks... gotta catch up on some other stuff
[14:04] <thomas> bye
[14:04] thomas (thomas at 212.100.172.175) left irc: [x]chat
[14:56] _gst_newt_ joined #gstreamer.
[15:14] Nick change: matth_ -> matth-waking
[15:15] greg_ (greg at home.sente.pl) joined #gstreamer.
[15:51] Nick change: richardb -> richardb-away
[16:05] asmod (stevec at 64.5.222.2) joined #gstreamer.
[16:33] Nick change: matth-waking -> matth_
[16:33] greg_ (greg at home.sente.pl) left irc: Ping timeout for greg_[home.sente.pl]
[16:34] greg_ (greg at home.sente.pl) joined #gstreamer.
[16:34] richardb-away (richard at ixion.tartarus.org) left irc: BitchX: its shagadellic, baby!
[16:51] lsetia (lsetia at 203.195.142.187) joined #gstreamer.
[16:59] _gst_newt_ joined #gstreamer.
[17:07] holger_ (holger at Q.convergence.de) joined #gstreamer.
[17:08] lsetia (lsetia at 203.195.142.187) got netsplit.
[17:08] taazzzz (dlehn at 66.37.66.32) got netsplit.
[17:08] thomas (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[17:08] rdj (rdj at a37030.upc-a.chello.nl) left irc: Ping timeout for rdj[a37030.upc-a.chello.nl]
[17:11] Topic changed on #gstreamer by ChanServ!s at ChanServ: GStreamer: the ultimate multimedia framework
[17:12] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[17:17] taazzzz (dlehn at 66.37.66.32) returned to #gstreamer.
[17:17] lsetia (lsetia at 203.195.142.187) returned to #gstreamer.
[17:17] rdj (rdj at a37030.upc-a.chello.nl) left irc: Ping timeout for rdj[a37030.upc-a.chello.nl]
[17:23] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[17:26] holger_ (holger at Q.convergence.de) left irc: Client Exiting
[17:27] dobey (dobey at dreadnought.ximian.com) joined #gstreamer.
[17:33] Gman (gman at beryllium.eu.sun.com) joined #gstreamer.
[17:34] Gman (gman at beryllium.eu.sun.com) left irc: [x]chat
[17:35] Nick change: wtay-sleeping -> wtay
[17:35] <wtay> yo
[17:37] lsetia (lsetia at 203.195.142.187) left irc: Ping timeout for lsetia[203.195.142.187]
[17:40] <matth_> wtay: howdy... what's up?
[17:42] <wtay> matth_: recovering from work :-)
[17:43] <wtay> matth_: hectic situations, we have a mayor release this weekend
[17:43] <wtay> for gstreamer I'm working a bit on more API docs updates
[17:43] <matth_> cool
[17:44] <wtay> They are probably built this night on the gstreamer.net docs pages...
[17:44] <wtay> yup
[17:45] <wtay> mostly examples to the API calls
[17:45] <matth_> cool - i'll check them out later
[17:45] <matth_> i'm going to play with omega's incsched branch and add some "wakeable" blocking open/read/write calls
[17:46] <matth_> which plugins can / should use
[17:46] <wtay> cool
[17:46] <wtay> I'd like to rework the capsnego thing a bit too soon
[17:47] <matth_> i still haven't taken a close look at what you've done -- that's next on my list
[17:47] <matth_> it's what i really want to do
[17:47] <wtay> ok
[17:47] <wtay> I could use some feedback on it
[17:49] <wtay> hmm, I need to make identity work with capsnego
[17:50] Action: wtay is eating 
[18:01] thomas (thomas at 212-100-172-175.adsl.easynet.be) left irc: [x]chat
[18:03] thomas (thomas at 212-100-172-175.adsl.easynet.be) joined #gstreamer.
[18:03] <thomas> hi
[18:03] <wtay> hello
[18:03] Action: wtay is compiling Overflow
[18:04] <thomas> wtay: I wrote a disksink, but there are a few things I wasn't clear about from the other elements...
[18:04] <thomas> can I compile them on mail for you to check ?
[18:04] <wtay> sur
[18:04] <thomas> maybe I can write some sort of simple doc on it then for you guys to review
[18:04] <wtay> sure
[18:05] <thomas> btw have you written a SAX xml parser in C yet ?
[18:05] <thomas> It's hard to find clear examples...
[18:05] <wtay> libxml has a sax parser
[18:05] <thomas> ... and code I write seems to segfault in the xml library ...
[18:05] <wtay> oh
[18:05] <thomas> ... so I guess I should download the lib source then.
[18:05] <wtay> no I haven't written one yet
[18:06] <thomas> gstreamer uses libxml1 right ?
[18:06] <wtay> I can get you a COBOL one though =-)
[18:06] <thomas> do you know of a project that uses sax from libxml ?
[18:06] <wtay> yup
[18:06] <wtay> nope
[18:06] <thomas> wtay: no thanks ;) I can easily write one myself if it's only for the simple stuff I'm going to do
[18:06] <wtay> there is a SAX example on the site
[18:06] <thomas> wtay: where ? on xmlsoft.org ? if it's that one article, it's very unclear
[18:07] <wtay> true
[18:07] <thomas> pftt...
[18:07] <thomas> I guess I'll download the libxml2 source then.
[18:07] <thomas> hope it doesn't break gstreamer ;)
[18:07] <wtay> no idea :)
[18:08] <wtay> gmbl.. Overflow compilation failed...
[18:09] <thomas> wtay: is there a way I can check out incsched sooner ?
[18:10] <wtay> thomas: yup, check out the INCSCHED1 branch
[18:10] <wtay> cvs checkout -r BRANCH-INCSCHED1 gstreamer
[18:11] <thomas> so... I make a different directory next to my current CVS for that then ?
[18:11] <wtay> yup
[18:11] <wtay> I then rename it to GStreamer-INCSCHED1
[18:14] <thomas> did you guys ever consider also having text/plain as data ...
[18:15] <thomas> ... for stuff like metadata, subtitles, ... ?
[18:15] <wtay> yeah :-)
[18:15] <wtay> and text to speach
[18:15] <wtay> s/speach/speech
[18:15] <thomas> yeah, that would be great...
[18:16] hjames (hjames at proxy4.cc.stevens-tech.edu) left irc: Read error to hjames[proxy4.cc.stevens-tech.edu]: EOF from client
[18:16] <thomas> so any specific reason why it's not implemented yet ?
[18:16] <thomas> time, or orther issues ?
[18:16] <wtay> time
[18:16] <thomas> but, basically, it shouldn't be that hard to implement, right ?
[18:16] <wtay> nope
[18:16] <thomas> because I have to do something like that anyway for title streaming
[18:17] <wtay> it's just another mime type, gstreamer doesn't care
[18:17] <wtay> you'll need text2speech too?
[18:18] <thomas> not right away ;)
[18:18] <wtay> I think there is a common subtitle format somewhere, we could easily write a src/decoder for it
[18:18] <thomas> I didn't check up on that recently... I should, just to know how it sounds these days.
[18:18] <thomas> Do you remember what it was called ?
[18:18] <thomas> the format I mean
[18:18] <wtay> nope, but lot's of DivX sites link to it
[18:19] <thomas> ok, I'll check up on that
[18:19] <wtay> just a simple text file with timestamp/text pairs
[18:19] <thomas> hmmm... I seem to do something wrong with the cvs...
[18:19] <thomas> I get this :
[18:19] <thomas>  cvs checkout -r BRANCH-INCSCHED1 gstreamer
[18:19] <thomas> cvs checkout: No CVSROOT specified!  Please use the `-d' option
[18:19] <thomas> cvs [checkout aborted]: or set the CVSROOT environment variable.
[18:20] <wtay> ok, you'll need to login too
[18:20] <wtay> cvs -d:pserver:anonymous at cvs.gstreamer.sourceforge.net:/cvsroot/gstreamer login
[18:20] <wtay> cvs -z3 -r BRANCH-INCSCHED1 -d:pserver:anonymous at cvs.gstreamer.sourceforge.net:/cvsroot/gstreamer co gstreamer
[18:21] <wtay> as taken from http://sourceforge.net/cvs/?group_id=1936
[18:36] BBB (BBB at ucu-105-116.ucu.uu.nl) joined #gstreamer.
[18:37] <BBB> hey, omega not here?
[18:37] Action: BBB just found out who wrote libdv ;)
[18:39] <wtay> not yet :-)
[18:39] <wtay> he's going to integrate libdv in gstreamer today
[18:39] <BBB> ok
[18:40] <BBB> I just relinked quicktime against the official libdv and the official jpeg
[18:40] <BBB> what a terrible work
[18:40] <BBB> :|
[18:40] <BBB> that quicktime guy is nuts
[18:41] <wtay> heh
[18:41] <BBB> ugh
[18:41] Action: BBB kicks glib
[18:41] <BBB> my glib is fscked up
[18:41] <wtay> ouch
[18:42] <BBB> glib-config says 1.2.8
[18:42] <BBB> but I have 1.2.9
[18:42] <BBB> :|
[18:42] <BBB> UGH
[18:42] Action: BBB kicks libdv
[18:42] Action: BBB installs glib from source
[18:42] <BBB> brb
[18:42] <wtay> BBB: ?
[18:43] <wtay> BBB: you maintain mjpegtools?
[18:43] <BBB> yes
[18:43] <BBB> with some others :)
[18:43] <wtay> is the mpeg encoder librarified yet?
[18:43] <BBB> Andrew is official maintainer - and he does all the work
[18:44] <BBB> uh oh - Andrew made the encoder - how do I see whether it is librarified?
[18:44] <wtay> it isn't, but are there plans?
[18:44] <BBB> you mean to make it a gstreamer module?
[18:44] <BBB> yes
[18:44] <wtay> oh cool
[18:44] <BBB> Andrew wants to do that if there isn't any yet
[18:44] <wtay> a gstreamer module right away?
[18:44] <BBB> I guess so
[18:45] <BBB> we also wanna make 'lav' a gstreamer module
[18:45] <wtay> maybe better make a lib first and then a plugin...
[18:45] <BBB> i.e. mjpeg/avi/quicktime/movtar
[18:45] Action: BBB installs glib
[18:45] Action: BBB kicks RPMs
[18:45] <BBB> I'm kinda stressed, I guess ;)
[18:45] <wtay> 'cause the encoder is very neat
[18:45] <BBB> yup, I know - I love the encoder
[18:45] <wtay> current CVS of gstreamer has an old copy though...
[18:46] <BBB> you want a new copy?
[18:46] lsetia (lsetia at 203.195.140.72) joined #gstreamer.
[18:46] <wtay> yeah
[18:46] Action: BBB can put the sources online
[18:46] <BBB> just mpeg2enc.....
[18:46] <BBB> k
[18:46] <wtay> they are in CVS
[18:46] <lsetia> hi thomas
[18:46] <BBB> I'll make a tar.gz for the current CVS of mpeg2enc
[18:46] <wtay> hi lsetia
[18:47] <lsetia> hi wtay 
[18:47] <wtay> BBB: I can download the mjpegtools CVS version..
[18:47] <BBB> how do I add a file to the sourceforge download page, btw?
[18:47] <lsetia> wtay: I upgraded (?) from 0.1.1 to CVS, and have some probs.
[18:49] <lsetia> If I do a 'make install', then run /usr/local/bin/gstreamer-register, all plugies are registered from where I compiled them
[18:49] <wtay> BBB: no idea
[18:49] <lsetia> and not from /usr/local
[18:49] <wtay> lsetia: thats normal
[18:49] <wtay> lsetia: don't do make install
[18:49] <lsetia> wtay: that's what thomas suggested to me
[18:50] <wtay> lsetia: you can avoid this behaviour by adding --disable-plugin-srcdir
[18:50] <lsetia> wtay: ok, now that I know its normal, I'll run it from my home dir itself :)
[18:50] <wtay> or addapt the autogen.sh script
[18:50] <wtay> lsetia: yeah
[18:51] <lsetia> wtay: is gstmediaplay broken in CVS?
[18:51] <wtay> lsetia: nope, it should work
[18:51] <dobey> no,it's broke everywhere
[18:51] <dobey> :-/
[18:51] <wtay> dobey: no it isn't
[18:51] <dobey> heh
[18:52] <BBB> I got glib back
[18:52] <BBB> :)
[18:52] <lsetia> wtay: it crashes when I try to play a mp3 file...
[18:52] <dobey> ppc?!
[18:52] <wtay> lsetia: what happens?
[18:52] <dobey> hehe
[18:52] Action: thomas curses at libxml SAX and picks up expat again
[18:53] <lsetia> ** CRITICAL **: file gstbin.c: line 172 (gst_bin_add): assertion `element != NULL' failed.
[18:53] <BBB> <g>
[18:53] <lsetia> 3 more messages like that
[18:53] Action: BBB laughs
[18:53] <lsetia> then a gnome-crash dialog
[18:53] <BBB> try helloworld
[18:53] <BBB> :)
[18:53] <BBB> lol
[18:53] <wtay> lsetia: looks like it can't find some plugins
[18:54] <wtay> lsetia: gstreamer-launch fakesrc ! fakesink
[18:54] <lsetia> wtay: but helloworld etc. run fine
[18:55] <lsetia> ooops
[18:55] <lsetia> RUNNING pipeline
[18:55] <lsetia> fakesrc: ******* (fakesrc0:src)> 
[18:55] <lsetia> fakesink: ******* (fakesink0:sink)< 
[18:55] <wtay> lsetia: cool
[18:55] <lsetia> infinitely
[18:55] <wtay> gstreamer-launch disksrc location=some.mp3 ! mad ! osssink
[18:55] <BBB> grmbl
[18:56] <BBB> quicktime refuses to link
[18:57] <lsetia> Couldn't create a 'mad', no such element or need to run gstraemer-register?
[18:57] <lsetia> ** CRITICAL **: file gstbin.c: line 172 (gst_bin_add): assertion `element != NULL' failed.
[18:57] <wtay> lsetia: ok
[18:57] <wtay> lsetia: gstreamer-launch disksrc location=some.mp3 ! mp3parse ! mpg123 ! osssink
[18:57] <lsetia> wtay: Is gstremer ok with upgraded libxml etc. for gnome-1.4
[18:57] <wtay> lsetia: yup
[18:58] <wtay> I think..
[18:58] <lsetia> wtay: this one works fine
[18:58] <wtay> lsetia: gstreamer-inspect xvideosink
[19:00] <lsetia> wtay: displays correctly I think
[19:00] <wtay> lsetia: hmm
[19:00] <wtay> lsetia: does gstreamer-register work?
[19:02] <lsetia> wtay: it does without any errors
[19:02] <BBB> if omega comes here, ask him to help me ;) I got some problems here.....:\
[19:03] <wtay> lsetia: and gstmediaplay refuses to work?
[19:03] <lsetia> wtay: the right way to run gstmediaplay is to 'cd gstplay; ./gstmediaplay' ?
[19:04] <wtay> lsetia: yup, and add the media file as an arg
[19:05] omega_ (paul at temple-baptist.com) joined #gstreamer.
[19:05] <wtay> yo
[19:05] <wtay> omega_: BBB needs help he said
[19:05] <omega_> ello
[19:05] <BBB> YEAH!
[19:06] <BBB> :)
[19:06] <BBB> omega_: I'm trying to get libquicktime to do what I want
[19:06] <lsetia> wtay: 4 critical errors then crash dialog
[19:06] <dobey> it's sad that a library based on an apple product, can't build on a mac
[19:06] <wtay> lsetia: can you paste them here?
[19:06] <BBB> omega_: but uhm, libdv is refusing to cooperate....:)
[19:06] <lsetia> [lsetia at milkyway gstplay]$ ./gstmediaplay ~/songs/Rem-_Everybody_hurts.mp3 
[19:07] <lsetia> INFO(30412:-1): Initializing GStreamer Core Library
[19:07] <lsetia> INFO(30412:-1): CPU features: (808029bf) MMX 3DNOW 
[19:07] <lsetia> ** CRITICAL **: file gstbin.c: line 172 (gst_bin_add): assertion `element != NULL' failed.
[19:07] <lsetia> ** CRITICAL **: file gstelement.c: line 577 (gst_element_connect): assertion `src != NULL' failed.
[19:07] <lsetia> ** CRITICAL **: file gstelement.c: line 326 (gst_element_get_pad): assertion `element != NULL' failed.
[19:07] <lsetia> ** CRITICAL **: file gstelement.c: line 273 (gst_element_add_ghost_pad): assertion `pad != NULL' failed.
[19:07] <lsetia> [lsetia at milkyway gstplay]$ 
[19:07] <wtay> lsetia: try another mp3?
[19:08] <lsetia> wtay: this mp3 plays with helloworld
[19:08] <wtay> lsetia: helloworld doesn't use typefind so...
[19:08] <BBB> omega_?
[19:09] <omega_> is omega_ even awake yet?
[19:09] <omega_> umm
[19:09] <omega_> i'm not omega
[19:09] <lsetia> wtay: same error with other mp3's
[19:09] omega (omega at omegacs.net) joined #gstreamer.
[19:09] <omega_> errr
[19:09] <omega> CHW...
[19:09] Nick change: omega_ -> ChiefHighwater
[19:09] Nick change: omega -> omega_
[19:09] <ChiefHighwater> doh
[19:09] <wtay> heh
[19:09] Action: omega_ slaps ChiefHighwater around with a trout
[19:10] <BBB> ?
[19:10] <BBB> lol
[19:10] <ChiefHighwater> i didn't change the login here
[19:10] <lsetia> wtay: exactly the same errors with an avi also,
[19:10] Action: ChiefHighwater slaps omega_ around a bit with a large trout
[19:10] Action: omega_ just fixed his laptop keyboard, they installed the cable incorrectly
[19:10] <wtay> lsetia: hmm
[19:10] <lsetia> wtay: these files used to work with 0.1.1, if I recall correctly
[19:10] <BBB> omega_: I need your help
[19:10] <omega_> oh?
[19:11] Action: omega_ leaves in 30min for OGI
[19:11] <omega_> and /me won't get anywhere close to xfering his hard drive before then
[19:11] <BBB> I'm trying to link libquicktime (1.3 from Adam **UGH**) to libdv but get 3 unresolved symbols
[19:11] <omega_> I thought he shipped a hacked copy of libdv with qt4l
[19:11] <BBB> yes
[19:11] <omega_> I looked through the code yesterday
[19:11] <BBB> but I want to get rid of that
[19:11] <omega_> ah
[19:11] <omega_> good luck <g>
[19:11] <BBB> I already got rid of jpeg :)
[19:12] <BBB> but I am getting 4 unresolved symbols - since you wrote libdv you might help me
[19:12] <omega_> you sure you want to be doing this at all?  3ivx is working on quicktime stuff....
[19:12] <BBB> it's for mjpegtools *L*
[19:12] <omega_> ah
[19:12] <omega_> um
[19:12] <BBB> [rbultje at tux quicktime4linux-1.3]$ gcc -o qtdump dump.o libquicktime.a -ljpeg -lpng -lz -lpthread -lglib -ldl -L/usr/local/lib -ldv -I/usr/local/include/libdv
[19:12] <BBB> libquicktime.a(dv.o): In function `quicktime_delete_codec_dv':
[19:12] <BBB> dv.o(.text+0xa5): undefined reference to `dv_delete'
[19:12] <BBB> libquicktime.a(dv.o): In function `quicktime_decode_dv':
[19:12] <BBB> dv.o(.text+0x1b6): undefined reference to `dv_read_video'
[19:12] <BBB> dv.o(.text+0x1e7): undefined reference to `dv_read_video'
[19:12] <BBB> libquicktime.a(dv.o): In function `quicktime_init_codec_dv':
[19:12] <BBB> dv.o(.text+0x2d3): undefined reference to `dv_new'
[19:12] <omega_> why not just port to gstreamer and let 3ivx do their qt stuff <g>
[19:12] <BBB> collect2: ld returned 1 exit status
[19:12] <BBB> [rbultje at tux quicktime4linux-1.3]$ 
[19:12] <BBB> that ^^^^^^^^^^
[19:12] <omega_> all of those symbols are Adam's
[19:13] <BBB> there's no such functions in libdv?
[19:13] <omega_> if you do a diff of the *real* libdv.c to his libdv.c you'll find that he added all kinds of 1394 stuff to libdv.c, where it doesn't belong
[19:13] <omega_> that's the code I used as reference to build the 1394src yesterday
[19:13] <BBB> uhm.....
[19:13] <BBB> not good, is it? :)
[19:13] <omega_> no
[19:13] <wtay> to be expected
[19:14] <omega_> what's your goal with this?
[19:14] <BBB> uhm...
[19:14] <omega_> because there may be a better route to accomplish it, depending
[19:15] <BBB> well.....
[19:15] <BBB> thing is
[19:15] <BBB> some people record with mjpegtools, and thenwant to edit it in broadcast
[19:15] <BBB> so I need quicktime-1.3
[19:15] <BBB> but some people also have DV video which they work with in MJPEGtools
[19:15] <omega_> do you need quicktime-1.3 or just .qt support?
[19:15] <BBB> so I want to link it against their version of libdv
[19:15] <BBB> to be 100% nice ;)
[19:15] <BBB> I need qt-1.3
[19:15] <omega_> dv is dv, as .qt is supposed to be .qt
[19:15] <BBB> qt-1.2 is already linked
[19:16] <BBB> dv.qt?
[19:16] <omega_> so you're saying that quicktime-1.3 .qt files are different from quicktime-1.2 ?
[19:16] <BBB> yes, very
[19:16] <BBB> 100% incompatible
[19:16] <BBB> I tried it
[19:16] <BBB> :)
[19:16] <omega_> that would mean that one or the other is *BROKEN*, since .qt is a STANDARD
[19:16] <BBB> (sidenote: let's burn Adam)
[19:16] <omega_> and thus, to take an RMS stance:
[19:16] <omega_> you should NOT support broken formats
[19:16] <BBB> we should, since it's broadcasts :(
[19:16] <BBB> and some people actually wanna use bc
[19:16] <BBB> :()
[19:16] <omega_> um, broadcast2k is broken
[19:17] <BBB> yup
[19:17] <BBB> I know
[19:17] <omega_> then lets replace b2k
[19:17] <BBB> but some people wanna use it
[19:17] <BBB> since there's not much better
[19:17] Action: BBB tries to replace bc2k
[19:17] <omega_> then there should be a separate converter (cmdline) from *real* .qt to quicktime-1.x 'formats'
[19:17] <BBB> grmbl - too much work
[19:17] <omega_> .qt is a standard, there is no reason to support broken versions of the file format standard
[19:17] <BBB> people don't care, omega_, they're stupid and just want to use it
[19:18] <dobey> and none of you are working on a realplayer plugin?
[19:18] <BBB> unfortunately
[19:18] <wtay> BBB: people should be educated then
[19:18] <BBB> you wanna do it, omega_?
[19:18] <omega_> er, *dobey* one is possible, I haven't put any thought into it
[19:18] <omega_> BBB: educate people? yes.
[19:18] <dobey> heh
[19:18] <dobey> i know
[19:18] <BBB> not me - it's annoying
[19:18] <BBB> here's a quote from a new wiseguy on our mailinglist:
[19:19] Action: dobey doesn't want to look at the api again though
[19:19] <BBB> "
[19:19] <BBB> More speed probably comes because I can write faster code than most people."
[19:19] <omega_> if quicktime-1.3 is writing broken formats, then the only correct thing to do is tell people that, hey, they can't interoperate because *b2k* is broken, not because mjpegtools is broken
[19:19] <omega_> BBB: is that Adam, or some other person?
[19:19] <lsetia> wtay: any ideas?
[19:19] <BBB> omega_: we (that is, the general feeling amongst the developers) want that, we would just lose a LOT of users by doing that
[19:20] <wtay> lsetia: nope
[19:20] <BBB> omega_: no, someone else :)
[19:20] <omega_> BBB: I take RMS's stance on this issue (we have the power to change people's minds) because we do have the power, and it's the correct thing to do
[19:20] Action: BBB fears MJPEGtools is not that powerful...
[19:20] Action: omega_ hopes that b2k loses a LOT of users until they support a 100% implementation of a long-existing standard
[19:20] <BBB> although dv2jpg is quite kew and shows the dv people's attitude towards us, quite nice
[19:20] <BBB> :)
[19:21] <BBB> omega_: problem is, nobody knows the quicktime standard except apple
[19:21] <omega_> BBB: I thought you were porting all the mjpegtools stuff to gstreamer, which means someone *else* can do the work of a quicktime-1.3 plugin
[19:21] <BBB> Adam writes bad bad code
[19:21] <BBB> but he cannot make qtlib much better (not the coding, but the content) since he doesn't know qt by heart
[19:22] <BBB> omega_: we'll do that as soon as the final release is out - it isn't yet, we're almost there, though
[19:22] <BBB> read your mail :)
[19:22] <omega_> BBB: there is enough documentation and sample files for .qt that someone can write a correct lib
[19:22] <BBB> not Adam, for sure :(
[19:22] <omega_> well, then, he loses
[19:23] <omega_> I suggest sending mail to the 3ivx guys to see if they'll consider getting the code out there ASAP, whether it work or not
[19:24] Action: omega_ will be back in 10min, then leaving in <5min
[19:24] <BBB> :(
[19:25] lsetia (lsetia at 203.195.140.72) left irc: Read error to lsetia[203.195.140.72]: Connection reset by peer
[19:25] <wtay> mpeg2enc is highly thread unsafe...
[19:25] <BBB> ??? I thought Andrew had done a LOT of threading work
[19:25] <BBB> dammit,
[19:25] Action: BBB kicks Adam
[19:26] <wtay> current mjpegtools CVS version..
[19:26] <BBB> hm.... I don't knowandrew is doing the mpeg2enc work
[19:26] <BBB> I'm only doing higher level stuff, mostly
[19:28] <wtay> hmm, looks like the global vars are maybe copied to a struct...
[19:29] <wtay> hmm no :(
[19:30] Action: BBB gives up on quicktime
[19:30] <BBB> I'll just relink it to jpeg and leave the libdv for what it is :(
[19:31] <wtay> libqt should be done with modularity and thread safety in mind from the start..
[19:31] <BBB> <g> then we can start all over again
[19:31] Action: wtay loves to get mpeg2enc librarified though...
[19:31] <BBB> :)
[19:31] <BBB> mpeg2enc rocks, true....
[19:32] <BBB> can I already do layer-combining in gstreamer?
[19:32] <BBB> someone in mjpegtools has made a start in that, so he might help you too...
[19:32] <wtay> BBB: define that pls?
[19:32] <wtay> like a muxer?
[19:32] <BBB> muxer?
[19:32] <wtay> mplex
[19:32] <BBB> something to combine multiple yuv-streams
[19:32] <wtay> into what?
[19:33] <BBB> so multiple video stream layers into one
[19:33] <BBB> wanna see a sample?
[19:33] Action: BBB thinks how he's gonna do that
[19:33] <wtay> an mpeg system stream with multiple video elementary streams?
[19:34] <BBB> something like that....
[19:34] <wtay> we can do that
[19:34] <BBB> already?
[19:34] <BBB> kewl
[19:34] <wtay> system_encode can do that
[19:34] <BBB> so just like premiere, I can do a 50%/50% blend between two movies?
[19:34] <BBB> :)
[19:34] Action: BBB loves that
[19:35] <wtay> you can only create them, not play them back due to the lack of a video mixer
[19:35] <omega_> BBB: FYI, Apple proposed qt as the standard file format for stored MPEG-4, and it was accepted.  qt the file format (not qt the codecs) is well known outside apple
[19:35] <dobey> heh
[19:35] <wtay> which isn't hard actually...
[19:35] <omega_> I will get krasic to find the links and post them in a couple hours (I'll get him in IRC)
[19:36] <dobey> i just want to watch sorensen in linux
[19:36] <BBB> wtay: we can make a single end video of it which we can play back - there's no such thing as "preview", though
[19:36] hadess (hadess at pc121-gui14.cable.ntl.com) joined #gstreamer.
[19:36] <BBB> :|
[19:36] <dobey> dude!
[19:36] <hadess> hi gang
[19:36] <wtay> hi hadess
[19:37] <hadess> hi dobey
[19:37] <hadess> wtay: 
[19:37] Action: omega_ goes to OGI
[19:37] omega_ (omega at omegacs.net) left irc: commute!
[19:37] <hadess> i was let down :/
[19:37] <wtay> hadess: ?
[19:38] <hadess> i was supposed to come back from work with audrey, and she let me down
[19:39] Action: thomas sympathizes with hadess
[19:39] <wtay> hadess: ouch
[19:40] <hadess> bah...
[19:40] thomas (thomas at 212-100-172-175.adsl.easynet.be) left irc: [x]chat
[19:40] <dobey> aww
[19:43] <wtay> hadess: take a beer
[19:43] <hadess> wtay: i'm gonna do that i think
[19:59] <wtay> BBB: is there still much work done on mpeg2enc?
[20:08] <BBB> yes
[20:09] <BBB> a lot
[20:09] Action: BBB gave up on quicktime
[20:09] <BBB> just jpeg then :(
[20:09] <BBB> stupid thing, refuses to compile without DV support :(
[20:09] <BBB> I'm gonna write Adam an e-mail to fix that.
[20:09] <BBB> I hate that guy
[20:11] <wtay> heh
[20:11] <wtay> tell him to make a libmped2enc too
[20:11] <wtay> s/mped/mpeg
[20:17] <BBB> lol
[20:17] <BBB> ok
[20:37] Nick change: BBB -> BBB-[away]
[20:37] Action: BBB-[away] is away: gtg shopping
[20:53] ChiefHighwater (paul at temple-baptist.com) left irc: 
[21:18] greg_ (greg at home.sente.pl) left irc: Ping timeout for greg_[home.sente.pl]
[21:19] greg_ (greg at home.sente.pl) joined #gstreamer.
[21:20] chillywilly (baumannd at 155.92.201.243) joined #gstreamer.
[21:36] dobey (dobey at dreadnought.ximian.com) left irc: eh
[21:38] thomas (thomas at adsl-64038.turboline.skynet.be) joined #gstreamer.
[21:42] <thomas> wtay ?
[21:42] <wtay> yeah
[21:42] <thomas> I've been wondering why I'm having problems with osssink
[21:42] <wtay> problems?
[21:43] <thomas> (because when i use it in the mixer, the audio is totally wrong)
[21:43] <wtay> I know why
[21:43] <thomas> and when I compare esdsink and osssink, they have different parameters
[21:43] <thomas> why ?
[21:43] <wtay> you don't do caps negotiation in the mixer
[21:43] <thomas> doesn't surprise me ;)
[21:43] <thomas> are you done with the caps nego stuff ?
[21:44] <thomas> I mean, is it still being reworked ?
[21:44] <wtay> no but It'll work
[21:44] <wtay> I'm not satisfied with it yet
[21:44] <thomas> ok... so any idea why osssink and esdsink have different kinds of parameters
[21:44] <thomas> that seem to do the same ?
[21:44] <wtay> they do?
[21:44] <thomas> well I'm not sure...
[21:44] <thomas> but I can see, for osssink :
[21:45] <thomas> format as an int, width and depth both as either 8 or 16
[21:45] <wtay> ok
[21:45] <thomas> or else I'm not clear what format is about
[21:45] <thomas> esdsink doesn't seem to have width as an argument
[21:45] <wtay> int == integer bytes
[21:46] <wtay> CVS?
[21:46] <thomas> yeah.
[21:46] <wtay> I thought I fixed that
[21:46] <thomas> so what does format describe, actually ? it's not clear from the code ?
[21:47] <wtay> format == int means that the samples are integers
[21:47] <wtay> format == float means float samples
[21:47] <thomas> ah, ok... well the oss plugin mentions this in the element arguments :
[21:47] <thomas>   GstOssSink::format: Enum (default 16)
[21:47] <thomas>     (8):        8 Bits
[21:47] <thomas>     (16):       16 Bits
[21:47] <thomas> while esd mentions this
[21:47] <thomas>   GstEsdsink::depth: Enum (default 16)
[21:47] <thomas>     (8):        8 Bits
[21:47] <thomas>     (16):       16 Bits
[21:48] <thomas> ... but since these are the GTK_settable objects...
[21:48] <thomas> it doesn't matter for gstreamer internals then, does it ?
[21:48] <wtay> that's an incosistency
[21:48] <wtay> it doesn't matter
[21:49] <thomas> ok... and what difference is there between width and depth ?
[21:49] <wtay> width == padding
[21:49] <wtay> depth == actual bits used in the width
[21:49] <wtay> so width = 16, depth = 12 is possibler
[21:50] <thomas> hmmm... is this useful in video ?
[21:50] <wtay> yes
[21:50] <thomas> and should filters take this into account ?
[21:50] <wtay> possibly
[21:50] <wtay> if they can't they should set depth==width
[21:50] <wtay> and only list what they can handle
[21:51] <thomas> ok... thanks
[21:51] <thomas> so, what example can I copy to fix the mixer's caps nego ?
[21:51] <wtay> is the mixer always going to send out the same format?
[21:51] <thomas> no, I wouldn't think so...
[21:52] <thomas> basically it could be 8 bit input, or mono input, or four channel input for that matter
[21:52] <thomas> do you mean the same format in one instance of it ?
[21:52] <wtay> does it output the same format as it inputs?
[21:52] <thomas> right now, I'm keeping it that way
[21:53] <thomas> but there's no real reason for it
[21:53] <thomas> depends on how big it's going to get
[21:53] <thomas> do you want gstreamer plugins to be light-weight single-function and have functionality be implemented by the plans...
[21:53] <thomas> ...or do they have to do a lot at the same time ?
[21:53] <wtay> I would suggest that it always sinks the same type as it sources, adding converters to the pads if necessary
[21:54] <thomas> yes, that's how I'd like to do it
[21:54] <wtay> ok
[21:54] <thomas> ... but does that mean that the mixer plugin is responsible for setting up ways to it's pad ?
[21:54] <thomas> or is the app ?
[21:55] <thomas> wtay: no wait, hang on.  I wouldn't sink the same type as the source, since there's more than one source.
[21:55] <thomas> so I guess the best way is to set it from the app
[21:55] <wtay> you should IMO
[21:55] <thomas> I should what ?
[21:55] <wtay> sink/src the same type on all the pads
[21:55] <wtay> it's going to get messy else
[21:56] <wtay> rate conversion etc...
[21:56] <wtay> it's best handled by other plugins
[21:56] <thomas> yes... but how do you decide what format the mixer will use ?
[21:56] <thomas> or do I just say "this is a 16 bit stereo mixer" ?
[21:56] <wtay> lets say the mixer addapts itself to the first input pad and forces all other inputs pads to be of the same type
[21:57] <thomas> wtay: yes, that would be the other alternative.
[21:57] <thomas> but it feels to random.
[21:57] <thomas> I mean too random.
[21:57] <thomas> so if you start with a bad song, you're stuck.
[21:57] <wtay> yeah
[21:58] <wtay> you could have a set of args to force all pads to be of that type...
[21:58] <thomas> yeah, I think that's best.
[21:58] <wtay> ok, for now I guess it is
[21:58] <thomas> btw suppose the app wants to do 24 bit mixing ...
[21:59] <thomas> ... and needs the head room for filtering and stuff ...
[21:59] <thomas> ... then it would probably make more sense to allow that to be set in advance
[21:59] <wtay> yeah
[21:59] <thomas> so, does that mean the mixer doesn't need to do caps nego ?
[22:00] <wtay> depends...
[22:00] <wtay> thinking..
[22:00] <wtay> hmm
[22:00] <thomas> the caps should be set by arguments and then forced on in and outputs, no ?
[22:00] <wtay> it does
[22:00] <wtay> yes
[22:01] <wtay> also the rate?
[22:01] <wtay> or channels?
[22:01] <thomas> well, the rate is tricky.
[22:01] <thomas> channels as well, but easier.
[22:01] <thomas> they should both be set from the start...
[22:02] <thomas> ok the problem is you can't do rate right until gstreamer has a sense of time
[22:02] <wtay> ok, then you don't need capsnego
[22:02] <thomas> in what case would I have needed it then ?
[22:02] <wtay> no entirely I think..
[22:02] <thomas> I'm not yet all clear about the caps nego thing
[22:03] <wtay> if you wanted to set the sink properties to those of the src properties
[22:03] <wtay> caps describe the media types of the pads
[22:03] <thomas> so caps nego in that case means "matching capabilities inside of the plugin" ?
[22:03] <wtay> matching the properties with those of the peer plugins
[22:04] <thomas> oh, ok.
[22:04] <wtay> liek the osssink...
[22:04] <thomas> so where does the esdsink differ from the osdsink there ?
[22:04] <wtay> the mp3decoder sets the properties to what it'll output
[22:04] <thomas> ... and osssink matches it.
[22:04] <wtay> thomas: it shouldn't
[22:04] <wtay> osssink has a capsnego function to accept or reject the properties
[22:05] <wtay> it can also suggest something better
[22:05] <thomas> something better ? like what ?
[22:05] <wtay> let's say a plugin says it would like to do 8 channel audio...
[22:06] <wtay> osssink cannot handle it and it suggest to do 2 channel audio instead
[22:06] <wtay> the plugin can then addapt... (if it can of course)
[22:06] <thomas> oh cool... so that will be possible ?
[22:06] <thomas> plugins actually talk to each other then.
[22:06] <wtay> yup
[22:07] <wtay> xvideosink is quite good at it right now
[22:07] <thomas> ok... but as far as I can tell esdsink and osssink only differ right now in that esdsink actually has two elements, 8bit and 16bit, while oss seems to handle it in one element
[22:07] <thomas> could that cause problems ?
[22:07] <wtay> hmm, depends..
[22:08] <wtay> esdsink has no nego function
[22:08] <wtay> the padtemplate is very specific so that's enough
[22:08] <wtay> osssink's padtemplate is more generel and so it does capsnego
[22:09] <wtay> esdsink really only can handle a few types
[22:09] <wtay> osssink can handle a lot more
[22:09] <thomas> for example ?
[22:10] <wtay> actually not really but...
[22:10] <wtay> osssink can potentially support ac3 and mulaw
[22:10] <thomas> ok... but it's not coded in yet ?
[22:10] <wtay> osssink can be optimised quite a bit in fact...
[22:10] Nick change: taazzzz -> taaz
[22:10] <wtay> depends on the oss driver actually
[22:11] <wtay> in fact the padtemplates should be generated from the oss capabilities
[22:11] <wtay> like xvideosink does when it probes X
[22:11] <thomas> what ? automatically ?
[22:11] <wtay> yeah
[22:11] <thomas> but the oss plugin is responsible for that itself right ?
[22:11] <wtay> yup
[22:11] omega_ (omega at dhcp-57-240.cse.ogi.edu) joined #gstreamer.
[22:12] <wtay> yo omega_
[22:12] <thomas> hi
[22:12] <omega_> yo
[22:12] <wtay> omega_: my previous mpeg2enc code doesn't work anymore :(
[22:12] <omega_> oops
[22:12] <wtay> I'm not surprised but anyway
[22:13] <omega_> now, lemme try gstarts again
[22:13] <wtay> well, it's the pipeline setup that fails...
[22:13] <wtay> I plan to do some vob to mpeg1 encoding this evening...
[22:13] <omega_> cool
[22:14] <omega_> um, so what I was seeing with gstarts was that oss_sync_parms wasn't ever getting called in the normal connect() case
[22:14] <wtay> I'll use the autoplugger so libdv should work out of the box too...
[22:14] <BBB-[away]> omega_!! :)
[22:14] <omega_> I had to hack it to do that on startup, at least, and that only partially fixed the problem
[22:14] <BBB-[away]> I kicked out libdv, quicktime will not support libdv in our case :)
[22:14] <wtay> omega_: ok, I fixed up a capsnego proxy function in identity, this is what you'll need
[22:15] <omega_> not entirely...
[22:15] <wtay> you also need to adjust some properties?
[22:16] <omega_> no, just caps
[22:16] thomas (thomas at adsl-64038.turboline.skynet.be) left irc: Client Exiting
[22:16] <wtay> what is the relation between sink and src caps then?
[22:18] <omega_> I set arts caps to s16le, and that's not what osssink is doing
[22:18] <omega_> or something else is wrong, but the resulting audio is fast and clicking
[22:18] <wtay> omega_: you set the caps on the src pad?
[22:18] <omega_> template, yes
[22:19] <omega_> I shouldn't need to force them
[22:19] <wtay> oh ok, the template caps are not automatically set to the pad
[22:19] <omega_> I do a new_with_template
[22:20] <wtay> you should have a gst_pad_set_caps somewhere in the chain/loop function as well..
[22:21] <omega_> hrm, it seems to work better now, checking
[22:21] <omega_> nope
[22:21] <omega_> um
[22:21] <omega_> if the template caps are sufficient, I shouldn't need to set them
[22:21] <omega_> imo
[22:22] <omega_> can I do set_caps in _init ?
[22:22] <wtay> well, right now, the caps negotiation is not triggered without a _set_caps somewhere
[22:22] <omega_> I thought connect() triggered an implicit negotiation?
[22:22] <wtay> checking...
[22:23] <wtay> yup, it will
[22:23] <omega_> it isn't
[22:23] <wtay> you can set the caps in _init then
[22:23] <omega_> ok
[22:23] <wtay> the prob might be that the capsnego function of oss will be trigered when it has not actually opened the device yet...
[22:24] <omega_> hmm
[22:24] <wtay> it should do a _sync when the device is opened...
[22:25] <omega_> right
[22:25] <wtay> I'll change that...
[22:29] <wtay> ok, that should work
[22:31] greg_ (greg at home.sente.pl) left irc: Read error to greg_[home.sente.pl]: EOF from client
[22:32] <wtay> omega_: do you know the rate property ad pad creation time?
[22:33] <omega_> it's hardcoded to s16le stereo 44.1 so far
[22:33] Action: omega_ works with krasic and wagle on a libdv decoder plugin
[22:33] <wtay> ok
[22:33] <wtay> cool
[22:33] Action: wtay goes back to his mpeg1 encode...
[22:45] chillywilly (baumannd at 155.92.201.243) left irc: Philosophers and plow men, each must know his part, to sow a new mentality closer to the heart...
[22:59] <omega_> wtay: try gstmediaplay of AlienSong.mpg, you'll hear the problem I have with gstarts
[23:00] <wtay> ouch!
[23:00] <wtay> hmm
[23:00] <omega_> yeah
[23:00] <wtay> what happened!
[23:01] <omega_> audio params
[23:02] <omega_> is YUY2 supported in colorspace?
[23:03] <wtay> I420 is
[23:03] <wtay> if you have Xv it'll work with Xv
[23:03] <omega_> no xv
[23:03] <wtay> is YUY2 planar?
[23:04] <omega_> yes
[23:04] <omega_> it's 4:2:2
[23:04] <wtay> hmm, no luck then
[23:04] <wtay> it's not like I420 with Cr/Cb switched?
[23:04] <omega_> no, it's 4:2:2
[23:05] <wtay> do you have YUY2 to RGB?
[23:05] <omega_> yes
[23:05] <omega_> we can integrate it, or you can <g>
[23:05] <omega_> libdv.sourceforge.net <g>
[23:05] <omega_> if you want to do that while we write the libdv stuff
[23:05] <wtay> ok, I'll check it out.. but first the audio probs
[23:05] <omega_> ok
[23:06] <wtay> pfff, everything crashes now..
[23:07] <omega_> don't do that
[23:14] Action: wtay is doing a full rebuild
[23:15] <omega_> good idea <g>
[23:16] <wtay> gstmediaplay doesn't even play a simple mpeg1 anymore...
[23:17] <omega_> oops
[23:18] <wtay> strange... I didn't change anything...
[23:20] <omega_> goblins...
[23:21] <wtay> hmm, now it works again... but AlienSong still is wrong...
[23:23] <wtay> hehe, it looks like mad can't decode the AlienSong sund
[23:23] <wtay> s/sund/sound
[23:23] <wtay> or not...
[23:28] <taaz> isnt that about the same as multithreaded?
[23:28] <wtay> aaarghh, mad buffer fill code dosn't take nchannels into account..
[23:28] <taaz> crap... wrong window ;)
[23:32] <omega_> oops
[23:32] <wtay> and I added propper syncing too...
[23:33] <wtay> there, fixed mad in CVS..
[23:44] richardb (richard at ixion.tartarus.org) joined #gstreamer.
[23:44] <wtay> hi
[23:44] <richardb> Evening...
[23:45] <richardb> Todays been the first chance I've had to catch up with projects since being at GUADEC.
[23:45] <richardb> How's it been going?
[23:46] <omega_> getting stuff working, slowly <g>
[23:46] <omega_> wtay just broke things quite thoroughly, again <g>
[23:46] <richardb> Got my email about version numbers yet?
[23:46] <wtay> naah , it's ok
[23:47] <omega_> no
[23:48] taaz (dlehn at 66.37.66.32) left irc: Disconnecting
[23:48] <richardb> Hmm.
[23:48] taaz (dlehn at 66.37.66.32) joined #gstreamer.
[23:48] <richardb> I'm getting core dumps due to out of date plugins too frequently. 
[23:51] <omega_> date plugins?
[23:51] <omega_> duh
[23:51] <omega_> 'out of date plugins'
[23:51] Action: omega_ needs to recompile/restart his english parser...
[23:51] <richardb> Ones compiled against a previous version of the library.
[23:51] <richardb> core library.
[23:52] <richardb> eg, I have an old videosink plugin lying around.
[23:52] <richardb> I can just delete it to fix the problem, but would be better to prevent problem in future.
[23:55] <richardb> I think that plugins should only be expected to work with a core library which has the same major and minor version numbers as that the plugin was compiled against.
[23:58] <wtay> then we should have bumped the version number between that change...
[23:59] <richardb> Or, we could give plugin_init() with both the major and minor version numbers of the core as parameters..
[23:59] <richardb> typedef GstPlugin* (*GstPluginInitFunc) (GModule *module, gint major, gint minor);
[00:00] --- Sat Apr 21 2001
[00:01] <wtay> I think I prefer the core to make the decision, the plugin states it's build against version X.Y, core decides it cannot be loaded
[00:02] <omega_> wtay: what're the props for rgb24 ?
[00:02] <wtay> omega_: look at xvideosink.c line 521
[00:03] <richardb> I suppose having the core decide would reduce code duplication...
[00:03] <wtay> FOURCC is "RGB ", red/green/blue are done with a bit mask
[00:03] <wtay> we then could decide that plugins prior to X.Y are incompatible...
[00:03] <omega_> bpp 24, depth 24, endian LITTLE, red_mask 0xff0000, etc., ?
[00:04] <omega_> 0.5 ish?
[00:04] <wtay> omega_: yup
[00:04] <richardb> Not sure what neatest way for a plugin to give its version number would be.
[00:04] <richardb> Could look up another (two?) symbols.
[00:05] <wtay> richardb: the elementfactory has the version number
[00:05] <wtay> omega_: "0.5 ish"?
[00:06] <richardb> wtay: but that's created too late...
[00:06] <richardb> wtay: and a plugin might not have an element factory at all...
[00:06] <omega_> oh, sorry, I thought you were asking when the API would be stable enough to start bothering to check
[00:06] <richardb> I think we need to check more when the API is _unstable_.
[00:07] <omega_> hehehe
[00:07] <wtay> we could add a version to _plugin_new...
[00:07] <omega_> wtay: is there a test program I can derive from to do 1394src -> dvdec -> colorspace -> xvideosink ?
[00:08] <richardb> _plugin_new() might work, yes.
[00:08] <wtay> omega_: hmm, not really.. test/mp3mad.c comes close...
[00:09] <richardb> As long as all plugins check the version number, of course. ;-)
[00:09] <wtay> richardb: no, the core would refuse to register the plugin is the version is too low
[00:10] <richardb> Sorry: I meant "As long as all plugins check the return value of gst_plugin_new()."
[00:10] <wtay> richardb: right :-)
[00:10] <wtay> richardb: they should
[00:10] <richardb> Indeed.
[00:10] <wtay> richardb: they currently all do
[00:10] <omega_> wtay: mp3mad doesn't have a videosink, does it???
[00:11] <wtay> omega_: true... you'll need the code from videotest too
[00:11] <wtay> omega_: actually videotest2 is better
[00:12] <omega_> ok
[00:12] <wtay> omega_: v4lsrc -> xvideosink
[00:14] <wtay> hmm, a thread issue in xvideosink with the bufferpool alloc...
[00:14] <omega_> right
[00:15] <omega_> causes segfault?
[00:17] <wtay> omega_: yup, XvImage alloc and XvPut with the same X connection
[00:17] <omega_> hmm
[00:40] Action: wtay just found out the difference between XSync and XFlush
[00:48] <omega_> any progress on the videosink issues?
[00:49] Action: omega_ isn't using bufferpools, btw
[00:49] <omega_> #0  0x40572c8b in memcpy (dstpp=0x40698000, srcpp=0x40732008, len=1036800) at ../sysdeps/generic/memcpy.c:55
[00:49] <omega_> #1  0x406940d4 in gst_xvideosink_chain (pad=0x80bec60, buf=0x80dd3e8) at xvideosink.c:429
[00:50] <omega_> wtay: ping?
[00:54] <wtay> pong, sorry was away
[00:54] <wtay> I commited the locking
[00:55] <richardb> Have a patch adding major and minor version paramters to gst_plugin_new(), and modifying all plugins appropriately.  Just about to test: seems to work though.
[00:55] <omega_> wtay: no change
[00:56] <wtay> omega_: what exactly is wrong?
[00:56] <omega_> segfault
[00:56] <omega_> see above
[00:56] <wtay> in the memcpy?
[00:57] <omega_> yes
[00:57] <omega_> mpeg1encoder is faulting in _new_picture, in fwrite(?!)
[00:57] <omega_> but focus on the videosink
[00:57] <wtay> is the display 24 bits?
[00:58] <omega_> the data is
[00:58] <omega_> display is 15 or 16
[00:58] <wtay> ah ok, you have a colorspace element too?
[00:58] <omega_> um, no
[00:58] <omega_> oops
[00:58] <wtay> doh
[00:59] <omega_> 'nother fault
[00:59] <taaz> walken put some X completion event stuff in mpeg2dec output code... does xvideosink do that sort of thing?
[00:59] <omega_> dunno
[00:59] <omega_> wtay: same stack
[01:00] <omega_> #0  0x40572c8b in memcpy (dstpp=0x4069d000, srcpp=0x4075b008, len=1036800) at ../sysdeps/generic/memcpy.c:55
[01:00] <omega_> #1  0x406992a8 in gst_xvideosink_chain (pad=0x80c0930, buf=0x80df088) at xvideosink.c:447
[01:00] <omega_> wtay: this isn't impressing krasic <g>
[01:01] <omega_> can I inspect what hte colorspace converter has set up for?
[01:03] Action: wtay is seriously distracted..
[01:03] Action: omega_ thwacks wtay into working on videosink <g>
[01:04] <wtay> hmm
[01:04] <richardb> Okay; this versioning patch seems to work.
[01:04] <richardb> It's only going to work properly if the minor version number is updated whenever a change to the plugin API is made, though.
[01:05] <richardb> It's also a patch which touches all plugins, and now probably isn't a good time to commit it.
[01:05] <wtay> omega_: you'll need to add GST_INFO to colorspace, I'll do that now...
[01:06] Action: richardb tries to remember how to make a CVS branch.
[01:06] <richardb> Going to bed now actually, I'll make a branch tomorrow for this.
[01:06] <omega_> richardb: ok, one of us should be on when you do it <g>
[01:06] <omega_> cvspolicy.txt
[01:07] <wtay> grrr
[01:08] <wtay> are you using a queue too?
[01:08] <omega_> no
[01:08] <richardb> Goodnight.
[01:08] Nick change: richardb -> richardb-away
[01:08] <wtay> cya
[01:08] <wtay> ok
[01:08] <wtay> building a colorspace with very verbose output now...
[01:12] <wtay> omega_: can you try colorspace from CVS... paste the ouput here...
[01:14] <omega_> ok
[01:16] <omega_> what category ?
[01:16] <wtay> just g_print
[01:16] <omega_> um, none
[01:16] <wtay> nothing?
[01:16] <omega_> nothing
[01:17] <wtay> that explains...
[01:17] <omega_> no nego?
[01:17] <wtay> so negotiation must have failed...
[01:17] <omega_> or not happened.........
[01:17] <omega_> I don't force caps, remember
[01:17] Action: omega_ thinks nego should be tried on connect()
[01:17] <wtay> it is
[01:17] <omega_> it is?
[01:17] <omega_> hrm
[01:18] <omega_> for AS.mpg
[01:18] <omega_> colorspace: no common format found
[01:18] <omega_> set up converter for 30323449 to 20424752
[01:18] <omega_> colorspace: YUV to RGB
[01:18] <wtay> ok, thats good
[01:19] <wtay> does it print  colorspace: no common format found for libdv too?
[01:21] <wtay> do you set the caps at init time now? 
[01:21] <omega_> no
[01:22] <omega_> 129.95.57.240 wtay at wtay
[01:22] <wtay> ok, you should to that with gst_pad_set_caps (pad, gst_pad_get_padtemplate_caps (pad))
[01:22] <omega_> ~omega/gst/test/dvshow
[01:22] <wtay> ok
[01:24] <omega_> xhost + on :0
[01:25] <wtay> I'll add the caps to the pad now in dvdec.c
[01:25] <omega_> um, ok
[01:26] <wtay> ok, I see the caps error now too...
[01:27] <wtay> do you have a dv file somewhere?
[01:27] <omega_> ~/media/pond.dv
[01:27] <omega_> disksrc ! dvdec ! ....
[01:28] <omega_> the camera is on (again), so you can use gst1394src
[01:28] <wtay> oh ok...
[01:29] <wtay> heh, yeah...
[01:29] <wtay> of course
[01:30] <wtay> you connect the dvdec src pad to colorspace, which cannot do proper negotiation because the videosink is not yet attached...
[01:30] <omega_> oh
[01:31] <wtay> hmm
[01:32] <wtay> you can either set caps right before the pad_push or connect colorspace to xvideosink first
[01:33] <omega_> trying connect
[01:33] <wtay> and colorspace should be more intelligent
[01:33] <omega_> um
[01:33] <omega_> it doesn't fault
[01:34] <omega_> but there's a window of 0x0 size???
[01:34] <wtay> but...
[01:34] <omega_>   gtk_object_set(GTK_OBJECT(videosink),"width",720,"height",480,NULL);
[01:34] <wtay> omega_: yeah, I still havn't figured out how to set the size of a gtk_plug...
[01:34] <omega_> so ??
[01:34] <omega_> it also fraggs the disk for some reason
[01:35] <wtay> any indication of RGB converter setup?
[01:35] <omega_> initializing dv decoder
[01:35] <omega_> colorspace: no common format found
[01:35] <omega_> set up converter for 20424752 to 20424752
[01:35] <omega_> source red mask   00ff0000
[01:35] <omega_> source green mask 0000ff00
[01:35] <omega_> source blue mask  000000ff
[01:35] <omega_> source bpp        00000018
[01:35] <omega_> dest red mask   0000f800
[01:35] <omega_> dest green mask 000007e0
[01:35] <omega_> dest blue mask  0000001f
[01:35] <omega_> dest bpp        00000010
[01:35] <omega_> converter set up
[01:35] <omega_> set up converter for 20424752 to 20424752
[01:35] <omega_> source red mask   00ff0000
[01:35] <wtay> cool
[01:35] <omega_> source green mask 0000ff00
[01:35] <omega_> source blue mask  000000ff
[01:35] <omega_> source bpp        00000018
[01:35] <omega_> dest red mask   0000f800
[01:35] <omega_> dest green mask 000007e0
[01:36] <omega_> dest blue mask  0000001f
[01:36] <omega_> dest bpp        00000010
[01:36] seer (seer at tela.nethelpnow.com) joined #gstreamer.
[01:36] <omega_> converter set up
[01:36] <omega_> yo
[01:36] <wtay> hmm twice
[01:36] <wtay> yo
[01:36] <seer> hey there!  when is the next release going to be?
[01:36] <omega_> um ;-)
[01:36] <wtay> resizing the window doesn't help at all?
[01:36] <omega_> what window?
[01:36] <seer> I haven't tried today yet, but I haven't been able to build CVS version recently
[01:36] <wtay> omega_: the 0x0 one :)
[01:37] <wtay> seer: lots of bugs :(
[01:37] <omega_> seer: can you post the errors to the list?
[01:37] <omega_> we don't get all the errors on our machines, obviously <g>
[01:37] <seer> sure.. i'll try it again today.  the last version I have working is great.  
[01:38] <seer> it seg faults every now and then, but with the input i'm feeding it, i'm glad it doesn't try to bite my head off!
[01:38] <wtay> heh
[01:39] <omega_> wtay: any clue?
[01:39] <wtay> omega_: no output?
[01:39] <omega_> nothing new
[01:39] <omega_> there's a window, with 'test' in it....
[01:39] <wtay> but there's nothing in it
[01:39] <omega_> ah
[01:39] <omega_> there is something
[01:40] <omega_> I get an incorrectly strided view
[01:40] <omega_> then it faults
[01:40] <omega_> I think it oom's
[01:40] <seer> oh, i also read something about a plugin for mozilla using gstmediaplay.  does that exist for real?
[01:40] <omega_> supposedly
[01:40] Action: omega_ hasn't seen it yet
[01:42] <wtay> omega_: the oom could be in colorspace, checking...
[01:42] <seer> also, how far "along" would you say gstreamer was?  i mean, should I be showering Apple with emails asking for a Sorensen plugin yet? :-)
[01:42] <seer> whoops.  here's a compile time bug for ya:
[01:42] <seer> In file included from gsttypes.c:21:
[01:42] <seer> ../../gst/gst.h:29:28: gst/gstversion.h: No such file or directory
[01:42] <omega_> oops, re-autogen
[01:43] <wtay> omega_: colorspace has no leaks...
[01:43] <omega_> maybe we should have a keyphrase we put in our commit logs that tells people to re-autogen <g>
[01:43] <wtay> omega_: how far off is the stride?
[01:43] <seer> should I --prefix=/usr --sysconfdir=/etc like I do for most GNOME apps?
[01:43] <omega_> I never install gstreamer
[01:43] <omega_> autogen puts in options that lets you do everything from the build dir
[01:44] <seer> cool.  it's funny.  using bleeding edge software has taught me so much about the GNU tool set :-)
[01:45] <omega_> wtay: did you just break my copy again?
[01:45] <omega_> I can't show video anymore
[01:45] <seer> silly question: do I have to do anything crazy to get my v4l source to go thru gstreamer?
[01:45] <wtay> omega_: I didn't touch it?
[01:46] <omega_> wtay: you're supposed to be!!! :-)
[01:46] <wtay> I added a line to dvdec.c with caps copy, that's all...
[01:46] <omega_> seer: a chicken or two would be good to have handy, to sacrifice to the capsnego subsystem <g>
[01:47] <seer> coming right up.  
[01:47] <seer> what about caffeine products instead?
[01:48] <omega_> that works too
[01:48] <omega_> send them to wtay
[01:48] <wtay> yeah, I need it...
[01:49] Action: omega_ is killing time adding audio
[01:49] <wtay> ooh
[01:49] <wtay> damn
[01:50] <omega_> don't hack dvdec.[ch] without telling me
[01:50] <wtay> a bug
[01:50] <omega_> <gasp!>
[01:50] <wtay> no colorspace...
[01:50] <omega_> howso?
[01:51] <wtay> the dest stride was used as the src stride...
[01:52] <wtay> try again
[01:52] <omega_> fault
[01:52] <omega_> you can try it
[01:52] <omega_> display=:0
[01:52] <wtay> dvshow?
[01:53] <omega_> yeah
[01:53] <omega_> that would be you <G>
[01:53] <wtay> what happened?
[01:53] <omega_> bugbuddy
[01:53] <omega_> libtool gdb dvshow
[01:54] <wtay> Element: /bin/decoder
[01:54] <wtay> Error: source element has no pad "src"
[01:54] <wtay> ***** attempting to stack trace.... *****
[01:54] <wtay> can you run -register
[01:54] <omega_> dohe
[01:55] <omega_> you can run it too now
[01:56] <seer> ahh.. got further that last compile ... looks like it's gonna work :-)  Thanks!
[01:56] <wtay> Error: source element has no pad "src"
[01:56] <omega_> heh
[01:56] <omega_> oops
[01:56] <omega_> fixing
[01:56] seer (seer at tela.nethelpnow.com) left irc: [x]chat
[01:57] <omega_> um, sec...
[01:57] <omega_> grrr
[01:58] <omega_> grrrrrrr
[01:59] <omega_> oh
[01:59] <omega_> um
[01:59] <omega_> scheduling problem, darnit
[01:59] <omega_> working around
[01:59] <omega_> ok, try again
[02:00] <wtay> what did you do now?
[02:00] <wtay> uh oh
[02:00] <wtay> yeah, dvshow should ask for the video pad then :-)
[02:00] <omega_> yeah, fixed
[02:00] <wtay> -register?
[02:00] <omega_> you can
[02:00] <wtay> #1  0x40956233 in bitstream_next_word () at parse.c:95
[02:00] <wtay> #2  0x409579b6 in dv_parse_header (dv=0x8107f58, buffer=0x8109990 "\037\a") at bitstream.h:117
[02:00] <omega_> huh?
[02:00] <wtay> that's not my problem :-)
[02:00] <omega_> erm, kill and lemme try
[02:01] <omega_> I don't get that
[02:01] <omega_> image!
[02:01] <omega_> rgb/bgr
[02:01] <omega_> oom
[02:01] <omega_> window size is still screwed
[02:02] <omega_> I have to resize it before oom kills it
[02:02] <wtay> known issue...
[02:02] <omega_> can it be fixed??
[02:02] <omega_> gstplay works
[02:03] Action: omega_ is leaking
[02:04] <wtay> you can set the size of the gtk_plug
[02:04] <wtay> I don't know how to send the size to the gtk_plug from the xid
[02:04] <wtay> xvideosink has a signal when the size is known, I use this to set the size of the gtk_plug in gstplay
[02:04] <omega_> no, not leaking, something else is killing it
[02:04] <wtay> hmm
[02:04] <wtay> gstplay works with dv?
[02:05] <omega_> no
[02:05] <omega_> no typefind
[02:05] <wtay> ok
[02:05] Action: omega_ has no idea what's causing the thrashing
[02:06] <wtay> I can't spot a leak in colorspace or videosink
[02:06] Action: omega_ is going to try it from a file
[02:06] <omega_> maybe 1394 doesn't take kindly to being held up
[02:07] <wtay> internal buffering maybe
[02:07] <omega_> hrm, get fault immediately on pond.dv
[02:08] <wtay> how do you play that?
[02:08] <omega_> it works in gdb
[02:08] <wtay> doh
[02:10] Action: omega_ thinks -launch should add intelligence to handle xvideosink
[02:10] Action: wtay thinks a special bin should be added that has knowledge of the xvideosink
[02:11] <omega_> maybe
[02:11] <omega_> I think launch should be sufficient
[02:11] <wtay> launch will become dependent of X stuff then
[02:14] <wtay> what happens?
[02:19] <omega_> a lib...'
[02:20] <wtay> ?
[02:21] Action: wtay continues to hack on the mpeg1 encoder...
[02:22] Action: omega_ is distracted
[02:27] <BBB-[away]> g'nite guys
[02:27] <BBB-[away]> 2.40am here
[02:27] <wtay> 'night
[02:27] <wtay> same here
[02:27] <BBB-[away]> does the libdv in gstreamer work already?
[02:27] <wtay> nope
[02:27] <BBB-[away]> okay - great job nevertheless
[02:27] <BBB-[away]> I will send Andrew an e-mail tomorrow about the mpeglibencoder
[02:28] <wtay> cool
[02:28] <BBB-[away]> or I can give you his e-maila ddy if you want
[02:28] <wtay> ok
[02:28] <BBB-[away]> andrew.stevens at philips.com
[02:28] <wtay> ok thx
[02:28] <BBB-[away]> np
[02:28] <wtay> will mail him tomorrow too
[02:29] <BBB-[away]> happy hacking, I've done enough and got libdv out of quicktime after all (stupid me)
[02:29] <BBB-[away]> now someone else can get libdv linked to MJPEGtools and then we cna start having fun :)
[02:29] <BBB-[away]> and I will start in a few weeks porting 'lav' to gstreamer
[02:29] <BBB-[away]> g'nite - zzzzzzzzzzzz
[02:29] Nick change: BBB-[away] -> BBB-[away]-[away]
[02:29] Action: BBB-[away]-[away] is away: zzzzzzzzzzzz
[02:30] Nick change: BBB-[away]-[away] -> BBB-zZz
[02:43] ajmitch (ajmitch at p20-max1.bal.ihug.co.nz) joined #gstreamer.
[02:45] <wtay> yo
[02:45] <omega_> wtay: aren't you supposed to be asleep?
[02:45] <wtay> yeah
[02:45] <wtay> well..
[02:47] <wtay> I can't seem to get enough of those lovely segfaults :)
[02:55] <ajmitch> hi ppl
[02:55] <ajmitch> someone send me a decent computer, this one's probably too crap to run gstreamer stuff
[02:55] <ajmitch> ;)
[03:03] <hadess> bye guys
[03:03] <wtay> bye
[03:12] hadess (hadess at pc121-gui14.cable.ntl.com) left irc: sleep
[03:21] omega_ (omega at dhcp-57-240.cse.ogi.edu) left irc: restarting X with new driver (Xv maybe?)
[03:37] jack (jack at i.cantcode.com) joined #gstreamer.
[03:37] <jack> hola hola
[03:37] <jack> anybody around?
[03:37] <wtay> yo
[03:37] <jack> is anyone working on rtp stuff?
[03:38] <wtay> an rtp sink is done AFAIK
[03:38] <jack> i don't know much about gstreamer.. trying to get up to speed
[03:38] <jack> although you guys seem to be doing complementary work to us
[03:38] <jack> (i do icecast and vorbis)
[03:39] <wtay> cool
[03:39] <jack> is there any work being done to use this on other platforms?
[03:39] <wtay> like?
[03:39] <jack> win32, macos, and beos
[03:40] <wtay> hmm no
[03:40] <jack> any reason why not?
[03:40] <taaz> our time machine broke
[03:40] <wtay> lack of knowledge/people helping us
[03:40] <jack> ah
[03:41] <jack> would be nice to have something on win32 as well.
[03:42] <jack> and blow microsoft's and real's crap out of the way.
[03:42] <wtay> yeah I totaly agree
[03:42] <wtay> depends actually on how portable the glib2.0 threading stuff will be I think
[03:42] <ajmitch> hmm
[03:43] <jack> i think that the pthreads for win32 is fairly mature now.
[03:43] <ajmitch> do you really want to show those windows users what software shouldbe like?
[03:43] <jack> back when i first wrote icecast 1.3, i had to wrap native win32 threads and pthreads with something more abstract.
[03:43] <jack> now with 2.0 i'm planning on using pthreads only.
[03:44] <wtay> glib will be our abstraction layer
[03:44] <jack> are there a lot of glib people working with win32?
[03:44] <wtay> no idea...
[03:45] <wtay> GTK has been ported
[03:45] <jack> it would be a shame to lose a great cross platform media framework, just because it depended on glib which was unix-centric.
[03:45] <jack> gtk mostly works in windows.
[03:45] <wtay> glib certainly is aware of other platform
[03:45] <jack> i'm sure glib works much better :)
[03:46] <wtay> video stuff is always a bit harder to wrap...
[03:46] <wtay> especially when it was not developped to be crossplatform
[03:46] <wtay> s/developped/designed
[03:47] <jack> RealNetworks has done a decent job of providing a cross platform api
[03:47] <jack> it's not a good one, but a plugin written to it will work easily on other systems.
[03:47] <taaz> hmm? you mean M$ doesn't support Xv API? ;)
[03:58] ajmitch (ajmitch at p20-max1.bal.ihug.co.nz) left irc: [x]chat
[04:19] <wtay> going to sleep,cya
[04:19] Nick change: wtay -> wtay-zZz
[05:11] seer (seer at gamehendge.org) joined #gstreamer.
[05:12] <seer> hey all.. anyone alive?
[05:12] <seer> my gstreamer-register is seg faulting on me.. recent CVS
[05:12] seer (seer at gamehendge.org) left irc: [x]chat
[05:13] seer (seer at gamehendge.org) joined #gstreamer.
[05:13] <seer> whoops.
[05:17] seer (seer at gamehendge.org) left irc: [x]chat