From: IRC B. <wt...@us...> - 2002-11-10 06:43:13
|
******************************************************************* [03:03] <taaz> thanks! [03:03] chrisime (~chr...@p5...) left irc: "Client Exiting" [03:15] steveb (~st...@20...) joined #gstreamer. [03:37] ds-work (ds...@co...) left irc: Remote closed the connection [03:45] ds-work (ds...@co...) joined #gstreamer. [04:09] <thomasvs-eat> ds-work: heh, yeah, I have that too (->getting 100+ packages installed on buliding the plugins-) [04:09] steveb (~st...@20...) left irc: Read error: 104 (Connection reset by peer) [04:13] chillywilly (da...@mk...) left irc: "Free Your Enterprise! - http://www.gnuenterprise.org" [04:36] steveb (~st...@20...) joined #gstreamer. [05:09] ska-away_ (~sk...@ds...) joined #gstreamer. [05:12] ska-away (~sk...@ds...) left irc: Read error: 60 (Operation timed out) [06:31] walters (wa...@st...) joined #gstreamer. [06:45] Nick change: KuroHome -> Kuroyi [06:47] Marsupilami23 (~Mar...@22...) joined #gstreamer. [06:56] steveb (~st...@20...) left irc: Read error: 113 (No route to host) [07:52] tjansen (~tjansen@pD9E212EE.dip.t-dialin.net) left irc: Read error: 60 (Operation timed out) [08:05] walters (wa...@st...) left irc: "z" [08:06] Action: Marsupilami23 waves [08:34] Action: Marsupilami23 is away: Sleeping [09:11] Nick change: ChrHJW_zZZz -> ChrisHJW [09:20] Nick change: ChrisHJW -> ChrHJW_log [09:46] tjansen (~tj...@p5...) joined #gstreamer. [09:53] Uraeus (~csc...@c2...) joined #gstreamer. [09:53] <Uraeus> morning [10:30] Uraeus (~csc...@c2...) left irc: "Client Exiting" [10:39] cschalle (~csc...@c2...) joined #gstreamer. [10:41] cschalle (~csc...@c2...) left #gstreamer ("I like core dumps"). [10:41] Uraeus (~csc...@c2...) joined #gstreamer. [10:53] Nick change: harshy|out -> harshy [10:54] Action: harshy is away: I gotta go!!!! [10:54] Action: harshy is back (gone 00:00:04) [11:24] ds (~ds@66.124.254.23) joined #gstreamer. [11:24] <ds> moo [11:25] <Uraeus> morning ds [11:26] harshy (~ha...@dh...) left irc: "And I'm spent!" [11:27] Nick change: Uraeus -> Ura_brb [11:39] harshy (~ha...@dh...) joined #gstreamer. [11:49] <harshy> yay sid was updateed to 0.4.2 finnally [12:05] harshy (~ha...@dh...) left irc: Remote closed the connection [12:23] Nick change: Ura_brb -> Uraeus [12:29] Nick change: ska-away_ -> ska-awas [12:29] Nick change: ska-awas -> ska-away [12:36] <Uraeus> wtay-tv: ping [12:37] harshy (~ha...@dh...) joined #gstreamer. [12:37] Nick change: harshy -> harshy-z [13:05] thaytan_ (~jan@CPE-144-137-122-229.nsw.bigpond.net.au) got netsplit. [13:05] Uraeus (~csc...@c2...) got netsplit. [13:05] tjansen (~tj...@p5...) got netsplit. [13:05] abraar (~abraar@AToulouse-105-1-7-54.abo.wanadoo.fr) got netsplit. [13:05] ChrHJW_log (Wiesner@pD9E5A778.dip.t-dialin.net) got netsplit. [13:05] smoser (~sm...@pi...) got netsplit. [13:05] Kuroyi (~ri...@14...) got netsplit. [13:05] wtay-tv (~wi...@ca...) got netsplit. [13:05] ds (~ds@66.124.254.23) got netsplit. [13:05] ska-away (~sk...@ds...) got netsplit. [13:05] aflinta (af...@at...) got netsplit. [13:05] vektor (~ve...@ca...) got netsplit. [13:05] camh (~ca...@xi...) got netsplit. [13:05] ajmitch (~me...@wl...) got netsplit. [13:05] thaytan_ (~jan@CPE-144-137-122-229.nsw.bigpond.net.au) returned to #gstreamer. [13:05] <thomasvs-eat> ds-work: heh, yeah, I have that too (->getting 100+ packages installed on buliding the plugins-) [13:05] Nick change: thomasvs-eat -> thomasvs [13:06] Uraeus (~csc...@c2...) returned to #gstreamer. [13:06] tjansen (~tj...@p5...) returned to #gstreamer. [13:06] abraar (~abraar@AToulouse-105-1-7-54.abo.wanadoo.fr) returned to #gstreamer. [13:06] ChrHJW_log (Wiesner@pD9E5A778.dip.t-dialin.net) returned to #gstreamer. [13:06] smoser (~sm...@pi...) returned to #gstreamer. [13:06] Kuroyi (~ri...@14...) returned to #gstreamer. [13:06] wtay-tv (~wi...@ca...) returned to #gstreamer. [13:11] ajmitch (~me...@wl...) got lost in the net-split. [13:11] camh (~ca...@xi...) got lost in the net-split. [13:11] vektor (~ve...@ca...) got lost in the net-split. [13:11] aflinta (af...@at...) got lost in the net-split. [13:11] ska-away (~sk...@ds...) got lost in the net-split. [13:11] ds (~ds@66.124.254.23) got lost in the net-split. [13:11] <Uraeus> thomasvs: long meal? :) [13:13] ska-away (~sk...@ds...) joined #gstreamer. [13:13] ds (~ds...@ad...) joined #gstreamer. [13:13] vektor (~ve...@ca...) joined #gstreamer. [13:13] aflinta (af...@at...) joined #gstreamer. [13:13] camh (~ca...@xi...) joined #gstreamer. [13:13] ajmitch (~me...@wl...) joined #gstreamer. [13:23] <thomasvs> Uraeus: yeah ;) [13:30] ^iain^ (~ia...@us...) joined #gstreamer. [13:37] abraar (~abraar@AToulouse-105-1-7-54.abo.wanadoo.fr) left irc: Read error: 110 (Connection timed out) [13:37] abraar (~abraar@AToulouse-105-1-3-123.abo.wanadoo.fr) joined #gstreamer. [14:21] thaytan_ (~jan@CPE-144-137-122-229.nsw.bigpond.net.au) left irc: Read error: 110 (Connection timed out) [14:31] <Uraeus> thomasvs: our goal is still to make a rapid 0.4.3 right? [14:33] ChrisHJW (Wiesner@pD95410C3.dip.t-dialin.net) joined #gstreamer. [14:40] <thomasvs> Uraeus: yeah, but fix our problems before it ;) [14:42] <Uraeus> thomasvs: we have no problems, only fun challenges :) [14:42] <thomasvs> haha ;) [14:42] <thomasvs> well, a spider fix or replacement would be nice if we have any hope of convincing anyone to use gst-player [14:43] <Uraeus> thomasvs: yeah, not sure what we need to do to get company into action there [14:43] <thomasvs> painful application of torture devices [14:44] <Uraeus> agreed, unfortunatly it seems IRC puts some limitations on what we can do compared to RL :) [14:54] ChrHJW_log (Wiesner@pD9E5A778.dip.t-dialin.net) left irc: Connection timed out [14:56] <kconger> good morning! [15:06] <Uraeus> morning kconger [15:11] <kconger> thomasvs:Hows Nautilus-media coming? [15:12] <thomasvs> kconger-work: still working on metadata currently [15:12] <thomasvs> it is of course taking longer than I thought [15:12] <kconger> ah [15:13] <kconger> well you see a release of my Terminal view soon [15:14] <kconger> I've got it reading your gnome-terminal settings out of gconf now [15:23] chrisime (~chrisime@pD959060D.dip.t-dialin.net) joined #gstreamer. [15:23] <chrisime> hi [15:24] <chrisime> could anybody please have a look at murrays mail? we currently figuring out whether gst_object_destroy() is essential or not. It's important for us to fix lifecycle stuff in gstmm. [15:24] vektor (~ve...@ca...) left irc: "ugh" [15:26] <chrisime> thomasvs ? [15:26] <thomasvs> chrisime: start the discussion on the mailing list about it. [15:26] <chrisime> thomasvs, murray started it [15:27] <chrisime> we need your comments [15:27] <chrisime> it's on gstreamer-devel, dude [15:27] <thomasvs> chrisime: dude, I don't know about that stuff, not everything should go by me, on the contrary. No need to "dude" me. [15:27] <thomasvs> you don't need my comments at all. [15:27] <chrisime> *g* [15:27] <chrisime> well who knows about it [15:27] <chrisime> thomasvs, hey! don't be that way, i was just asking... [15:28] <Uraeus> sounds like a typical wtay-tv question to me [15:28] <thomasvs> I'm not being "that way", I'm just surprised I get asked about everything when it's obvious I only know stuff about some things ;) [15:28] <Uraeus> thomasvs: huh [15:28] <chrisime> thomasvs, wtay TV <--- [15:29] <chrisime> that's why i was aksing you [15:29] <Uraeus> thomasvs: I was sure you where wtay-tv's twin brother :) [15:29] <thomasvs> Uraeus: haha, belgium is small, but not *that* small [15:29] <chrisime> *gggg* [15:29] <thomasvs> chrisime: I know, but that doesn't really help you ;) wtay doesn't transfer all his knowledge to me when he watches tv [15:29] <chrisime> thomasvs, well, I'll wait for wtay then. [15:29] <thomasvs> sadly ;) [15:29] <chrisime> thomasvs, np [15:29] <chrisime> i just didn't know [15:30] <chrisime> sorry [15:30] <thomasvs> chrisime: which is why it's better to bring those things up on the mailing list - you reply to murray's mail and give your view, and so on [15:30] <thomasvs> but you need to give *specific* details about what is wrong and why, preferably with test code that shows it [15:30] <thomasvs> ie, if you think the refcounting is wrong, it's easy to show that using a test app [15:31] <chrisime> thomasvs, i'm on #c++ on irc.gnome.org and i was discussing that with murray [15:31] <chrisime> i told him, it might be a good idea to ask here [15:31] <thomasvs> we're all for getting the stuff fixed, we just need to know what's wrong exactly [15:31] <chrisime> thomasvs, murray is worried about the lifecycle issues [15:32] <chrisime> thomasvs, so, should I ask you a more specific question [15:32] <chrisime> thomasvs, the thing is, that question is on gstreamer-devel [15:32] <chrisime> it just needs to get answered [15:33] <thomasvs> well, the question posed there assumes a very intimate knowledge about gtk which I don't have. [15:34] <thomasvs> So I'll repeat my statement on it : if there is something wrong, please explain what exactly and show us something that brings out the error [15:34] <thomasvs> ie, tell us what you think is going wrong instead of asking us if it is similar to other toolkits, because I don't have a clue [15:36] <chrisime> thomasvs, okok, thx for now [15:37] <thomasvs> so, will you give us an example of what goes wrong then on the mailing list ? so we can understand ? [16:17] <^iain^> http://discomachinegun.prettypeople.org/~iain/marlin-record.png [16:17] <^iain^> comments on the UI? [16:18] <chrisime> thomasvs, i'll discuss that with wtay [16:43] sxpert__ (~sxpert@APh-Aug-105-1-5-104.abo.wanadoo.fr) left irc: Read error: 110 (Connection timed out) [16:44] walters (walters@216.226.142.156) joined #gstreamer. [16:45] sxpert__ (~sxpert@APh-Aug-105-1-5-128.abo.wanadoo.fr) joined #gstreamer. [16:54] abraar (~abraar@AToulouse-105-1-3-123.abo.wanadoo.fr) left irc: Remote closed the connection [16:55] abraar (~abraar@AToulouse-105-1-3-123.abo.wanadoo.fr) joined #gstreamer. [16:58] <Uraeus> ^iain^: small issue, I think you should align the two drop down menus with eachother so the left side is aligned that is [16:59] <^iain^> Uraeus: well, my justification for that is that the second option menu is part of the "Existing" radio group, so needs to be indented [16:59] <^iain^> Uraeus: but I dunno [17:01] <Uraeus> ^iain^: well science have shown that symetri is what people consider beautiful [17:02] <^iain^> ah, but are the HIG people really human? [17:03] <Uraeus> they are generally considered inhuman as far as I know :) [17:04] <Uraeus> ^iain^: actually I think you should align the two dropdown menus, the three button collection and the help button, would make the GUI look much cleaner [17:05] <Uraeus> currently the GUI leaves you feeling stuff where sprinkled out over it with no concrete plan behind it [17:06] <^iain^> the 3 buttons aren't lined up properly...no [17:06] <^iain^> the Help button I have no control over [17:06] <^iain^> and the HIG says that you have a label and indent stuff to show what label it relates to [17:45] Uraeus (~csc...@c2...) left irc: "I like core dumps" [17:47] <chrisime> wtay-tv, still tv? [17:55] ^iain^ (~ia...@us...) left irc: "time to watch my XF screw up" [18:00] ^iain^ (~ia...@us...) joined #gstreamer. [18:29] Manny (~chris@pD9E9656E.dip.t-dialin.net) joined #gstreamer. [18:30] Action: Marsupilami23 is back (gone 09:56:57) [18:32] ct (~ct...@13...) joined #gstreamer. [18:34] walters (walters@216.226.142.156) left irc: "I like core dumps" [18:42] kconger (~kc...@us...) left irc: Remote closed the connection [19:18] BBB (~BB...@bu...) joined #gstreamer. [19:20] <thomasvs> dom di dom [19:22] <BBB> thomasvs: how about i18n&&gst-rec? ;) [19:22] <BBB> or, if you really want to be my today's master, help me separating libgstrec and gst-record (so that gst-rec can goto gnome-CVS) [19:26] <thomasvs> hehe ;) [19:26] <thomasvs> nice try ;) [19:26] <BBB> darn, I failed ;) [19:26] <thomasvs> I'm going to hold you to your promise about spider first ;) [19:26] <BBB> did you try running it? :) [19:26] <BBB> oh fsck :D [19:26] Action: BBB begs company to come back [19:26] <thomasvs> yeah, and it failed on the account of libgstaudio not being a lib [19:27] <chrisime> wtay's a TV dude ;) [19:27] <thomasvs> so I can't even imagine how you made it work without either a nasty symlink hack or messing with ld.so.conf [19:27] <BBB> I simply never tried installing it ;) [19:27] <BBB> I only run local installations [19:28] <BBB> but erm [19:28] <BBB> wouldn't it be a good idea to just make libgst{video,audio} libs in rpefix/lib? [19:29] <BBB> apparently, I can't load them dynamically [19:32] <thomasvs> BBB: so how do you link to it uninstalled then ? [19:32] <BBB> gstreamer-libs-uninstalled.pc [19:32] <thomasvs> and what's in it that you can't get at through the plugin mechanism ? [19:33] <BBB> look at it :) [19:33] <thomasvs> they are plug-in helper libs, not app libs [19:33] <BBB> I use the functions directly [19:33] <BBB> so the symbols need to be in the app when linking [19:33] <BBB> hrm.... [19:33] <BBB> how about special app helpers? ;) [19:35] <thomasvs> well, I guess you should mail the list then. There must have been a reason why they were never libs before. [19:35] skroob (~be...@12...) joined #gstreamer. [19:35] <thomasvs> if they need to be libs, we'll change it, but we need to agree on needing that change ;) [19:47] <BBB> http://cvs.sf.net/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins/gst-libs/gst/video/video.h.diff?r1=1.1&r2=1.2 [19:47] <BBB> ? [19:47] <BBB> is that useful? [19:49] <thomasvs> yeah, it's more sensible [19:50] <thomasvs> the symbol should have the same name as the header, otherwise it's pretty useless to have it in the first place [19:53] <BBB> hm, ok [20:03] chillywilly (da...@mk...) joined #gstreamer. [20:16] ct (~ct...@13...) left #gstreamer ("Client Exiting"). [20:25] Manny (~chris@pD9E9656E.dip.t-dialin.net) left irc: "..." [21:02] BBB (~BB...@bu...) left irc: "Client Exiting" [22:01] ct (~ct...@13...) joined #gstreamer. [22:12] <ds> moo [22:37] steveb (~st...@20...) joined #gstreamer. [22:45] _marco_c_ (~ma...@pp...) joined #gstreamer. [22:47] <_marco_c_> somebody knows what is this: [22:47] <_marco_c_> (rhythmbox:18576): GStreamer-CRITICAL **: file gstelement.c: line 1492 (gst_element_connect_filtered): assertion `dest != NULL' failed [22:47] <_marco_c_> rhythmbox (pid:18576): [E]xit, [H]alt, show [S]tack trace or [P]roceed: [22:47] <_marco_c_> ???? [22:51] <ds> rb is apparently trying to connect elements with a bad pointer [23:13] _marco_c_ (~ma...@pp...) left irc: "Uscita dal client" [23:16] <ct> thomasvs: hey [23:16] <ct> got a gstreamer app question [23:17] <ct> the demo in the gstreamer programming doc is giving me problems [23:18] <ct> (process:2114): GStreamer-CRITICAL **: file gstelement.c: line 1604 (gst_element_connect_many): assertion `element_1 != NULL && element_2 != NULL' failed [23:19] <ct> i'm getting one of those numbers when i run the mp3 player demo app [23:19] <ct> any suggestions for a fix? [23:22] <ct> ah [23:22] <ct> hmm [23:26] chrisime (~chrisime@pD959060D.dip.t-dialin.net) left irc: "leaving" [23:28] chrisime (~chrisime@pD959060D.dip.t-dialin.net) joined #gstreamer. [23:28] <ds> ct: find out why gst_element_connect_many() is being called with NULL [23:30] <ds> note that it doesn't check any return values of gst_element_factory_make() [23:30] <ct> i think i found out the problem [23:30] <ct> ds i don't have the plugin's package installed [23:31] <ct> more deps blah ;) [23:31] <ds> ah, that will be a problem [23:31] <ct> heh [23:32] <ct> ds can gstreamer handle ID3 tag editing? [23:32] walters (walters@216.226.142.156) joined #gstreamer. [23:32] <ds> the helloworld demo is equivalent to running 'gst-launch filesrc location=xxx.mp3 ! mad ! osssink' [23:32] <ct> ah ok [23:32] <ds> ct: not sure; I know it's being worked on [23:33] <ds> there's been some discussion recently about the proper way to do metadata [23:33] <ct> would it be just a simple plugin? [23:34] <ct> once an agreed representation format is picked out? [23:34] <ChrisHJW> i dont like this kind of hacks [23:34] <ChrisHJW> but this is just IMHO [23:35] <ChrisHJW> simply ignore me [23:35] <ct> ChrisHJW: whatcha mean? [23:35] <ChrisHJW> adding any form of tags to a format that was not designed for this [23:35] <ChrisHJW> or doesnt have any real specs [23:35] txtger (~nj...@13...) joined #gstreamer. [23:36] <ChrisHJW> like adding id3v2 tags to Vorbis [23:36] Kuroyi (~ri...@14...) left irc: Remote closed the connection [23:36] Kuroyi (~ri...@14...) joined #gstreamer. [23:36] <ChrisHJW> or similar [23:36] <ct> yeah [23:36] <ChrisHJW> s/Vorbis/Ogg/ [23:37] <ct> ds: thanks [23:38] <ChrisHJW> if i start recommeding how to do this better it will end in an advertising scenario for MCF, so i better dont start or uraeus will tll me to fuck off with my unfinished shit ;-) [23:38] <ChrisHJW> lol [23:38] Zeenix (~zak@203.135.60.38) joined #gstreamer. [23:40] Nick change: ChrisHJW -> ChrHJW_log [23:46] <ska-away> How old is rhythmbox 0.3.0? [23:52] <ct> well i'm taking off for the day [23:52] <ct> later all [23:52] <ct> thanks for the help [23:52] ct (~ct...@13...) left #gstreamer ("Client Exiting"). [23:53] steveb (~st...@20...) left irc: Read error: 110 (Connection timed out) [23:53] txtger (~nj...@13...) left irc: "Client Exiting" [00:00] --- Sun Nov 10 2002 [00:02] steveb (~st...@20...) joined #gstreamer. [00:05] Nick change: wtay-tv -> wtay [00:05] <wtay> yo [00:06] <wtay> chrisime: refcounting should be implemented exactly like gtk [00:07] <chrisime> hmm? [00:07] <chrisime> wtay, please reply on the ML [00:07] <chrisime> I'm busy with other things right now [00:07] iDub (~jdub@203.206.207.14) joined #gstreamer. [00:07] <chrisime> it'd confuse me [00:07] <iDub> pants off, gstreamer hackers [00:07] <chrisime> ooh no [00:08] <Zeenix> yo wtay [00:08] <chrisime> the crazy j^HiDub [00:09] <chrisime> wtay, ok? [00:09] <wtay> chrisime: yep [00:10] <chrisime> fine, thanks! [00:10] <iDub> anyone attempted gstreamer on ppc? [00:10] <chrisime> nah [00:10] <chrisime> coz i don# [00:10] <chrisime> t have one [00:10] <chrisime> *g* [00:10] <steveb> iDub: dobey does ;) [00:11] <iDub> and hadess [00:11] <Zeenix> wtay: i have a plan for rtp: (1) we move our existing working to udp plugins for the timebeing, it wont make much difference cause we are already abusing rtp as udp(not following standards) (2) well i'll try to make encoder/decoder elements that would make rtp packets for each media type [00:11] <iDub> it doesn't seem to check host type before building the asm bits: [00:11] <iDub> <flood> [00:11] <iDub> [00:12] <iDub> gstmemchunk.c: In function `gst_mem_chunk_alloc': [00:12] <iDub> gstmemchunk.c:124: unknown register name `ebx' in `asm' [00:12] <iDub> gstmemchunk.c:124: unknown register name `ecx' in `asm' [00:12] <iDub> gstmemchunk.c:124: inconsistent operand constraints in an `asm' [00:12] <iDub> gstmemchunk.c: In function `gst_mem_chunk_free': [00:12] <iDub> gstmemchunk.c:162: inconsistent operand constraints in an `asm' [00:12] <iDub> make[7]: *** [gstmemchunk.o] Error 1 [00:12] <iDub> [00:12] <iDub> </flood> [00:12] <chrisime> hehe [00:12] <chrisime> ebx, ecx [00:12] <chrisime> *g* [00:12] <chrisime> base x86 registers [00:12] <Zeenix> wtay: ok? [00:12] <wtay> iDub: correct, we need to remove that piece of code [00:12] <wtay> Zeenix: fine for me [00:13] walters (walters@216.226.142.156) left irc: "I like core dumps" [00:15] <Zeenix> wtay: and imho we wont then be needing rtpsend/recv, we'll be using udpsrc/sink so that user is not bound to be on UDP, should i make tcpsink/src too? [00:15] <wtay> Zeenix: if you want, yes [00:17] <Zeenix> wtay: BTW, i fixed that centuries old bug in udpsrc which didnt allow it to work on RedHat :) [00:18] <wtay> what was it? [00:20] <Zeenix> wtay: you defined len as int, while it should have been socklen_t [00:22] <wtay> ok [00:24] <Zeenix> wtay: strange to find such difference in RH and debian... [00:25] <steveb> the memory use of filesrc ! mad ! osssink appears to grow and grow [00:25] <steveb> is that an illusion or a leak? [00:28] <wtay> steveb: it's normal to grow while mmap brings more pages into memory, but it should not keep on growing [00:28] <steveb> gnomevfssrc ! mad ! osssink seems to grow faster [00:29] <Zeenix> wtay: we inserted a bt878 tv card into one of the machines of the videowall, then we played -launch v4lsrc ! fameenc ! udpsink and -launch udpsrc ! mpeg2dec ! .... on the clients, it was coool but we only had an old VCR as the source :( [00:29] <wtay> steveb: hm.. [00:29] <steveb> maybe it grows at the same rate, but it uses more memory at the start [00:30] <wtay> steveb: it does appear to leak a little.. [00:34] <wtay> steveb: memprof doesn't show a leak.. [00:39] <wtay> steveb: I don't see leaks, maybe top is just kidding you [00:39] <steveb> maybe [00:40] <steveb> libgstplay leaks a lot, and i have a suspicion that spider is the problem [00:42] <wtay> gnomevfssrc ! spider ! osssink doesn't leak [00:42] <wtay> constant at 656771 allocated bytes [00:44] <wtay> my little gtk app leaks though.. [00:44] iDub (~jdub@203.206.207.14) left irc: "it's time to try the monkeybars" [00:44] <steveb> i'll write a test app which mimics the libgstplay pipeline [00:46] <wtay> hovering over the buttons leaks a lot.. [00:46] <wtay> somewhat.. [00:47] <wtay> heh +1MB by just dragging the slider :) [00:48] <steveb> heh [00:50] <steveb> how come spider ! osssink works but spider ! { queue ! osssink } doesn't? [00:50] <thomasvs> evening [00:50] <steveb> mad ! { queue ! osssink } works [00:51] <wtay> steveb: probably because queue does caps proxying and mad doesn't handle it? [00:52] <thomasvs> wtay: is it ok that I separate out the tags from the metadata ? [00:52] <wtay> steveb: er, spider.. [00:52] <wtay> thomasvs: ? [00:53] <thomasvs> wtay: since tags will be read/writable as opposed to the stream data, I separated tags from metadata in vorbisfile [00:53] <thomasvs> so that the program can get the tags only, change them in the GstCaps struct, and hand them back to the write function [00:53] <wtay> what is your definition of tags and metadata? [00:53] <thomasvs> "tags" = the comment fields, the data that is changeable without reencoding [00:53] <thomasvs> ie, artist, title, and so on [00:54] <wtay> ok [00:54] <wtay> you mean the average bitrate etc? [00:54] <thomasvs> no, that is metadata [00:55] <thomasvs> ie, you can't change the average bitrate without reencoding or transcoding [00:55] <wtay> I'm not a fan of putting this info in the metadata struct, yes [00:55] <thomasvs> I mean "tags" as "all the data that can be changed without touching the media data itself" [00:55] <thomasvs> wtay: ok, me neither, so that's why I moved it out of the metadata struct in vorbisfile [00:55] <thomasvs> just checking if that is ok with you or not ;) [00:55] <wtay> thomasvs: yes, only the tags should be in metadata [00:56] <thomasvs> ah, ok, now it's the other way around. Let me restart ;) [00:56] <thomasvs> * I originally put in metadata in vorbisfile for the comments (artists, and so on) [00:56] <thomasvs> * You added the bitrate properties and so on [00:57] <thomasvs> * I wanted to separate the "tags" from the present metadata structure (where metadata is bitrate and so on) [00:57] <thomasvs> but now it looks like you want metadata to be only the tags, not info about the media stream properties ? [00:57] <wtay> metadata is always stuff like author, title etc [00:57] <thomasvs> hm, ok ;) [00:57] <thomasvs> so [00:57] <wtay> the other stuff is more stream properties [00:57] <thomasvs> in what sort of name should I stick the bitrate stuff and so on ? [00:57] <thomasvs> can we use something shorter ? [00:58] <thomasvs> is stream info ok ? [00:58] <wtay> maybe we can define another caps property for that type of properties [00:58] <wtay> stream_info is fine for me [00:58] <wtay> but be careful.. [00:59] <thomasvs> for ? [00:59] <wtay> it should only contain the stuff that is encoded in the stream and canot be queried otherwise, ie, it might be wrong [00:59] <thomasvs> might be wrong ? for example ? [01:00] <wtay> for example, I can add an id3 tag that says how long the mp3 is, I can just put some wrong value in there [01:01] <thomasvs> oh, yeah, of course [01:01] <thomasvs> but that doesn't make much sense does it ? I mean, there's no set way to encode that information in the metadata tag [01:01] <wtay> the real length should be queried with pad_query [01:01] <thomasvs> yeah, right [01:01] <thomasvs> no, I would use this currently [01:01] <thomasvs> a) metadata = tags like author and so on [01:02] <thomasvs> b) streaminfo = properties due to the codec, like layer, joint-stereo stuff, bitrate [01:02] <thomasvs> c) (something unnamed) = length and so on (through the current interface) [01:02] <wtay> hmm.. are you saying not to use properties for b)? [01:03] <thomasvs> b) and a) are handled similarly, they both use a GstCaps pointer in the struct, they both pass it on through the argumentm echanism [01:03] <thomasvs> so, yes, I'd use properties for b) [01:03] <thomasvs> just as it is currently - ie, the "metadata" in vorbisfile is now separated to a) and b) [01:04] <wtay> for what would we use properties then? [01:04] <thomasvs> what do you mean ? [01:05] <wtay> GObject properties [01:06] <thomasvs> uhm, we didn't want to use them anymore for this kind of thing, right ? All we use them for then is to get the pointer to the GstCaps struct of metadata and mediainfo [01:06] <thomasvs> or do I misunderstand it now ? [01:06] <wtay> thomasvs: do you want to get rid of GObject properties? [01:06] <thomasvs> wtay: no. [01:07] <thomasvs> but I'm under the impression that you prefer properties to set stuff on the codecs that can't be done through filtered caps, no ? [01:07] <wtay> yep [01:07] <thomasvs> but i'm not really sure why you ask ;) I mean, I'm not worried about GObject properties at the moment. [01:08] <wtay> one reason: automatic gui, like the editor [01:08] <thomasvs> ok, but my current question now is very simple ;) is it ok if I do the following : [01:08] <thomasvs> a) have a GstCaps structure in plug-ins for metadata [01:09] <thomasvs> b) have a GstCaps structure in plug-ins for media-info that can't be queried through pad caps [01:09] <thomasvs> c) pass both on to the app through a GObject property ? [01:09] <wtay> I'm fine with that in theory but we have to be careful [01:10] <wtay> for example, there is a difference with caps and properties, properties are queried on demand while caps usually get g_object_notified [01:11] <thomasvs> Ok, so currently in vorbisfile, what gets done is [01:11] <thomasvs> a) the GstCaps struct gets filled [01:11] <thomasvs> b) the object notifies of having metadata [01:11] <wtay> thomasvs: for vorbisfile, I don't see a problem [01:11] <thomasvs> c) the plug-in can be queried through a gobject property [01:12] <thomasvs> are you saying that c) is not necessary because b) already hands the struct in the notification ? [01:12] <wtay> thomasvs: no, you still have to _get the property in the handler [01:13] <thomasvs> ok, so what you were saying is - make sure that apps listen to the object notifcation before they get the gobject property that gives them the pointer ? [01:13] <thomasvs> is that what you meant with the warning ? [01:14] <wtay> thomasvs: my problem is that the info of the other caps has to be well defined [01:14] <thomasvs> which other caps, and defined in what way ? [01:14] <wtay> thomasvs: for example, is the type of frame currently decoded by mpeg2dec a candidate? [01:15] <thomasvs> hm, I don't know - I haven't thought about that, but I would say I'd only use this mechanism for properties of the whole stream [01:15] <thomasvs> ie, the average bitrate, but not the immediate one [01:15] <thomasvs> so, no [01:15] <wtay> thomasvs: ok, are you also going to add the info that can be queried with _pad_query? [01:15] <thomasvs> not the type of frame currently being decoded [01:15] <thomasvs> wtay: no [01:16] <thomasvs> wtay: if it can be queried, it should be queried [01:16] <thomasvs> wtay: the API I'm writing will probably convert that to a GstCaps though because it makes sense to make it similar. [01:16] <thomasvs> wtay: but there's no point in providing two ways to get the same data in gstreamer itself, I think [01:17] <wtay> thomasvs: no point in that, it only adds confusion [01:17] <thomasvs> wtay: I do not consider any type of dynamic data that changes with the position in the stream at this point. Ie, media-info will only deal with all of the stream info that describes the whole file as is [01:17] <thomasvs> wtay: it is of course a good question how gstreamer will deal with position-specific properties ... [01:17] <thomasvs> ... and my feeling is that gobject properties are best for that. [01:17] <wtay> thomasvs: ok, so stuff that can be queried at the start and usually doesn't change that much [01:17] <thomasvs> wtay: yep, exactly [01:18] <thomasvs> wtay: or, stuff for which it needs to seek through the file, but it only needs to find it out once [01:18] <wtay> thomasvs: layer, bitrate can change quite often [01:18] <thomasvs> wtay: yeah - but I would only query the average bitrate, or the nominal one, and so on [01:18] <thomasvs> not the current bitrate [01:18] <thomasvs> "current bitrate" has no meaning when describing the whole file. [01:19] <wtay> thomasvs: ok, so for mad, this would mean, only the bitrate encoded in some id3 tag [01:19] <thomasvs> wtay: so, my idea would be that there should be a property (gobject) for "bitrate" which would give the current bitrate [01:19] <thomasvs> wtay: hm, no. nobody encodes bitrate in the id3tag, do they ? [01:19] <wtay> thomasvs: what about VBR mp3s then? they change bitrate every frame [01:19] <thomasvs> wtay: for an mp3, the API would use the pad_query functions to figure out the bitrate I think [01:20] <thomasvs> I think we're saying the same things here [01:20] <thomasvs> for mp3's, it's simple. You get the average bitrate using pad query functions [01:20] <wtay> ok, agree [01:21] <thomasvs> for a vorbis file, you have a few specific bitrate properties that only say "how the file was encoded" [01:21] <thomasvs> like nominal, upper, and lower [01:21] <thomasvs> these should be returned in the stream_info GstCaps struct, through an object notify [01:21] <wtay> yep, they can go into stream_info or something [01:21] <thomasvs> right [01:21] <thomasvs> and the immediate bitrate for vorbisfile would, IMO, best be done still through a specific separate GObject property [01:21] <thomasvs> just like immediate bitrate for mp3's [01:22] <wtay> ok, that's a clear distinction [01:22] <thomasvs> ok, great ;) [01:22] <thomasvs> btw, I thought there was one thing pretty nice about vorbisfile and current bitrate [01:22] <thomasvs> they return the average bitrate between the current position and the last call of the function [01:23] <thomasvs> I think that's a pretty good idea, and I was thinking of doing that for both mad and vorbisfile [01:23] <thomasvs> so that an app can get the property as much as it wants to, at it's own rate, and still get a decent value every time [01:23] <thomasvs> does that make sense ? [01:23] <wtay> thomasvs: hmm... I thought that was pretty stupid.. [01:23] <thomasvs> wtay: hm, why ? [01:24] <thomasvs> I thought it was good because if it returns for example the bitrate of the block used in one _chain, then you have to query this on each iteration [01:24] <thomasvs> so, take xmms for example - it shows the current bitrate every .1 second or something [01:24] <wtay> yes, but nothing else, then [01:24] <thomasvs> if your ui wants to only update each second, the app has to average out all of the bitrates of each iteration [01:24] <wtay> you can't for example get the average over 3 seconds and 1 second with this API [01:25] <thomasvs> yeah, but how would you do that ? [01:25] <thomasvs> I mean, that's even more advanced if you want to do that [01:26] <wtay> query number of bytes at time X and bytes at time X+3, then you have average bitrate over X->X+3 [01:26] <thomasvs> oh, yeah, but that is done using only the GstClock and the pad_query functions, right ? [01:26] <wtay> yes [01:27] <thomasvs> well, will that always work ? Suppose you have two muxed streams, and you do this calculation, then it doesn't work. [01:27] <wtay> you can't use the bitrate API of vorbis for that [01:27] <wtay> thomasvs: oh yes, it works on muxed streams too [01:28] <wtay> it's a sink pad_query [01:28] <thomasvs> oh, right [01:28] <thomasvs> the sink pad keeps a note of how many bytes have passed through it [01:28] <thomasvs> hm, great ;) [01:28] <wtay> yep [01:28] <thomasvs> so you just have to query the right pad [01:28] <wtay> mad supports this [01:29] <wtay> not sure about vorbis.. [01:29] <thomasvs> which reminds me, that's another thing I have to take care of, multiple src pads on the decoder [01:29] <thomasvs> well, ok [01:29] steveb (~st...@20...) left irc: Read error: 113 (No route to host) [01:29] <thomasvs> so you're saying "we don't need to use the vorbisfile API to return a "current" bitrate through a gobject property" ? [01:29] <wtay> ok, the vorbis sinkquery function is there but doesn't do anything, as the bitrate API was broken for it :) [01:30] <thomasvs> and for mad it is the same, so, hm, we don't really need any gobject properties for those things either [01:30] <wtay> thomasvs: well, you can use a property for that, with an explanation of what is does in the blurb [01:30] <wtay> thomasvs: but it's a subset of what gstreamer can do with pad_query [01:30] <thomasvs> hm, yeah [01:31] <thomasvs> so there's not much of a point I think in having a property for it [01:31] <thomasvs> ok, let me first fix up vorbisfile again then so that it fits what we just said [01:31] <wtay> you practically have it for free, as the vorbis API gives it to you, I don't mind a property then [01:31] <thomasvs> ah, ok [01:32] <thomasvs> well, that was my original idea, but you have convinced me again that gstreamer does it better ;) [01:32] <thomasvs> (in theory) [01:32] <wtay> if you do complicated calculations for that, I say leave it out [01:32] <thomasvs> well, I wouldn't do complicated stuff, just return what the vorbisfile API gives us [01:32] <thomasvs> but my feeling is, that if we do this for vorbisfile, we should have the same argument for mad, and make it work the same [01:33] <thomasvs> ie, that would mean we make the argument in mad return the same sort of "bitrate" that we do for vorbisfile, ie average since last call [01:33] <thomasvs> I don't see the point in having inconsistent arguments across similar plugins in any case [01:33] <wtay> thomasvs: actually, it's not that hard, just save the number of bytes of the previous query, do a new query and substract.. [01:33] <thomasvs> yeah, indeed [01:33] <thomasvs> it is simple [01:34] <wtay> thomasvs: yeah, but people should use the gstreamer API, with all of its power [01:34] <thomasvs> right - which is why I currently feel we shouldn't even have a bitrate gobject property [01:35] <wtay> let's just leave it out then, it's pretty useles anyway [01:35] <thomasvs> ok, good ;) [01:36] <wtay> a prefer a general API instead of random properties that causes headaches to sync between plugins [01:37] <thomasvs> yes, I agree [01:37] <wtay> that's why I removed offset and filesrc in filesrc too.. [01:37] <wtay> er filesize [01:37] <thomasvs> yeah, good ;) I'll look at other plug-ins as well and see if we can remove more of those [01:37] <thomasvs> but then we need to think about getting this into the gst-launch line syntax [01:38] <wtay> yes [01:38] <wtay> general pad queries in -launch would rock [01:38] <thomasvs> it would make testing and debugging a lot simpler too [01:40] <wtay> I'm going to remove the std_props in gstelement.c, standard properties should not exist [01:40] <thomasvs> what are those ? [01:41] <wtay> gst_element_populate_std_props [01:41] <wtay> fd, blocksize, bytesperread, dump, silent, touch.. [01:42] <wtay> I didn't like that function, now I have a reason to remove it :) [01:42] <thomasvs> heh, great ;) [01:42] <thomasvs> ok, so, here's a simple question [01:43] <thomasvs> ideally, the api the codec uses has some way to find the metadata, and also knows when there isn't any [01:43] <thomasvs> without having to decode the whole file [01:43] <thomasvs> is it ok if the plugin does a g_object_notify of metadata while leaving it empty ? [01:43] <thomasvs> as a way of saying "there is no metadata in this stream" ? [01:44] <wtay> hmm [01:44] <thomasvs> (btw, just committed vorbisfile changes again, if you agree with how it is done now let me know, I will do the same in mad then) [01:46] <thomasvs> does "hmm" mean "I don't like that idea ?" ;) [01:46] <thomasvs> I just want some mechanism that allows me to find out that there is no metadata without having to iterate the pipeline to completion [01:47] <wtay> I'm thinking.. [01:48] <wtay> the streaminfo in vorbis is nice :) [01:50] <wtay> the problem is that the only thing you can say is, no metadata yet (after a fair number of attempts) [01:50] <thomasvs> wtay: well, it depends [01:50] <thomasvs> for example, for an mp3, the id3 tag is at the beginning or the end of the file, nowhere else [01:51] <thomasvs> so it can be found out a lot quicker than going through the whole file in search for it, no ? [01:51] <wtay> yes [01:51] <thomasvs> so, I'd want to make that possible, before it goes through the whole file [01:51] <thomasvs> one thing to do that would be to make the mad plugin start seeking for metadata [01:51] <thomasvs> before it actually goes through with the chain function [01:51] <thomasvs> I just don't know if that's the right way to do it [01:51] <wtay> yes, that's a good idea [01:52] <thomasvs> do we have a way to identify if it's a seekable stream ? [01:52] <wtay> yes [01:53] <thomasvs> how ? [01:53] <wtay> if the seek event returns FALSE, it's not seekable [01:53] <thomasvs> ah ;) [01:53] <thomasvs> and without actually doing a seek ? ;) [01:54] <wtay> you can't [01:54] <thomasvs> hm, and we can't provide that ? [01:54] <wtay> well, you can get the events supported on a pad [01:54] <wtay> if the seek event is in the list, it should be seekable [01:55] <wtay> gst_pad_get_event_masks [01:56] <wtay> I'm just thinking about streams that *require* a complete decoding cycle to decide if there is no metadata [01:57] <wtay> 'decoding' or parsing [01:57] <thomasvs> hm, there probably will be, but then it's just slower. [01:58] <wtay> notifying an empty metadata caps is fine, if the plugin is sure about it [02:00] <wtay> hmm, caps should exten gstdata.. [02:00] <wtay> extend even [02:01] <wtay> I'm thinking about adding a timestamp to GstCaps so you can know where the metadata was found inside the stream [02:01] <wtay> and it might be useful for other stuff as well [02:01] thomasvs_ (~th...@27...) joined #gstreamer. [02:04] <thomasvs_> ugh [02:04] <thomasvs_> did I miss anything you said ? ;) [02:05] <thomasvs_> I saw everything up to "extend even" [02:05] <wtay> I'm thinking about adding a timestamp to GstCaps so you can know where the metadata was found inside the stream [02:05] <wtay> and it might be useful for other stuff as well [02:05] <wtay> from there on I was silent.. [02:06] <thomasvs_> heh. yeah, sounds like a good idea. [02:07] <wtay> we could also make the plugins smart: [02:08] <wtay> if the srpad is not connected, it just looks for relevant stream info and then goes to eos when it's done [02:08] <wtay> no need to fire empty caps then [02:09] thomasvs (~th...@12...) left irc: Read error: 60 (Operation timed out) [02:10] <wtay> for example, vorbisfile would walk the links and fire metadata info, when it's done, go to PAUSED [02:12] <^iain^> why did no-one tell me that X did translucent colour cursors with drop shadows [02:12] <thomasvs_> ^iain^: in cvs xfree ? [02:12] <^iain^> thomasvs_: yeah [02:12] <thomasvs_> ^iain^: I've heard about it. is it useful ? [02:12] <^iain^> thomasvs_: no, but it looks cool [02:12] <thomasvs_> wtay: hm, yeah, I like that idea. [02:13] <thomasvs_> wtay: so, in the case where the src pad is unconnected, it just spends it's time getting info the quickest way possible [02:13] <wtay> thomasvs_: yes [02:13] <thomasvs_> wtay: in the case where it is connected, it just fires it as it encounters it in the stream ? [02:13] Nick change: thomasvs_ -> thomasvs [02:13] <wtay> thomasvs: yes [02:13] <^iain^> thomasvs_: its like I'm running E17 without the associated lack of memory and slowness [02:14] <thomasvs> wtay: does the vorbisfile API do that ? I mean, it looks like you can only query for the metadata of a link, not have a callback when it comes to that point [02:14] <thomasvs> ^iain^: hehe ;) and without the associated personality [02:15] <thomasvs> damn [02:15] <thomasvs> now I just need a name for the "stream properties" like length and average bitrate [02:15] <thomasvs> the ones that don't get passed on through caps, but are queried through _query's [02:16] <wtay> thomasvs: you can see when the link changes, this is how instream metadata is reported [02:16] <^iain^> thomasvs: and mozilla already seemed to have support for colour cursors as all their custom ones are coloured too [02:24] Zeenix (~zak@203.135.60.38) left irc: Read error: 60 (Operation timed out) [02:31] <thomasvs> well, night ;) [02:31] Nick change: thomasvs -> thomasvz [02:31] <wtay> me too [02:31] Nick change: wtay -> wtay-zZz [02:39] chillywilly (da...@mk...) left irc: "Free Your Enterprise! - http://www.gnuenterprise.org" [02:49] <Vakor> thomasvz: you get notified when you get to a new link, so at that point you can query metadata for the new link and fire off your callback [02:49] <^iain^> hmm, gstspider is borked [02:53] ^iain^ (~ia...@us...) left irc: "!" |