From: IRC <wt...@us...> - 2004-01-31 06:41:53
|
******************************************************************* [03:00] <taaz> eh.. why does the play/ dir have play.[ch] and gstplay.[ch]? [03:01] <Company> ds: we're not going to fix the GST_ELEMENT_ERROR lisp style anymore? [03:02] <ds> Company: don't know, don't care. We need to freeze, grossness or not [03:03] <Company> ok [03:09] <ds> my ex-gf was surprised when I named my new laptop gromit, since she recalled that I had a machine a few years ago with that name [03:09] <ds> some people remember the strangest things [03:11] Shoragan (~rid...@d0...) left irc: "Leaving" [03:11] <Company> a computer for me is a computer [03:11] <Company> so my laptop is "ibook" [03:11] <Company> d'oh [03:11] <desrt> my laptop is an ibook g4 named polyethylene [03:12] <Company> my server is "server" [03:12] <Company> i'm so creative [03:12] <desrt> i have a server named server. it's not really mine though. it belongs to the city of hamilton. [03:13] <Misirlou> My computer is duende! [03:13] <desrt> that's an interesting name [03:13] <desrt> it has a certain odd symmetry [03:14] <Misirlou> My sister's iMac is limeade. [03:14] <desrt> aqisdn [03:14] <Misirlou> (Guess what color it is.) [03:14] <desrt> blueberry? [03:14] <Company> pink [03:14] <Company> girls have pink computers :p [03:14] <Misirlou> Green, silly. [03:14] <desrt> oh. [03:14] <Company> now really? [03:14] <desrt> so.. why did you call it limeade? [03:15] <Company> it's the name of his sister probably ;) [03:15] <Misirlou> You don't know what a limeade is? [03:15] <desrt> ah. [03:15] <desrt> i know some people with weird names.... but not many as weird as limeade [03:15] <desrt> lee-me-ah-day? [03:16] <Misirlou> No. :) [03:16] <Misirlou> Limeade, like lemonade. [03:16] <Misirlou> <http://www.m-w.com/cgi-bin/dictionary?book=Dictionary&va=limeade> [03:16] <desrt> others: peloton, copacetic, audrey, beastie, tegan, sara, moonpix, ... [03:16] <desrt> Misirlou; thanks for the tip :) [03:17] <Misirlou> The first one is Spanish, though. [03:17] <Misirlou> Spanish for "ghost" I think. [03:18] <desrt> copacetic is the best hostname ever. hands down. [03:18] <desrt> :) [03:18] <Misirlou> I've heard that before. [03:18] <desrt> as a hostname? [03:18] <Misirlou> In a song where it rhymed with pathetic. [03:18] Action: Misirlou Googles [03:19] <desrt> by local H? [03:19] <desrt> the original song was by velocity girl [03:20] <Misirlou> ah, yes, Local H [03:20] <Misirlou> <http://www.raincitystory.com/archives/000993.html> [03:20] <desrt> local H are imposters. [03:20] <desrt> velocity girl rules [03:20] <desrt> how do i tell the current stream position of a pipeline? [03:20] <Misirlou> At least, I think. [03:21] <Misirlou> I couldn't tell Local H from Velocity Girl. [03:22] <desrt> velocity girl is the prototype alpha indierock/britpop band from seattle [03:22] <Misirlou> Would you happen to have the song on hand? [03:22] <desrt> ya. of course. [03:22] <Misirlou> -> /msg :) [03:23] <desrt> :) [03:23] <Company> oh great [03:23] <Company> we now have GST_ELEMENT_ERROR twice [03:24] <Company> who wouldn'T want that :) [03:24] <ds-gromit> oops [03:24] <Company> AND IT STILL DOESN'T DO A GST_ERROR DEBUGGING MESSAGE [03:24] <Company> man [03:24] Action: desrt hands jabber to ds [03:24] <Company> that had to be said [03:25] <ds-gromit> um, it does it in the gst_element_error_full() function [03:26] Action: ds-gromit is about to break down and make liboil depend on glib [03:26] <Company> ds-gromit: it doesn't [03:26] <Company> ds-gromit: 1) that's not a GST_ERROR, 2) it's the wrong category [03:27] <Company> 1) is especially important, because in cvs builds this prints out where the error happens (because default-level is set lower) [03:27] <ds-gromit> then change it instead of complaining [03:27] <Misirlou> Now let's see if this is the one I've heard . . . [03:28] <Company> i wonder why nobody thought that's important [03:29] <Misirlou> Nope, I must have heard the one from Local H. [03:29] <ds-gromit> keep in mind that errors might not need to be reported to the user [03:30] <Misirlou> desrt: Are the lyrics different? [03:30] <Company> it triggers a debugging message [03:30] <desrt> Misirlou; totally different songs. this is a bit off topic. [03:31] <Misirlou> Okay, that's enough. :) [03:40] <Company> g# gst-player /mixtape.ogg [03:40] <Company> ** Message: track found min max volume 0, 40 [03:40] <Company> Killed [03:41] <ds-gromit> Company: btw, do you have any idea about mpeg not playing for more than 2 sec currently? [03:41] <Company> not yet [03:42] <Company> it's _probably_ a time issue [03:42] <Company> or timestamps [03:44] <Company> d'oh [03:45] <Company> ffdec_vp3 claims to support x-theora [03:46] <Company> now it doesn't [03:46] <Misirlou> hm [03:46] <Misirlou> Are they incompatible? [03:46] Action: Misirlou always forgets [03:47] <Company> dunno [03:47] <Company> probably the bitstream used is different [03:47] <Company> vp3 doesn'T have any setup for example [03:48] <Misirlou> Q: Is the Theora bitstream identical to VP3? [03:48] <Misirlou> aldug: Yes and No. Theora is a superset of VP3, so VP3 streams (with minor syntactic modifications) can be made into Theora streams without recompression (but not vice versa) [03:48] Action: Misirlou kicks X-Chat [03:49] <Misirlou> Sorry about that, aldug. [03:49] Action: desrt chuckles [03:49] <Company> yeah [03:49] <Company> and that goesa for the raw bitstream only [03:50] <Company> theora streams have setup data [03:50] <desrt> is theora ever not in ogg? [03:50] <Company> no [03:50] <Company> well, yes [03:50] Action: desrt eyes oggdemux [03:50] <Company> when oggdemux got it out of the ogg, it's not in it anymore ;) [03:51] <desrt> ya. that's what i was getting at :) [03:51] <Company> ogg is just a packaging format [03:51] <desrt> i know. like avi [03:51] <Company> it puts buffers into a bytestream and fetches them out again [03:51] <desrt> what i don't understand is why vorbis can't live without ogg [03:51] <Company> kinda like avi [03:51] <Company> vorbis can [03:51] <Misirlou> I liken them to suitcases. :) [03:51] <Misirlou> In RTP, for example. [03:51] <Company> it needs a container that knows about packets [03:52] <Misirlou> But Vorbis relies on Ogg for seeking, IIRC. [03:52] <desrt> ah.... [03:52] <Company> yes, it requires something from the packets [03:52] <Company> the packets need to save the position [03:52] <desrt> no matter. i'm rather fond of ogg/vorbis. so whatever works [03:52] <Company> so raw vorbis into mov should be possible [03:53] <desrt> is stream positioning currently broken? [03:53] <Company> depends on the format i think [03:53] <desrt> you're right. [03:53] <desrt> vorbisfile = broken [03:53] <desrt> mad = works [03:54] <desrt> i added tag reading for vorbisfile. [03:54] <desrt> but you're switching to oggdemux/vorbisdec [03:54] <Company> i have already switched cvs HEAD [03:54] <desrt> i'm using cvs from a couple days ago [03:55] <Company> if you have a cvs from today and have run gst-register you don't use vorbisfile anymore [03:56] Action: Company wonders why thomas wants to rewrite esd [03:56] Action: Company thinks we have already enough to do with gst [03:56] Action: desrt runs an update [03:57] <desrt> btw. new spider/metadata stuff rocks, company. [03:57] <desrt> i'm back to the point where i'm extremely happy with gstreamer [03:58] <Company> desrt: thx [03:58] <Company> i'm not happy though [03:58] <Company> it's still much too unstable [03:59] <desrt> well.. stability is an implimentation thing [03:59] <desrt> implimentation always lags behind design and api [03:59] <desrt> and those are the things i'm impressed with [04:00] Action: Company is a design and api junkie [04:00] <Company> as opposed to "get stuff done" junkies [04:00] <desrt> then you understand what i mean [04:00] <desrt> broken by design is 100x worse than bugs in the implimentation [04:01] <Company> unfortunately there'S still large parts of gst that are broken by design [04:01] <desrt> it's really big [04:01] <desrt> i think that's what disappoints me most [04:01] <desrt> it seems like it could be a lot smaller... but i wouldn't really know [04:02] <Company> noone ever cared about optimizing [04:02] <Company> it's certainly full of memleaks and non-optimal code [04:02] <Company> and it's very verbose [04:02] <ds-gromit> ah, yes [04:02] Action: desrt greps for /* XXX TODO: FIXME */ [04:02] <ds-gromit> memleak checking is also on my 0.8 list [04:03] <Company> how does one do memleak checking? [04:03] Action: desrt has a nice program for it [04:03] <desrt> 'memprof' [04:03] <desrt> there's something called valgrind too, but i couldn't get it to work properly [04:03] <Company> valgrind 2.0 works fine with gst [04:04] <desrt> memprof just hooks calls to malloc/free and tracks them.... valgrind emulates the machine (so it can trace memory accesses, too) [04:04] <ds-gromit> I use valgrind [04:04] <desrt> i think it disagrees with gentoo [04:04] Action: ds-gromit disagrees with gentoo [04:04] <desrt> because my libc and everything is -O3 -march=stupid -O99999 -munroll-optimise-until-you-go-crazy [04:05] <Company> the nice thing about vorbis is that vorbisdec is 450 lines of code [04:06] <desrt> wow. [04:06] <desrt> like... big wow. [04:06] <Company> vorbisfile is 1100 [04:06] <desrt> vorbisfile has some nice helpers in it [04:06] <Company> oggdemux is 900 [04:07] <desrt> it suprises me that ogg > vorbis [04:07] <desrt> "decompress audio stream" seems beefier than "put some bits in order" [04:07] <Company> demuxers are a lot more complicated than simple decoders [04:07] <Company> well, both use libs to achieve that [04:07] <desrt> ohhh [04:07] <desrt> ok :) [04:07] <Company> oggdemux uses libogg, vorbisdec uses libvorbis [04:08] <desrt> you mean excluding -logg and -lvorbis [04:08] <Company> yeah [04:08] <Company> just the code i need to care about [04:08] <desrt> i thought you meant that decoding vorbis was a 500line job [04:08] <Company> nah [04:08] <desrt> that was my 'big wow' [04:08] <Company> getting libvorbis plugged into gst is a 500 line job [04:09] <ds-gromit> swfdec is 528 lines [04:10] <Company> gst-template is 280 lines [04:10] <Company> can swfdec do length querying and seeking and all that? [04:10] <ds-gromit> no [04:11] <ds-gromit> but it handles multiple output streams [04:11] <desrt> heh. i tried. [04:11] Action: desrt cvs up && make [04:11] <Company> well, oggdemux was 600 when it didn't do that yet :) [04:17] Action: ds-gromit breaks down and adds a glib dep to liboil [04:17] <Company> poor ds [04:17] <Company> ffmpeg will now never use it :p [04:18] <ds-gromit> then they can rewrite the code that needs it [04:18] <Company> but they will only use it if gst gets faster than mplayer anyway [04:18] <desrt> heh. [04:18] <ds-gromit> I have no interest in rewriting strndup() [04:18] <desrt> i use mplayer for everything [04:20] <Company> i use mplayer for video [04:20] <Company> playback [04:20] <Company> or i use totem, depending on machine [04:20] <desrt> by everything, i mean .mpeg, .avi, .wmv, .mov, ... [04:21] <desrt> too many stupid video formats [04:21] <Company> mplayers AVI wasn't BE clean and totem is apt-gettable [04:21] <desrt> i have some corrupted avis that segfault mplayer [04:21] <Company> so my laptop runs xine [04:21] <desrt> that's worrying [04:21] Action: ds-gromit uses gst-player, gst-launch-ext, or suffers [04:21] <Company> i suffer, too [04:21] <desrt> ds is hardcore :) [04:21] Action: ds-gromit suffers a lot [04:21] <desrt> hahahah [04:22] <Company> me too [04:22] <Company> "oh a bug, do we blame it on company directly or indirectly via spider?" [04:22] <ds-gromit> blaming a bug on spider is not blaming a bug on you [04:22] <Company> at least i'm not the default owner of new bugs yet [04:23] <desrt> getting the blame for bugs is an honour [04:23] <desrt> it means that you are seen by people as being the person responsible/in charge [04:23] <Company> bugs in spider end up with "comnpany, could you look at it" [04:23] <ds-gromit> Company: and your response should be "ds is writing the new autoplugger, talk to him" [04:23] <ds-gromit> :) [04:23] <Company> i'd be really honoured if people looked at the bugs themselves [04:24] <Company> ds-gromit: i'm writing one, too :p [04:24] Action: desrt can barely get ./configure to work [04:24] Action: Company hopes that this leads to some incredible circular speedup in autoplug code evolution when ds and Company have different ideas and want theirs implemented ;) [04:25] <desrt> *** Warning: You have configured using the --enable-plugin-builddir option. [04:25] <ds-gromit> Company: I think the process would go a little faster if we worked on the code :) [04:25] Action: desrt slaps autogen in the face a bit [04:25] <desrt> see what i mean? [04:26] <ds-gromit> desrt: I have a mygen.sh that calls ./autogen.sh --disable-plugin-builddir --disable-static [04:26] <desrt> does it also set WANT_AUTOCONF=1.7? [04:26] <ds-gromit> no, because autoconf-1.7 is about 5 years old [04:26] <ds-gromit> perhaps automake-1.7? [04:27] <desrt> yes. that one. [04:27] <ds-gromit> no, because I only have automake-1.7 installed [04:27] <desrt> again... gentoo. [04:27] <desrt> i'm not sure why exactly the old one is installed [04:28] Action: desrt blames python or libtool or something [04:29] <Company> don't use gentoo, use LFS or Debian :p [04:29] <desrt> linux from scratch? [04:29] <desrt> sounds like gentoo but easier [04:30] <Company> yeah [04:30] <Company> and you don't follow any packaging at all [04:30] <Company> you just do what you like [04:30] <desrt> i used to think that was cool [04:30] <desrt> then i got sick of upgrading stuff [04:30] Action: ds-gromit wants to see a distro based on stow [04:31] <desrt> i also got sick of my filesystem decaying [04:31] <Company> yeah, i'm running a mix of gnome 2.1, 2.2, 2.3 and 2.5 [04:31] <desrt> i'm running the only one that you aren't [04:31] <Company> i might actually run gnome-terminal 2.4.sth [04:32] <Company> i actually upgraded most of my stuff to 2.4 [04:33] <Company> bonobo-activation is still 2.1.11 :) [04:33] <Company> and libgnomeprint is 2.2 (I don't even have a printer...) [04:35] <desrt> hah [04:35] <desrt> bonobo-activation doesn't even exist anymore :) [04:35] <desrt> it's libbonobo/libbonoboui now [04:35] <Company> nah [04:36] <Company> there's a 2.4.0 release [04:37] <desrt> ya [04:37] <desrt> it disappeared for 2.5 [04:37] <desrt> no. 2.4.something [04:37] <desrt> because i have the new ones (versions 2.4.2 and 2.4.1) [04:38] <Company> great, that means i'll run 2.1 forever ;) [04:38] <desrt> about frickin' time gst-plugins finished [04:39] <desrt> er.. finished ./configure, that is [04:39] C (~iav@152.3.45.221) joined #gstreamer. [04:39] <Company> ;) [04:39] <Company> gst-plugins needs some splitting [04:39] <desrt> no. gst-plugins needs to not exist. [04:39] <ds-gromit> or fewer directories [04:40] <Company> and not so much options in configure [04:40] <desrt> perfect world scenario: libogg/libvorbis come with gstreamer plugins of their own [04:40] <desrt> (and everything else) [04:40] <ds-gromit> gross [04:40] <Company> there'd still be gst-plugins [04:40] <desrt> gross? isn't that the point. [04:41] <desrt> so that vendor X can release a module for format Y? [04:41] <C> why do i get a this weird error? /tmp/ccKglufa.o(.text+0x1e): In function `main': : undefined reference to `gst_init where did that weird file even come from? [04:41] <Company> because they have the interfaces and common plugins (like audioconvert etc) [04:41] <desrt> C; it's a compiler temp file [04:41] <desrt> are you writing a gstreamer program? [04:41] <ds-gromit> because it would be impossible to change the API [04:42] <Company> no it wouldn't [04:42] <Company> they'd just ship 0.8 plugins and 0.10 would not support a single plugin ;) [04:42] <C> the pre-processor doesn't complain about being unable to find files (it did before, i included the paths in the command), so why can it not find the function gst_init? [04:42] <desrt> C; if you're using pkgconfig.. [04:42] <desrt> you probably have --cflags and not --ldflags [04:42] <desrt> cflags lets it see the #include headers [04:42] <Company> it's --libs, isn'T it? [04:42] <C> i'm not using pkg-config, should i? [04:42] <desrt> --ldflags includes the libraries [04:42] <desrt> C; for sure [04:43] <desrt> oh. --libs [04:43] <desrt> sorry. [04:43] <Company> gcc `pkg-config --cflags --libs gstreamer-0.7` file.c works [04:43] <Company> i use that for simple test files [04:46] <C> hmm...gcc thinks pkg-config is an input file [04:46] <C> it can't find it :P [04:46] <Company> be sure to use the ` [04:46] <desrt> use ` lie company did [04:49] <C> oh ok, works now. libgstreamer-0.7.la is in a file format it can't recognize, i'll try recompiling it [04:52] <desrt> it's a libtool stupidism [04:53] Nick change: bluejay|gone -> bluejay [04:53] <desrt> vorbisdec in cvs is broken [04:53] Action: desrt takes a peek [04:53] sri (~sr...@c-...) joined #gstreamer. [04:53] <sri> hello my kurus [04:54] <desrt> Company; doing a #ifdef inside the middle of a macro call like that is bad mojo according to my compiler. [04:54] <desrt> line 55 [04:54] <Company> kuru is the right word for kde clippy [04:56] <Company> desrt: don't use forte on gentoo [04:56] <desrt> forte? [04:56] <Company> :p [04:57] <desrt> anywy [04:57] <desrt> i've fixed it [04:57] <Company> me too [04:57] <desrt> thanks [04:58] <taaz> should the audio header/libs be exported as a lib rather than a plugin? [04:59] <desrt> so is spider smart enough to say.... construct src ! oggdemux ! mad ! sink out of src!spider!sink? [04:59] <Company> spider is even smarter [04:59] <Company> it uses vorbisdec [04:59] <Company> and float2int [04:59] <desrt> oh. neat. [04:59] <desrt> so if i had a divx inside an ogg it would handle that too? [05:00] <desrt> (assuming a had a video capable sink on the other side) [05:00] <Company> yes [05:00] <Company> if you had a typefind function for the divx stream [05:00] <desrt> heh. i'm doing something oddly. [05:00] <taaz> cause things like osssink can return their clock which is really an GstAudioClock but apps can't use the AudioClock api [05:01] <Company> apps aren't supposed to use it [05:01] <taaz> what about python plugin writers? ;) [05:01] Action: desrt is doing pipeline reuse and it's remembering where it's seeked for one song and seeking to that point when playing the next :) [05:02] Action: desrt investigates [05:02] <Company> taaz: hmmm... [05:02] <Company> taaz: file a bug please [05:02] <C> i recompiled gstreamer, and i still get the "../gst/libgstreamer-0.7.la: file not recognized: File format not recognized" error when compiling my app. what gives? [05:02] <Company> taaz: file against core/bytestream [05:02] <taaz> i'm just looking at wrapping issues and noticed that the audio stuff just made a lib plugin vs a real lib [05:03] <Company> yeah, as does bytestream and some more [05:04] Action: desrt scratches head [05:04] <taaz> i guess i've never really understood why this plugin lib thing is a good idea over real libs [05:04] The_Company (~Company@pD9E3343F.dip.t-dialin.net) joined #gstreamer. [05:05] Company (~Company@pD9E3338A.dip.t-dialin.net) left irc: Nick collision from services. [05:05] Nick change: The_Company -> Company [05:07] <desrt> Company; i transition a pipeline from NULL to PLAYING again. playback picks up where it left off. is this a bug? [05:07] <desrt> and if so do you think i should file it? [05:15] walters (wa...@ve...) joined #gstreamer. [05:23] <sri> Company: hehe [05:25] <Company> desrt: it's probably the current clocking issue [05:26] <Company> desrt: it doesn't hurt to file it though [05:27] <C> i've been stuck with this error for half an hour now: /gst/libgstreamer-0.7.la: file not recognized: File format not recognized. gstreamer compiles cleanly, but when i compile my app it returns that error [05:28] <Company> you use gcc `pkg-config --cflags --libs gstreamer-0.7` file.c ? [05:28] <C> gcc `pkg-config --cflags --libs gstreamer-0.7` mp.c [05:30] <Company> that works on my box [05:30] <Company> what does pkg-config --cflags --libs gstreamer-0.7 print? [05:31] <C> -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -I/root/compile_space/gstreamer-0.7.3/pkgconfig/.. -I/root/compile_space/gstreamer-0.7.3/pkgconfig/../libs -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 /root/compile_space/gstreamer-0.7.3/pkgconfig/../gst/libgstreamer-0.7.la -Wl,--export-dynamic -pthread -lgobject-2.0 -lgmodule-2.0 -ldl -lgthread-2.0 -lxml2 -lpthread -lz -lm -lglib-2.0 [05:31] <Company> uh [05:32] <Company> that needs to be an absolute path [05:33] <Company> do you run uninstalled? [05:33] <C> the ./autogen.sh script doesn't let me install [05:33] <Company> otherwise you probably gave a relative path to ./configure --prefix [05:33] <Company> use --disable-plugin-builddir on autogen.sh [05:37] <C> ah ok. i didn't think it mattered, i'll check back if i have further probs [05:49] <desrt> bug filed [05:55] mathrick|sleep (~mathrick@Zietka-18.a-inter.net) left irc: Remote closed the connection [05:56] <C> desrt: i'm not expert (duh) but isn't that the way it should work? docs say NULL is like pause, so going to play should start off where you paused it [05:56] <Company> nope, PAUSED is like paused [05:57] <Company> NULL is more like null (or uninitialized) [05:57] <C> ....ah [05:57] <Company> even READY is only initialized - but no started [05:57] <Company> so READY always resets to start of stream [06:06] <C> ok...gst-plugins doesn't even compile. gstxvidenc.c has `XVID_ENC_PARAM' undeclared [06:21] ChriHJW_log (~ch...@p5...) joined #gstreamer. [06:37] ChrisHJW_log (~ch...@p5...) left irc: Read error: 110 (Connection timed out) [06:40] <taaz> neat. i can make GstPlay objects in python ;) [06:43] <walters> you know, i was thinking today...gstreamer is really cool. [06:43] <sri> heh [06:44] <sri> although there is this problem I'm having thats been pissing me off to no end. [06:44] <walters> i mean, yeah, it has some bugs, but overall it's just really great. [06:44] <sri> my gnome-volume-control doesn't work. [06:44] <walters> like rb is right now using gstreamer in two separate threads [06:44] <walters> possibly simultaneously [06:44] <walters> one for metadata reading, another for playback [06:44] <sri> it tells me it knows of no mixer devices. [06:44] <walters> and it just worked [06:44] <sri> bastard. [06:44] <sri> but aumix and alsamixer work fine. [06:44] <sri> why lord, WHY? [06:49] <taaz> sri: check the code [06:50] <sri> taaz: check the code? [06:50] <sri> osssink? [06:51] <taaz> i guess... whatever is supporting the mixer interface and telling you it cant find mixers [06:51] Action: taaz has no idea how that code works [06:52] <taaz> walters: can rb do gapless and/or crossfading playback? [06:52] <walters> taaz: nope [06:53] <taaz> why do all players suck like that? ;) [06:53] <taaz> it's an absolute requirement for the 200+ dj mix cds i have [06:54] <walters> my todo list for rb is nearly infinite in length [06:54] <taaz> very aggrivating that iriver widgets don't support it either [06:54] <taaz> heh ;) [06:54] <taaz> my todo list for an rb clone is infinite too ;) [06:55] Nick change: Jaramir -> Jara[zZ] [06:55] <sri> well..how hard could it be to do cross-fading? [06:55] <taaz> this gstplay code looks nice and convienient. i think i'll make a cli audio player with time feedback. let's see how long it takes. [06:55] <taaz> in python of course [06:56] <sri> actually, it sounds like a managing problem, you have to start two streams, and then slowly switch one to the other I suppose [06:56] <sri> while changing the volume. [06:57] <sri> thank god I'm not writing that code. [06:57] <taaz> there are a number of algorithms to do such things [06:58] <taaz> in the past when peecees were slower it was hard to decode two streams and mix all at once... ;) [06:58] <taaz> not such an issue anymore i guess [06:58] <taaz> you still need 2 pipelines though.... [06:58] <taaz> gapless is probably easier for some formats. if you know ahead of time you have two ogg streams, just concat them into the demuxer [07:01] <thaytoo> something based on 'adder' would work, I guess [07:01] <thaytoo> gapless sounds like a cross fader with 0 crossover time [07:02] <thaytoo> anyway, gotta go [07:02] <thaytoo> cya! [07:02] thaytoo (~ja...@ad...) left irc: "leaving" [07:03] bitshifter (~bit...@ds...) left irc: Remote closed the connection [07:04] bitshifter (~bit...@ds...) joined #gstreamer. [07:15] ct_ (~ct...@ad...) left irc: Client Quit [07:23] <taaz> hrm... so i figured out how to fix my bindings, wrote code, and GstPlay is doing nothing now :( [07:23] <taaz> hmm... [07:24] <taaz> how do i programmatically turn on debugging stuff in 0.7? [07:28] <taaz> ahh, gst_debug_(g,s)et_default_threshold [07:50] NFusi0n (~nuc...@ls...) joined #gstreamer. [07:50] <taaz> is there a reason found_tag signal in element marshals the tag structure as a pointer rather than a boxed type? [07:52] <taaz> actually, i'm not sure what type that should be... but pointer seems wrong [07:52] ChrisHJW (~chr...@p5...) joined #gstreamer. [07:52] <taaz> makes it hard for python bindings to use the value [07:58] Action: taaz confused... [07:59] <taaz> anyone know how this sort of thing is supposed to be handled? [08:11] <ds-gromit> GstStructure [08:12] <ds-gromit> you need to look it up in the documentation (i.e., the source code) [08:16] <walters> hm [08:17] <walters> so would queries not working be part of the seeking not workign problem? [08:17] <walters> wow [08:17] <walters> lots of changes to gst-plugins in the last few days [08:20] <ds-gromit> queries don't work? [08:21] Nick change: bluejay -> bluejay|sleep [08:21] <taaz> ds-gromit: yeah, but it's passed as a pointer, not a GstStructure [08:22] <walters> ds-gromit: i can't get a length query to work [08:22] <walters> ds-gromit: i haven't had a chance to debug it in depth though [08:22] <walters> ds-gromit: updating to the latest build now [08:23] <taaz> ds-gromit: i was wondering if it's possible to marshal as the actual type rather than just using casting in the signal handler. [08:23] <taaz> ds-gromit: it's an issue for bindings since they use that type info to create the proper wrapped data [08:27] ChrisHJW (~chr...@p5...) left irc: Read error: 104 (Connection reset by peer) [08:29] mathrick (~mathrick@Zietka-18.a-inter.net) joined #gstreamer. [08:33] <mathrick> lo [08:34] <ds-gromit> taaz: no, it's not passed as a pointer [08:34] <ds-gromit> the signal type has nothing to do with the prototype [08:34] <ds-gromit> using that type info is wrong [08:44] <thomasvz> taaz: last time around I added options to the python bindings so that commandline wise you could use --gst-debug. does that not work anymore ? [08:47] david_ (~da...@h-...) joined #gstreamer. [08:50] <taaz> thomasvz: oh, i have no idea ;) [08:50] <taaz> ds-gromit: well, right now i receive the taglist as a pointer, which makes sense since the marshaller for found_tag is ..._OBEJCT_POINTER [08:51] <ds-gromit> everything is passed around as a pointer [08:51] <taaz> not the element arg [08:52] <taaz> that uses the object marshaller [08:52] <taaz> and appears as a GstElement in the signal handler [08:52] <ds-gromit> objects are just pointers, too [08:53] <taaz> maybe i'm not explaining the problem properly... [08:53] <ds-gromit> let me explain: ignore _everything_ the signal system tells you about types [08:53] <taaz> how? [08:54] <ds-gromit> it is not to be used by anyone except marshallers [08:55] <taaz> well, the python binding code uses the marshaling info to wrap the values on the handler side. found_tag says it's a POINTER so i get a gpointer wrapper instead of a GstStructure wrapper [08:55] <ds-gromit> that's a bug in the wrapper code, then [08:55] <taaz> it's a bug to do what the code told it to do? [08:56] <ds-gromit> no, because the code didn't tell it to do that [08:56] <ds-gromit> that is not information for wrappers [08:56] <ds-gromit> because of the exact problem that you see [08:56] <taaz> so how am i supposed to solve this problem? [08:57] <ds-gromit> don't know [08:58] <taaz> where is the code supposed to know that arg is a structure? [08:59] <ds-gromit> from the documentation :) [09:01] <thomasvz> argh, I never want to do big commits anymore [09:01] Nick change: thomasvz -> thomasvs [09:01] <thomasvs> at least, not on my home line [09:04] <thomasvs> should vorbisdec already work at this point ? [09:05] <ds-gromit> I think so [09:05] <ds-gromit> with float2intnew [09:10] <thomasvs> float2intnew ? [09:10] <thomasvs> we're not going to ship it called that are we ? [09:10] <ds-gromit> probably not [09:10] <thomasvs> though it does work [09:10] <ds-gromit> just that there was no consensus about float2int [09:10] <thomasvs> yeah [09:11] <thomasvs> I know [09:11] <thomasvs> but it needs a change, just don't know what yet [09:11] <ds-gromit> other than "don't touch it", which isn't workable [09:11] <thomasvs> so, I suppose benjamin then also means to deprecate vorbisfile ? [09:12] <thomasvs> then I should look at the tags in there [09:12] <ds-gromit> I thought vorbisfile never did tags [09:13] Action: thomasvs tries to think of a good name without using an abbreviation of interleaved [09:13] <thomasvs> ds-gromit: I thought it did - how else was I getting vorbis comments ? [09:13] <thomasvs> or maybe it in fact never ever did [09:13] Action: ds-gromit didn't [09:14] <thomasvs> so walters doesn't test with oggs in rhythmbox, or what ? [09:14] <ds-gromit> that works with vorbistag, iirc [09:15] <ds-gromit> it's all stupidly complicated, which is why vorbisfile must go [09:19] Rotty (~an...@ch...) joined #gstreamer. [09:22] <walters> thomasvs: i just haven't updated in a few days [09:37] <walters> hm [09:38] <taaz> ds-gromit: could you explain what you're thinking regarding these pointers? i'm really unclear why it shouldn't be using the actual data types [09:39] <ds-gromit> the g_signal code treats typed objects differently than pointers [09:40] <walters> /build/gstreamer-0.7/bin/gst-register-0.7: relocation error: /build/gstreamer-0.7/lib/gstreamer-0.7/libgstintfloat.so: undefined symbol: gst_float2_2_int_get_type [09:40] <ds-gromit> specifically, it deeply copies everything that isn't an object [09:40] <walters> it doesn't seem to be in the src [09:40] <walters> am i missing something? :) [09:42] <ds-gromit> woohoo! videotestsrc now uses liboil [09:46] BBB (~rbultje@213.160.215.2) joined #gstreamer. [09:47] <mathrick> lo BBB [09:48] <BBB> hi [09:51] <thomasvs> BBB: I've been trying to get a useful screenshot of gst-recorder, but I'm failing [09:51] <thomasvs> BBB: what settings should work ? [09:53] <BBB> 'useful screenshot'? [09:53] <BBB> define that please [09:53] <thomasvs> I wanted to have videotestsrc or qcamsrc running and it displaying the running time and so on [09:53] <thomasvs> you know, the kind of stuff it can do :) [09:54] <thomasvs> BBB: but I went through the wizard again and again (btw you should have a "run wizard again" option :)) and I couldn't find any set of settings that didn't make it crash for me [09:54] <thomasvs> so I was wondering what settings you use [09:54] <thomasvs> the interface seems really nice, btw [09:55] <thomasvs> hang on, back in half an hour [09:56] Uraeus (~csc...@3j...) joined #gstreamer. [09:57] <ds-gromit> cool, now videobalance uses liboil [09:57] <Uraeus> walters: have you seen that seeking is now fixed? :) [09:57] <Uraeus> ds-gromit: it works like oiled lightning now? [10:00] Action: sxpert is away: going to work [10:01] <ds-gromit> Uraeus: er, no [10:01] <ds-gromit> because there aren't actually any optimizations in liboil [10:01] <ds-gromit> just infrastructure [10:01] <Uraeus> ds-gromit: ok, so you added a new dependency that doesn't actually add anything? ;) [10:02] <ds> yup :) [10:02] walters_ (wa...@ve...) joined #gstreamer. [10:02] <Uraeus> hi walters_ [10:03] walters (wa...@ve...) left irc: Remote closed the connection [10:03] Action: BBB kicks ds [10:03] <walters_> hi Uraeus. [10:03] Action: ds goes to sleep [10:03] <BBB> apart from that, I guess it's cool [10:03] <BBB> gnight [10:03] <Uraeus> walters_: did you see my message about seeking now working? [10:04] <BBB> thomasvs: I didn't test it at all the past month, I'm sure it's broken. Last time I tested it, it gave all kinds of random capsnego errors in any sort of possible encoding elements [10:04] <BBB> and I didn't bother fixing, too much work [10:04] Nick change: walters_ -> walters [10:04] <BBB> I'll do that in New York when I have some time [10:05] <BBB> thomasvs: I basically just continued working with gst-rec linked to a gst of before the caps merge, it was the easy way out for me [10:05] <BBB> and gst-rec cannot display videotestsrc, I added that some time ago and directly removed it again because it took 100% CPU when *not* recording [10:05] <BBB> that's not useful [10:06] <walters> Uraeus: ah, no... [10:06] <Uraeus> walters: dolphy fixed seeking last night [10:06] <walters> Uraeus: awesome :) [10:06] <Uraeus> BBB: did the ffmpeg people respond on the issue of adding the new colorspace we need for that avi I put into bugzilla? [10:06] <BBB> Uraeus: didn't ask them yet [10:08] teuf (~te...@gr...) joined #gstreamer. [10:08] <teuf> mornint [10:08] <Uraeus> morning teuf [10:10] <mathrick> yo teuf [10:10] <walters> hey teuf. [10:11] <walters> so does anyone know about my gst_float2_2_int_get_type issue? [10:16] <Uraeus> walters: doesn't seem like anyone have heard about it ;) [10:17] <BBB> maybe if you'd explain the issue...? :) [10:18] <walters> /build/gstreamer-0.7/bin/gst-register-0.7: relocation error: /build/gstreamer-0.7/lib/gstreamer-0.7/libgstintfloat.so: undefined symbol: gst_float2_2_int_get_type [10:18] <walters> i'm staring at GST_BOILERPLATE_FULL now... [10:18] thomasvs (~th...@88...) left irc: Read error: 110 (Connection timed out) [10:18] <walters> it looks like it should work... [10:20] <walters> no one else is getting this? [10:20] <Uraeus> haven't tested yet with todays CVS [10:20] <Uraeus> didn't have it last night [10:23] dolphy (~do...@po...) joined #gstreamer. [10:25] <dolphy> morning [10:26] <taaz> blah. i failed to get python gstplay player working. oh well. [10:27] <Uraeus> morning dolphy [10:28] <dolphy> anybody tried seeking ? [10:28] <Uraeus> dolphy: compiling now, and I advocated the fix to walters :) [10:28] <taaz> dolphy: maybe gstplay.[ch] should merge back into play.[ch] to be uniform with the rest of those lib dirs. [10:28] <BBB> walters: not me... which file? [10:29] wheels (~sc...@ds...) left irc: "using sirc version 2.211+KSIRC/1.3.9" [10:29] foser (d0...@22...) joined #gstreamer. [10:29] <dolphy> taaz: what do you mean ? [10:30] <BBB> float2_2_int? [10:30] <BBB> that's wrong [10:30] <dolphy> taaz: everything is usually called gst*.[ch] [10:30] <dolphy> taaz: the old play.[ch] is kind of out of the standards [10:30] <dolphy> taaz: i was planning to cvs delete them soon [10:30] <BBB> actually [10:31] <BBB> most in that dir is not prefixed by gst [10:31] <BBB> and that's my fault, I wrote most of the stuff there [10:31] <dolphy> but it should [10:32] <dolphy> i think it's much better to include a <gstplay.h> than just a <play.h> [10:32] <dolphy> like <gtkwidget.h> is better than <widget.h> [10:33] <BBB> ? [10:33] <BBB> no [10:33] <BBB> you include <gst/play/play.h> [10:33] <dolphy> yeah [10:33] <dolphy> but well i m talking about the header name [10:34] <dolphy> i feel it much better to be gst prefixed [10:34] <BBB> I preferred gst/mixer/mixer.h over gst/mixer/gstmixer.h [10:34] <BBB> dunno why [10:34] <BBB> personal preference, I guess [10:34] <dolphy> yup [10:34] <taaz> i was just comparing with all the other subdirs in that location [10:34] <Uraeus> the gst in the path kinda works as a prefix [10:36] <BBB> exactly [10:38] <Uraeus> seems we will be setting a record in Oslo this january; we are breaking the old record for most snow in january, think we are just a couple of centimeters short and it is snowing today [10:39] <walters> speaking of weather, this is a pretty scary but fascinating article: http://www.fortune.com/fortune/technology/articles/0,15114,582584,00.html?=yes [10:39] <mathrick> Uraeus: cool, how much do you have already? :) [10:41] <dolphy> BBB: have you seen the fix for seeking ? [10:41] <dolphy> BBB: rifflib is a pain in the ass for event handling [10:41] <Uraeus> mathrick: 52 centimeters downtown [10:42] <teuf> with seeking fixed, does that mean that a new 0.7 release is getting closer ? [10:42] <mathrick> Uraeus: wow, we only have something like 20, but it hasn't snowed in a while [10:43] thomasvs (~th...@po...) joined #gstreamer. [10:43] <mathrick> yo thomasvs [10:43] <teuf> hi thomasvs [10:43] <Uraeus> mathrick: in the forest outside Oslo it is probably higher, but I haven't found any numbers anywhere [10:43] <thomasvs> morning peeps [10:43] <thomasvs> BBB: so, gst-recorder ? :) care to make a screenshot ? [10:43] <thomasvs> Uraeus: went to reserve your room this morning [10:43] <thomasvs> the bed is stacked, is that a problem ? [10:43] Action: thomasvs likes stacked beds [10:44] <Uraeus> thomasvs: that is ok with me [10:45] <Uraeus> ok, so I got a SMS from the computer store that the print server I ordered has arrived and that they will reserve it for me for 5 days.....considering I prepaid I think they need to get their head straight [10:45] Action: thomasvs goes to the store pretending to be christian fredrik kallager schaller [10:46] <thomasvs> Uraeus: so, you can build the website locally now ? [10:46] Action: thomasvs tries again to build the 0.6.4 docs [10:46] <Uraeus> thomasvs: yes [10:46] <thomasvs> cool [10:46] <thomasvs> so now you can chck before committing right ? [10:46] <Uraeus> thomasvs: you will not get the item as you mispelled my first last name [10:46] <Uraeus> thomasvs: yes ;) [10:47] <BBB> dolphy: how so? [10:47] <BBB> dolphy: it makes sure that avidemux does **NOT** have to care about events [10:47] <dolphy> BBB: riff lib peeks head [10:47] <BBB> dolphy: because those sort of things make elements suck [10:47] <dolphy> BBB: peeking head is using bytestream_fillbytes [10:47] <Uraeus> walters: yeah, we have similar worries here; that the warm water coming from the gulf of mexico will suddenly change its course due to global warming which would lower the average temprature in norway with 10 degrees celsius [10:48] <dolphy> BBB: bytestream_fillbytes stops on any event [10:48] <BBB> thomasvs: I just gave an answer [10:48] <BBB> thomasvs: I basically just continued working with gst-rec linked to a gst of before the caps merge, it was the easy way out for me [10:48] <dolphy> BBB: and peek_head then returns false [10:48] <BBB> and gst-rec cannot display videotestsrc, I added that some time ago and directly removed it again because it took 100% CPU when *not* recording [10:48] <dolphy> BBB: so if you send an event to avidemux it just tells "Unable to read from ressource" [10:48] <dolphy> BBB: which sucks hard [10:48] <BBB> dolphy: actually, no... if you seek (riff_seek), that function handles the vent already [10:48] <thomasvs> BBB: ah, ok. so you need to update it first ? [10:48] <dolphy> BBB: so i modified bytestream so that it's only stopping to fill bytes when EOS is catched [10:49] <thomasvs> BBB: and you don't happen to have a screenshot lying around for the website ? [10:49] <dolphy> BBB: only seeking [10:49] <BBB> so if you want rifflib to handle flush events, add a handler for that in the seek function in rifflib [10:49] <dolphy> BBB: not anything else [10:49] <BBB> ? [10:49] <BBB> I'm not following you [10:49] <BBB> thomasvs: only old ones [10:49] <dolphy> BBB: the loop function of avidemux is getting riff read [10:49] <dolphy> BBB: if an event comes [10:50] <dolphy> BBB: it stops [10:50] <dolphy> BBB: why are you only focusing on seek [10:51] <BBB> no, wait... you're not getting one thing [10:51] <BBB> the reason that I rewrote avidemux is simply because the **whole** file was completely messed up with event handling [10:51] <sxpert_work> dolphy: ok; I got it to play, but now it gets stuck... [10:51] <BBB> a simple bytestream read function worked like this: [10:51] <BBB> while (read < wanted) { [10:51] <BBB> read_here = bytestream_read(); [10:51] <BBB> if (read_here != wanted) { handle event } [10:51] <BBB> blabla; [10:51] <BBB> } [10:52] <sxpert_work> dolphy: current position goes straignt to a huge number (larger than the length of the piece) [10:52] <BBB> I moved all that up into rifflib... for the simple reason so that I could read data out of bytestream in one line rather than 50 [10:52] <BBB> I want *small* code [10:52] <BBB> because then, I can add new feature very fast [10:52] <dolphy> BBB: understood but riff lib is not doing that [10:52] <BBB> rifflib reads, avidemux uses rifflib to read easily [10:53] <BBB> and indeed, rifflib is not doing that... rifflib is very easy: read data... on the start of a chunk, we allow events to come in [10:53] <dolphy> BBB: look this [10:53] <BBB> everywhere else, we're doomed to lose sync, so we bail out with a read error [10:53] <dolphy> if (!(tag = gst_riff_peek_tag (riff, &avi->level_up))) [10:53] <dolphy> return FALSE; [10:53] <BBB> so event handling can only take place in the peek_header() function [10:53] <dolphy> riff_peek_tag can return FALSE because of an event [10:54] <BBB> yes [10:54] <BBB> I'm telling you [10:54] <BBB> event handing can take place in the function that reads the chunk header [10:54] <teuf> BBB: if I have comments about the PWG, should I send them to you, to the mailing list, tell them here ? [10:54] <BBB> so if you want to add flush handling, go ahead and implement it there [10:54] <BBB> teuf: in bugzilla please [10:54] <teuf> BBB: ok [10:54] <BBB> I think it was #125890 [10:54] Action: BBB forgot [10:54] <dolphy> BBB: it sucks... [10:54] <BBB> dolphy: no, it makes it simple [10:55] <BBB> ok, let's do it differently: tell me what event you need and I'll add it to rifflib, ok? [10:55] <dolphy> BBB: the peek_head function is just checking for EOS [10:55] <mathrick> teuf: http://bugzilla.gnome.org/show_bug.cgi?id=125890 [10:55] <BBB> eventhandling in rifflib is indeed very basic, but that's simply to allow rifflib to b simple [10:55] <dolphy> BBB: and for anything else makes a gst_element_error [10:55] <BBB> dolphy: yes, and you add other events there [10:55] <BBB> dolphy: *just add the event there* [10:55] <dolphy> BBB: and do what with the event ? [10:56] <BBB> flush? simply forward it [10:56] <dolphy> BBB: peek_head is supposed to return TRUE for avidemux not to fail [10:56] <BBB> or if you want you can change the gst_element_error() to gst_pad_event_default() [10:56] <BBB> that should work too, and fixes all your issues at once [10:56] <dolphy> nope that makes other issue [10:57] <BBB> if you want to know why I added gst_element_error() instead of gst_pad_event_default(), just ask [10:57] <dolphy> the best fix i found is in bytestream [10:57] <dolphy> it's the code making the gst_pad_pull which has to handle event [10:57] <BBB> ? [10:57] <BBB> no, no... events are for elements [10:57] <BBB> bytestream is an element helper [10:57] <BBB> not an element [10:58] <BBB> the code can interpret the event [10:58] <BBB> but it should still forward it to the element [10:58] <dolphy> it does [10:58] <dolphy> bytestream is simply filling a buffer list [10:58] <dolphy> when an event arrives on gst_pad_pull [10:58] <BBB> where's your patch? [10:58] <dolphy> it's in cvs [10:58] <BBB> do you have a cvsweb link? [10:58] <dolphy> yes [11:00] Nick change: Uraeus -> Ura_shop [11:00] <dolphy> http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gstreamer/libs/gst/bytestream/bytestream.c.diff?r1=1.33&r2=1.34 [11:01] <BBB> bytestream shouldn't do that [11:01] <BBB> rifflib should do that [11:01] <BBB> ... [11:01] <dolphy> well i tend to disagree on that [11:01] <BBB> it's really not the right way to do this [11:01] <BBB> a demuxer can have an internal queue [11:01] <BBB> it should clean that out on flush, too [11:01] <BBB> and you're assuming that it doesn't handle any other events [11:01] <dolphy> but it can [11:02] <BBB> which is untrue, too [11:02] <BBB> (imagine GST_EVENT_TAG) [11:02] <BBB> (id3tag handles that perfectly fine) [11:02] <dolphy> bytestream is only doing a gst_pad_event_default on the sink pad [11:03] <BBB> yes [11:03] <BBB> that's normal [11:03] <BBB> but still, the element isn't notified [11:04] <BBB> ohwell, we'll see how other elements respond [11:04] <BBB> if they fail working, I'd suggest to revert it [11:04] <BBB> else, well, whatever [11:04] <Ura_shop> BBB: have you fixed the gst-mixer issue that hadess brought up? you made an assumption that didn't work for usb soundcards [11:05] <BBB> Ura_shop: ? [11:05] <dolphy> the best would be to have a gst_pad_handle_event that woull call the pad->eventfunc [11:05] <dolphy> then elements just the gst_pad_set_event_func on the sinkpad to handle events [11:05] mathrick (~mathrick@Zietka-18.a-inter.net) left irc: Read error: 104 (Connection reset by peer) [11:05] <Ura_shop> BBB: don't remember the details, but you just choose the firt element to be volume or something like that [11:05] <dolphy> BBB: no? [11:05] mathrick (~mathrick@Zietka-18.a-inter.net) joined #gstreamer. [11:06] <Ura_shop> BBB: you and hadess discussed it like a month ago or something [11:06] <dolphy> s/just/just set [11:06] <BBB> dolphy: sink pads can't have event functions [11:06] <BBB> dolphy: sink pads handle events in their chain or loop function (pull) ;) [11:06] <BBB> dolphy: that was decide long ago and has a very good reason, believe me [11:06] <BBB> it's scheduler and stream related and cannot be solved differently [11:08] <dolphy> well [11:08] <dolphy> feel free to revert it then [11:08] <dolphy> but avidemux should let any event go downstream [11:08] <dolphy> not implemented ones [11:08] <BBB> I know... [11:08] <BBB> I just said a minute ago: [11:09] <BBB> <BBB> if you want to know why I added gst_element_error() instead of gst_pad_event_default(), just ask [11:09] <dolphy> then tell me :) [11:09] <BBB> to fixate the protocol and optimized avidemux for it ;) [11:09] <dolphy> i m curious to know why you broke seeking voluntarily :) [11:09] <thomasvs> http://www.freedesktop.org/~gstreamer/documentation/ [11:09] <thomasvs> 0.6.4 docs online as well [11:09] <BBB> it always worked in the past [11:09] <BBB> it only stopped working because you added the flush and thereby changed the protocol [11:10] <BBB> anyway, you're right, it is wrong to error out there [11:10] <BBB> it should always pad_event_default() [11:10] <walters> BBB: well, i've rebuilt core and plugins twice with the latest cvs, and i'm still getting this. you aren't? [11:10] <thomasvs> BBB: the flush is necessary, itw was removed as a hack [11:10] <BBB> I didn't do that for debugging stuff [11:10] <thomasvs> walters: whatchagettin ? [11:10] <walters> /build/gstreamer-0.7/bin/gst-register-0.7: relocation error: /build/gstreamer-0.7/lib/gstreamer-0.7/libgstintfloat.so: undefined symbol: gst_float2_2_int_get_type [11:10] <BBB> walters: no... gst-inspect floatint should trigger it? [11:10] <dolphy> ok so should i revert bytestream and remove the gst_error ? [11:10] <BBB> dolphy: yes [11:10] <dolphy> i m almost sure i tried that already [11:10] <dolphy> and it was failing badly [11:10] <walters> BBB: yeah [11:10] <thomasvs> BBB: I don't get it - why should rifflib error out on events ? [11:11] <dolphy> but i ll try again [11:11] <thomasvs> walters: is the symbol in that .so file ? [11:11] <BBB> dolphy: and feel free to kick me into not adding gst_element_error() everywhere, I'm just doing it because it's useful for debugging new elements [11:11] <BBB> thomasvs: dor debugging [11:11] <BBB> thomasvs: in real life, it isn't useful [11:11] <thomasvs> BBB: I mean - how should events be handled then for a rifflib using plugin ? [11:11] <BBB> plugins using rifflib don't need to handle events at all [11:11] <thomasvs> BBB: hang on [11:12] <thomasvs> BBB: rifflib gives an error on an event [11:12] <thomasvs> BBB: a plugin shouldn't care [11:12] <BBB> a [11:12] <thomasvs> BBB: so, any rifflib using plugin will error on an event ? [11:12] <BBB> no, you're not following [11:12] <thomasvs> I know :) [11:12] <BBB> I'm saying that I added the error for debugging purposes [11:12] <thomasvs> so explain it properly :) [11:12] <BBB> it should be a gst_pad_event_default() [11:12] <BBB> and then, plugins never have to care about events if they use rifflib [11:12] <BBB> and that makes sense, because that's how RIFF works [11:12] <thomasvs> you use an error for debugging ? how did you expect seeking to work for avi files then ? [11:13] <BBB> it worked when I tested it [11:13] <thomasvs> how could it have worked ? it didn't handle seeking at all ? [11:13] <thomasvs> I mean [11:13] <thomasvs> flush [11:13] <BBB> riff doesn't use complicated caches like MPEG, riff doesn't use complicated things such as metadata caches such as id3/mp3... riff is very simple and basic [11:13] <thomasvs> I know [11:13] <BBB> because filesrc never emitted flush [11:13] <thomasvs> but without the flush, it must have been slow to seek no ? [11:13] <thomasvs> with lag and all due to the queue [11:13] <BBB> and yes, it's an error on my side to have left that piece of code in [11:14] <thomasvs> ah, ok [11:14] <thomasvs> so, then we can now do the right fix ? [11:14] <thomasvs> with flush being sent so queues get flushed ? [11:14] <BBB> dolphy is doing that right now [11:14] <thomasvs> BBB: want to fix another avi-related bug ? [11:14] <thomasvs> BBB: every time I seek now, my mem usage goes up 6% [11:14] <BBB> revert the bytesteam hack, add that to rifflib instead (it belongs there) and make filesrc emit a flush just as he proposed [11:14] <thomasvs> so I can seek ten times before it gets killed by the scheduler :) [11:14] <BBB> that sounds interesting [11:15] <thomasvs> yes, very :) [11:15] <thomasvs> BBB: as for mpeg, after two seconds the mpeg stops playing correctly [11:15] <thomasvs> BBB: do you have the same issue ? [11:15] <BBB> no [11:15] <BBB> do you use libmpeg2-0.3.1? [11:15] <thomasvs> no, 0.3.2cvs [11:15] <BBB> bleh [11:15] <BBB> please update to 0.4.0 [11:15] <BBB> :) [11:16] <thomasvs> crap [11:16] <thomasvs> ok [11:16] <teuf> why does gst_pad_new_from_template takes a gchar *name argument, and the GST_STATIC_PAD_TEMPLATE also defines a name ? is that used for non static pads ? [11:17] <BBB> teuf: for request/sometimes pads, yes [11:18] <dolphy> BBB: but still i don't like the way bytestream works [11:18] <dolphy> BBB: :) [11:18] <dolphy> BBB: it should fill the buffer and generate a GList of encountered events along the way for exemple [11:18] <BBB> dolphy: neither do I, but I won't fix it before 0.10.0 [11:19] <thomasvs> BBB: what version of mpeg do you have ? [11:19] <dolphy> BBB: except for events that are blocking [11:19] <BBB> no, byestream should have a better way of handling events with the elemtn [11:19] <BBB> the current way is illogical [11:19] <dolphy> agreed [11:19] <BBB> bytestream and the element should have a way of 'talking to each other' for events [11:19] <dolphy> i m afraid many bytestream enabled elements are event broken then [11:19] <BBB> but anyway, 0.10.0 material [11:19] <BBB> matroskademux is... it used the same debugging hack [11:19] <BBB> other elements use bytestream in the way the old avidemux did [11:19] <teuf> BBB: btw, I'm reading the web version of the PWG, is it new enough ? [11:20] <BBB> 50 lines of code for nothing [11:20] <BBB> look at wavparse to have a good laugh [11:20] <BBB> teuf: yes [11:20] <dolphy> BBB: i did [11:21] <dolphy> BBB: and that was not funny [11:21] <dolphy> BBB: bit depressing is the right word [11:21] <BBB> depends on your sense of humour [11:21] <dolphy> :-D [11:21] <BBB> doy uo know see why I rewrote avidemux and made rifflib handle all events? [11:21] <BBB> s/know/now/ [11:21] <dolphy> well yeah [11:21] <BBB> :) [11:21] <dolphy> this thing is a nightmare [11:22] <BBB> yup [11:22] <dolphy> we can clearly see it was designed before events were really used :) [11:23] <BBB> :) [11:23] <BBB> we do need events in such a way... [11:23] <BBB> I really want to stel some pieces from ffmpeg here [11:23] <BBB> they have per-buffer byte/bit stuff [11:24] <BBB> I want that too [11:24] <sxpert_work> dolphy: filename: /media/music/Carl Cox/U60311 Compilation techno division Vol. 3 (Disc 2)/10 - Slam - Stepback (smith + selway mix).ogg [11:24] <sxpert_work> dolphy: and then position 3 1075425908040577000 [11:25] <dolphy> sxpert_work: lol :) [11:25] <dolphy> sxpert_work: please wait a little i m reverting some changs [11:25] <sxpert_work> ok [11:25] <dolphy> sxpert_work: check with an avi please [11:25] <sxpert_work> uh... [11:26] <sxpert_work> my thing can't do avis... it's hardwired filesrc | tremor | osssink [11:27] <dolphy> tremor ? [11:27] <sxpert_work> dolphy: yeah [11:27] <dolphy> not vorbisfile ? [11:27] <dolphy> or oggdemux ! vorbisdec ?? [11:27] <sxpert_work> no, the proc I run on has a super-slow FPU that I want to keep for the GPS part [11:29] <sxpert_work> don't tell me tremor hasn't been maintained in a buildable state since the end of december when I hacked it back to life ? [11:30] <thomasvs> sxpert_work: did you maintain it since then ? [11:30] <dolphy> thomasvs: lol [11:30] <sxpert_work> thomasvs: uh, no, have been busy at work. do I have to update it again ? [11:31] <sxpert_work> if so, I can... [11:31] <dolphy> sxpert_work: well dude if you brought it back to life :) [11:31] <dolphy> sxpert_work: keep it alive then :) [11:31] <sxpert_work> dolphy: ah, hehe [11:31] <dolphy> sxpert_work: otherwise you are a serial killer [11:31] <thomasvs> sxpert_work: I don't know, why do you expect someone else to maintain it if you're the only one using it ? [11:31] Action: sxpert_work goes into compare vorbis / tremor once again... [11:32] <sxpert_work> thomasvs: well, those on ipaqs need it too [11:33] sublett (~rv...@21...) joined #gstreamer. [11:33] <thomasvs> sxpert_work: yes, but you're the maintainer of tremor [11:33] <dolphy> sxpert_work: well you are probably one of the only tremor users here [11:33] <sxpert_work> ok :D [11:33] <dolphy> sxpert_work: so you better maintain it yourself :) [11:34] Action: sxpert_work puts on maintainer vest :D [11:34] <teuf> rah, I suck [11:34] <teuf> I'm spamming the PWG bug with useless comments :( [11:34] <dolphy> sxpert_work: if you plan to comit some stuff ini tremor use ChangeLog please ! [11:34] <thomasvs> teuf: ? [11:36] <teuf> thomasvs: I'm reading the updated PWG, and I was told to comment on #125890 if I had issues with it. And each time I comment about something, I realize it's dealt with a bit later in the guide :( [11:36] <thomasvs> teuf: well, you could grep for such things in the source [11:37] <dolphy> lol [11:37] Shoragan (~rid...@d0...) joined #gstreamer. [11:39] <sxpert_work> dolphy: I do use changelog... [11:39] sublett (~rv...@21...) left irc: "I like food, food is good!" [11:39] <dolphy> sxpert_work: good [11:41] <sxpert_work> dolphy: if you check at the end of december, you can see me hacking tremor... [11:41] Action: thomasvs prepares to build packages again for gst [11:41] <thomasvs> taaz: getting anywhere on the python bindings ? [11:42] <dolphy> thomasvs: will you do a release today ? [11:42] <BBB> teuf: doesn't matter [11:42] <BBB> teuf: just add comments [11:43] <BBB> if we fixed it already, it's simply a 'great minds think alike' [11:43] <BBB> if we didn't, we'll still fix it [11:43] <thomasvs> dolphy: not today, too many small niggles still need to be fixed [11:43] <thomasvs> but I hope to get started at least today, and finish this weekend/monday [11:50] <teuf> how does http://www.freedesktop.org/~gstreamer/data/doc/gstreamer/head/pwg/html/section-types-definitions.html relate with docs/random/mimetypes ? is one better than the other ? [11:52] <thomasvs> BBB: teuf has a good question - maybe stuff should be deleted from random/ as it gets moved to official docs [11:54] <thomasvs> heh [11:54] <thomasvs> jamboree is playing the whole morning [11:54] <thomasvs> but only parts of songs [11:54] <thomasvs> and the longer it plays, the shorter the parts it plays :) [11:54] <thomasvs> but it doesn't crash [11:54] Action: thomasvs wonders what clocking bugs are at the core of that [11:55] <BBB> thomasvs: yes, I noticed :p [11:56] <BBB> teuf: good Q... I tihnk docs/random/mimetypes should be removed or marked obsolete [11:56] <BBB> or at least give a pointer to the HTML thing [11:56] <BBB> the HTML thing is the official specs [11:57] <BBB> and in general, thomas has a good point [11:58] <BBB> we could remove 80% of docs/random ;) [11:59] <teuf> the PWG is pretty neat ;) [11:59] <thomasvs> BBB: yeah, we should just go over those files one by one [11:59] <thomasvs> teuf: it is - it's nice to see BBB pushing everyone for these changes :) [12:00] <BBB> I've got time right now ;) [12:00] <teuf> ok, let's add a last comment to the bug with a bunch of typos, and I should stop spamming ;) [12:01] <BBB> does anyone care if I re-do a putbits/getbits-in-GstBuffer implementation (but LGPL)? :) [12:01] <thomasvs> whoops [12:01] <thomasvs> BBB: yeah, I do, you should do something else [12:01] <BBB> teuf: good idea [12:01] <BBB> like? [12:01] <thomasvs> killing bonobo to fix my errors wasn't a good idea [12:01] <thomasvs> BBB: fix seeking and clocking for all formats [12:01] <thomasvs> argh, need to reboot, i messed up my gnome seriously :) [12:01] <thomasvs> biab [12:01] thomasvs (~th...@po...) left irc: "Client exiting" [12:01] <BBB> I'll stick to documentation for now [12:01] <BBB> reboot? [12:01] <BBB> oh my [12:02] <BBB> logout/login is enough, dude [12:02] Action: BBB messed up bonobo quite often [12:03] Company (~Company@pD9E3343F.dip.t-dialin.net) left irc: Remote closed the connection [12:04] jdahlin (~da...@10...) joined #gstreamer. [12:04] thomasvs (~th...@po...) joined #gstreamer. [12:07] <thomasvs> (jamboree:32501): GStreamer-WARNING **: inconsistent state information, fix threading please [12:09] <teuf> before using GstBytestream, gst_library_load ("gstbytestream") must be called, right ? [12:10] <BBB> yes [12:10] <teuf> it doesn't seem to be mentioned in the PWG, I'll add a comment about that after linch [12:10] <BBB> actually... I think you call gst_library_load ("bytestream"); [12:11] <BBB> oh no gstbytestream [12:11] <BBB> nevermind me [12:12] <thomasvs> BBB: ok, so [12:12] <thomasvs> I upgraded to 0.4.0 [12:12] <thomasvs> rebuilt [12:12] <thomasvs> still after 2 secs in the player it stops [12:12] <thomasvs> gst-launch-ext plays it fine [12:13] <thomasvs> and ds was seeing the same thing afaict [12:13] <thomasvs> BBB: so could you please try playing alien in gst-player ? [12:14] sublett (~rv...@21...) joined #gstreamer. [12:15] Action: sxpert_work found a potential bug in vorbis [12:15] <BBB> thomasvs: the player is doing all sort of evil weird things with replugging etc... the bug is probably there... you need to bug dolphy with it [12:15] <thomasvs> BBB: this is not a replugging bug [12:15] <BBB> if gst-launch with spider plays it, that's good enough for me [12:15] <thomasvs> BBB: it plays the first two seconds fine [12:15] <sxpert_work> in vorbisfile.c -> gst_vorbisfile_read , variable got_bytes is not initialized [12:16] <BBB> does it play with gst-launch & spider? [12:16] <thomasvs> sxpert_work: vorbisfile is being deprecated as we speek [12:16] <thomasvs> BBB: what would be the line for both audio and video there ? [12:16] <sxpert_work> thomasvs: ah... [12:16] <BBB> thomasvs: gst-launch filesrc location=alien.mpg ! spider name=s... [truncated message content] |