Menu
▾
▴
[gst-daily] IRC Logs
|
From: IRC B. <wt...@us...> - 2002-01-29 05:27:50
|
*******************************************************************
[03:04] <taaz> wingo: out of curiosity, why does that cothread stuff need its own build sub-system?
[03:04] <Company> hm, should I go into gnomecc and associate audio/mp3 with "gst-launch filesrc location=%s ! spider ! osssink" ? :)
[03:05] <wingo> taaz: because it's logically a separate package, and its configure stuff is really long
[03:05] <RagingMind> Company: spider ?
[03:05] <Company> RagingMind: my new autoplugger :)
[03:05] <wingo> Company: does that work?
[03:05] <Company> wingo: It should, no?
[03:05] <wingo> ! spider ! i mean
[03:06] Action: taaz ponders
[03:06] <wingo> dunno, what with the requet pads and all
[03:06] <Company> wingo: not yet, but you're having it done until I need it ;)
[03:06] <wingo> oh that's right ;)
[03:06] <wingo> maybe i should look into that...
[03:07] rkarl (~rkarl@12.13.175.44) left #gstreamer ("Client Exiting").
[03:09] <wingo> Company: gst_element_connect_elements() does just that?
[03:09] <Company> wingo: yes
[03:10] <Company> try to connect, including request pads
[03:10] <Company> see gst/autoplug/spidertest.c
[03:10] <taaz> so when you have a pipeline like that does it "know" how do move the osssink into a thread with a queue and so on? or is it better to filesrc ! spider ! { queue ! osssink }?
[03:10] <wingo> better with the queue
[03:11] <wingo> that should work anyway
[03:11] <Company> taaz: spider is programmed to work without queues
[03:12] <Company> It was a design decision :)
[03:12] <taaz> does it do video to both audio and video sinks yet? ;)
[03:13] <Company> taaz: yes
[03:14] <Company> taaz: you might want to try it
[03:14] <Company> gst/autoplug/spidertest is a nice little media player :)
[03:15] Action: taaz is very busy writing report due friday ;)
[03:15] <taaz> like last friday
[03:18] <wingo> Company: dude, parse needs a bit more thought i think
[03:18] <Company> ok, if nobody complained yet I can probably go to bed :)
[03:18] <wingo> wait one more thing
[03:18] <Company> ok
[03:18] <wingo> i think parse needs a new separator,
[03:18] <wingo> meaning 'autoplug' or something
[03:19] <wingo> maybe.
[03:19] <Company> uhm, why?
[03:19] <wingo> well, it's not worth staying up for ;)
[03:19] <wingo> because it's so brittle in its implementation. n/m, talking to myself ;)
[03:19] <wingo> go sleep, tomorrow's monday
[03:20] <Company> if this spider thing is really going to do what it seems to do right now, it's almost perfect
[03:20] <Company> since the only real obstacle were unconnected chains
[03:20] <Company> and that's solved now
[03:21] <Company> wingo: I don't need sleep before Monday, I've gotta work tomorrow and that's stupid MS Office stuff ;)
[03:22] <Company> anyway: good night everybody
[03:22] <RagingMind> Company: is spidertest good enough for an mp3 player?
[03:22] <RagingMind> just y or n ;)
[03:22] <Company> RagingMind: it's good enough for a media player, I played mpg's with it
[03:22] <Company> err...
[03:22] <Company> y
[03:23] <RagingMind> cool, good night :)
[03:23] Company (Company@pD9004184.dip.t-dialin.net) left irc: "Client Exiting"
[03:30] derek (~de...@cp...) joined #gstreamer.
[03:31] derek (~de...@cp...) left #gstreamer.
[03:33] Action: RagingMind thinks the scilence was too much for derek ;)
[03:35] <ajmitch> ... silence?... what silence?
[03:36] Action: taaz lets out some silence
[03:36] leif (le...@rd...) left irc: "Client Exiting"
[03:44] RagingMind_ (~Rag...@fl...) joined #gstreamer.
[03:45] Action: RagingMind_ is afraid of 'ls'
[03:53] wingo (wi...@rd...) left irc: "rollin'"
[04:03] RagingMind (Rag...@fl...) left irc: Read error: 113 (No route to host)
[04:03] Nick change: RagingMind_ -> RagingMind
[04:17] ShrimpX (~marius@131.252.244.168) joined #gstreamer.
[05:24] chillywilly (da...@d2...) left irc:
[05:46] walken (fo...@12...) joined #gstreamer.
[05:46] <walken> hi
[05:47] <ajmitch> hi walken
[05:47] <walken> hi
[05:49] wingo (~wi...@rd...) joined #gstreamer.
[05:54] <RagingMind> yllo
[05:54] <ajmitch> an d now we have the mighty wingo...
[06:04] <wingo> you're too kind ;)
[06:05] <ajmitch> ;)
[06:11] <snax> I have something to say:
[06:11] <snax> _ __ _|_ . _ _ _. . . _ . _ . _ . . | _ __
[06:11] <snax> |_| (_ | |/ /_) / | |v| /_) |/ |/ | | | /_) (_
[06:11] <snax> _/ __) | | \__ \_| | | \__ | | |_| \_ \__ __)
[06:11] <wingo> :-)
[06:12] <tnt> Kool.
[06:12] <ajmitch> hehe
[06:12] <snax> now I just need to draw (write?) upper case letters :P
[06:13] <wingo> that's a nice start to an irc screen though ;)
[06:13] <snax> . , _ __ . _|_ . __
[06:13] <snax> V /_) (_ | | | (_
[06:13] <snax> | \__ __) | | | __)
[06:13] <tnt> :-)
[06:14] Action: ajmitch thinks snax has too much spare time ;)
[06:14] <snax> . ._ _| _ _ _|
[06:14] <snax> | | | / | /_) /_) / |
[06:14] <snax> | | | \_| \__ \__ \_|
[06:37] <RagingMind> "see" you people later :)
[06:38] <RagingMind> and snax, just to let you know, your not the only one ;)
[06:38] <wingo> cya
[06:38] RagingMind (Rag...@fl...) left irc: "Client Exiting"
[07:00] Action: wingo sleeps
[07:00] Nick change: wingo -> wingo-zz
[07:07] steveb (~st...@no...) joined #gstreamer.
[07:08] <ajmitch> hey steveb
[07:09] <steveb> mmphhjetlagfuk
[07:11] <ajmitch> hehe, tired still?
[07:12] <ajmitch> grmblsillyrealplayergottadownloadnonfreesoftwaregrmbl
[07:14] <steveb> idontbelieveihavetoworktoday
[07:15] <ajmitch> thatswonderfulnews
[07:16] <steveb> ah, coffee. thats better
[07:16] <ajmitch> hehe
[07:34] <ajmitch> hrmm
[07:34] <ajmitch> looks like the best option until gstreamer gets a realmedia plaugin is to hijack the sound output & dump it into gstreamer
[09:37] Nick change: taaz -> taazzzz
[09:52] thomasvs-sleep (th...@ad...) left irc: Read error: 113 (No route to host)
[10:08] thomasvs (~th...@21...) joined #gstreamer.
[10:08] thomasvs-sleep (~th...@21...) joined #gstreamer.
[10:22] thomasvs-sleep (th...@21...) left irc: "Client Exiting"
[11:06] walken (fo...@12...) left irc: "l8r"
[11:16] bstard (~Lor...@pl...) joined #gstreamer.
[11:34] snax (sn...@12...) left irc: Remote closed the connection
[12:02] thomasvs (th...@21...) left irc: "[x]chat"
[12:53] ShrimpX (marius@131.252.244.168) got netsplit.
[12:53] ShrimpX (~marius@131.252.244.168) returned to #gstreamer.
[13:40] mattias (ma...@ga...) got netsplit.
[13:44] mattias (~ma...@ga...) returned to #gstreamer.
[14:03] thomasvs (~th...@21...) joined #gstreamer.
[14:38] <thomasvs> urgh
[14:38] <thomasvs> whatever happened to configure ? ;)
[14:42] Action: BBB|zZz is back (gone 13:50:24)
[14:42] Nick change: BBB|zZz -> BBB
[15:01] Nick change: wingo-zz -> wingo
[15:01] <wingo> hmm?
[15:02] Action: thomasvs wipes his cvs tree clean
[15:03] harpin (~floh@195.3.98.253) joined #gstreamer.
[15:05] <harpin> hi there, is there anybody who knows this:
[15:06] <harpin> do i still need gtk(2) when compiling with glib2
[15:07] <wingo> no
[15:07] <wingo> and /me leaves ;)
[15:07] Nick change: wingo -> wingo-out
[15:10] BBB (BB...@uc...) left irc: Read error: 104 (Connection reset by peer)
[15:11] BBB (~BB...@uc...) joined #gstreamer.
[15:39] Uraeus (~csc...@c2...) joined #gstreamer.
[15:39] <Uraeus> hello
[15:39] wingo (~wi...@rd...) joined #gstreamer.
[15:40] <thomasvs> hey uraeus
[15:40] <thomasvs> so, anyone care to update me on what happened to autogen/configure in core ?
[15:40] <thomasvs> it does something weird with cothreads, is anything in flux or something ?
[15:41] <wingo> i deleted a lot of stuff,
[15:41] <wingo> and i added a configure for the new cothreads system
[15:41] <wingo> based on pth's configure
[15:41] <wingo> the new cothreads system isn't fully functional yet though
[15:42] <wingo> but it is logically a separate package (ie, checking out gstreamer/gst/cothreads chould build on its own
[15:43] <thomasvs> ?
[15:43] <thomasvs> so what would a separate cothreads package do ?
[15:43] <wingo> it is a coroutines library
[15:44] <wingo> it could go in glib eventually
[15:44] <thomasvs> cool
[15:45] <thomasvs> do they know that yet ?
[15:45] <wingo> no ;)
[15:45] <wingo> it's just a thought at this point
[15:45] <thomasvs> so, shouldn't we move it out of core or something ?
[15:45] <wingo> but it is a separate subsystem
[15:45] <thomasvs> I mean, it's a bit messy atm ;)
[15:45] <wingo> no it's not ;)
[15:45] <thomasvs> I meant the configure part, not the code
[15:46] <wingo> yeah i know. but it doesn't take long, it caches most of its answers
[15:46] <wingo> and when you build gst you'll want to build cothreads too
[15:47] <thomasvs> does it change a lot ?
[15:47] <thomasvs> I mean, is it still in development or set in stone already ?
[15:48] <thomasvs> I like the titles you put there btw ;)
[15:48] <wingo> i'm still working on it at
[15:48] <wingo> atm
[15:48] <wingo> heh
[15:48] <thomasvs> I would like for the main configure to run after the cothread configure though
[15:48] <thomasvs> is that possible ?
[15:48] <wingo> yes
[15:49] <wingo> moving the AC_CONFIG_SUBDIRS up to the top
[15:49] <wingo> i think anyway
[15:58] BBB (BB...@uc...) left irc: Remote closed the connection
[15:58] taazzzz (dlehn@66.37.66.32) left irc: Read error: 104 (Connection reset by peer)
[15:58] BBB (~BB...@uc...) joined #gstreamer.
[16:03] <thomasvs> can someone point me in the right direction as to what gob is ?
[16:03] <wingo> i don't have a url handy,
[16:03] <Uraeus> http://www.5z.com/jirka/gob.html
[16:03] <wingo> but it's a preprocessor for the gtk object system
[16:03] <wingo> makes coding look like c++ ;)
[16:04] <Uraeus> thomasvs: need a link try my index at www.gnome.org/projects :)
[16:05] rkarl (~rk...@hr...) joined #gstreamer.
[16:05] <Uraeus> hi rkarl
[16:05] <rkarl> howdie howdie
[16:05] <BBB> does my rewrite of the AVI muxer (and possibly, later on, of the AVI demuxer) need to be added to the dotplan?
[16:06] <Uraeus> BBB: need is a subjective term, but it doesn't hurt :)
[16:06] <BBB> lemmetry
[16:08] <BBB> how is the www module called?
[16:08] <BBB> gst-www?
[16:08] <BBB> gstreamer-www?
[16:08] <BBB> cvs -z3 -d:ext:rb...@cv...:/cvsroot/gstreamer co gst-www/dotplan/index.php
[16:08] <BBB> that's not working (?)
[16:08] <rkarl> itnst it just www?
[16:08] <Uraeus> BBB: just www
[16:09] Action: thomasvs tries to see why one would use gob over c++
[16:10] <Uraeus> thomasvs: well if you are developing gnome apps, using C is easier and some people like George who made GOB things C++ sucks
[16:10] <thomasvs> I think it sucks too
[16:10] <thomasvs> that's not the point ;)
[16:11] <thomasvs> but you're actually writing c++ code to do stuff in c when using gob
[16:11] <thomasvs> I mean, it looks really similar
[16:11] <thomasvs> there might be a point where you might have gone full circle and outdone yourselves a bit
[16:12] <thomasvs> wingo: do you still need smp testing for the threads stuff ?
[16:12] <Uraeus> thomasvs: well ask hadess his opinion, some people hate GOB some love it :)
[16:12] <thomasvs> well my opinion doesn't count, I haven't used it yet ;)
[16:12] <Uraeus> thomasvs: rhytmbox use GOB
[16:13] <Uraeus> thomasvs: and the new Gimp will aso use GOB if I understand correctly
[16:13] <thomasvs> ok
[16:13] <thomasvs> is rhytmbox gettable yet ?
[16:13] <wingo> thomasvs: you mean real threads, gthreads?
[16:13] <thomasvs> wingo: whatever you need tested ;)
[16:13] <thomasvs> I have an smp machine for gstreamer testing
[16:13] <Uraeus> thomasvs: according to hadess CVS commit messages in gnome cvs it is kinda useable now
[16:14] <wingo> thomasvs: iirc we have some threading issues on SMP. that's as far as i understand the situation. also, GSignals and glib2 and SMP and multithreading needs testing. basically it's an 'investigate, see what's wrong and fix it' sort of an endeavor ;)
[16:15] <thomasvs> wingo: oh, ok. but there's not test apps ready ? I'm not an imaginary threads person, I only deal with real threads and needles ;)
[16:15] Action: thomasvs is not kidding actually
[16:16] <wingo> there aren't test cases really, but i would start with fakesrc ! { queue ! fakesink }
[16:17] <BBB> dotplan is updated
[16:21] <thomasvs> heh, I see jcdutton has passed by last week ;)
[16:21] <thomasvs> hope he helps out on gst, that would be great
[16:22] <wingo> he seems to be quite good
[16:22] <thomasvs> yeah
[16:22] <thomasvs> I helped out on some packaging issues for dvdnav
[16:22] <thomasvs> they do great work
[16:22] <thomasvs> I mean, xine is pretty stable and usable ;)
[16:25] Action: thomasvs is slowly gathering speed again
[16:26] <thomasvs> so, are we close to releasing ?
[16:26] <Uraeus> thomasvs: we where, but I am not sure now as a new autoplugger was checked in last night and wingo still hasn't fixed the build AFAIK
[16:26] <thomasvs> wingo: you're the man I can ask something I've been thinking about ;)
[16:26] <thomasvs> Uraeus: what's wrong with the build ?
[16:27] <thomasvs> wingo: I want to make releasing less painful ....
[16:27] <thomasvs> especially with all of the modules
[16:27] <Uraeus> thomasvs: well last night it failed on make dist with some cothreads stuff
[16:27] <thomasvs> hm, we still need to decide on some stuff re: policies anyway
[16:27] <thomasvs> but anyway ...
[16:27] <thomasvs> I would like to make the release process easier
[16:27] <thomasvs> by adding something to configure to release stuff
[16:28] <thomasvs> or at least to differentiate between cvs and distribution builds
[16:29] <thomasvs> hm, I have the make distcheck error in cothreads too
[16:30] <thomasvs> that is of course a problem when trying to include "stand-alone" source in a source package
[16:30] <wingo> back now
[16:31] <wingo> make distcheck works within the cothreads dir, haven't checked making distcheck from gstreamer/
[16:31] <thomasvs> I suspect there's something wrong with that ln hack
[16:31] <thomasvs> in any case, it complains here because they exist already ;)
[16:31] <thomasvs> wingo: why is it needed ?
[16:31] <wingo> an autotools bug,
[16:31] <thomasvs> I have a vague recollection of a similar issue I had with it
[16:32] <wingo> where it automagically searches in .. and in ../.. for configure info,
[16:32] <thomasvs> yeah
[16:32] <wingo> and thereby borks the build
[16:32] <thomasvs> because it puts config files in the wrong dir
[16:32] <wingo> right
[16:32] <wingo> i'm glad we're on the same page there ;)
[16:33] <thomasvs> ok, i'm adding mkinstalldirs to that fix too
[16:33] <thomasvs> that's what's failing
[16:33] <wingo> ok
[16:33] <thomasvs> wingo: I never tracked that down fully, any clues on what is wrong ?
[16:33] <wingo> not really
[16:33] <thomasvs> I'm also doing an ln -sf if that's ok with you
[16:33] <wingo> ok
[16:34] <thomasvs> so, you cooked up all of this cothreads stuff ? the force is strong in you ;)
[16:34] <thomasvs> and also adding install-sh
[16:35] <wingo> thanks for fixing all that ;)
[16:35] <wingo> yeah the cothreads stuff is fun
[16:35] <thomasvs> urgh
[16:35] <thomasvs> mkdir pth-1400
[16:35] <thomasvs> /bin/sh ../../../mkinstalldirs pth-1400/. pth-1400/../..
[16:35] <thomasvs> cp: cannot create regular file `pth-1400/../../compile': Permission denied
[16:35] <thomasvs> any idea ?
[16:35] <thomasvs> hm, this seems to come from the same problem
[16:35] <wingo> there will be no limitations as to the number of cothreads
[16:35] <wingo> dunno
[16:35] <thomasvs> damn, that sucks
[16:36] <thomasvs> looks like it's still picking up ../../ as the config dir somehow
[16:36] <wingo> arrgh
[16:36] <thomasvs> hm
[16:36] <thomasvs> I s'pose we need to dive into m4 world to hack this ?
[16:36] <wingo> sounds painful :-\
[16:37] <thomasvs> hm, yeah ;)
[16:37] <thomasvs> we need to figure out what macro is being messed up
[16:38] <thomasvs> hm, ok, so somehow it tries to pick helper apps from ../..
[16:38] <thomasvs> the question is, do we want it do that ?
[16:38] <thomasvs> or do we want it to function as a totally stand-alone package ?
[16:38] <thomasvs> wingo: what would you like best ?
[16:39] <wingo> standalone? but if it actually worked the other way it would be fine
[16:39] <thomasvs> btw what's pth-1400 ?
[16:39] <thomasvs> wingo: hm, I'm not sure
[16:39] <wingo> 1400 is the version,
[16:39] <wingo> pth is the code i took it from
[16:39] <thomasvs> I guess if it's widely applicable it might be better as a separate package
[16:39] <thomasvs> but that's just one more thing to pester gst developers with ;)
[16:39] <wingo> well the thing is,
[16:39] <wingo> if you move the cothreads dir somewhere else, say /tmp/,
[16:39] <wingo> and try to make distcheck it works fine
[16:40] <thomasvs> wingo: yeah, I remember that
[16:40] <thomasvs> I believe I somehow hacked it by explicitly stating the config dir
[16:40] <thomasvs> but holidays trouble the mind ;)
[16:40] <thomasvs> I can't remember where I had that before
[16:40] <thomasvs> I would think I had it in the new player with the mplib stuff, actually
[16:40] <thomasvs> hm, I'll check that
[16:40] <thomasvs> hm, that puts me to thinking ...
[16:41] <thomasvs> ... what does the cothreads dir build ? a library ?
[16:41] <wingo> yup
[16:42] Action: thomasvs has an evil glint in the eye
[16:42] <thomasvs> so actually, you could consider it as an external development library ...
[16:42] <thomasvs> ... which we'd be including our own version of ?
[16:42] <thomasvs> like, a really good test case for including external libs ?
[16:42] <thomasvs> for which the author hasn't made up his mind yet ?
[16:45] <wingo> that would work
[16:45] <wingo> i like that evil glint :)
[16:49] <thomasvs> hm, I'll see how I can make it do the same thing I did as for mplib
[16:49] <thomasvs> that should do the trick
[16:49] <thomasvs> and cook up something that should work for other external libs too
[16:49] <thomasvs> it's about time I started contributing something useful again ;)
[16:49] <rkarl> is there a reason the new gstplay just has 1 global gstplayprivate, while the old ver passed arguments to each func?
[16:54] <Uraeus> rkarl: arik is probably the best to answer that, but he hasn't been here in a while
[16:54] <rkarl> Uraeus: okie..
[17:05] Nick change: Uraeus -> Ura_gym
[17:06] taaz (dlehn@66.37.66.32) joined #gstreamer.
[17:06] <thomasvs> hi taaz
[17:06] <taaz> hey
[17:11] Nick change: wingo -> wingo-class
[17:21] taaz (dlehn@66.37.66.32) left irc: Read error: 104 (Connection reset by peer)
[17:21] taaz (dlehn@66.37.66.32) joined #gstreamer.
[17:34] foxdragonx (~chatzilla@66.200.164.35) joined #gstreamer.
[18:03] <rkarl> http://entertainment.yahoo.com/entnews/wwn/20020116/101119320009.html
[18:05] Nick change: Ura_gym -> Uraeus
[18:05] <thomasvs> heh, that's funny ;)
[18:05] <Uraeus> and a little sick
[18:09] rkarl (~rk...@hr...) left #gstreamer ("Client Exiting").
[18:12] Action: Uraeus downloaded the latest album from No Doubt, but he is not sure he likes it
[18:12] <BBB> s/downloaded/bought/ :)
[18:13] <Uraeus> cough cough, yes of course bought
[18:16] <thomasvs> my advice is not to like it ;)
[18:17] <thomasvs> just download some gwen stefani pictures instead
[18:17] <thomasvs> then wonder how to bash in gavin rossdale's head and run away with her
[18:18] <thomasvs> maybe throw him a s trip party and have the stripper smother him in her breasts ;)
[18:19] <BBB> ;)
[18:22] <Uraeus> hmm, that is an idea
[18:25] harpin (floh@195.3.98.253) left irc: "using sirc version 2.211+KSIRC/1.1"
[18:25] ShrimpX (marius@131.252.244.168) got netsplit.
[18:27] <thomasvs> later
[18:27] thomasvs (th...@21...) left irc: "[x]chat"
[18:27] ShrimpX (~marius@131.252.244.168) returned to #gstreamer.
[18:31] ShrimpX (marius@131.252.244.168) got netsplit.
[18:33] ShrimpX (~marius@131.252.244.168) returned to #gstreamer.
[18:44] <Uraeus> wingo-class: cry out when you have 1 minute for a question
[19:16] Nick change: wingo-class -> wingo
[19:16] <wingo> hey
[19:17] <wingo> Uraeus: ?
[19:19] <Uraeus> wingo: I get make[2]: Entering directory `/home/cschalle/gstreamer/docs/gst'
[19:19] <Uraeus> make \
[19:19] <Uraeus> top_distdir="." distdir="../../gstreamer-0.3.11/docs/gst" \
[19:19] <Uraeus> dist-hook
[19:19] <Uraeus> make[3]: Entering directory `/home/cschalle/gstreamer/docs/gst'
[19:19] <Uraeus> *** gtk-doc must be installed and enabled in order to make dist
[19:19] <Uraeus> make[3]: *** [dist-check-gtkdoc] Error 1
[19:19] <Uraeus> wingo: when I try to so make dist, I have gtk-doc 0.7.90 installed
[19:20] <wingo> you need 0.8.0 iirc
[19:20] <wingo> checking...
[19:20] <wingo> hmm.
[19:21] <wingo> it says only that 0.6 is required.
[19:21] <wingo> which is probably right.
[19:21] <Uraeus> ok, I try and downgrade
[19:21] <wingo> no, don't do that
[19:21] <wingo> upgrade to 0.8
[19:22] <wingo> that's what i have here
[19:24] <Uraeus> but there is no 0.8
[19:25] <wingo> gtkdoc-scanobj --version says 0.8 for me
[19:25] <Uraeus> ok, found the tarball
[19:26] <Uraeus> and it works with the 0.7.0 from PLD linux too
[19:27] <wingo> interesting to know
[19:29] <Uraeus> wingo: I got the 0.7.90 rpm from redhat rawhide and that didn't work
[19:37] <wingo> ok, redhat's rpm is broken then it seems.
[19:39] <Uraeus> wingo: is this something we can fix: configure.ac:8: warning: do not use m4_patsubst: use patsubst or m4_bpatsubst
[19:39] <Uraeus> configure.ac:834: warning: do not use m4_regexp: use regexp or m4_bregexp
[19:40] <wingo> um, what configure.ac is that?
[19:40] <Uraeus> wingo: I get that on both gstreamer and gstreamer-plugins
[19:40] <wingo> and what autoconf do you have?
[19:40] <Uraeus> 2.52f
[19:41] <wingo> f?
[19:41] <wingo> is that a rh version?
[19:41] <Uraeus> let me check
[19:42] <wingo> i think that's an autoconf bug, we don't use those routines directly i don't think
[19:42] <Uraeus> yes it is a redhat version
[19:43] <Uraeus> wingo: it doesn't stop, but it is ugly so np :)
[19:43] <wingo> so no, we can't fix those right now ;)
[19:44] <Uraeus> wingo: any new files we need to include in the SPEC between this release and 0.3.1?
[19:45] <wingo> dunno
[19:45] <wingo> bbb's plugins
[19:45] <Uraeus> I have added those
[19:45] <Uraeus> wingo: any files from your new cothread?
[19:45] <wingo> not yet, no
[19:46] <Uraeus> wingo: and company's new autoplugger?
[19:47] <wingo> yeah that should probably be included
[19:47] <Uraeus> wingo: so it creates some files we don't currently include?
[19:54] bstard (Lor...@pl...) left irc: Remote closed the connection
[19:58] <ajmitch> morning
[19:58] <ajmitch> yo wingo, still around? :)
[20:06] <wingo> Uraeus: gst/autoplugin/libgstspider.so
[20:06] <wingo> hi ajmitch
[20:06] <wingo> s/autoplugin/autoplug
[20:09] Nick change: wtay-zZz -> wtay
[20:09] <wtay> yo
[20:10] <ajmitch> hey
[20:11] <ajmitch> having some issues, i want to be able to 'capture' realplayer output :)
[20:11] <wtay> I once did that using gstoss
[20:11] <ajmitch> yeah, used that last night
[20:11] <wtay> doesn't work anymore?
[20:11] <ajmitch> it works for other apps, but realplayer sits there saying 'Buffering'
[20:12] <ajmitch> eg, i caputured sound from mp3blaster (and also just dumped it out to osssink)
[20:12] <wtay> then gstoss isn't handling all the ioctls correctly
[20:12] <wtay> Uraeus: looks like the KDE people will go for option
[20:12] <wtay> err
[20:12] <ajmitch> i set realplayer to old OSS compatibility mode
[20:13] <wtay> Uraeus: option 2 that is..
[20:13] <wingo> hi wtay
[20:13] <wtay> ajmitch: it probably wants more than gstoss can give
[20:13] wingo-out (wi...@rd...) left irc: Remote closed the connection
[20:13] <ajmitch> wtay: no fair :)
[20:14] Zeenix (zeenix@195.219.29.75) joined #gstreamer.
[20:14] <ajmitch> i guess i'll have to see what i can do with gstoss then
[20:14] <Zeenix> hello everyone!
[20:14] <wtay> ajmitch: maybe the bufsize/fragsize/bytes processed needs to be implemented
[20:14] <wingo> hi Zeenix
[20:14] <wtay> hi
[20:15] <wtay> ajmitch: I would guess it sends some bytes to oss, see how long it took etc..
[20:15] <ajmitch> wtay: yeah, i have the OSS docs here, i'll see what i can do with strace :)
[20:15] <Zeenix> Uraeus: give me one more day to get to know about price of return ticket to Madrid & Sevilla
[20:15] <wtay> ajmitch: yeah strace is your friend :)
[20:16] <ajmitch> i see _lots_ of '21030 ioctl(7, 0x541b, [0]) = 0'
[20:16] <ajmitch> but fd 7 looked like gui stuff
[20:16] <ajmitch> ah well
[20:17] <wtay> ajmitch: open ("/dev/dsp"..) should give you the fd...
[20:17] <ajmitch> yeah
[20:17] <ajmitch> 21030 ioctl(502, SNDCTL_DSP_RESET, 0) = -1 EBADF (Bad file descriptor)
[20:17] <ajmitch> i'll slog thru it ;)
[20:17] <wtay> ajmitch: going to rip RA streams? :)
[20:18] <ajmitch> trying to ;)
[20:18] <ajmitch> 21017 open("/dev/dsp", O_WRONLY|O_NONBLOCK|O_LARGEFILE <unfinished ...>
[20:18] <wtay> ajmitch: you naughty boy! :)
[20:18] <ajmitch> that's the interesting line
[20:18] <ajmitch> wtay: hey, i have the .ra files on my hard drive
[20:19] <Zeenix> wtay: are we supporting realmedia streams? what are the plans for it if not?
[20:20] <wtay> Zeenix: we don't support them
[20:20] <ajmitch> ok, gotta figure out what ioctl 0x541b is :)
[20:21] <wtay> ajmitch: be happy it's in hex :)
[20:22] <ajmitch> hehe
[20:23] <wingo> wtay: check out gst/cothreads/test-cothreads.c
[20:23] <wingo> much simpler
[20:23] <wingo> i do have to add thread-private data, i'll do that at the top stack boundary
[20:23] <ajmitch> wtay: which header file are the ioctl's defined in?
[20:24] <wingo> that will allow calling of func (argc, argv)
[20:25] rkarl (~rk...@fl...) joined #gstreamer.
[20:25] <wtay> ajmitch: /usr/include/linux/soundcard.h
[20:25] <ajmitch> thx
[20:25] <wtay> ajmitch: don't ask me how it works though...
[20:25] <wtay> wingo: neat
[20:26] <ajmitch> wtay: umm, thru some voodoo & black magic? ;)
[20:26] <wtay> wingo: you mean cothread private data?
[20:26] <ajmitch> just looking at this header, i think it'll wait until _after_ i go to work today
[20:26] <wtay> ajmitch: yeah, drink a few beers first :)
[20:27] <rkarl> oss fun?
[20:27] <wtay> rkarl: highjacking oss ioctls from RealPlayer :)
[20:27] <wtay> s/high/hi/
[20:27] <wingo> wtay: yeah, cothread private data,
[20:28] <wtay> wingo: neat, we don't have that now..
[20:28] <wingo> the cothread stacks themselves will all be aligned on their top boundaries
[20:28] <rkarl> wtay: ahh
[20:28] <wingo> actually, we do i think
[20:28] <wtay> we do?
[20:28] <ajmitch> wtay: i swear the person that came up with that system was tripping on something...
[20:28] <wingo> there's a hash table for each thread i think
[20:28] <wingo> it could be for the whole context though
[20:28] <wtay> wingo: hmm could be.. I don't remember
[20:29] <wingo> but this will be much better, no static structures pointing to the current thread, we'll do our own stack math to get at the private data
[20:29] <wtay> wingo: yup
[20:29] <wingo> btw pth, to point to the currently running thread, has a static data element. we're doing better than that ;)
[20:30] <wingo> their system isn't MT safe even if it did cooperate with linuxthreads.
[20:30] <wtay> wingo: hmm. sucks.
[20:32] <wtay> wingo: we're going to need some other cothread tricks soon.. like a cothread switch when it blocks etc..
[20:32] Action: BBB cries
[20:32] <BBB> school has started - my whole days are being spent in school
[20:32] <wtay> ?
[20:32] <BBB> aaaaaah
[20:32] Action: BBB screams
[20:33] <BBB> actually, it's not that bad ;) I hope to finish avimuxer somewhere this week ;)
[20:33] <wtay> BBB: wait 'till you have a fultime job..
[20:33] <BBB> wtay: please, don't remind me of more horror and pain
[20:33] <wtay> BBB: did you know I implemented seek in avidemux (to read the index)
[20:33] <BBB> I expect an oase and girls in bikinis bringing me exotic sodas while I'm lying in the sun
[20:33] <BBB> :P
[20:34] <BBB> wtay: oh, that's wonderful! but does it only go via the index?
[20:34] <BBB> sometimes, AVIs don't have an index
[20:34] <wtay> BBB: it doesn't even use the index yet :)
[20:34] <wtay> BBB: it just tries to read it
[20:34] <BBB> hmm... ok....
[20:35] <BBB> xawtv doesn't write an index if the file is a 'big AVI file'....
[20:35] <BBB> I'm not sure why
[20:35] <BBB> I'll ask mr. Knorr some day
[20:35] <wtay> BBB: the index is pointed to with a 32 bit offset
[20:36] <BBB> if the HAVE_INDEX bit is set ;)
[20:38] <wingo> wtay: you mean wrapping system calls? or other blocking functions
[20:38] <BBB> #define GST_RIFF_AVIH_HASINDEX 0x00000010 /* has idx1 chunk */
[20:38] <BBB> that one
[20:38] <BBB> only if that bit is set, it has an index ;)
[20:38] <wtay> wingo: maybe
[20:38] <wtay> BBB: yup
[20:39] <BBB> but I need to ask mr. Knorr why only non-large AVI files have an index.....
[20:39] <BBB> might be a design mistake in xawtv
[20:39] <BBB> might also be a feature
[20:39] <BBB> not sure.....
[20:40] <wtay> BBB: dunno if it's even possible to have an index on large avis
[20:40] <wtay> BBB: since the index is referenced with a 32 bit offset..
[20:40] <BBB> correct......
[20:40] <BBB> and it's variable size
[20:40] <BBB> so you can't pre-allocate it
[20:40] <BBB> well, you can
[20:40] <BBB> actually
[20:40] <BBB> ....
[20:40] <BBB> I need to ask mr Knorr.... ;)
[20:41] <wtay> you can't, the entries are all 32 bit offsets
[20:41] <BBB> oh, right.... doh
[20:41] <BBB> then why is the index there at all?...
[20:41] <wtay> BBB: maybe odml can handle it, dunno
[20:41] <BBB> you need to be able to search through files-without-an-index....
[20:42] <BBB> which you can
[20:42] <BBB> so why is the index there at all?
[20:42] <wtay> sortof
[20:42] <BBB> well, you need to manually index it at read-time
[20:42] <wtay> because there are no sync points in the avi
[20:43] <wtay> BBB: yes, but then you cannot jump to somewhere near the end
[20:43] <wtay> BBB: only backwards
[20:43] <ajmitch> that'd suck
[20:43] <ajmitch> wtay: got ideas on how to do seeking on files like oggs? :)
[20:43] <wtay> ajmitch: of course not :)
[20:44] <ajmitch> hehe
[20:44] Zeenix (zeenix@195.219.29.75) left irc: "I pay 25 Rs( 0.5$ )/hour"
[20:44] <BBB> wtay: think about it this way (this was my idea for a "new avidemuxer"): first, read the whole file, index it etc.
[20:45] <BBB> and then, go back to frame 1 (SEEK_EVENT) and play it
[20:45] <BBB> that allows full seeking
[20:45] <BBB> and doesn't require an index
[20:45] <BBB> just takes some more time
[20:45] <wtay> BBB: that's an option, but it wont work for streamed avis
[20:45] <BBB> true.....
[20:46] <BBB> AVIs aren't for streaming anyway
[20:46] <BBB> ;)
[20:46] <wtay> BBB: can just play the avi, if a seek happens, just read but not decode the frames in between
[20:46] <wtay> BBB: delayed indexing..
[20:46] <wtay> BBB: seek is a bit slower though..
[20:46] <BBB> that'd be an option as well......
[20:46] <BBB> not noticeably, I suppose....
[20:47] <BBB> it sounds pretty good, what you're saying there..... do you think you can implement that?
[20:47] <BBB> that'd be awesome :)
[20:47] <wtay> It can be done
[20:47] <BBB> sounds like a "but...." ;)
[20:47] <wtay> but I'm doing other things first :)
[20:48] RagingMind (~Rag...@fl...) joined #gstreamer.
[20:48] <BBB> so am I ;)
[20:49] Zeenix (~zeenix@195.219.161.20) joined #gstreamer.
[20:49] <RagingMind> yllo Zeenix
[20:50] <Zeenix> hi
[20:51] <ajmitch> hi Zeenix, RagingMind
[20:51] <RagingMind> yllo ajmitch
[20:51] <ajmitch> back to torture us again ? ;)
[20:52] <RagingMind> which one of us?
[20:52] <ajmitch> either
[20:53] <RagingMind> ok, then yea ;)
[20:54] Action: RagingMind pokes ajmitch
[20:54] <ajmitch> hmm well this gstcapture works fine for mp3blaster
[20:56] <ajmitch> doesn't noticeably add cpu load
[20:56] <Uraeus> wtay: what is option 2?
[20:56] Action: wtay prapares for an X crash
[20:56] <Zeenix> ah updatedb really sucks....
[20:56] <ajmitch> hehe
[20:56] wtay (wi...@ca...) left irc: Remote closed the connection
[20:56] <ajmitch> Uraeus: see i did some gst coding last night :)
[20:57] <Zeenix> Uraeus: hi
[20:57] <Zeenix> Uraeus: got my message?
[20:57] <Uraeus> Zeenix: yes, ok with tommorow
[20:57] wtay (~wi...@ca...) joined #gstreamer.
[20:57] <Uraeus> ajmitch: fantastic :)
[20:57] <Uraeus> wtay: what is option 2?
[20:57] <ajmitch> Uraeus: not gstplay tho ;)
[20:57] <wtay> Uraeus: implement something from scratch
[20:58] <Zeenix> Uraeus: but the return ticket wont be more than 800$ in either case
[20:58] <ajmitch> Uraeus: a _very_ simple app which has a pipeline with ossgst & osssink
[20:59] <Uraeus> wtay: good I don't want them doing something intelligent, it would force me to reevaluate them :)
[20:59] <wtay> Uraeus: they figure it out eventually..
[20:59] <Uraeus> wtay: where did you see this?
[20:59] <wtay> dot.kde.org
[21:00] <ajmitch> why do they get lots of developer support at times? ;)
[21:00] <wtay> Uraeus: http://dot.kde.org/1012195348/
[21:01] <wtay> Uraeus: three teams, each taking a different but suboptimal approach
[21:01] <rkarl> eug. that meeting was a mess..
[21:02] <ajmitch> ah well i guess we just plod ahead showing them what gstreamer can do ;)
[21:03] <wtay> Uraeus: it boils down to that they focus on getting some sort of video playback done...
[21:03] <RagingMind> xine integration? hope you guys hurry, I use xine ;)
[21:03] <Uraeus> wtay: yeah, well if that is what they want they should just make mplayer frontend, but what do I care it is their loss
[21:04] <ajmitch> RagingMind: why shoudl we hurry?
[21:04] <wtay> Uraeus: exactly
[21:05] <RagingMind> ajmitch: read link from wtay
[21:06] <ajmitch> RagingMind: i have, i'm on the kde-multimedia mailing list
[21:06] <wtay> RagingMind: xine works fine, no need to copy/intergrate it
[21:07] <RagingMind> wtay: but they plan on trying and who knows how far it would go, people do some weird things at times
[21:08] <ajmitch> so?
[21:08] <wtay> RagingMind: of course I hope they succeed
[21:08] <ajmitch> wtay: you don't hope they fail miserably & use gstreamer instead? ;)
[21:08] <wtay> ajmitch: I'm not that kind of guy :)
[21:08] <ajmitch> heheh
[21:09] <wtay> I can only state my opinion and report on my 2 years of experience with gstreamer...
[21:10] <rkarl> anyone know why the new gstplay interface is different from the old? specifically the global gstplayprivate...
[21:10] <wtay> rkarl: no idea.. seems like a bad idea to me..
[21:12] <ajmitch> wtay: how so?
[21:13] <rkarl> you cant have multiple players in an app, for one thing..
[21:14] <wtay> I still think the old player has the best design (appart from gstplay extending from gtkHBox)
[21:14] <ajmitch> well tell arik that when you see him ;)
[21:15] <wtay> ajmitch: arik knows
[21:15] <ajmitch> we need a decent player sometime
[21:15] <wtay> I guess it's only the global that's wrong.. didn't look at it closely enough
[21:16] <wtay> ajmitch: define 'decent'
[21:16] <rkarl> well, changing the global thing is like a 10 minute job.. but still a pain..
[21:16] <ajmitch> working, well designed...?
[21:17] <ajmitch> stable, functional, singing, dancing, makes coffee....
[21:17] <rkarl> clothed?
[21:17] <wtay> ajmitch: well, then get to it! :)
[21:18] <ajmitch> wtay: i will once i get this fscking python app out of the way
[21:19] <ajmitch> it's giving me 'issues' at the moment
[21:23] <Uraeus> BBB: the libmmx in the acconfig.h file in gst-plugins, is that the library for your new plugins?
[21:27] omega (~om...@om...) joined #gstreamer.
[21:28] <wtay> yo
[21:28] <omega> yo
[21:28] <RagingMind> yllo
[21:29] <Uraeus> hi omega
[21:29] <ajmitch> yo omega
[21:29] <omega> Uraeus: was the multimedia abstract accepted?
[21:29] <Zeenix> hi
[21:29] <Uraeus> omega: yes
[21:29] <omega> cool
[21:29] <ajmitch> yay
[21:30] <omega> now we have two papers to write that will both be pushing the 4000 word limit, by the 15th
[21:30] <wtay> omega: so, who's going to write that paper? :)
[21:30] <omega> yikes
[21:30] <Uraeus> omega: and I am still waiting for Leon to reply, he mailed me yesterday promising it, then I mailed him today asking, and he promised it again :)
[21:30] <omega> neat
[21:31] <Zeenix> omega: i am too busy to write them for you <g>
[21:31] <Uraeus> omega, wtay: well for the paper the two of you are doing lets do it like this: 1 writes the paper, the other documents events, I don't care who does what :)
[21:32] <wtay> Uraeus: events are too stupid to document right now
[21:32] <rkarl> heh
[21:32] greg_ (~gr...@ho...) joined #gstreamer.
[21:32] <Uraeus> wtay: well if we have them we have to document them no matter how stupid
[21:32] <Uraeus> gi greg_
[21:33] <Uraeus> err
[21:33] <Uraeus> hi I meant
[21:33] <wtay> Uraeus: there is other stuff undocumented that is far less trivial
[21:33] <Uraeus> wtay: oh? I thought only dparams and events where not documented, bummer
[21:34] <greg_> hi Uraeus! Hi ALL ! ;-) A windy day today ;-) (at least at my place)
[21:34] <wtay> Uraeus: is there anything that is documented properly?
[21:34] Company (~Company@pD9004166.dip.t-dialin.net) joined #gstreamer.
[21:34] <ajmitch> hey Company
[21:34] <taaz> tell you all what, i'll write the papers if someone will write a thesis for me
[21:34] <Uraeus> wtay: depends on the level you place things I guess, but events missing documentation is the only complaint I have ever heard here
[21:35] <Company> hi all
[21:35] <Uraeus> hi Company
[21:35] <wtay> Uraeus: there are lots of randon notes but no real, clear document
[21:35] <wtay> hi
[21:35] <Company> Uraeus: I wanted to start them today
[21:35] <Company> but I wanted to first clear some things with wtay
[21:35] <Uraeus> Company: cool
[21:36] <Company> has anybody tested if the spider works on glib1 yet?
[21:37] <ajmitch> spider?
[21:37] <Uraeus> ajmitch: that is the name of Company new autoplugger
[21:38] omega_ (~om...@om...) joined #gstreamer.
[21:38] <omega_> stupid pcmcia....
[21:38] omega (om...@om...) left irc: Read error: 104 (Connection reset by peer)
[21:38] Nick change: omega_ -> omega
[21:38] <Company> yeah, I didn't know a better name and "autoplugger" was taken :)
[21:39] <Uraeus> Company: well I am testcompiling gstreamer for glib2 now, how can I test spider?
[21:39] <Company> Uraeus: in gst/autoplug is a test program
[21:40] <Company> Uraeus: usage ./spidertest <mediafile>
[21:40] <taaz> Company: add -launch examples of how to use it to the gst-launch.1 page once you know it works
[21:40] <Company> but it works with glib2
[21:40] <Company> taaz: that's wingo's job - I don't even know how the parsing works :)
[21:42] <taaz> heh... i'm just saying, the fact that someone asked how to use it means it needs to be documented ;)
[21:45] <Uraeus> Company: is spidertest buildt and installed when a make install is done?
[21:48] <Company> Uraeus: it's built but not installed anywhere
[21:48] <Uraeus> Company: well if we are to bundle it with the upcomming release it need to be installed :)
[21:49] <Company> Uraeus: the spider element is installed
[21:49] <Uraeus> Company: but nothing uses it?
[21:49] <Company> Uraeus: but gst-launch doesn't work with it yet
[21:49] <Company> Uraeus: the spider uses request pads
[21:50] <Uraeus> Company: well I think that either do we decide that gst-launch should use it for this release and make sure it does, or we bundle spidertest
[21:50] <Company> Uraeus: and I think gst-launch can't use them yet
[21:50] <Uraeus> Company: ok, the choice is set then :)
[21:50] <Company> Uraeus: yes, wingo said he wanted to get it working
[21:51] <Company> Uraeus: but he's doing threading right now so he's busy elsewhere
[21:51] <Uraeus> Company: ok, so could you make spidertest get installed, then we can ship it with the 0.3.2 release
[21:53] <taaz> call it something else like gst-spider or whatever if you plan on installing it in a system bin dir
[21:54] <Uraeus> yeah
[21:54] <RagingMind> Company: does spider work with dvds (and stuff) or just files?
[21:55] <Company> RagingMind: theoretically, spider is an element, so it works like mad or mpegdemux or whatever
[21:55] <Company> RagingMind: practically, it is the first element that seriously uses request pads so it doesn't work with -launch
[21:56] <Company> yet
[21:56] <RagingMind> s/spider/spidertest
[21:57] <Company> spidertest does the same as -launch filesrc location=argv[1] ! spider ! osssink spider.src2! xvideosink is supposed to do
[22:03] <taaz> you sure you don't want to add queues in there? ;)
[22:03] steveb (st...@no...) left irc: Read error: 110 (Connection timed out)
[22:08] rkarl (rk...@fl...) left irc: Remote closed the connection
[22:11] <Company> taaz: I'm still absolutely sure I don't want that ;)
[22:13] <omega> huh?!?
[22:16] <Company> is anybody seriously using (or even knows that he can use) element1.pad1,pad2,pad3!element2.pad4,pad5,pad6 to connect pad1 to pad4, pad2 to pad5 and so on in gst-launch?
[22:17] <omega> for some audio situations, yes
[22:18] <Company> just wanted to know, because it was new to me and is implemented a bit ugly in the parser :)
[22:18] <Zeenix> Uraeus: ping?
[22:20] <Zeenix> wingo: can you summarize all you recent work on cothreads in a few words?
[22:25] <wtay> omega: we need glib mainloop intergration at some point..
[22:27] <omega> wtay: to what degree?
[22:28] <ajmitch> hmm ossgst & osssink only add about 2% cpu time when capturing /dev/dsp & forcing it thru that
[22:28] <wtay> omega: the app getting clock notifications at regular times or the app that can get a callback at time X
[22:29] <ajmitch> and top probably has a +-2% accuracy anyway ;)
[22:29] <omega> wtay: ok
[22:29] <wtay> omega: it works when there is a clock master as it can push the callback to the app
[22:29] <wtay> omega: but when the clock is using a select this doesn't work
[22:29] <omega> yup
[22:29] <wtay> omega: not unless I spawn a thread in the clock
[22:31] <wtay> omega: problem with doing this in the mainloop is that it'll be very slow..
[22:31] <wtay> omega: as you need to call iterate in the idle loop
[22:32] <omega> yup
[22:32] <omega> well, assuming you have everything in the main process
[22:32] <wtay> yup
[22:35] <wtay> I could also fire async requests when a plugin waits for a clock time
[22:36] <Zeenix> omega: have wingo been doing something with cothreads, that could make gst work on FreeBSD
[22:36] <Zeenix> ?
[22:36] <omega> Zeenix: dunno
[22:37] <wtay> Zeenix: same situation as before I guess: it'll work on FreeBSD if you use LinuxThreads
[22:37] <Zeenix> omega: he committed some linux-threads.h file in the cothread dir, thats why i got curious..
[22:37] <Zeenix> wtay: ok
[22:38] <omega> wtay: a different scheduler using pthreads for everything would work, but it could suck performance-wise
[22:38] <wtay> omega: data passing using mutexes etc..
[22:38] <omega> that may be required in order to easily run on all the gnome platforms
[22:39] <Zeenix> omega: i havent yet hacked into gst-core, but i know pthread programming, can i be of any help to implement this?
[22:39] <wtay> omega: if we can make the scheduler use real chaining some of the performance problems might be bearable
[22:40] <omega> Zeenix: there's a huge amount of gst internals voodoo involved
[22:40] <omega> wtay: yeah
[22:40] <omega> though more and more elements are loop-based anyway
[22:40] <wtay> omega: I have a simple version of that working here (1 cothread per scheduler)..
[22:40] <omega> hmm?
[22:41] <omega> 'that'?
[22:41] <wtay> real chaining
[22:41] <omega> ah
[22:41] <Zeenix> omega: so should i wait & see if someone else do that?
[22:41] <wtay> it can play an mpeg:)
[22:41] <omega> if my head were feeling better (beginnings of a cold), I'd start looking into that
[22:42] <wtay> omega: it requires substantial changes to the way the chains are grouped AFAICS
[22:43] <omega> probably, yes
[22:43] <wtay> need to have a concept of cothread chains..
[22:43] <omega> yup
[22:44] <omega> it'll be a from-scratch scheduler
[22:44] <omega> eventually replace basicscheduler, but for now it'll be separate
[22:45] <omega> atm, though, I think I need a short nap to let some of the drugs kick in <g>
[22:45] <wtay> heh
[22:45] <omega> bbiab
[22:46] <Company> wtay: some questions wrt events
[22:46] <wtay> ok
[22:46] foxdragonx (chatzilla@66.200.164.35) left irc: "ChatZilla 0.8.5 [Mozilla rv:0.9.7/20011221]"
[22:46] <Company> - do we want to distinguish vertical/horizontal events and call them events and messages or are both events?
[22:46] <wtay> Company: both events for now
[22:47] <Company> - events can happen only while playing?
[22:47] <wtay> PAUSED or PLAYING
[22:47] <wtay> well...
[22:47] <wtay> yes
[22:48] <Company> how are events from an app handled that are inserted when READY or NULL?
[22:48] <wtay> that should work too
[22:48] <wtay> not recommended though..
[22:49] <Company> can apps insert any event? like EOS?
[22:49] <Uraeus> why do I get 'warning: failed to load external entity "/etc/gstreamer/reg.xml"' installing gstreamer now?
[22:49] <wtay> Company: I would say no
[22:50] <wtay> Company: seek and flush are about the only ones allowed for the app I guess
[22:51] <Company> timebased seeking uses which unit and should seek to current/end be allowed for time seeks, too?
[22:52] <wtay> Company: timebased uses a guint64, relative to the stream clock (starting at 0 usually)
[22:52] <Company> that would be milliseconds?
[22:52] <wtay> Company: microseconds
[22:52] <Company> ok
[22:53] <wtay> I would also allow a seek to the end and relative to the current offset (SET/CUR/END)
[22:53] <Company> ok
[22:53] <wtay> Company: then there is also the SEEK_UNIT (frames, ..)
[22:53] <Zeenix> sleep(wtay); :)
[22:54] <Zeenix> sleep(wtay, now); :)
[22:54] <wtay> Company: dunno how that should behave on audio samples..
[22:54] <Zeenix> sleep(zeenix, now); bye all
[22:54] <Company> should you be allowed to seek frames?
[22:54] Action: wtay puts Zeenix in an uninterruptable sleep
[22:54] Zeenix (zeenix@195.219.161.20) left irc: "Client Exiting"
[22:54] <wtay> Company: yes
[22:55] <Company> isn't it possible to do this timebased wrt to framerate?
[22:55] <wtay> Company: yes, that's how the plugin should implement the seek
[22:56] <Company> so an app should be able to seek framebased, I see...
[22:56] <wtay> Company: timebased can be a bit awkward because an mpeg video doesn't show the first frame at time 0 usually
[22:57] <Company> two items are missing for apps right now: requesting info (author) as the app doesn't know which plugin holds the info
[22:57] <wtay> I want to do: PAUSE, seek to frame 5, add callback on frame 10, run
[22:58] <wtay> Company: the app can find out about the plugin by looking at the event src field
[22:58] <wtay> Company: the app can find out about what the plugin does by looking at the klass properties
[22:58] <Company> wtay: no the app can only find out about this if it got an event before
[22:58] <wtay> Company: the app can also find out what it is doing by looking at the pad caps
[22:59] <wtay> Company: at, yes, the plugins push the info current, there is no pull mechanism other than properties
[22:59] <wtay> s/at/ah
[22:59] <wtay> s/current/currently/
[23:00] <wingo> ok, back, for a moment at least
[23:00] <Company> wtay: ok, that's something media players and playlists won't like, but it's no immediate problem :)
[23:00] <wingo> i'd imagine that cothreads will work on freebsd, but with a finite limit of 8 or so
[23:00] <wingo> their default stack size is 1M, and i don't know how to allocate more chunks under uthreads
[23:00] <wtay> Company: yup.. as long as they push their events nicely it'll work for now..
[23:01] <Company> wtay: length information will be managed in what way?
[23:01] <wtay> Company: no idea yet.. maybe some plugins pushes an event with this info?
[23:02] <Company> wtay: problem is that you need plugin communication about the length, so you cannot use simple INFO events
[23:03] <Company> wtay: but you have to use INFO events at some point :)
[23:03] <wtay> Company: yes, filesrc maybe has to push a NEW_STREAM event at some point (with the filelength, filename, etc..)
[23:04] <wtay> Company: other plugins try to convert this to a timebased length and eventually turn it into a message
[23:05] <wtay> Company: just thinking out loud :)
[23:06] <Company> wtay: you would have the restriction that the time could only be computed with NEW_STREAM events
[23:06] <Company> wtay: could this be a problem if you don't know the length at the beginning (ftp or something) but find out later?
[23:07] <wtay> Company: I don't think this restriction is needed, although a guideline would be that a plugin has to make an educated guess ASAP
[23:07] <wtay> Company: it can update this guess later on
[23:07] <Company> wtay: so we would need a separate event for that
[23:08] <wtay> why not a message?
[23:08] Nick change: wingo -> wingo-out
[23:08] <wtay> Company: with some fixed property value, like all other messages?
[23:09] <Company> ftpsrc or httpsrc which doesn't know the size from the start and is an mp3
[23:10] <wtay> the player should leave the total_playing_time blank until a message arrives
[23:10] <wtay> like live streaming, you'll never get a total_time at all
[23:11] <Company> the player should set total_playing_time to max(current, lastmessage)
[23:11] <wtay> Company: something like that, or take the average
[23:12] <wtay> depends on whether the first was overestimated
[23:12] <Company> wtay: but the problem remains: my src doesn't know the filesize from the beginning
[23:13] <wtay> Company: then the NEW_STREAM size is left at -1
[23:13] <wtay> and no message is sent to the app
[23:13] <Company> wtay: yes, but which event does the src send if it finds out?
[23:14] <Company> remmber: we send this event to the next element
[23:14] <Company> because the app isn't interested in file sizes
[23:14] <wtay> Company: yeah, NEW_STREAM is not a good name..
[23:15] <Company> but NEW_STREAM is needed anyway
[23:15] <wtay> Company: the app is interested in the file size too (my app that is) :)
[23:15] <Company> wtay: right, could be
[23:15] <wtay> Company: why not STREAM_PROPERTIES
[23:15] <wtay> with a gboolean indicating a new stream
[23:15] <wtay> or somesuch
[23:15] <Company> hmm
[23:16] <Company> I would separate them
[23:16] <wtay> maybe, depends on what is in it
[23:16] <Company> if someone opens a file you send NEW_STREAM
[23:17] <Company> or you merge NEW_STREAM with DISCONTINUOUS somehow to indicate a break
[23:17] <Company> and then send STREAM_PROPERTIES
[23:18] <wtay> sounds acceptable
[23:18] <Company> can events overtake buffers?
[23:18] <wtay> overtake?
[23:19] <Company> yes, src emits buf1, event, buf2
[23:19] <Company> is this order preserved (right word?) at the sink?
[23:19] <wtay> yes, that's mandatory
[23:19] <wtay> that's why they travel using the scheduler
[23:19] <Company> it's a problem when they can travel when paused, no?
[23:20] <wtay> an element cannot propagate the event when paused
[23:20] <Company> right
[23:21] <wtay> upstream events bypass the scheduler
[23:21] <wtay> that's why you can seek in paused
[23:21] <Company> not really, because the image in your video doesn't change :)
[23:21] <wtay> but the element receiving the event doesn't imidiatly push the event downstream
[23:22] <Company> ok, some more things
[23:22] <wtay> Company: yeah, you can seek but it'll only show when you PLAY again
[23:22] <wtay> D$ does this differently though
[23:23] <Company> INFO and STREAM_PROPERTIES events should probably be able to carry many properties/infos at once?
[23:24] <Company> something like a GList of key/value pairs?
[23:24] <wtay> INFO is certainly key/value pair based, STREAM_PROPERTIES would probably carry some fixed fields and maybe a CAPS
[23:24] <wtay> s/CAPS/PROPS/
[23:25] <Company> what's the easiest way to use INFO? would having it carry a glist of string/GValue pairs work?
[23:26] <wtay> Company: it's a GstProps
[23:26] <Company> currently, yes, but GstProps is private
[23:26] <wtay> we should make it public
[23:26] <Company> or we could use GValues - but I don't know if they would be better or not - they seem so
[23:27] <wtay> Company: if we use GValues, we should use them everywhere, also for padtemaplates and caps IMO
[23:29] <wtay> no point in having two system for specifying key/value pairs
[23:30] <Company> dunno, I just thought the API for GValues might be cleaner and you have more functions and they integrate better with Glib
[23:30] <Company> so an app could be happier
[23:30] <Company> but I don't know about speed and such
[23:30] <wtay> it's a lot heavier too
[23:31] <wtay> they don't do lists or fourccs AFAIK
[23:32] <wtay> but worth investigating..
[23:32] <Company> well, I don't know, I haven't looked deeply into either - I just don't want to copy the header into all my apps :)
[23:33] <Company> and I want to have an easy API
[23:33] <wtay> Company: we need to make API public and provide some nice methods to access the props
[23:33] <wtay> Company: we could add fundamantal types to GValue too actually..
[23:34] thomasvs (~thomas@217.136.150.121) joined #gstreamer.
[23:34] <Company> ok, let's keep that decision "pending" and decide that tomorrow or some day
[23:34] <thomasvs> hi
[23:34] <Company> when we know a bit more about it, I'll read some docs/code :)
[23:34] <Company> hi thomasvs
[23:34] <ajmitch> yo thomasvs
[23:34] <RagingMind> yllo thomasvs
[23:35] Action: thomasvs just spent an hour and a half with a *very* weird dentist
[23:36] <ajmitch> haha
[23:36] <Company> wtay: one last question: avimux needs an event to signal, that a new file is needed at 4GB: is NEW_MEDIA ok or could this cause problems?
[23:36] <Company> s/NEW_MEDIA/NEW_STREAM or DISCONTINUOUS
[23:38] <wtay> Company: NEW_STREAM would be fine I guess, disksink would act on that just fine
[23:38] <BBB> erm
[23:38] <BBB> wait.....
[23:38] <Company> I'm starting to lose track of all problems that start popping up in my head, I think I need to write down everything we said so far
[23:38] <BBB> that signal is in my new avimux, I called it GST_EVENT_RESTART
[23:39] <wtay> BBB: then we'll rename it :)
[23:39] <Company> BBB: we (I?) wanted to merge that with the DISCONT event
[23:39] <BBB> oh.....
[23:39] <BBB> ok
[23:39] <Company> DISCONT with flag "newmedia = TRUE"
[23:39] <BBB> I don't want flags, to be honest......
[23:40] <BBB> just an event, that's all....
[23:40] <BBB> I've created a hacked gstdisksink.c already....
[23:40] <BBB> and am working on avimux
[23:40] <wtay> I don't want a lot of events, just a few that make sense
[23:40] <BBB> ok.....
[23:40] <BBB> but no flags, please ;)
[23:40] <wtay> BBB: what's the problem with a new flag?
[23:41] <Company> BBB: call it a property, ok?
[23:41] <wtay> BBB: if (someflag) do this
[23:41] <Company> BBB: you can even make yourself a nice #define like GST_IS_EVENT_RESTART ;)
[23:41] <wtay> yes :)
[23:42] <BBB> lol :)
[23:42] <Company> ok, I'm gonna write that down and commit it to docs/random/events, ok? I'll add a list with all issues at the end - probably be the biggest part :)
[23:42] <BBB> no, but come on, honestly
[23:42] <wtay> Company: fine
[23:42] <BBB> if you need a flag for an event
[23:42] <BBB> that's just two seperate events
[23:42] <BBB> make it two or don't use the flag
[23:43] <thomasvs> BBB: why a hacked disksink ?
[23:43] <wtay> BBB: the event has other uses
[23:43] <BBB> thomasvs: because the disksink in the CVS didn't have multifile support yet ;)
[23:43] <BBB> I can upload my changes if there's any interest, but then we need to decide on the event name issue first ;)
[23:43] <thomasvs> BBB: what do you mean ? you can pause, flush and change location, no ?
[23:43] <BBB> thomasvs: you shouldn't pause
[23:43] <wtay> BBB: and we run out of names else :)
[23:44] <BBB> lol
[23:44] <thomasvs> BBB: what do you mean, no pause ?
[23:44] <BBB> GST_EVENT_OPEN_NEW_MEDIA_LOCATION
[23:44] <wtay> ack
[23:44] <Company> BBB: how many events do you want for SEEK_TIMEOFFSET/BYTEOFFSET_SET/CUR/END? ;)
[23:44] <thomasvs> BBB: pausing doesn't cause you to lose frames, does it ?
[23:44] <BBB> thomasvs: pause will, in the case of (example) v4lsrc, stop the plugin for a certain amount of time to unload the queued buffers
[23:44] <BBB> so it does
[23:45] <thomasvs> I mean, you can pause the writing thread while the input tread still takes in frames, no ?
[23:45] <BBB> Company: you win :P
[23:45] <thomasvs> wtay: isn't that what happens in my little aaa app as well ?
[23:45] <wtay> thomasvs: yes
[23:45] <BBB> thomasvs: but how do you know *when* to open a new file?
[23:45] <BBB> you need to do it at exact points
[23:45] <BBB> sometimes, the app should initiate the open-a-new-file
[23:45] <thomasvs> BBB: meaning, the data needs to be framed right ?
[23:46] <BBB> sometimes, a peer plugin should (in the case of AVI - 2/4 GB limit)
[23:46] <thomasvs> BBB: it should be done through flushing imo
[23:46] <BBB> ?
[23:46] <thomasvs> BBB: like, avi probably need seeking info at the end, so when you need to split files ...
[23:46] <thomasvs> ... you should send flush to the avi encoder so that it closes the file
[23:46] <wtay> thomasvs: it should be possible to do it by flushing but there are better ways in the avimux case
[23:46] <thomasvs> and then change the location and re-open a file
[23:46] <BBB> right, that's what my current GST_EVENT_RESTART triggers
[23:46] <BBB> this is my way:
[23:47] <BBB> in the case of a signal to disksink (GST_EVENT_RESTART or whatever name), it sends RESTART to the peer plugin on the sink pad
[23:47] <BBB> let's assume this is avimux
[23:47] <thomasvs> ok
[23:47] <Company> wtay: If we have this event stuff sorted out, we should probably create an event status doc for the plugins to keep track of which plugin does what events
[23:47] <BBB> avimux catches the RESTART
[23:47] <wtay> thomasvs: and your app would be so much more simple with NEW_MEDIA
[23:47] <Company> it's gonna change a _lot_
[23:47] <BBB> writes the headers
[23:48] <BBB> sends RESTART back to disksink
[23:48] <wtay> Company: yes
[23:48] <BBB> disksink closes the file and opens a new one
[23:48] <BBB> and avimux writes the new header
[23:48] <BBB> and then, we're done and we can continue
[23:48] <thomasvs> BBB: ok, sounds good
[23:48] <BBB> if the signal is catched by avimux directly, the same happens
[23:48] <BBB> so it always works, no matter who gets the actual signal
[23:48] <BBB> and this is what we want
[23:48] <thomasvs> I suppose that code is not in cvs yet ?
[23:49] <BBB> thomasvs: no, it's on my HD - I'll upload it when avimux works
[23:49] <thomasvs> wtay: NEW_MEDIA isn't in yet either I suppose ?
[23:49] <wtay> BBB: now that is where the NEW_MEDIA is a better name, since when avimux is connected to avidemux, avidemux can catch the event and restart all over, just like it did when filesrc sent the NEW_MEDIA event to it
[23:49] <thomasvs> because I'd like to finish up aaa this week
[23:49] <thomasvs> and it seems it'd be a good test case for this event stuff
[23:49] <BBB> new_media?
[23:50] Action: BBB will look at names and use whichever works best
[23:50] <wtay> BBB: new media starts...
[23:50] <BBB> hmm.....
[23:50] <BBB> ok
[23:50] <BBB> NEW_MEDIA it will be
[23:50] <wtay> that's what it says and does :)
[23:50] Action: BBB creates a third TODO list
[23:50] <wtay> a simple, efficient, non bloated event :)
[23:51] <BBB> ok
[23:51] <BBB> added to...
[truncated message content] |