From: IRC <wt...@us...> - 2004-01-27 06:41:56
|
******************************************************************* [03:03] <aeyakovenko> how do i reference a tee? [03:03] sxpert (~sx...@sx...) got netsplit. [03:08] <Company> aeyakovenko: in gst-launch? [03:09] sxpert (~sx...@sx...) 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 (~sx...@sx...) 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 (~Company@pD9E33AFB.dip.t-dialin.net) joined #gstreamer. [04:25] Company (~Company@pD9E33986.dip.t-dialin.net) left irc: Nick collision from services. [04:25] Nick change: The_Company -> Company [04:27] bitshifter (~bit...@ds...) 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_ (~ct...@ad...) joined #gstreamer. [05:31] hadley (~hadley@AC99B4D6.ipt.aol.com) left irc: Read error: 110 (Connection timed out) [05:36] ct_ (~ct...@ad...) left irc: "Client exiting" [06:09] KyleB (~kyle@65.24.13.66) joined #gstreamer. [07:40] ds-gromit_ (~ds...@ad...) joined #gstreamer. [07:42] ds-gromit (~ds...@ad...) left irc: Read error: 104 (Connection reset by peer) [07:43] ds-gromit__ (~ds...@ad...) joined #gstreamer. [07:44] ds-gromit_ (~ds...@ad...) 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 (~rk...@ip...) joined #gstreamer. [08:27] <rk> morning [08:31] herzi (~he...@ki...) left irc: Remote closed the connection [08:31] Nick change: mathrick|sleep -> mathrick [08:32] <mathrick> mornin [08:33] herzi (~he...@ki...) joined #gstreamer. [08:43] aeyakovenko (~aey...@us...) left #gstreamer. [08:48] harshy (~ha...@dh...) joined #gstreamer. [09:00] apoc_ (~ap...@dy...) joined #gstreamer. [09:01] mathrick (~mathrick@Zietka-18.a-inter.net) left irc: Remote closed the connection [09:17] apoc (~ap...@dy...) left irc: Read error: 110 (Connection timed out) [09:21] tim_ (~bit...@ds...) joined #gstreamer. [09:21] bitshifter (~bit...@ds...) left irc: Read error: 104 (Connection reset by peer) [09:21] Nick change: tim_ -> bitshifter [09:25] harshy (~ha...@dh...) left irc: Remote closed the connection [09:42] BBB (~rbultje@213.160.215.2) joined #gstreamer. [09:43] <BBB> howdy [09:46] ChrisHJW (~chr...@p5...) joined #gstreamer. [09:47] thomasvz (~th...@10...) left irc: Read error: 110 (Connection timed out) [09:53] swentel (~swentel@D5768B92.kabel.telenet.be) joined #gstreamer. [09:56] km_sleep (~km...@22...) left irc: "Leaving" [10:02] thomasvs (~th...@po...) joined #gstreamer. [10:22] dolphy (~do...@po...) 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 (~Al...@pp...) 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 (~an...@ch...) joined #gstreamer. [10:50] wheels (~sc...@ds...) 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 (~Company@pD9E33AFB.dip.t-dialin.net) 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 (~charlie@D5760249.kabel.telenet.be) 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 (wa...@ve...) 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 (~ia...@us...) 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 (~rid...@d0...) joined #gstreamer. [12:22] jdahlin (~kri...@10...) joined #gstreamer. [12:22] sxpert_work (~sx...@ra...) left irc: Remote closed the connection [12:26] sxpert_work (~sx...@ra...) 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 (~as...@rz...) joined #gstreamer. [12:34] <Company> thomasvs: ping? [12:43] shawarma (~sh@193.108.190.157) joined #gstreamer. [12:46] <thomasvs> Company: pong [12:47] pb_ (~pb...@cp...) 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:ano...@fr...:/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 (~chr...@p5...) 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_ (~pb...@cp...) 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:an...@fr...:/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 (~ja...@ad...) left irc: "See y'all" [13:31] <BBB> doesn't unref buffers [13:46] thaytan (~jan@202.76.176.22) joined #gstreamer. [13:47] Company (~as...@rz...) left irc: Remote closed the connection [14:02] pb_ (~pb...@ds...) joined #gstreamer. [14:06] Company (~as...@rz...) joined #gstreamer. [14:12] alley_cat (AlleyCat@pD951940F.dip.t-dialin.net) joined #gstreamer. [14:20] sublett (~rv...@21...) joined #gstreamer. [14:21] Company (~as...@rz...) left irc: Remote closed the connection [14:35] ct_ (~ct...@ad...) 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 (~me...@po...) 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 (~te...@gr...) joined #gstreamer. [15:06] teuf (~te...@gr...) left #gstreamer. [15:06] teuf (~te...@gr...) joined #gstreamer. [15:10] markey (~me...@po...) 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 (~rv...@21...) 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__ (~ds...@ad...) left irc: Read error: 110 (Connection timed out) [16:00] Company (~Co...@p5...) 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 (~chr...@p5...) 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 (~rv...@21...) 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 (~ae...@c-...) left irc: Read error: 104 (Connection reset by peer) [16:58] Misirlou (~ae...@c-...) joined #gstreamer. [17:05] KA (~ka...@so...) 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 (~sh@193.108.190.157) 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 (~rk...@ip...) 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 (~rv...@21...) 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 (~swentel@D5768B92.kabel.telenet.be) 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 (~chr...@p5...) 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_ (~al...@gl...) 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 (~rbultje@213.160.215.2) 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 (~al...@gl...) 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 (~chr...@p5...) 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 (~link@129.210.180.84) 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 (~te...@gr...) 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 (~do...@po...) left irc: "Network down, IP Packets delivered via UPS" [19:15] walters (wa...@ve...) joined #gstreamer. [19:15] ds-gromit (~ds...@ad...) joined #gstreamer. [19:34] thomasvs (~th...@po...) 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 (~hallibaby@pD9511ED4.dip.t-dialin.net) 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_ (~pb...@ds...) 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 (~br...@nw...) 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 (~th...@10...) 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 (~rv...@21...) 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_ (~pb...@cp...) 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 (~tr...@ds...) joined #gstreamer. [20:46] <thomasvs> KyleB: yeah, but that's normal [20:46] <thomasvs> KyleB: how did... [truncated message content] |