IRC Logs

*******************************************************************
[03:03] <aeyakovenko> how do i reference a tee?  
[03:03] sxpert ([email protected]) got netsplit.
[03:08] <Company> aeyakovenko: in gst-launch?
[03:09] sxpert ([email protected]) got lost in the net-split.
[03:09] <aeyakovenko> yea, i can make it work in the editor
[03:10] <Company> like this: gst-launch-0.7 videotestsrc ! tee name=mytee ! ximagesink mytee. ! ximagesink
[03:10] <Company> (you can also use the name that is given to the tee by default but that's unsupported:
[03:11] <Company> gst-launch-0.7 videotestsrc ! tee ! ximagesink tee0 ! ximagesink
[03:11] <Company> )
[03:11] <Company> gst-launch-0.7 videotestsrc ! tee ! ximagesink tee0.! ximagesink
[03:11] <Company> gst-launch-0.7 videotestsrc ! tee ! ximagesink tee0. ! ximagesink
[03:11] <Company> now i got it
[03:12] <Company> oh wait, are you using 0.6 ?
[03:13] <aeyakovenko> yea
[03:13] <aeyakovenko> does it not work with 0.6?
[03:13] sxpert ([email protected]) joined #gstreamer.
[03:13] <aeyakovenko>  gst-launch-0.6 v4lsrc ! tee name=mytee ! xvideosink mytee. ! xvideosink
[03:13] <aeyakovenko> INFO (18250: 0) Initializing GStreamer Core Library version 0.6.4
[03:13] <aeyakovenko> INFO (18250: 0) CPU features: (00000744) MMX 3DNOW MMXEXT
[03:13] <aeyakovenko> INFO (18250: 0) registry: loaded global_registry in 0.219674 seconds
[03:13] <aeyakovenko>           (/var/lib/cache/gstreamer-0.6/registry.xml)
[03:13] <aeyakovenko> error: syntax error, unexpected '!', expecting '('
[03:13] <aeyakovenko> ERROR: pipeline could not be constructed: Invalid syntax
[03:14] <aeyakovenko> i get that
[03:14] <Company> yeah, you're using 0.6, that had another syntax there
[03:15] <Company> try gst-launch-0.6 videotestsrc ! tee ! ximagesink tee0.src%d! ximagesink
[03:15] <Company> (but i don't know if that's correct, nearly noone in here uses 0.6 anymore ;))
[03:16] <aeyakovenko> hehe
[03:16] <aeyakovenko> maybe i should upgrade then
[03:18] <Company> developers are highly encouraged to update
[03:19] <Company> and use cvs
[03:20] <aeyakovenko> i am just trying to write an app using gstreamer
[03:21] <Company> yeah, those are developers, too :)
[03:21] <aeyakovenko> well if that tee thing works ill take your word for now
[03:22] <aeyakovenko> i am to lazy to write an ebuild right now
[03:23] <Company> heh
[03:23] <Company> well, there's a syntax to get tee working in 0.6 - i used it there
[03:24] <aeyakovenko> its ok, ill figure it out when ill need it
[03:25] <aeyakovenko> a tee can be placed anywere in the pipeline?
[03:26] <Company> yeah
[03:26] <Company> it takes everything that comes in and gives it to anything that's connected as output
[03:26] <Company> and it works for any format
[03:40] <aeyakovenko> Lets say i had a bin that had a pipeline with a tee in it, if I add a tee.n->somesink to it, would it automagicaly send to the somesink?
[03:41] <Company> yeah
[03:41] <aeyakovenko> wow, thats pretty wicked
[03:45] <Company> :)
[04:25] The_Company ([email protected]) joined #gstreamer.
[04:25] Company ([email protected]) left irc: Nick collision from services.
[04:25] Nick change: The_Company -> Company
[04:27] bitshifter ([email protected]) joined #gstreamer.
[04:28] <bitshifter> Hi. I'm playing around with gstreamer (0.7/cvs), and have problems finding a pipeline that would discover ID3v1 tags.
[04:28] <Company> use the id3tag element
[04:29] <bitshifter> ah. I've tried    file://foo.mp3 ! typefind ! spider ! application/x-gst-tags ! fakesink
[04:29] <Company> that's supposed to work, too
[04:30] <bitshifter> that only worked with ID3v2 tags and ogg/vorbis comments so far for me
[04:30] <bitshifter> if the mp3 stream starts right away (FF FB), then it finds the type to be an 'octet stream'
[04:31] <bitshifter> ah well, it's easy enough to check for an ID3v1 tag
[04:31] <Company> that shouldn't happen
[04:31] <bitshifter> Company: thanks, id3tag works fine
[04:31] <Company> at least not in a file reading situation
[04:32] <Company> if it's a non-seekable stream, that might happen
[04:32] <bitshifter> anything I can do to found out more about what might be the problem? 
[04:33] <Company> you could try filesrc location=foo.mp3 ! typefind ! spider ! application/x-gst-tags ! fakesink
[04:33] <Company> just to be sure
[04:33] <Company> and it should never find an octet stream
[04:34] <bitshifter> sorry, my bad. It didn't say it found an octet stream, it shows octet stream as file source + type find element pad capabilities
[04:34] <Company> yeah, that's ok
[04:34] <Company> it should find audio/mpeg
[04:35] <bitshifter> using filesrc didn't make a difference
[04:38] <Company> hm
[04:38] <Company> it works here
[04:39] <Company> they're correctly identified as application/x-id3 at least
[04:39] <bitshifter> hmm. Having 0.6 and 0.7 both installed shouldn't make a difference, should it?
[04:40] <Company> but you're correct, spider doesn't work
[04:46] <Company> i'll blame the caps merge for now...
[04:47] <bitshifter> shall I file a bug report against CVS head? or just wait?
[04:48] <Company> filing a bug never hurts
[04:49] <bitshifter> k. Thanks for your help
[05:27] ct_ ([email protected]) joined #gstreamer.
[05:31] hadley ([email protected]) left irc: Read error: 110 (Connection timed out)
[05:36] ct_ ([email protected]) left irc: "Client exiting"
[06:09] KyleB ([email protected]) joined #gstreamer.
[07:40] ds-gromit_ ([email protected]) joined #gstreamer.
[07:42] ds-gromit ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[07:43] ds-gromit__ ([email protected]) joined #gstreamer.
[07:44] ds-gromit_ ([email protected]) left irc: Read error: 54 (Connection reset by peer)
[08:16] <aeyakovenko> if i have a pipeline with a bunch of bins, do i need to remove the bins from the pipeline before i destroy them?
[08:27] rk ([email protected]) joined #gstreamer.
[08:27] <rk> morning
[08:31] herzi ([email protected]) left irc: Remote closed the connection
[08:31] Nick change: mathrick|sleep -> mathrick
[08:32] <mathrick> mornin
[08:33] herzi ([email protected]) joined #gstreamer.
[08:43] aeyakovenko ([email protected]) left #gstreamer.
[08:48] harshy ([email protected]) joined #gstreamer.
[09:00] apoc_ ([email protected]) joined #gstreamer.
[09:01] mathrick ([email protected]) left irc: Remote closed the connection
[09:17] apoc ([email protected]) left irc: Read error: 110 (Connection timed out)
[09:21] tim_ ([email protected]) joined #gstreamer.
[09:21] bitshifter ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[09:21] Nick change: tim_ -> bitshifter
[09:25] harshy ([email protected]) left irc: Remote closed the connection
[09:42] BBB ([email protected]) joined #gstreamer.
[09:43] <BBB> howdy
[09:46] ChrisHJW ([email protected]) joined #gstreamer.
[09:47] thomasvz ([email protected]) left irc: Read error: 110 (Connection timed out)
[09:53] swentel ([email protected]) joined #gstreamer.
[09:56] km_sleep ([email protected]) left irc: "Leaving"
[10:02] thomasvs ([email protected]) joined #gstreamer.
[10:22] dolphy ([email protected]) joined #gstreamer.
[10:28] <BBB> hi fluendo's
[10:29] <thomasvs> morning
[10:33] <BBB> thomasvs: I've got an issue with doc building
[10:34] <BBB> configure:21163: Will not output HTML documentation
[10:34] <BBB> configure:21178: Will not output PS documentation
[10:34] <BBB> configure:21190: Will not output PDF documentation
[10:34] <BBB> I really have all the tools in here, this is the only thing not right:
[10:34] <BBB> configure:20949: checking whether xsltproc docbook processing works
[10:34] <BBB> configure:20966: result: no
[10:34] <BBB> how do I fix that?
[10:36] <thomasvs> BBB: what does /etc/xml/catalog have ?
[10:36] <BBB> a lot of XML strings
[10:36] <dolphy> morning
[10:36] <thomasvs> paste them to me privately so I can compare
[10:36] <BBB> scrollkeeper, docbook, ISO something
[10:36] <thomasvs> BBB: did the gtk-docs build for you before ?
[10:37] <BBB> I think it did
[10:37] <BBB> it always says 'building HTML documentation'
[10:37] <thomasvs> yeah, but did it build them without errors ?
[10:37] <BBB> but my documentation was incomplete, so I checked what was going on
[10:37] <thomasvs> right, that's probably the reason
[10:37] <thomasvs> give me the catalog privately
[10:37] KoRnouille ([email protected]) joined #gstreamer.
[10:37] <thomasvs> so I can compare
[10:38] <KoRnouille> good morning thomasvs
[10:39] <thomasvs> KoRnouille: morning
[10:39] <thomasvs> BBB: you're missing docbook stylesheets, let me check what rpm they are in
[10:39] <KoRnouille> you wanted me to test something with you ?
[10:39] <KoRnouille> for the swfdec
[10:39] <KoRnouille> or more the repository
[10:39] <KoRnouille> for RH9
[10:39] <thomasvs> BBB: docbook-style-xsl
[10:39] <thomasvs> KoRnouille: correct - but I need to build the packages first
[10:40] <KoRnouille> take your time
[10:40] <thomasvs> KoRnouille: so I hope to finish the site today and start building those packages tomorrow
[10:40] <KoRnouille> i'll be there
[10:40] <KoRnouille> all right then
[10:40] <thomasvs> KoRnouille: most of the packages are done, but I need to verify on rh9
[10:40] <thomasvs> KoRnouille: thanks for helping out with this :)
[10:40] <thomasvs> BBB: install that rpm and rerun configure
[10:40] <KoRnouille> no problem... so you went snowoarding this week end ?
[10:40] <thomasvs> KoRnouille: yep
[10:40] <KoRnouille> cool :)
[10:40] <thomasvs> KoRnouille: had to take a break :)
[10:40] <KoRnouille> lucky you
[10:40] <KoRnouille> ;)
[10:41] <KoRnouille> alright, I'll get back to work. Just let me know if you need me
[10:41] <thomasvs> heh, I know :)
[10:41] <thomasvs> KoRnouille: will do, thanks
[10:43] <BBB> thomasvs: aha! will do, ty
[10:46] Rotty ([email protected]) joined #gstreamer.
[10:50] wheels ([email protected]) left irc: "work"
[10:56] <BBB> Using catalogs: /etc/sgml/xml-docbook-4.2-1.0-17.cat
[10:56] <BBB> Using stylesheet: /usr/share/sgml/docbook/utils-0.6.12/docbook-utils.dsl#print
[10:56] <BBB> Working on: /home/rbultje/projects/gstreamer/gstreamer/docs/faq/build/faq.xml
[10:56] <BBB> rm: cannot lstat `faq.out': No such file or directory
[10:56] <BBB> /usr/share/sgml/docbook/utils-0.6.12/backends/ps: line 37: dvips: command not found
[10:56] <BBB> ?
[10:57] <BBB> I do have tetex installed
[10:59] <BBB> (which includes the file, according to rpmfind)
[11:03] <thomasvs> tetex-dvips has it
[11:03] Action: thomasvs wonders whether or not to chec kfro dvips
[11:03] Action: thomasvs decides it's a packaging bug
[11:05] Action: BBB thinks it's an important packaging bugs and lots of people will complain
[11:07] Company ([email protected]) left irc: Remote closed the connection
[11:10] <BBB> *** Generating PS output ***
[11:10] <BBB> cd build && docbook2ps -o .. faq.xml
[11:10] <BBB> whee
[11:10] Action: BBB plans on fixing up the PWG for the next few days
[11:11] Action: BBB hopes he can now actually generate gtk-docs from the interfaces
[11:11] <BBB> thomasvs: does gtk-doc work in gst-plugins?
[11:11] <BBB> rm: cannot lstat `faq.out': No such file or directory <- is that bad?
[11:12] <BBB> rm: cannot lstat `manual.out': No such file or directory
[11:12] <BBB> rm: cannot lstat `pwg.out': No such file or directory
[11:12] <BBB> [etc.]
[11:13] <thomasvs> BBB: in gst-plugins, it odesn't work
[11:13] <thomasvs> BBB: don't know if that's bad, you ahve to try from a fresh build to make sure if it's bad :)
[11:14] <BBB> oh
[11:14] <BBB> well, I have docs
[11:14] <BBB> and in gst-plugins, how do I generate docs for the interfaces?
[11:14] <BBB> I mean, API docs etc.
[11:14] <BBB>  Make sure the state of an element gets reset when going to NULL. Ideally, this should set all object properties to their original state. This function should also be called from _init. <- bah
[11:14] Action: BBB disagrees
[11:14] <thomasvs> BBB: I think I stopped setting it up due to lack of feedback
[11:15] <BBB> ok, well, we're getting closer to 0.8.0, so I'd like to re-work on this
[11:18] <thomasvs> well, motivate me and it iwll probably get done :)
[11:25] <BBB> I wrote mixer docs and people asked questions about the mixer API so I'd love to get some gtk-doc API docs from these gtk-doc style comments
[11:25] <BBB> pleaaaaaaaaaaaaaaaaaaaasE?
[11:25] <BBB> s/E/e/
[11:25] Action: BBB puts on his sweetlook mask
[11:25] lilo_booter ([email protected]) joined #gstreamer.
[11:26] <lilo_booter> anyone with more than a passing knowledge of libavformat around here?
[11:27] <thaytan> evening, all
[11:29] <lilo_booter> hi
[11:30] <BBB> I know bits about it, but why do you ask here?
[11:31] walters ([email protected]) left irc: Remote closed the connection
[11:31] <lilo_booter> figured there'd be someone who knows bits of it around here ;-)
[11:31] <BBB> grmbl :p
[11:31] <lilo_booter> heh
[11:31] <BBB> how do I seek to a specific position in hexedit?
[11:34] <lilo_booter> hmm - close the file, open in gvim and convert to hex? ;-)
[11:35] <lilo_booter> sorry - dunno hexedit at all
[11:35] <BBB> but anyway, ask the Q
[11:36] <lilo_booter> well - two problems... first one is a crash when i use two contexts which use mp3 codecs (doesn't matter if i compile with lame or not)
[11:37] <lilo_booter> av_decode_audio works well for the first context, but as soon as i hit the second, i get a core dump
[11:37] <lilo_booter> wondering if there's some kind of 'reset' on the codec required
[11:40] <lilo_booter> sorry - wife called me away
[11:40] <lilo_booter> also not sure if it's specifically a libavformat issue, or something to do with libavcodec
[11:42] <lilo_booter> any clues?
[11:45] <BBB> lame is encoder, not edcoder
[11:45] <BBB> ffmpeg includes its own mp3 decoder
[11:45] <BBB> do you use the same context struct? or do you create a new one?
[11:45] <BBB> you need to clean it up
[11:47] <lilo_booter> k - may have read that wrong then - thought it used lame for decoding when available (know it has its own).. np
[11:47] <lilo_booter> i create two contexts - no clean up though... might be worth trying
[11:48] <BBB> isn't needed
[11:48] <BBB> (afaik)
[11:49] <lilo_booter> that's what i would've thought, but no harm in trying it anyway
[11:49] <BBB> do you copy data from one to the other?
[11:49] <BBB> true
[11:49] <lilo_booter> nope - they're used quite separately
[11:51] <lilo_booter> trying to recompile ffmpeg with DEBUG support... proving bothersome :-/
[11:55] <lilo_booter> ah - revealing though :-)
[11:56] <BBB> works? :)
[11:56] Action: BBB hopes thomasvs is working on gtk-doc integration in gst-plugins
[11:56] <lilo_booter> not yet, but DEBUG is giving loads of info which may help :-) - anyway - thanks for being a sounding board... i'll continue looking
[11:56] <BBB> fine, have fun ;)
[11:56] <thomasvs> BBB: I probably would be if the time to configure/autogen gst-plugins wasn't sooooo big
[11:56] <BBB> lavf debugging is hell
[11:57] <thomasvs> BBB: I completely lack all motivation on doing any build stuff on gst-plugins because of it
[11:57] Action: BBB feels thomasvs is now going to propose to split things off
[11:57] <thomasvs> no, I'm done proposing :)
[11:57] <thomasvs> I'm waiting for other people to fix the build so they know what it feels like
[11:57] <lilo_booter> BBB, so it would seem :-)
[11:57] Action: BBB cries
[11:59] <BBB> dolphy: please buy thomasvs a quad xeon 4x3GHz so he'll go back working on gst-plugins
[12:00] <BBB> [/random idea]
[12:00] <thaytan> just install distcc :)
[12:00] <lilo_booter> curious - any of you guys going to fosdem again this year?
[12:01] <BBB> thaytan: doesn't work for configure
[12:01] <BBB> lilo_booter: no, I'll be in NYC
[12:01] <BBB> if there's some event there, I'll go
[12:01] <lilo_booter> heh - k
[12:01] <thaytan> BBB: well, true, but neither does a quad xeon then 
[12:01] <thomasvs> lilo_booter: I am
[12:01] <thomasvs> lilo_booter: so is dolphy
[12:02] <lilo_booter> well, was planning to meet up with sxpert, so i'm sure i'll run into you guys at some point
[12:03] <lilo_booter> no presentation this year? more time for beers? :-)
[12:04] <BBB> is there any event in Boston or NYC?
[12:04] <BBB> between feb and aug
[12:05] <sxpert_work> lilo_booter, heya :D
[12:05] <lilo_booter> hey sxpert :-)
[12:06] <sxpert_work> BBB, no, you'll be alone... of course, you can go have lunch with miguel de Icaza...
[12:08] <BBB> I don't *live* in boston
[12:08] <BBB> boston is half a day travelling for me unless I take the airplan
[12:14] iain ([email protected]) joined #gstreamer.
[12:19] <thomasvs> hm
[12:19] <thomasvs> so what's the RIGHT way for an app to get current playing time ?
[12:19] <thomasvs> query the clock of the playback thread ?
[12:20] <BBB> query() the element with GST_QUERY_POSITION
[12:20] <BBB> element=demuxer, decoder, ..
[12:20] <thomasvs> so why not query the clock ?
[12:20] <thomasvs> (trying to look at it from an outsider's perspective)
[12:20] <BBB> in gst-rec, my pipeline doesn't *have* a clock
[12:21] <BBB> brb
[12:22] Shoragan ([email protected]) joined #gstreamer.
[12:22] jdahlin ([email protected]) joined #gstreamer.
[12:22] sxpert_work ([email protected]) left irc: Remote closed the connection
[12:26] sxpert_work ([email protected]) joined #gstreamer.
[12:28] <thomasvs> BBB: FYI, all programs doing playback use the clock querying method
[12:31] <lilo_booter> BBB, hmm - found a workaround - problem seems to be on line 2442 of mpegaudiodec (calls s->antialias) - i put a != NULL check on s and the function pointer and now it's stabilised...
[12:31] <lilo_booter> no idea why it's needed in this case in not others though....
[12:34] <lilo_booter> second question is related to pts :-) - time stamps on most audio and video packets from divx avi files match nicely - sometimes though, there is a huge discrepancy on audio (ie: audio pts is 1/3rd of video pts)... 
[12:34] Company ([email protected]) joined #gstreamer.
[12:34] <Company> thomasvs: ping?
[12:43] shawarma ([email protected]) joined #gstreamer.
[12:46] <thomasvs> Company: pong
[12:47] pb_ ([email protected]) joined #gstreamer.
[12:47] <shawarma> Is there a script for adding new plugins to gstreamer or do I have to manually figure out how autoconf'n'friends work?
[12:48] <BBB> lilo_booter: can be a file problem... or maybe an integer overflow
[12:48] <BBB> I'm having PTS issues with MPEG files myself in ffmpeg too
[12:48] <thomasvs> shawarma: there is a gst-template module
[12:48] <BBB> shawarma: just copy from another plugin
[12:48] <lilo_booter> possible... finding it quite consistent over a number of files....
[12:48] <thomasvs> shawarma: it may be outdated though
[12:48] <thomasvs> shawarma: let me check it
[12:48] <BBB> and indeed, gst-template
[12:49] <Company> thomasvs: there were 2 bugs I noticed while reworking audioconvert yesterday: 1) int audio doesn't have buffer-frames and 2) if you gst_library_load another plugin, you _must_ do it before registering elements
[12:49] <Company> thomasvs: I wanted to make sure you're aware of those two points :)
[12:49] <shawarma> Where is this template plugin to be found? I fetched the source package from Debian called 'gst-plugins-0.6.4'..
[12:49] <thomasvs> Company: 1), I never understood what buffer-frames was supposed to do :) I don't think I added it, just reworked the link function
[12:50] <thomasvs> 2) can you elaborate a bit more ?
[12:50] <thomasvs> shawarma: from cvs
[12:50] <shawarma> thomasvs: Where is that these days? sf?
[12:50] <thomasvs> shawarma: no, freedesktop
[12:51] <shawarma> thomasvs: Have you got the CVSROOT handy?
[12:51] <Company> thomasvs: buffer-frames is used in float audio to make it possible for a plugin to define the sizes of buffers it wants as input
[12:51] <thomasvs> -d:pserver:[email protected]:/cvs/gstreamer should work
[12:51] <shawarma> And the module?
[12:51] <thomasvs> gst-template
[12:52] <Company> thomasvs: some plugins can only work with 128 frames buffers for example, so they set buffer-frames to 128
[12:52] <thomasvs> it still seems to build fine
[12:52] <BBB> buffer-frames needs to die
[12:52] <thomasvs> Company: ah, so it's for lowlatency applications then ?
[12:52] <BBB> that can be done using bytestream or similar
[12:52] <Company> thomasvs: yeah
[12:52] <thomasvs> BBB: well, good luck converting
[12:53] <Company> BBB: bytestream has a high overhead
[12:53] <BBB> or we need a read(num_samples) method (next to get-based elements -> rea-dbased elements)
[12:53] <BBB> Company: ok, but something similar
[12:53] <BBB> buffer-frames in caps is a hack
[12:53] <thomasvs> Company: about 2), that just means you need to call the library_load function before actually registering the plugin's internal elements ?
[12:53] <Company> thomasvs: yes
[12:53] <BBB> I know it's useful, but it needs to be done differently
[12:53] <thomasvs> Company: is that because otherwise they get registered twice ?
[12:53] <shawarma> thomasvs: That CVSROOT didn't work. anonymous: no such user
[12:53] <thomasvs> shawarma: hold on, let me check
[12:53] <lilo_booter> BBB, hmm - not getting a discrepancy with mpeg-1 here... 
[12:53] <Company> thomasvs: because library_loads often fail when you run gst-register
[12:53] <thomasvs> yep
[12:53] <thomasvs> got it, I probably got that wrong :)
[12:54] <lilo_booter> BBB, or at least, mpeg=1 being generated by ffmpeg
[12:54] <Company> thomasvs: and you don't want to have your element registered and then fail plugin_init
[12:54] <thomasvs> right
[12:54] <thomasvs> Company: although, in other cases where it's not black/white, I suppose you could try checking if an element is already registered before registering ?
[12:54] <thomasvs> ok, so
[12:55] <thomasvs> can someone comment on why the proper way of getting current playing position is now using the query ?
[12:55] <Company> thomasvs: you probably could, but that has never been a problem before...
[12:55] <thomasvs> because all the apps use clocks to query the playing time right now
[12:55] ChriHJW ([email protected]) joined #gstreamer.
[12:55] <BBB> Company: I basically want 'read-based' elments... i.e. I want to be able to say 'give me X bytes of data', that'd be useful for osssrc (which now has a bytes-per-read property for that purpose)... imagine ffmpeg, where each audio encoder only allows one buffersize, e.g. 1152 samples for mp3/mp2 encoding
[12:55] <thomasvs> and I don't mind fixing them all, I just need to know what we want to be the right way :)
[12:55] <BBB> Company: that's why I want a read() method next to get() - read is just an extension to get
[12:56] <BBB> and bytestream can wrap that
[12:56] <BBB> and emulate it through get/other if read() isn't available
[12:56] <Company> BBB: hmm, that's a hard problem with gst I think
[12:56] <BBB> it'll be tricky, but I don't think its hard
[12:57] <Company> BBB: you could adjust the get function to gst_buffer_get (pad, offset, size);
[12:58] <BBB> Company: can all get-elements give a specific size?
[12:58] <BBB> (alsa, oss, file, gnomevfs can... but others?)
[12:58] <Company> BBB: but that would mean forcing element to honour it and finding a way to do it if they can't ...
[12:58] <BBB> we could say that 'size' is "requested" size and not "obligatory" size
[12:59] <Company> yeah, that would be an optimization thing though you'd still need to check everywhere
[12:59] <BBB> well, bytestream would do the check
[12:59] <BBB> just like now
[12:59] <Company> i'll add that to docs/random/company push-vs-pull
[12:59] <shawarma> Does anyone know what the current CVSROOT is?
[12:59] <BBB> elements would just use bytestream
[12:59] <Company> bah, bytestream sucks
[13:00] <BBB> why?
[13:00] <BBB> it's probably not perfect
[13:00] <BBB> but it does the job
[13:00] <BBB> I really want to keep it
[13:00] <BBB> it might need to be optimized slightly
[13:00] <Company> because it requires loopbased elements and has a crappy event handling
[13:00] <BBB> the loopbased thing is indeed evil
[13:00] <BBB> I wanted to add some functions to make it usable in chainbased elements
[13:00] <BBB> like 'add_buffer' or so
[13:01] <Company> make it 2 different GObjects
[13:01] <Company> with a common base class
[13:01] <BBB> maybe... I think most stuff can be shared though
[13:01] <BBB> but yes, you've got a point
[13:01] <BBB> will you make bufferstore extend that base class too then?
[13:02] <Company> thomasvs: clocks were reset when you went from READY to PAUSED
[13:02] <Company> thomasvs: they're not anymore because that lead to all sorts of errors
[13:03] <Company> thomasvs: and gst_element_get_time is more precise anyway :)
[13:03] <thomasvs> Company: so should I be using QUERY_POSITION, or element_get_time ?
[13:03] <Company> BBB: yeah, abstract the common functionality into a base class
[13:04] <BBB> (still, I don't see how bufferstore is different from bytestream)
[13:04] <Company> thomasvs: element_get_time if you know the element uses a clock, otherwise use query_position
[13:04] <Company> BBB: bufferstore stores buffers
[13:04] <BBB> yes...
[13:04] <Company> BBB: it's essentially a sophisticated cache
[13:04] <BBB> so...
[13:04] <BBB> so is bytestream...?
[13:04] <thomasvs> Company: but something like esdsink doesn't have a good clock, does it ?
[13:05] <Company> thomasvs: "has a clock" was meant as "uses a clock"
[13:05] <Company> thomasvs: so if you query mad or vorbisfile, you can't use element_get_time because they have no clocks
[13:06] <Company> BBB: no, bytestream only stores a linear amount of the stream
[13:06] <thomasvs> Company: ok, so in general a player app should use a QUERY_POSITION on the sink anyway
[13:06] <Company> (that was described in an awul way)
[13:06] <Company> thomasvs: no, in general a player app should get_time on the sink
[13:06] <thomasvs> Company: ok, but esdsink doesn't have a clock, or does it ?
[13:06] <Company> thomasvs: because the sink almost always uses a clock :)
[13:07] <Company> thomasvs: it doesn't have one, but it uses one
[13:07] <thomasvs> ok, let me rephrase - do all of our audio output sinks currently use a clock, and is it thus ok to use element_get_time ?
[13:07] <Company> good question
[13:07] <thomasvs> I know :)
[13:08] <Company> they should
[13:08] <thomasvs> there's no point in promoting get_time if we don't do it right
[13:08] <thomasvs> esp. since QUERY_POSITION seems to be a mechanism that's better implemented currently
[13:08] <Company> QUERY_POSITION is much higher overhead and much less exact
[13:08] <BBB> that's not true
[13:09] <BBB> QUERY_POSITION is ususally correct
[13:09] <BBB> it is for MPEG video with my patches (still in bugzilla, it has issues), avi, quicktime, matroska, ...
[13:09] <BBB> wav
[13:09] <Company> well, if you have a video with 0.2 fps it only jumps every 5 seconds
[13:09] <thomasvs> hm
[13:09] <thomasvs> so _get_time doesn't seem to work (returns 0 always)
[13:10] <BBB> that's an implementation detail
[13:10] <Company> BBB: yeah, but get_time is better in that case :)
[13:10] <thomasvs> what I'm asking is
[13:10] <thomasvs> a) what do we want to say is the standard
[13:10] <Company> get_time is an optimization that is not always available though
[13:10] <thomasvs> b) what do we need to fix to make sure that it works ok ?
[13:10] <Company> get_time does not always return 0 btw
[13:11] <thomasvs> if QUERY_POSITION can be made to work as well as get_time we should do that
[13:11] <thomasvs> ie, promote the most general way of doing it.
[13:11] <Company> they both do different things
[13:11] <thomasvs> we cannot tell application developers "well, if your element has a clock, the ndo this, otherwise do that" :)
[13:11] <Company> yes we can
[13:11] <thomasvs> we're trying to tell them not to worry about what sort of output element you use
[13:11] <BBB> why doesn't get_time() call QUERY_POSITION if it can't find out in another way?
[13:12] <thomasvs> BBB: that would be a good idea, for example
[13:12] <Company> because it's supposed to get the time, not the position
[13:12] <BBB> QUERY_POSITION with fmt=GST_FORMAT_TIME
[13:12] <Company> that's still a position
[13:12] <thomasvs> if we want to get gstreamer used properly, we need to make it easy to use it properly
[13:12] <BBB> yes
[13:13] <thomasvs> there are a lot of apps giving up on gst because it's too hard/doesn't work/... and I'm tired of losing apps to xine for exmaple
[13:13] <Company> i'm not sure that's a good way to do it, because both are different concepts
[13:13] <thomasvs> I cannot tell someone who has an app "check the sink, find out if it has/uses a clock, if it does use a), otherwise use b)"
[13:13] <thomasvs> they will rightfully ask "why don't you just have one method to ask for the position" ?
[13:14] <Company> well, just use QUERY_POSITION
[13:14] <Company> it should be good enough
[13:14] <thomasvs> so can we fix the cases where it isn't good enough ?
[13:14] <thomasvs> ie, in the frame case you mentioned, what exactly is the problem ?
[13:14] <Company> that 0.2fps videos update the position every 5 seconds
[13:15] <thomasvs> but isn't that correct behaviour anyway ?
[13:15] <thomasvs> (if you want the playback position of the stream)
[13:15] <Company> yes, if you want the position, it's correct
[13:16] <Company> if you want the time, it's not :)
[13:16] <thomasvs> ok
[13:16] <thomasvs> so someone needs to write up something in our docs about what the difference is and how it applies to apps :)
[13:16] <Company> apps should use query_position for now
[13:17] <Company> get_time is an optimization that will move into an interface in 0.10
[13:17] <thomasvs> yeah, but none of all of our apps currently do :)
[13:17] <thomasvs> or maybe rhythmbox, didn't check
[13:17] <Company> that's bad
[13:17] <thomasvs> yep
[13:17] <Company> rb does measure time itself
[13:17] <thomasvs> which is why I want to fix it
[13:17] <thomasvs> Company: ugh, that's even worse :)
[13:18] <Company> yeah, I intend to fix that
[13:19] <thomasvs> BBB: do your docs build now ?
[13:19] <Company> hm, describing the conceptual difference of time and position is really an interesting task
[13:19] <thomasvs> yep
[13:19] <BBB> thomasvs: core or plugins?
[13:19] <BBB> thomasvs: core docs build now
[13:19] <thomasvs> and I'm pretty sure I don't really understand all of the reverberations
[13:20] <thomasvs> BBB: plugins won't unless someone fixes the build for it :)
[13:20] <BBB> gr
[13:21] pb_ ([email protected]) left irc: "Client exiting"
[13:22] <BBB> how do I get the 100th line of stdout?
[13:22] Action: BBB forgot
[13:22] <BBB> gr
[13:22] <thomasvs> head -n 100 | tail -n 1 ? :)
[13:22] <shawarma> BBB: head -n 100 | tail -n 1
[13:23] <shawarma> thomasvs: Ha, beat you to it. :-) 
[13:23] <shawarma> thomasvs: About that CVSROOT.. Have you dug it up yet?
[13:23] <thomasvs> shawarma: depends on your irc connection, really :)
[13:23] <BBB> no, every 100th line
[13:23] <shawarma> thomasvs: I can't seem to find any mention of it on the website.
[13:23] <BBB> so 100, 200, 300
[13:23] <thomasvs> shawarma: yeah, still working on the site
[13:24] <BBB> shawarma: I'll work on the PWg, which includes most of this
[13:24] <BBB> and yes, I seriously intend to work on PWG
[13:25] <thomasvs> shawarma: cvs -d:pserver:[email protected]:/cvs/gstreamer co gst-template
[13:25] <shawarma> BBB: Huh? PWg?
[13:25] <shawarma> thomasvs: Beautiful! Thanks!
[13:26] <shawarma> thomasvs: We'll have to check the IRC logs tomorrow to see who was first. :-D
[13:26] <thomasvs> shawarma: heh, you can win, I don't care :)
[13:28] <BBB> thomasvs was first here
[13:29] <BBB> shawarma: plugin writers' guide
[13:29] <BBB> our cool introduction to gstreamer plugin writing
[13:31] <BBB> holy crap
[13:31] <BBB> nice memlek
[13:31] <BBB> gst-launch filesrc location=large_mpeg_file ! mpegparse
[13:31] thaytan ([email protected]) left irc: "See y'all"
[13:31] <BBB> doesn't unref buffers
[13:46] thaytan ([email protected]) joined #gstreamer.
[13:47] Company ([email protected]) left irc: Remote closed the connection
[14:02] pb_ ([email protected]) joined #gstreamer.
[14:06] Company ([email protected]) joined #gstreamer.
[14:12] alley_cat ([email protected]) joined #gstreamer.
[14:20] sublett ([email protected]) joined #gstreamer.
[14:21] Company ([email protected]) left irc: Remote closed the connection
[14:35] ct_ ([email protected]) joined #gstreamer.
[14:41] <BBB> gr, I hate docs already
[14:41] <BBB> why does it overwrite everything that I'm writing in the XML files on the next 'make'?!?
[14:43] <thomasvs> because you need to adjust either the source, or if not in source, the .sgml files in tmpl/
[14:43] <BBB> so the SGML files aren't being used at all?
[14:43] <BBB> er
[14:43] <BBB> XML
[14:44] <BBB> I mean, the XML files are in CVS
[14:45] <thomasvs> BBB: no, the .sgml files in tmpl/ are in CVS
[14:46] <thomasvs> the reason is because the tools scan the docs, and sometimes move stuff around in the tmpl/ files
[14:46] <thomasvs> so sometimes they need to be commited again, e.g. on api changes
[14:48] <BBB> the .xml files in docs/pwg/ are also in CVS...?
[14:51] markey ([email protected]) joined #gstreamer.
[14:52] <thomasvs> BBB: where are you looking exactly ?
[14:56] <BBB> docs/pwg/pwg.xml
[14:56] <BBB> and intro_basics.xml
[14:58] Action: BBB is cleaning up the introduction to mimetypes
[14:58] <BBB> that part is *old*
[15:06] teuf ([email protected]) joined #gstreamer.
[15:06] teuf ([email protected]) left #gstreamer.
[15:06] teuf ([email protected]) joined #gstreamer.
[15:10] markey ([email protected]) left irc: "leaving"
[15:37] <BBB> can I write a horizontal line (like <hr>) in tables in XML?
[15:37] <thomasvs> hm
[15:37] <thomasvs> that's not the way you should write docbook, no
[15:37] <thomasvs> what do you want to do ?
[15:38] <BBB> I have a table of audio mimetypes, and I want to add a small <hr> or something similar (something visible as a delimiter) to separate between properties for all audio mimetypes, raw mimetypes and encoded mimetypes
[15:38] <BBB> the first would feature rate/channels
[15:38] <BBB> the second audio/x-raw-{int,float}
[15:38] <BBB> the rest goes in the third
[15:39] <BBB> I simply want some visible thing to separate between those three
[15:39] <BBB> simply for aesthetic purposes
[15:40] <thomasvs> yeah, I know what you want
[15:40] <thomasvs> it's just that that's not how it's done in docbook
[15:40] <thomasvs> it's a matter of markup vs display
[15:40] sublett ([email protected]) left irc: Read error: 110 (Connection timed out)
[15:40] <thomasvs> so, I guess you need to put stuff in a table
[15:40] <thomasvs> if you can show me an example in other gtk-doc stuff of what you want I can tell you how to do it though
[15:40] <BBB> so I'd make a row with '-' as content or so?
[15:40] <BBB> hm...
[15:41] Action: BBB will look for other gtk-doc thingies
[15:42] <thomasvs> BBB: for heavens' sake no, no row of -'s :)
[15:42] <thomasvs> check the gtk apis and friends
[15:42] <thomasvs> run devhelp, find an example :)
[15:42] <thomasvs> but it sounds like a table is all you need
[15:43] <BBB> I'm checking the docbook website
[15:53] Action: BBB thinks he found a wya to work arounf iot
[15:54] <thomasvs> BBB: what way ? removing/replacing random keys on your keyboard ?
[15:54] <BBB> yes... I now type 'hi' but still get '---' on my screen
[15:54] <BBB> good enogu
[15:54] <BBB> no, I can make subtitles in tables
[15:54] <BBB> that serves the same purpose
[15:54] <BBB> so it's good enough
[15:56] ds-gromit__ ([email protected]) left irc: Read error: 110 (Connection timed out)
[16:00] Company ([email protected]) joined #gstreamer.
[16:03] Action: BBB kicks wingo for creating the buffer-frames property
[16:07] <Company> what's so problematic about it?
[16:09] Action: thomasvs proceeds to autotool the website build
[16:09] <BBB> oh, nothing
[16:10] Action: BBB is converting docs/random/mimetypes into a docbook document
[16:16] ChrisHJW ([email protected]) left irc: Ping timeout: 14400 seconds
[16:24] <Company> BBB: i think buffer-frames is a useful idea - video already has that implicitly
[16:29] sublett ([email protected]) joined #gstreamer.
[16:35] <BBB> what you mean is audio frames, and I think that is useful... buffer-frames defines the amount of data, and as I said, I think we need to figure out a more general way to solve that, like a read() method or adapting the get() method
[16:41] <thomasvs> it's 2004 and making websites still sucks
[16:41] <thomasvs> we have too much junk on our site
[16:41] <thomasvs> and it's hard to separate
[16:42] Action: thomasvs wonders how to fix
[16:42] <BBB> we can throw out 50%
[16:42] <BBB> like the status tables
[16:42] <BBB> they're unmaintained and cause confusion
[16:42] <thomasvs> yeah, but I mean
[16:42] <BBB> please throw such stuff out
[16:42] <thomasvs> it's a matter of mixing tools too much
[16:42] <thomasvs> I want to make it very simple
[16:42] <thomasvs> and very maintainable
[16:42] <thomasvs> which is very hard :)
[16:42] <BBB> I want to write plugins in one second
[16:42] <BBB> which is very hard
[16:42] <BBB> ...
[16:42] <thomasvs> ah well
[16:43] <BBB> (as in: life of a developer is hard... that's just the way it is... :(
[16:43] <thomasvs> I guess I should just Do As I Please
[16:43] Action: BBB agrees
[16:44] <taaz> what's the trouble with the website?  i thought you were moving to a xml based autogenerated one?  that shouldn't be too hard to maintain.  just autogen status tables and such
[16:47] <BBB> from where?
[16:48] <taaz> from xml/xslt rather than sql and php
[16:50] <thomasvs> taaz: yeah, I'm just thinking about layout of dir structure, keeping built files away from source, separating cvs content from uploaded content
[16:50] <thomasvs> (for example, actual content vs. packages/releases/...)
[16:50] <thomasvs> taaz: for example, I'd like us to put the debian packages online neatly as well on our site
[16:50] <thomasvs> taaz: how do you feel about packages/debian ?
[16:57] Misirlou ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[16:58] Misirlou ([email protected]) joined #gstreamer.
[17:05] KA ([email protected]) joined #gstreamer.
[17:05] <taaz> ah, i see.  a little more formal about stuff ;)
[17:05] <taaz> should really have a web dev site too so changes can be verified before pushing to the live site
[17:06] <taaz> if you want to get complicated ;)
[17:08] <thomasvs> well
[17:09] <thomasvs> I'm thinking the dev site can easily be local
[17:09] <thomasvs> which is what works now in the new setup
[17:09] <thomasvs> and commit locally automatically updates live site
[17:09] <thomasvs> right now I'm just wondering about the best way to have the huge downloadable non cvs chunks be easily accessible
[17:10] <thomasvs> so, assume you want all the media files under gstreamer.net/media
[17:10] <thomasvs> should I start symlinking bits from a data/ subtree to the main root ?
[17:15] shawarma ([email protected]) left irc: "BitchX: its everywhere you want to be"
[17:24] <BBB> this is actually working quite well
[17:24] <BBB> shall I commit my first changes?
[17:24] <BBB> or does anyone want to control?
[17:24] <BBB> (I mean, the old docs were beyond antique...)
[17:25] <Company> if it still builds, everything is better than before ;)
[17:25] <thomasvs> well, commit if you're sure it works
[17:26] <thomasvs> does anyone care if our media files are under data/media ?
[17:26] <thomasvs> or will people complain ? :)
[17:27] <Company> you could symlink media to data/media for compatibility
[17:27] <Company> i'll only complain if there's no place telling me
[17:28] <thomasvs> yeah, I'm wondering if I should just deal with it and symlink chunks all over after separating content and data
[17:28] rk ([email protected]) left #gstreamer.
[17:28] <thomasvs> sites are always such a mess
[17:31] <Company> you could also make media just a html page forwarding to data/media
[17:32] <taaz> which wouldn't work too well for people who grab media via wget
[17:33] sublett ([email protected]) left irc: "I like food, food is good!"
[17:33] <Company> they would figure it out
[17:34] <Company> people using wget can read raw html...
[17:35] <dolphy> (gdb) print buffer->data
[17:35] <dolphy> $6 = (guint8 *) 0x103ecd78 "\023\027\036\022\016\030\026\024\030"
[17:35] <dolphy> something wrong with that ?
[17:35] <dolphy> call g_free (buffer->data) segfaults on ppc
[17:35] <BBB> doesn't VM usually start with 0x80...?
[17:36] <thomasvs> taaz: they can grab from data/media no ?
[17:36] swentel ([email protected]) left irc: 
[17:36] Action: BBB commits first list of changes
[17:36] <Company> dolphy: probably the buffer data was not allocated with (g_)malloc
[17:37] <BBB> this is work for a full week
[17:37] <BBB> :/
[17:37] <taaz> thomasvs: sure, i'm just saying doing html forwarding isn't such a great idea
[17:38] <dolphy> Company: hmm
[17:38] <dolphy> Company: weird
[17:38] <dolphy> Company: i get that with AlienSong.mpg
[17:38] <dolphy> Company: but not with matrix.avi
[17:41] <dolphy> outbuf = gst_buffer_new();
[17:41] <dolphy>   outbuf = gst_pad_alloc_buffer (videoscale->srcpad,
[17:41] <dolphy>                                  GST_BUFFER_OFFSET_NONE, videoscale->to_buf_size);
[17:41] <dolphy> wow
[17:41] <dolphy> who did that
[17:41] <dolphy> that's a nice leak
[17:42] <dolphy> no ?
[17:42] <BBB> videoscale sounds like it ds'?
[17:44] <dolphy> well i ve made changes to videoscale
[17:44] <dolphy> especially in that block but i remember removing the gst_buffer_new
[17:44] Action: BBB blames dolphy
[17:45] Action: Company blames thomasvs just because :p
[17:45] Action: BBB blames company too
[17:45] Action: dolphy fixes instead of blaming
[17:46] <BBB> btw, try the new PWG... I've added some small parts already, it'll be cute :)
[17:46] <BBB> please help me adding sections
[17:47] Action: Company is afraid of building doc-tools
[17:47] <Company> doc-tool writers can't write software that's simple to install i'm afraid
[17:48] <BBB> that's why sane people use debian, suse or redhat - everything's packaged
[17:48] <Company> yeah
[17:48] <thomasvs> Company: yeah, good luck - the whole toolchain is very obtuse
[17:48] <thomasvs> Company: I don't even know if all the wrapper scripts are easily available from source
[17:48] <Company> i'm switching to debian the moment it sutoinstalls source
[17:48] <Company> and debug stuff
[17:49] <thomasvs> Company: so why not use gentoo ?
[17:49] <Company> i can just use LFS instead, gentoo is not that much better
[17:49] <thomasvs> well, gentoo has it all unified, no ?
[17:49] <Company> dunno
[17:50] <Company> i prefer debian, because debian is exceptionally good at just working
[17:50] <thomasvs> well, except for the doc tools :)
[17:50] <thomasvs> apparently /etc/xml/catalog doesn't get rebuilt properly
[17:51] <Company> yeah, but i'll just blame the doctool writers for now
[17:51] <Company> the only disadvantage is that i can't hack on the docs build
[17:52] <Company> but i'm afraid of that, too anyway
[17:53] <Company> templates, obstruse .txt files and whatnot
[17:54] <Company> there's too little xml gurus in the world i think
[17:56] <Company> BBB: does wmv work?
[17:57] <Misirlou> I think some headway is being done on that /etc/xml/catalog problem.
[17:57] <dolphy> outbuf = gst_buffer_create_sub (buffer, headerlen + 4, datalen);
[17:57] <Misirlou> s/done/made/
[17:57] <dolphy> might that be my g_free problem  in mpegdemux?
[17:57] <Misirlou> I still don't think it's completed though. :(
[17:57] <BBB> Company: no
[17:57] <BBB> Company: or, rather: afaik, no
[17:58] <BBB> dolphy: could you provide a gst-launch pipeline that crashes?
[17:58] <dolphy> filesrc location="/home/dolphy/videos/AlienSong.mpg" ! mpegdemux ! mpeg2dec ! ffcolorspace ! videoscale ! xvimagesink
[17:58] <dolphy> videoscale is optional here :)
[17:59] <BBB> did you try other videosinks, without ffcolorspace, without videoscale, etc?
[18:00] ChriHJW ([email protected]) left irc: 
[18:00] <BBB> did you try ffdec_mpeg1video?
[18:00] <BBB> (i.e.: try to narrow it down)
[18:01] <dolphy> filesrc location="/home/dolphy/videos/AlienSong.mpg" ! mpegdemux ! mpeg2dec ! ffcolorspace ! ximagesink
[18:01] <dolphy> same crash
[18:01] <dolphy> same bt
[18:01] <dolphy> #1  0x0f9f5d94 in free () from /lib/libc.so.6
[18:01] <dolphy> #2  0x0fb31ecc in g_free () from /usr/lib/libglib-2.0.so.0
[18:01] <dolphy> #3  0x0feeb59c in gst_buffer_default_free (buffer=0x1002acc8) at gstbuffer.c:97
[18:01] <dolphy> #4  0x0fef09c4 in gst_data_unref (data=0x1002acc8) at gstdata.c:243
[18:01] <dolphy> #5  0x0f811454 in gst_mpeg2dec_chain (pad=0x0, _data=0x8) at gstmpeg2dec.c:614
[18:01] <dolphy> #6  0x0ff0b5f0 in gst_pad_push (pad=0x1002acc8, data=0x1002ac50)
[18:01] <dolphy>     at gstpad.c:2844
[18:01] <dolphy> #7  0x0f860ce8 in gst_mpeg_demux_parse_packet (mpeg_parse=0xf78457c,
[18:01] <dolphy>     buffer=0x102f8cb8) at gstmpegdemux.c:692
[18:01] <dolphy> #8  0x0f85e83c in gst_mpeg_parse_loop (element=0x2dbdc3a6)
[18:01] <dolphy>     at gstmpegparse.c:437
[18:01] <dolphy> #9  0x0f3ca1b8 in loop_group_schedule_function (argc=0, argv=0x8)
[18:01] <dolphy>     at gstoptimalscheduler.c:997
[18:01] <dolphy> i think this is from mpeg
[18:01] <dolphy> the buffer that the video sink tries to free has been badly allocated for ppc arch
[18:02] <BBB> try without mpeg2dec now?
[18:02] <BBB> ffdec_mpeg1video
[18:05] <dolphy> works :)
[18:06] Action: dolphy blames mpeg2dec
[18:06] <BBB> there's your bug then
[18:06] <BBB> so what version of libmpeg2?
[18:06] Action: BBB should go home, it's past 6pm
[18:06] <dolphy> outbuf = gst_buffer_new_and_alloc ((size * 3) / 2);
[18:06] <dolphy>   out = GST_BUFFER_DATA (outbuf);
[18:06] <dolphy> maybe
[18:06] aldug_ ([email protected]) joined #gstreamer.
[18:06] <BBB> no, that's valid
[18:07] <BBB> what version of libmpeg2?
[18:07] <dolphy> 0.3.1-6
[18:07] <BBB> hm
[18:07] <BBB> libmpeg2-0.3.x hands out the same buffer twice sometimes
[18:07] <BBB> could you update to 0.4.0?
[18:07] <dolphy> hmm that's not in debian .. :-/
[18:07] <BBB> I know
[18:07] <BBB> but still
[18:07] Action: BBB goes home
[18:07] <BBB> I'll be back tomorrow, I'll work on docs tonight, k?
[18:07] <BBB> saves me some phone costs
[18:08] <BBB> and please, you guys try to fix up more docs too
[18:08] <BBB> we need it
[18:08] <BBB> bye!
[18:08] BBB ([email protected]) left irc: "Client exiting"
[18:11] <dolphy> rahh i hate that
[18:11] Action: dolphy kicks BBB
[18:11] <dolphy> upgrading to a lib that is not even in debian unstable is not a solution
[18:12] <dolphy> i will get tons of bug reports from people saying "it crashes on my debian unstable"
[18:12] <KA> what's a5Cbout common method to interface gstreamer's plugins to the rest of the world (ie: how to manipulate them outside gst in a std way, with or without gnome possibly). monkey-media is the way rb follows, AFAIK. and others?
[18:12] <KA> dolphy: like me :)
[18:16] <jdahlin> dolphy, "inline" it in gstreamer?
[18:16] <dolphy> raaaahhh
[18:17] Action: dolphy kicks jdahlin
[18:17] <dolphy> that's even worse :)
[18:17] <jdahlin> la la la :)
[18:17] aldug ([email protected]) left irc: Connection timed out
[18:18] <jdahlin> 0.4.0 was released over a month ago
[18:21] <thomasvs> KA: what do you want to do ?
[18:21] <thomasvs> KA: not sure what you're asking
[18:24] <KA> thomasvs: I'm looking inside and around gst with some conding. I'm registered a plugin, and evolnving it in some random way :). Now, how to handle/manipulate/adjust/command it from a command line tool or a widget? (i.e. the volume button in RB operates on volume plugin via monkey-media, AFAIK)
[18:24] <KA> the volume plugin is the simplest example
[18:24] <thomasvs> KA: depends on the plugin, but gst-launch is a good way to start
[18:25] <KA> thomasvs: with gst-launch I create a pipeline, and it works.
[18:28] <KA> during a playback, outside the gst-lauch process, can I connect in some way to gst and modify some plugin properties? Is there a std way to do that?
[18:29] <thomasvs> KA: you can do that in the editor, for example
[18:29] <KA> I hope what I'm asking is clear
[18:29] <thomasvs> KA: it would be clearer if you said what your plugin does
[18:29] <thomasvs> KA: but, taking volume as an example ...
[18:29] <thomasvs> you can launch sinesrc ! volume ! osssink from the editor
[18:29] <thomasvs> and slide the volume's volume slider manually
[18:30] <KA> thomasvs: mu plugin now does nothing. I'm looking for a way to follow and hack around it
[18:31] <dolphy> KA: the standard way is to implement GObject properties in your plugin
[18:31] <dolphy> KA: so that application can change parameters on your plugin directly
[18:32] ChrisHJW ([email protected]) joined #gstreamer.
[18:32] <dolphy> KA: then you can also try to see if your plugin is implementing a common interface
[18:32] <dolphy> KA: and then implements one of our interfaces
[18:32] <dolphy> KA: setting the parameters
[18:32] <dolphy> KA: for example volume implements the mixer interface
[18:33] <dolphy> KA: this way applications that do not even know about your object's properties can find your plugin in the pipeline searching for an plugin implementing an interface and then call the interface function over that plugin to work with it
[18:35] Nick change: apoc_ -> apoc
[18:35] <KA> well
[18:35] <apoc> hi
[18:36] <KA> where the mixer interface is defined? not in gst-plugin/gst/volume 
[18:38] <KA> and monkey-media which role has? nothing more that 'yet another glue lib'?
[18:41] sub_pop ([email protected]) joined #gstreamer.
[18:41] <thomasvs> KA: yes
[18:41] <thomasvs> KA: suffering from NiH
[18:49] <Company> monkey media is the "compatibility wrapper" so there aree no regressions...
[18:50] <thomasvs> KA: monkey-media was basically made for rhythmbox, but it contains a lot of things that should've been in gst in the first place
[18:50] <thomasvs> KA: also, it's not used outside of rhythmbox
[18:51] <Company> that's why it's part of rb now and slowly vanishing :)
[18:52] <Misirlou> Company!
[18:52] <Misirlou> How do I exit "^X mode (^E/^Y/^L/^]/^F/^I/^K/^D/^V/^N/^P)"?
[18:53] teuf ([email protected]) left irc: "Client exiting"
[18:54] <Company> was that a joke i don't get?
[18:55] <Misirlou> no
[18:55] <Misirlou> I'm honestly stuck in VIM and I can't get out.
[18:57] <Company> new terminal, killall vim?
[18:57] <Misirlou> Shucks, I was hoping it wouldn't come to that.
[18:57] <thomasvs> press escape a few times ?
[18:57] <thomasvs> what's ctrl-x mode ?
[18:58] <Company> it doesn't matter anyway, vim keeps a .swp file, doesn'T it?
[18:58] <KA> when you press ^x in insert mode, vim permits to complete some string
[18:58] <alley_cat> escape should get you out of it
[18:58] <alley_cat> three times escape always gets you back into command mode in vim, wherever you are
[18:59] <KA> indeed
[19:00] <Misirlou> hmm
[19:00] <Misirlou> I think I borked the terminal, not vim
[19:03] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[19:15] walters ([email protected]) joined #gstreamer.
[19:15] ds-gromit ([email protected]) joined #gstreamer.
[19:34] thomasvs ([email protected]) left irc: Read error: 113 (No route to host)
[19:36] <Company> grrrrreat
[19:36] <Company> now i'm forced to understand asf
[19:38] <KyleB> is there any *trick* to getting gstreamer to build from cvs for the first time?
[19:38] <KyleB> autogen.sh claims my source tree is incomplete
[19:42] <taaz> on a fresh checkout?
[19:42] <KyleB> yeah
[19:43] <taaz> shouldn't happen. ;)
[19:43] <KyleB> does autogen try to get somthing else from cvs? my cvsroot isn't pointing to freedesktop anymore
[19:44] <taaz> so it's not a fresh checkout? ;)
[19:44] <KyleB> You are missing common/gst-autogen.sh
[19:44] <KyleB> well, it was last night
[19:44] <taaz> you need to point to fdo now
[19:44] <KyleB> ok
[19:48] <KyleB> hm, so now my cvsroot does point to fdo, and autogen spits out + getting common from cvs
[19:48] <KyleB> cvs server: cannot find module `common' - ignored
[19:48] <KyleB> cvs [checkout aborted]: cannot expand modules
[19:48] <ds-work> ugh
[19:48] <ds-work> what a weekend
[19:49] <Company> apoc: ping?
[19:49] <Company> ds-work: hm?
[19:49] hallibaby ([email protected]) joined #gstreamer.
[19:50] <Company> ds-work: i hope it's not problematic for your caps design that i made try_set_caps accept non-fixed caps?
[19:50] <ds-work> yes, very
[19:50] <ds-work> why would you do that?
[19:51] <ds-work> you oviously have not read the documentation
[19:51] <Company> ds-work: audioconvert
[19:52] <Company> ds-work: same for ffcolorspace
[19:53] <ds-work> they were working fine
[19:54] <Company> audioconvert wasn't or i wouldn'T have had segfaults
[19:54] <Company> anyway, it works fine with non-fixed caps and the docs don't have a reason for why fixedness is required
[19:54] <ds-work> because there's another way to do non-fixed caps
[19:55] <ds-work> revert it
[19:55] <Company> which one?
[19:55] <ds-work> I'll fix it, if you give me a launch line that is broken
[19:55] <ds-work> revert everything you've changed
[19:57] pb_ ([email protected]) left irc: "Client exiting"
[19:57] <taaz> does 0.6.x work with libmpeg2 0.4.0b?
[19:58] <ds-work> probably not
[19:59] <taaz> grr
[19:59] <Company> i can't give you a launch line, the problem is harder
[19:59] <ds-work> then describe it
[20:01] <Company> assume this launch line: sinesrc ! audioconvert ! audio/x-raw-int,channels=2,rate=48000;audio/x-raw-int,channels=1,rate=44100 ! osssink
[20:01] <Company> and then switch sinesrc from 48000 to 44100
[20:02] <ds-work> it will work fine
[20:03] <ds-work> you are near a case that doesn't work fine, though
[20:05] <Company> that one doesn't work either
[20:05] <Company> because you do get_engotiated_caps and change the rate
[20:05] <ds-work> in that case, you need to add a gst_pad_renegotiate() after the try_set_caps("int,2,44100")
[20:06] <Company> gst_pad_renegotiate calls the link function and that does a try_set_caps on the currently negotiating pad
[20:06] <ds-work> yep
[20:06] <Company> unless you add a big amount of code to check if you'Re currently in nego
[20:06] <Company> and i thought allowing unfixed try_set_caps was better
[20:06] <ds-work> no
[20:06] <Company> why not?
[20:07] <ds-work> because setting unfixed caps is a completely different process
[20:07] <ds-work> what you need is to renegotiate that link
[20:07] <Company> considering the amount of code i changed (deleting the if (_is_fixed()) return; ), it's not...
[20:07] <ds-work> because there are even harder problems with multiple elements that won't get solved by try_set_caps() with unfixed caps
[20:08] <ds-work> the entire system relies on directed negotiation being only done with fixed caps
[20:08] <Company> really?
[20:08] <Company> where?
[20:08] <ds-work> yes
[20:08] <ds-work> it's an assumption that is made everywhere
[20:08] <Company> for example?
[20:09] yippi ([email protected]) joined #gstreamer.
[20:11] <ds-work> can't find an explicit case right now
[20:11] <Company> yeah, i didn'T find one either
[20:12] <ds-work> it was designed that way
[20:12] <Company> yeah, i know
[20:12] <Company> but i didn't find a problem, so i thought it's ok
[20:12] <ds-work> it's not
[20:12] <Company> can we add an equivalent to try_set_caps that allows unfixed caps?
[20:13] <ds-work> yes, it's called renegotiate
[20:13] <Company> :(
[20:13] <ds-work> it could have better semantics
[20:13] <Company> the problem is that i essentially need to do 2 things to make renego work
[20:13] <ds-work> but you can't have a pad say "choose from these unfixed caps"
[20:14] <Company> why not
[20:14] <Company> ?
[20:14] <ds-work> you either have to do directed (with fixed caps), or do a full undirected negotiation
[20:14] <ds-work> because it gets too complicated
[20:14] <Company> i don't see why
[20:14] <ds-work> ok
[20:15] <ds-work> you either _know_ the caps you want to set
[20:15] <ds-work> or you don't
[20:15] <ds-work> if you do, you call try_set_caps()
[20:15] <ds-work> otherwise, you let the core figure out how to negotiate
[20:15] <Company> no, that's not true
[20:15] <Company> i have a function supported_outcaps = function (incaps)
[20:16] <Company> (that's essentially how converters work
[20:16] <Company> )
[20:16] thomasvs ([email protected]) joined #gstreamer.
[20:17] <Company> in that case the caps i want to allow for renego are an unfixed subset of the allowed caps
[20:17] <ds-work> so
[20:17] <ds-work> in the nondirected negotiation, those unfixed caps are returned by the getcaps function
[20:18] <Company> no
[20:18] <Company> the getcaps function returns all possible caps
[20:18] <ds-work> what is wrong with that?
[20:18] <ds-work> if they're all possible, they're all possible
[20:19] <Company> they're all possible, just not with the ones i currently want to set
[20:19] <ds-work> so the app gets to choose what it wants by using fixate signals
[20:19] <ds-work> as an element, you don't get that choice
[20:19] <Company> s/i want to set/the core wants to set/
[20:20] <ds-work> the core will figure it out anyway
[20:20] <Company> not currently unless i kill kittens in the getcaps and link functions of audioconvert
[20:22] <ds-work> and so you want to fix the wrong problem
[20:22] <ds-work> that's dumb
[20:24] <Company> ok, then fix audioconvert, so that this works: run sinesrc ! audioconvert ! audio/x-raw-int,channels=2,rate=48000;audio/x-raw-int,channels=1,rate=44100 ! fakesink
[20:24] <Company> with a custom fixation function on sinesrc
[20:24] <Company> first try you fixate rate to 44100, then renegotiate, second time you fixate to 48000
[20:25] <thomasvs> Company: out of curiosity, what would the filtered syntax do when two caps sets are given ?
[20:26] <Company> thomasvs: pick one in the fixation phase (normally the first)
[20:26] <KyleB> is gst-plugins somthing that should be built sperately from gstreamer, or at the same time?
[20:26] <Company> ds-work: i agree that it is pretty far fetched to do this, but my solution would allow this :)
[20:26] <Company> (it should at least...)
[20:33] <thomasvs> KyleB: separately
[20:34] <thomasvs> KyleB: i know of nothing htat needs to be built at the same time when it comes in different modules, really
[20:34] <KyleB> well, i just noticed i had to make a symlink from the common module to gstreamer module, and didn't know if i should do that for anything else
[20:36] <walters> thomasvs: well, the core api is still changing, so it's generally a good idea to always rebuild plugins when you build the core.  imo, anyways.
[20:38] sublett ([email protected]) joined #gstreamer.
[20:38] <thomasvs> walters: ah, yeah, in that sense, definately
[20:38] <thomasvs> KyleB: from cvs you mean ? you shouldn't need to symlink at all
[20:38] <thomasvs> KyleB: it should be there on a fresh checkout
[20:41] pb_ ([email protected]) joined #gstreamer.
[20:43] <KyleB> i did a checkout of all the modules at once, and common was one directory level higher than gstreamer
[20:43] trow ([email protected]) joined #gstreamer.
[20:46] <thomasvs> KyleB: yeah, but that's normal
[20:46] <thomasvs> KyleB: how did you do your checkout exactly ?
[20:46] <thomasvs> KyleB: if you used "." to check everything out, it's normal that it wouldn't work I think
[20:46] <KyleB> i used eclipse because i've been playing with it lately
[20:47] <thomasvs> KyleB: but then again, we don't really support/promote checking out .
[20:47] <KyleB> so im not sure what cvs command it sent
[20:47] <thomasvs> KyleB: try telling eclipse to check out the "gstreamer" and "gst-plugins" module instead
[20:47] <KyleB> it's all working now.. think i should bother to redo it?
[20:47] <thomasvs> KyleB: although, IIRC, I made autogen check it out properly
[20:48] <thomasvs> KyleB: well, remove the symlinks and just copy the whole common subtree in both gstreamer and gst-plugins
[20:48] <KyleB> ok
[21:06] Uraeus ([email protected]) joined #gstreamer.
[21:07] dolphy ([email protected]) joined #gstreamer.
[21:07] <Uraeus> yo
[21:11] <apoc> hi Uraeus
[21:11] <Uraeus> hola apoc
[21:12] <apoc> dolphy: do you have some time to play a SVQ3 files on PPC with last cvs ?
[21:12] <Company> apoc :)
[21:12] <Company> apoc: does wma playback work for you?
[21:13] <apoc> Company: yes
[21:13] <dolphy> apoc: yup
[21:13] <apoc> Company: it doesn't for you ?
[21:13] <dolphy> apoc: where's the file ?
[21:13] <Company> apoc: current cvs gives me "decoding error" in ffdec_wma2
[21:13] <apoc> dolphy: ftp://ftp.mplayerhq.hu/MPlayer/samples/V-codecs/SVQ3/Vertical400kbit.sorenson3.mov
[21:15] <apoc> Company: Can i download your file somewhere ?
[21:16] <dolphy> apoc: downloading
[21:16] <dolphy> apoc:  i rebuilt ffmpegcodecmap and qtdemux
[21:16] <dolphy> apoc: shoud do it
[21:16] <apoc> dolphy: thx
[21:16] <dolphy> apoc: pipeline ?
[21:17] <apoc> dolphy: -launch filesrc ! qtdemux ! ffdec_svq3 ! ffcolorspace ! xvimagesink
[21:18] <Company> apoc: it's still my standard Phil Collins test file
[21:18] <dolphy> apoc: hmm it s not segfaulting
[21:18] <dolphy> apoc:  but the video seems really damaged
[21:18] <Company> apoc: i must've broken something here then or there's a serious bug somewhere...
[21:18] <dolphy> apoc: and choppy
[21:19] <dolphy> apoc: and it pukes tons of ** (process:16076): WARNING **: ffdec_svq3: decoding error
[21:19] <dolphy> top block unavailable for requested intra mode at 10 0
[21:19] <dolphy> error while decoding MB 10 0
[21:20] <apoc> dolphy: ok ... can i change something and send you a patch for testing ?
[21:20] <dolphy> apoc: yup
[21:32] <apoc> dolphy: dcc or mail ?
[21:35] robUx4 ([email protected]) joined #gstreamer.
[21:35] <robUx4> lo
[21:35] yippi ([email protected]) left irc: "Client exiting"
[21:41] <dolphy> apoc: mail stp
[21:43] <robUx4> I have a basic question on GStreamer
[21:43] <dolphy> robUx4: ask
[21:43] <robUx4> is it meant to be build as a static library or dynamic ? or both are possible ?
[21:44] <robUx4> I'm going to try to build it with MSVC 7.1
[21:44] <dolphy> 1) gstreamer is plugins based so it s dynamic library
[21:44] <robUx4> k
[21:44] <dolphy> 2) it doesn't build on MSVC yet
[21:45] <dolphy> but still you can try to port it 
[21:45] <dolphy> :)
[21:45] <dolphy> looking how gtk and glib did it
[21:45] <robUx4> that's the idea
[21:45] <dolphy> gstreamer is using glib extensively
[21:45] <apoc> dolphy: mail sent :)
[21:45] <dolphy> so should be similar process
[21:45] <dolphy> apoc: gracias
[21:45] <robUx4> I started with MinGW but had too much troubles getting all the dependancies working
[21:47] <robUx4> is everything in the lib exported ?
[21:47] <robUx4> or is there a list somewhere ?
[21:47] <dolphy> apoc: congrats dude
[21:47] <dolphy> apoc: works great
[21:47] <dolphy> apoc: commit ! :)
[21:49] <thomasvs> dolphy: does it do sound too ?
[21:49] <thomasvs> hi robUx4 ! did ChrisHJW talk you into this ? :)
[21:49] <dolphy> thomasvs: well the pipeline does not contain sound elements :)
[21:49] <dolphy> apoc: sound ?
[21:50] <robUx4> thomasvs: talk/take ?
[21:50] <thomasvs> robUx4: heh, basically the same thing, no ? :)
[21:50] <robUx4> somehow
[21:50] <robUx4> and yes and no
[21:50] <robUx4> we are both heads of Matroska
[21:50] <robUx4> we work together a lot :)
[21:50] <thomasvs> robUx4: yeah, I know
[21:51] <robUx4> but noone forces me to work
[21:51] <thomasvs> robUx4: I saw some mails of him about gstreamer and windows
[21:51] <apoc> dolphy: cool ... audio not supported for this video
[21:51] <robUx4> yep, I actually wrote a bit more about it
[21:51] <thomasvs> robUx4: well, we'd gladly help you out if you let us know what problems you run into it
[21:51] <robUx4> I'll let you know
[21:51] mathrick ([email protected]) joined #gstreamer.
[21:52] <mathrick> yo
[21:52] <apoc> yo mathrick
[22:02] Action: Company has a VC++6 lying around here somewhere and he has a spare windows partition. If somebody does the grunt work, i'll gladly boot there and help
[22:02] <Company> especially because there's this interesting idea to port Rb to windows ;)
[22:02] Action: thomasvs gave away his two still sealed copies of microsoft visual studio 6
[22:04] <jdahlin> VC.NET (version 7) has a free download for the command line utilities (compiler etc)
[22:05] Action: Company bought VC and worked with it before he found out about Linux
[22:06] <robUx4> jdahlin: cool ! I didn't know that
[22:07] <robUx4> BTW, where else can I get the Glib sources ? the GTK FTP is saturated
[22:07] <jdahlin> robUx4, let me see if I can give you a link too
[22:08] <robUx4> thx
[22:09] <Company> are gnome and gtk ftp different btw?
[22:14] <ChrisHJW> robUx4 : tell them you are grown-up boy and wont allow anybody, not even me, to talk you into something :)
[22:15] markey ([email protected]) joined #gstreamer.
[22:15] <thomasvs> ChrisHJW: hm, if he does that, because yo utell him to, then ... :)
[22:15] <mathrick> lo markey
[22:16] <ChrisHJW> lol@ thomasvs
[22:16] <ChrisHJW> :)
[22:16] <ChrisHJW> you guys are really ok ...
[22:18] Action: mathrick notices more than usual Matroska guys
[22:18] <jdahlin> robUx4, http://www.microsoft.com/downloads/details.aspx?FamilyId=9B3A2CA6-3647-4070-9F41-A333C6B9181D&displaylang=en should do it
[22:18] <mathrick> did I miss some interesting flame or anything? ;)
[22:18] <jdahlin> large download though
[22:18] wheels ([email protected]) joined #gstreamer.
[22:18] <mathrick> hi wheels
[22:18] <wheels> howdy
[22:19] <robUx4> flame ? no
[22:19] <robUx4> interrest :)
[22:19] <robUx4> as soon as GStreamer works under Win32 natively, we'll love you :D
[22:20] <mathrick> jdahlin: if I read thomasvs blog correctly, you're the new full time gst hacker, right?
[22:20] <jdahlin> mathrick, that's correct
[22:20] <jdahlin> mathrick, starting on friday
[22:20] <walters> oh, cool
[22:21] <mathrick> thomasvs: you could have told that earlier :)
[22:21] <mathrick> jdahlin: cool :)
[22:22] <jdahlin> how many people are there that are paid to work on gstreamer?
[22:22] <walters> jdahlin: so what is your company doing with gst?  or is it s3kr1t? :)
[22:22] <thomasvs> mathrick: I could have
[22:23] <jdahlin> walters, ask thomasvs :)
[22:23] <robUx4> and I use libxml2 instead of libxml ?
[22:24] <Company> well, libxml-2.x is libxml2
[22:25] <robUx4> ?
[22:25] <Company> is there even a libxml anymore?
[22:30] <Company> geez, bytestream needs some optimizations
[22:31] <thomasvs> so, anyone care to write up how seeking should theoretically work so I can verify all of the relevant parts for every format ?
[22:32] <thomasvs> (with how it should work, I mean both inside and outside view)
[22:36] <robUx4> mmm
[22:36] <robUx4> something very bad :(
[22:36] <robUx4> #define g_error(...)
[22:37] <robUx4> MSVC7.1 doesn't support this kind of argument in macros
[22:37] <thomasvs> hm, I guess asking for "anyone" doesn't work well
[22:37] <thomasvs> ds-work: care to write up how seeking should theoretically work ?
[22:37] <thomasvs> robUx4: hm - maybe it's easiest to check what people use to compile glib on windows
[22:37] <ds-work> thomasvs: don't really know how it works
[22:38] <thomasvs> ds-work: ok, on to the next victim
[22:38] <thomasvs> Company: care to write up how seeking should theoretically work ?
[22:40] <robUx4> thomasvs: I know they use GCC
[22:40] mathrick ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[22:41] <robUx4> which is OK, but not the preferred way
[22:41] <thomasvs> robUx4: and you can't use gcc for some reason ?
[22:41] <robUx4> yes
[22:41] <thomasvs> ok
[22:41] <robUx4> I had TOO much troubles making GStreamer compile with GCC
[22:41] <KyleB> anyone know what could cause this: (rhythmbox:6674): GStreamer-WARNING **: element pipeline claimed state-change success,but state didn't change to PLAYING. State is PAUSED (NONE_PENDING pending), fix the element
[22:41] <thomasvs> robUx4: want me to ask around about what people have tried for glib ?
[22:41] <robUx4> I just wanted to make sure that in the end I would have something working before going the other way
[22:42] <thomasvs> robUx4: it should work fine with gcc - please file bugs for whatever you run into that doesn't work with gcc
[22:42] mathrick ([email protected]) joined #gstreamer.
[22:42] <robUx4> who should I send that to ?
[22:42] <thomasvs> robUx4: bugzilla.gnome.org, but in this case you can also mail the -devel list
[22:43] <robUx4> ok
[22:43] <robUx4> first I want to see if there is a workaround with MSVC or not
[22:44] <Company> thomasvs: ugh, anything special? basically it's just like every other event stuff: send event and let next element handle it
[22:44] <thomasvs> Company: no, I meant the bird's eye view.
[22:44] <thomasvs> Company: looking from the outside, here's how an app should do seeking.
[22:44] <thomasvs> and based on that, on the inside
[22:45] <Company> thomasvs: gst_element_seek (sinkelement, format, offset);
[22:46] <thomasvs> Company: hm, ok, so why isn't it working currently ?
[22:46] <Company> because some element isn't forwarding the seek correctly probably
[22:47] <Company> that's always the problem: ine function call triggers actions in loads of plugins
[22:47] <Company> s/ine/one/
[22:47] <hyriand> robUx4: there are 2 ways to do variable arguments in c(++) macros, of of them is "...", the other "args...", see here for more details: http://developer.apple.com/documentation/DeveloperTools/gcc-3.3/cpp/Variadic-Macros.html
[22:49] ChriHJW ([email protected]) joined #gstreamer.
[22:49] ChrisHJW ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[22:51] <robUx4> apparently Microsoft do it another way
[22:51] <robUx4> and it only works with functions not macros
[22:52] <robUx4> so instead of :
[22:52] <robUx4> #define GST_CAT_LEVEL_LOG(cat,level,args...)		/* NOP */
[22:52] <robUx4> I have :
[22:52] <robUx4> inline void GST_CAT_LOG_OBJECT(,...) {} /* NOP */
[22:52] <hyriand> well, now it's not a variadic macro anymore
[22:53] <robUx4> well, who cares ?
[22:53] <robUx4> as it's nop
[22:53] Action: hyriand doesn't
[22:53] <robUx4> I assume this macro does nothing
[22:53] <robUx4> does it ?
[22:53] thaytan ([email protected]) left irc: No route to host
[22:54] <hyriand> depending on the way msvc implements inline functions, there might be a slight speed penalty
[22:55] <robUx4> I think even without optimization this will produce no code
[22:56] <ChriHJW> nite people
[22:56] <robUx4> nite
[22:56] <mathrick> nite ChriHJW
[22:57] <Company> that macro produces code, but not when debugging is disabled
[22:57] <Company> :)
[22:58] <Company> but use whatever MSVC requires, we can fight that out with the sun people later on :)
[22:58] <robUx4> mmm, I just have found where it produces code
[22:58] <robUx4> maybe using GST_DEBUG_ENABLE_DEPRECATED ?
[23:06] hadley ([email protected]) joined #gstreamer.
[23:17] ChriHJW ([email protected]) left irc: Connection timed out
[23:18] <ds-work> thomasvs: what are we doing about freezing?
[23:18] hallibaby ([email protected]) left irc: "Bye bye"
[23:23] <Company> grr
[23:23] <Company> wma does not work here
[23:23] <Company> anyone got a working wma file for me?
[23:23] <Company> apoc ?
[23:29] thomasvs ([email protected]) got netsplit.
[23:29] thomasvs ([email protected]) returned to #gstreamer.
[23:29] <ds-work> thomasvs: what are we doing about freezing?
[23:31] <robUx4> bye everyone
[23:31] <robUx4> I'll let you know how I'm progressing
[23:32] robUx4 ([email protected]) left irc: "Baby wants to bleep"
[23:38] ct_ ([email protected]) left irc: "Client exiting"
[23:49] <thomasvs> ds-work: I'm all for it, this week.
[23:49] <thomasvs> ds-work: basically, I want some comments so I can fixate error
[23:50] <thomasvs> ds-work: but I'll fixate without comments if necessary
[23:50] <thomasvs> ds-work: when do you want it frozen ? I can do a release as soon as we declare it so
[23:50] <ds-work> just do it
[23:50] <thomasvs> ok
[23:50] <ds-work> a release is good
[23:51] <thomasvs> ds-work: is there anything else you can think of that needs to be done first
[23:52] <taaz> has anyone seen a libmpeg2 0.4.0 patch for 0.6.4?
[23:52] <taaz> i can't build new debs right now :(
[23:52] <Company> taaz: just look at the patch for HEAD, it wasn't this big iirc
[23:52] <thomasvs> taaz: so, how about gstreamer.net/pkg/debian :)
[23:55] <taaz> thomasvs: it's a pain to keep packaging info in upstream cvs
[23:55] Nick change: KA -> KA_afk
[23:55] <thomasvs> taaz: no, I meant that as a location for our official debs ?
[23:55] <taaz> oh, blah, i can't read ;)
[23:55] KA_afk ([email protected]) left #gstreamer.
[23:56] <taaz> what's wrong with the debian archives?
[23:56] Nick change: harshyLP -> harshy
[23:57] <taaz> Company: i see that bug was closed as a dup of the head one.  but the patch was never applied to 0.6 tree was it?
[23:57] <thomasvs> taaz: I don't know how it works, but don't the packages need to be approved and so on first ?
[23:57] <thomasvs> taaz: ie, isn't there an amount of lag between "stuff you get done" and "stuff that goes in upstream" ?
[23:58] <taaz> there's a lag for new packages.  less than a day for updated ones.
[23:59] <thomasvs> ok, so you have no need for pkg/debian ?
[00:00] --- Tue Jan 27 2004
[00:00] trow ([email protected]) left #gstreamer ("Leaving").
[00:00] <taaz> thomasvs: need somewhere to point people to debian archives
[00:03] <taaz> anyone care to figure out how to fix 0.6.4 mpeg2dec plugin for me? ;)
[00:03] <thomasvs> taaz: I'm pretty sure someone mailed ap atch to the list and filed a bug with it , no ?
[00:04] <taaz> for head maybe
[00:05] Action: taaz looks again...
[00:05] <Company> taaz: i don't think anyone still applies stuff to 0.6 ...
[00:05] <taaz> well i'm forced to now
[00:06] <taaz> new libmpeg2 can't coexist with old one.  therefore new mpeg2dec debs break gstreamer.  must fix gstreamer now.
[00:07] <taaz> it is kind of bad that stable gstreamer doesn't actually build with latest upstream sources
[00:07] <ds-work> no it isn't
[00:07] <ds-work> not when the maintainer can't keep a stable API
[00:08] <Company> taaz: http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins/ext/mpeg2dec/gstmpeg2dec.c.diff?r1=1.56&r2=1.60 doesn't look like a lot to backport
[00:08] <dolphy> taaz: there will be new mpeg2dec debs ?
[00:09] <dolphy> taaz: i dpkg -P mpeg2dec to install 0.4.0 this afternoon manually :-(
[00:09] Shoragan ([email protected]) left irc: "Leaving"
[00:09] <taaz> dolphy: yeah, i've got them here if you want them.  will take a few days to get through the new queue
[00:09] <taaz> dolphy: i wanted to fix fix gstreamer first before uploading
[00:10] <dolphy> taaz: fix gstreamer ?
[00:10] <dolphy> taaz: head builds alright with 0.4.0
[00:10] <taaz> dolphy: 0.6.4 doesn't, which is what is in debian
[00:12] taf2 ([email protected]) joined #gstreamer.
[00:12] <Uraeus> ok night guys
[00:12] Uraeus ([email protected]) left irc: "Client exiting"
[00:13] markey ([email protected]) left irc: "good nite"
[00:13] <taaz> Company: yeah, i'll do that.  thanks.  i was working off the bugzilla patch which is similar.
[00:15] Action: dolphy heads to bed too
[00:15] <dolphy> night
[00:15] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[00:16] <taf2> hi i'm trying out gstreamer: successfully compiled the helloworld example in the documentation on the gstreamer.net website
[00:16] <taf2>  i get the following error message:
[00:16] <taf2>  GStreamer-CRITICAL **: file gstelement.c: line 1533 (gst_element_link_many): assertion `element_1 != NULL && element_2 != NULL' failed
[00:16] <taf2> any pointers? i'm running fedora core 1 and used apt-get for redhat as explained on the website to setup gstreamers
[00:17] <taf2> i narrowed the error down to this line: gst_bin_add_many( GST_BIN( pipeline ), filesrc, decoder, audiosink, NULL );
[00:20] <thomasvs> taf2: filesrc and decoder are NULL, you didn't create/assign them correctly
[00:20] <thomasvs> taf2: one guess could be your registry isn't set up properly
[00:20] Action: bitshifter thought he remembers someone saying that Fedora doesn't have the 'mad' plugin for some reason (potential patent issues?), so 'decoder' is probably NULL. Tried replacing 'mad' with 'vorbisfile' and using an .ogg?
[00:21] <thomasvs> taf2: what bitshifter said makes sense too
[00:21] <taf2> bitshifter: i have libmad installed but i think its probably an issue with the registry cause i have a version of 0.7 installed along with 0.6
[00:22] <taf2> whats the best way to create a fresh regsitry?
[00:23] <thomasvs> taf2: the tw oversions don't collide, so that's not a problem
[00:23] <thomasvs> but run gst-register
[00:23] <thomasvs> otoh
[00:23] <thomasvs> taf2: how did you install 0.7 ?
[00:24] <taf2> apt-get
[00:24] <taf2> just changed it to unstable or testing
[00:25] <taf2> should i see mad in the regsitry file?
[00:26] yippi ([email protected]) joined #gstreamer.
[00:26] <ds-work> yo
[00:26] <thomasvs> taf2: yeah, but from where did you install 0.7 ?
[00:29] <taf2> thomasvs: i'm checking... but i thought i just modified my sources.list file
[00:30] <taf2> thomasvs: i must have compiled from source
[00:32] <taf2> bitshifter: you were right :)
[00:33] <taf2> i needed the gstreamer-plugin-mp3 rpm
[00:34] <Company> what is the possible cause of the bug if your app runs in gdb but not without?
[00:35] <wheels> Company: memory corruption
[00:35] <wheels> Company: try valgrind
[00:35] <taf2> company: lots of possiblities could be memory could be concurrency
[00:35] <mathrick> taf2: if you compile yourself, *always* run gst-register-0.[67] afterwards
[00:36] <Company> wheels: you win :)
[00:36] <Company> taf2: you too
[00:36] Action: wheels just has lots of practice corrupting memory.  :-)
[00:39] <iain> dumdudmdudmdudm
[00:39] <iain> wheels: thats cos you smoke too much dope
[00:39] <Company> i should just buy a better processor and valgrind everything
[00:39] <wheels> iain: crack, usually
[00:41] <wheels> iain: I'm much more of a stimulant man.
[00:42] <iain> ah, its not so good at memory corruption though
[00:42] <iain> LSD is though
[00:42] <wheels> iain: also not a stimulant  ;-)
[00:43] <Company> arrrrgh
[00:43] <iain> wasn't saying it was, sorry :)
[00:45] <Company> yeah, bla, f*ck it, DIE
[00:46] <Company> 2 loopbased elements and all sorts of weirdness happens
[00:47] <Company> i wonder how this works when i add spider to the mix
[00:52] Action: Company doesn'T get it
[00:53] yippi ([email protected]) left irc: Remote closed the connection
[00:55] <iain> Company: opt fun and games?
[00:58] <Company> iain: every scheduler crashes differently
[00:58] <Company> but only with alsa, oss works fine
[00:58] <iain> Company: hmm, nice
[01:01] harshy ([email protected]) left irc: "I quit for now"
[01:03] <Company> not really
[01:06] harshy ([email protected]) joined #gstreamer.
[01:06] hadley ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[01:06] harshy ([email protected]) left irc: Client Quit
[01:07] harshy ([email protected]) joined #gstreamer.
[01:10] Nick change: thomasvs -> thomasvz
[01:14] pb_ ([email protected]) left irc: "Client exiting"
[01:15] danb ([email protected]) left irc: Remote closed the connection
[01:22] <mathrick> nite
[01:23] Nick change: mathrick -> mathrick|sleep
[01:25] <taaz> ds-work: you checked in some doc cruft
[01:27] harshy ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[01:32] thaytoo ([email protected]) joined #gstreamer.
[01:33] <Company> ok, asfdemux works on BE machines and should work on 64bit machines, too
[01:34] <Company> though i still don'T get why it doesn'T work with alsasink
[01:34] <Company> (and yes, i need shift for a ' )
[01:34] <ds-work> taaz: I reverted it 5 minutes later
[01:34] kmaraas ([email protected]) joined #gstreamer.
[01:36] hadley ([email protected]) joined #gstreamer.
[01:41] iain ([email protected]) left irc: "a staggering account of the sermon on the mount"
[01:42] <taaz> ds-work: commit msg emails are slow i guess...
[01:42] <thaytoo> http://spalah.sourceforge.net 
[01:43] <thaytoo> First time I've seen that one
[01:44] <ds-work> Features:
[01:44] <ds-work> export one frame to SWF
[01:46] <thaytoo> not bad for version 0.01
[01:46] <ds-work> yeah
[01:46] <ds-work> I just thought it was amusing
[01:52] taf2 ([email protected]) left #gstreamer ("Leaving").
[01:54] Nick change: kmaraas -> km_sleep
[01:54] <taaz> +      if (G_BYTE_ORDER == G_BIG_ENDIAN)
[01:54] <taaz> +       flags = (flags << 8) | (8 >> flags);
[01:54] <taaz> ? is that really intended?
[01:55] <ds-work> where is that?
[01:55] <ds-work> someone's smoking crack
[01:55] <taaz> 2004-01-26  Jeremy Simon  <[email protected]>
[01:55] <taaz>         * ext/ffmpeg/gstffmpegcodecmap.c: (gst_ffmpeg_caps_to_extradata):
[01:55] <taaz>         Fix SVQ3 decoding on PPC
[01:56] <taaz> i assume it's just a byte swap, which should use glib macro
[01:56] <ds-work> most likely
[01:56] <taaz> right now it's a broken byte swap ;)
[02:15] sublett ([email protected]) left irc: "I like food, food is good!"
[02:18] hadley ([email protected]) left irc: "Leaving"
[02:19] <Company> "either it's already night and everybody's left the museum or the sun exploded and i'm the last man on earth"
[02:19] <Company> i like johnny bravo
[02:42] Rotty ([email protected]) left irc: Remote closed the connection
[02:46] lilo ([email protected]) got netsplit.
[02:52] lilo ([email protected]) got lost in the net-split.
[02:53] sub_pop ([email protected]) left irc: "Client exiting"


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn