IRC Logs

*******************************************************************
[03:04] kmaraas_ ([email protected]) joined #gstreamer.
[03:17] Action: walters scratches his head
[03:17] <walters>  walters@nexus> gconftool-2 -g /system/gstreamer-0.7/default/audiosink
[03:17] <walters> esdsink
[03:18] <walters> yet, when running rb: GConf audio sink not found, using osssink
[03:20] kmaraas ([email protected]) left irc: Read error: 110 (Connection timed out)
[03:24] bitshifter ([email protected]) left irc: Remote closed the connection
[03:27] bitshifter ([email protected]) joined #gstreamer.
[03:36] kmaraas_ ([email protected]) left irc: Client Quit
[03:36] ChrisHJW_log ([email protected]) joined #gstreamer.
[03:54] Nick change: camh|away -> camh
[04:00] Marsupilami23 ([email protected]) joined #gstreamer.
[04:03] kmaraas ([email protected]) joined #gstreamer.
[05:48] steveb_ ([email protected]) joined #gstreamer.
[05:50] <ds-work> MOO!
[05:50] Action: ds-work has resolved 13 bugs in the last few hours
[05:51] Action: wheels just resolved on as "report this in GStreamer's bugtracking system"  :-)
[05:52] <wheels> s/on/one/
[05:57] Rotty ([email protected]) joined #gstreamer.
[06:06] steve_b ([email protected]) left irc: Read error: 110 (Connection timed out)
[06:09] jcsston` ([email protected]) joined #gstreamer.
[06:12] Rotty ([email protected]) left irc: "Bye"
[06:33] jcsston ([email protected]) left irc: Read error: 110 (Connection timed out)
[07:06] NFusi0n ([email protected]) joined #gstreamer.
[07:27] chovy ([email protected]) joined #gstreamer.
[07:31] markey ([email protected]) joined #gstreamer.
[07:34] harshy ([email protected]) left irc: "I quit for now"
[07:49] Nick change: jcsston` -> jcsston
[08:02] thaytan ([email protected]) left irc: Read error: 54 (Connection reset by peer)
[08:04] chovy ([email protected]) left #gstreamer ("/join #politics on freenode! www.itsallpolitics.com  !").
[08:06] thaytan ([email protected]) joined #gstreamer.
[08:07] ChrisHJW ([email protected]) joined #gstreamer.
[08:13] sub_pop ([email protected]) left irc: "Client exiting"
[08:28] BBB ([email protected]) joined #gstreamer.
[08:37] walters ([email protected]) left irc: Client Quit
[09:04] mariano ([email protected]) left irc: "Leaving"
[09:11] BBB ([email protected]) left irc: "Client exiting"
[09:14] Uraeus ([email protected]) joined #gstreamer.
[09:19] <Uraeus> morning
[09:24] Nick change: mathrick|sleep -> mathrick
[09:24] <mathrick> mornin
[09:24] <Uraeus> hi mathrick
[09:25] <mathrick> yo Uraeus
[09:25] Action: Uraeus wonders if he should ask mathrick about libmms :)
[09:25] Action: mathrick think it'd be good for someone to kick him, I'm being too lazy
[09:27] Action: Uraeus kicks mathrick with an iron tip shoe
[09:28] <mathrick> Uraeus: it's a shame, but recently virtually no work has been done on libmms, the second half of our mighty team is extremely busy, so nothing comes from that side either
[09:28] <mathrick> Uraeus: thanks :)
[09:29] Nick change: khalek -> kh_out
[09:31] Action: mathrick points at http://www.gnu.org/software/emms/ as interesting thing and reason to make gst-elisp bindings :)
[10:05] somex1 ([email protected]) left #gstreamer.
[10:17] harshy ([email protected]) joined #gstreamer.
[10:23] Nick change: Uraeus -> Ura_gym
[10:32] jcsston ([email protected]) left irc: Read error: 110 (Connection timed out)
[11:10] teuf ([email protected]) joined #gstreamer.
[11:11] <teuf> hi
[11:11] <teuf> is there a gstreamer peercast plugin ?
[11:12] <thomasvs> peercast ?
[11:12] <thomasvs> "no", and "what's that" ?
[11:12] <teuf> http://www.peercast.org/
[11:13] <teuf> iradio using peer2peer
[11:16] <thaytan> yo thomas, christophe
[11:20] Company ([email protected]) joined #gstreamer.
[11:21] <thomasvs> mornmorn
[11:21] <Company> good morning angels
[11:26] alley_cat ([email protected]) joined #gstreamer.
[11:31] <teuf> thomasvs: actually gstreamer kind of support peercast, since you have to run a daemon which then create regular ogg/mp3 streams which you can access through and http://localhost:xxx/yyy url
[11:33] Nick change: mathrick -> mathrick|away
[11:34] <thomasvs> hm, I'm totally lost
[11:34] <thomasvs> (gdb) print ogg
[11:34] <thomasvs> $38 = (GstOggDemux *) 0x9a41aa0
[11:34] <thomasvs> (gdb) print pad
[11:34] <thomasvs> $39 = (GstPad *) 0x9a340cc
[11:34] <thomasvs> (gdb) next
[11:34] <thomasvs> 287       gboolean res = FALSE;
[11:34] <thomasvs> (gdb) next
[11:34] <thomasvs> 294       switch (type) {
[11:34] <thomasvs> (gdb) next
[11:34] <thomasvs> 292       cur = gst_ogg_get_pad_by_pad (ogg, pad);
[11:34] <thomasvs> (gdb) print ogg
[11:34] <thomasvs> $40 = (GstOggDemux *) 0x9a4c600
[11:34] <thomasvs> (gdb) print pad
[11:34] <thomasvs> $41 = (GstPad *) 0x9a340cc
[11:35] <thomasvs> can someone tell me, why, when stepping through this code, "ogg" would change value ?
[11:36] <teuf> something is trashing the stack ?
[11:36] <thomasvs> must be.  this is weird.
[11:37] <Company> valgrind it
[11:37] <thomasvs> the thing that looks like its thrashing the stack is gboolean res = FALSE
[11:37] <teuf> do you get the samae thing when you g_print the variable address ?
[11:37] <teuf> sometimes gdb is weird
[11:37] <thaytan> thomasvs: compiled it with optimisations?
[11:40] <thomasvs> thaytan: not that I know, no
[11:40] <thomasvs> I guess we should try and valgrind all our media testsuite pipelines sometime soon too :)
[11:42] Action: teuf should valgrind this leak when reading mp3 metadata
[11:56] Nick change: Ura_gym -> Uraeus
[11:56] <Uraeus> lot of guessing and thinking here, little action ;)
[11:56] <thaytan> Uraeus wants some action
[11:56] <thaytan> any offers?
[11:57] <Uraeus> thaytan: I am coming to .au this summer so I hope to meet you in person then 
[11:59] <thaytan> don't forget we're in Barcelona 21-23 April
[11:59] <thaytan> staying with thomas
[12:00] <thaytan> where are you going in .au?
[12:00] <Uraeus> thaytan: well I am thinking about a 1 month vacation so I was thinking about doing a small tour
[12:01] <thaytan> good stuff
[12:01] <thaytan> you'll definitely be in Sydney then :)
[12:01] <Uraeus> yes, probably do something like 2 weeks in sydney and 2 weeks traveling around
[12:03] <Uraeus> thaytan: just discussing the possibility of doing a talk in SLUG with jdub on the 30th of July
[12:03] <thaytan> I saw
[12:03] <Uraeus> ah, right you are in the channel too :)
[12:03] <thaytan> that'd be sensational
[12:04] bilboed_ ([email protected]) left irc: Read error: 60 (Operation timed out)
[12:05] mathrick|away ([email protected]) left irc: Remote closed the connection
[12:07] Nick change: markey -> markey|afk
[12:07] <thomasvs> ==30039== Invalid read of size 4
[12:07] <thomasvs> ==30039==    at 0x9A3FA9: gst_ogg_get_pad_by_pad (gstoggdemux.c:275)
[12:07] <thomasvs> ==30039==    by 0x9A3FFE: gst_ogg_demux_src_query (gstoggdemux.c:292)
[12:08] <thomasvs> does this mean it's reading an invalid pointer ?
[12:08] <Company> probably
[12:09] <Company> can you send me the file?
[12:09] <Company> or upload it somewhere?
[12:10] <thomasvs> well, it's when working in media-info
[12:10] <thomasvs> and it's on every file
[12:10] <thomasvs> so I'm not sure it's easily reproducable for you
[12:11] <thomasvs> the oggs are 100% fine however, so it might be me doing something wrong too
[12:11] <Company> any gst-launch pipeline?
[12:12] <thomasvs> well, does gst-launch do pad queries ? :)
[12:13] <Company> ah
[12:13] <thomasvs> hm, CURRENT_CHAIN looks like it has the potential to go wrong
[12:13] <Company> yes
[12:13] <Company> src_query should return false if you query too early
[12:14] Action: thomasvs adds some extra debugging to check
[12:14] sack ([email protected]) joined #gstreamer.
[12:15] <Company> it doesn't
[12:15] <Company> i'll fix it
[12:15] <thomasvs> ok, thanks
[12:15] <thomasvs> hi angel
[12:16] <thomasvs> ah, current chain is -1 :)
[12:16] <sack> Thomas :-)
[12:16] <thomasvs> probably not a good thing to have when using it to index a GArray
[12:16] kmaraas ([email protected]) left irc: Client Quit
[12:16] <thaytan> thomasvs: 'angel' is Company's catchphrase, do you have permission to use it? ;)
[12:17] <thaytan> thomasvs: I thought I mentioned that one to Company weeks ago and he fixed it
[12:17] <thaytan> but I guess not
[12:17] <Company> there's probably quite some errors wrt that
[12:17] <thomasvs> thaytan: heh :) I'd guess sack has first right
[12:17] <thomasvs> Company: want me to add an assert at least ?
[12:17] <thomasvs> Company: or should I leave it all to you ?
[12:18] <thomasvs> ah
[12:18] <sack> hehehe yes thomas ... well at least if someone wants called me by my name :-D
[12:18] Action: thomasvs now understand why valgrind says something like four bytes before block of 16 allocated
[12:18] <Company> thomasvs: update cvs hen i say "now"
[12:18] <sack> thomasvs, mem align ?
[12:18] <Company> now
[12:18] <thomasvs> since it's using -1 as the index array, it derefs something 4 bytes before
[12:18] <thomasvs> Company: :)
[12:19] <Company> haven'T checked it but should work
[12:20] <thomasvs> Company: ok, it runs now, but it doesn't do the query
[12:20] <thomasvs> Company: ie, no length
[12:21] <Company> thomasvs: yeah, you should wait until you got the first data on the fakesink or wherever
[12:21] <Company> oggdemux needs to parse the file to figure out how long it is
[12:22] <Company> s/it is/the chains are/
[12:23] Action: thomasvs checks again where the querying is happening
[12:24] <thomasvs> hm, it happens after quite some iterations already
[12:25] LeRoutier ([email protected]) joined #gstreamer.
[12:25] <LeRoutier> hello
[12:25] <Company> "quite some" might not be enough
[12:25] <Company> because oggdemux parses the whole file first :)
[12:25] <Uraeus> hello LeRoutier
[12:25] <thomasvs> hm, hang on
[12:25] <thomasvs> ok
[12:26] <thomasvs> it only tries to get length for format bytes
[12:26] <thomasvs> hm, should elements proxy query formats they don't change ?
[12:26] <LeRoutier> thomasvs, sorry, my answer on #131270 is a bit late (configure.ac conversions to pkg-config)
[12:26] <Company> yes, _if_ they don'T change them
[12:26] <thomasvs> Company: does vorbisdec do that ?
[12:27] <rvalles> let's hope the xiph guys release a stable liboggfile API soon enough
[12:27] <rvalles> x)
[12:27] <Company> vorbisdec changes bytes/default/time to a format suitable for oggdemux
[12:27] <Company> we're not gonna use liboggfile
[12:27] <Company> (i think, i haven't looked at it)
[12:28] sublett ([email protected]) joined #gstreamer.
[12:33] iain ([email protected]) joined #gstreamer.
[12:33] <Uraeus> yo iain
[12:33] <Company> iain!!!
[12:34] <iain> ME!!!
[12:34] <iain> hi
[12:34] <teuf> hi iain
[12:34] <iain> Company: I saw your bug...I'll see if I can hook my Extigy up again, but I'm not sure if I even compiled the drivers into the kernel...
[12:34] Action: iain wonders why he's so popular all of a sudden
[12:35] <Uraeus> iain: because you are the author of our favourite sound editor
[12:35] <iain> aww, thanks
[12:35] <iain> favourite sound editor which doesn't really work correctly at the moment
[12:36] <Uraeus> true, it fails to compile for me
[12:36] <Company> iain: hurry up, i want that fixed before 0.8.0 ;)
[12:36] <iain> Uraeus: what compilation errors do you get?
[12:36] <Uraeus> iain: somthing about not finding media-info.h I think
[12:37] <Uraeus> iain: I try again now to get correct error message for you
[12:37] <iain> #include <gst/media-info/media-info.h>
[12:38] <iain> hmmm, that should be installed whenever gst-plugins is installed
[12:39] <thomasvs> Uraeus: because it's not packaged in the rpm, because it's not stable yet and doesn't work
[12:39] <thomasvs> which is what I'm trying to fix right now
[12:40] <thomasvs> Uraeus: howsabout testing my nifty parallelinstallable gst rpms ?
[12:40] <iain> hmm, the return path on the spam I'm getting now is...Return-Path: <[email protected]>
[12:42] NFusi0n ([email protected]) left irc: "leaving"
[12:42] <LeRoutier>  
[12:42] <Company> yeah, i get mail from all of you, too
[12:42] <Company> s/mail/spam/
[12:42] <Uraeus> thomasvs: mail me the URL and I do it as soon as I get back, now I am going to the shop to buy some stuff needed before my appartment is taken pictures of for the sales description
[12:43] <LeRoutier> could someone who has speex 1.0.x try this gst-plugin patch and tell me if it finds/compiles it : http://bugzilla.gnome.org/showattachment.cgi?attach_id=25255
[12:44] Nick change: Uraeus -> Ura_shop
[12:45] <bitshifter> ?
[12:46] <bitshifter> sorry, wrong window
[12:47] Nick change: LeRoutier -> LeRaway
[12:48] <thomasvs> Company: ah, in my case I added an audioconvert element
[12:48] <thomasvs> Company: so audioconvert should handle src/sink queries then for length for example ?
[12:54] <Company> thomasvs: audioconvert should just pass them on i think
[12:55] <Company> thomasvs: no, it should handle the bytes query and adjust it, which it probably doesn't do...
[12:55] kmaraas ([email protected]) joined #gstreamer.
[12:55] <thomasvs> Company: right now it only handles bytes afacit
[12:56] <Company> thomasvs: it doesn't do anything which mewans it does the default: pass it on
[12:57] <thomasvs> yeah
[12:57] Action: thomasvs is confused now
[12:57] <thomasvs> ok, in a pipeline oggdemux ! vorbisdec ! audioconvert ...
[12:58] <thomasvs> querying on audioconvert src only seems to support bytes
[12:58] <thomasvs> same for vorbisdec
[12:58] <Company> nope
[12:58] <thomasvs> though vorbisdec seems to just pass on by default
[12:58] Action: thomasvs checks the masks
[12:58] <Company> vorbisdec supports time and default
[12:58] <thomasvs> yeah, I notice that in the code
[12:58] <thomasvs> so I'm wondering where it's going wrong here
[13:00] <thomasvs> Company: shouldn't vorbisdec have a get_query_types func ?
[13:02] <Company> it probably should
[13:03] <Company> does anybody care about query_types functions these days? ;)
[13:06] <thomasvs> of course
[13:06] <thomasvs> how else should I get the length of a file ?
[13:06] <thomasvs> plus, the query functions were a really good design imo, if they're supported correctly
[13:08] pb_ (~pb@2002:5160:45ef:0:240:95ff:fe30:aa84) joined #gstreamer.
[13:08] <Company> query_types
[13:08] <Company> not query functions
[13:08] <Company> and you'll never get the length of the file by asking the audiosink the length in bytes
[13:09] <thomasvs> well, how does vorbisdec now expose the formats it supports for querying ?
[13:09] psyduck ([email protected]) joined #gstreamer.
[13:09] <thomasvs> Company: I'm already getting the lengh in bytes, I'm trying to do a time query on vorbisdec's src pad to get the length in seconds
[13:09] <Company> it most probably doesn't right now
[13:09] <thomasvs> Company: afaict, I see vorbisdec only doing GST_FORMAT_DEFAULT queries, no ?
[13:09] <Company> dunno
[13:09] <Company> i never cared about query_types
[13:10] <Company> just query and look at the result
[13:11] Action: thomasvs tries to understand the src_query function in vorbisdec
[13:11] <Company> to understand it you have to know that oggdemux only supports one query: _DEFAULT
[13:11] <iain> thomasvs: so will the media-info stuff be in 0.8?
[13:12] <Company> and that query returns the last granulepos of the queried chain
[13:12] <thomasvs> iain: if I get it fixed this weekend, yeah
[13:14] <teuf> what does media info do exactly ? it returns length, duratio and stuff about a stream ?
[13:14] <thomasvs> teuf: yeah, and metadata, and number of tracks, and so on
[13:14] <teuf> how do you get length for mp3s ?
[13:14] <thomasvs> teuf: and, when I have some time to not update to new api and elements, caching
[13:15] <thomasvs> teuf: it's generic - ie, query the decoder for QUERY_TOTAL using FORMAT_TIME
[13:15] <teuf> through querying or using metadata ?
[13:15] <thomasvs> teuf: it's up to gst and the elements to provide it correctly
[13:15] <thomasvs> teuf: metadata querying of time is imo a broken design
[13:15] <iain> thomasvs: let me know if you do, because I always assumed it was, which was why I had marlin depend on it
[13:15] Action: bitshifter wonders how well the length query works for mp3s with VBR
[13:15] <iain> IMO if its in CVS it should be in all our releases as well
[13:16] <teuf> thomasvs: hey, company more or less told me to do the opposite
[13:16] <thomasvs> bitshifter,teuf: in theory it's entirely possible to query for lengths of vbr mp3's
[13:16] <thomasvs> bitshifter,teuf: in practice, it probably involves seeking through the whole file jumping header by header
[13:16] <teuf> thomasvs: length of vbr mp3s is properly reported, but through GST_TAG_DURATION
[13:16] <bitshifter> nice :)
[13:16] <thomasvs> teuf: hm, that's the wrong way to report it imo
[13:16] <Company> only if the tags support that
[13:16] <thomasvs> teuf: it should at least expose it to the query interface
[13:17] <Company> well
[13:17] <Company> the tag might be wrong
[13:17] <Company> the query interface doesn't know if the tag reported in the metadata is correct
[13:17] <teuf> Company: for vbr, file length/bitrate will be wrong
[13:17] <bitshifter> so ... once you get a handoff signal from the sink, the duration of an VBR mp3 will be correct if using the query interface?
[13:17] <teuf> the tag only *might* be wrong
[13:18] psyduck_ ([email protected]) joined #gstreamer.
[13:18] <Company> teuf: yeah, but for cbr it's different again
[13:18] <Company> teuf: that's why there's two ways to query ;)
[13:18] psyduck_ ([email protected]) left #gstreamer ("Leaving").
[13:18] <teuf> Company: query could return tag info if vbr, and file length/bitrate for cbr
[13:19] <Company> teuf: that's messy
[13:19] <thomasvs> teuf: I lost you.  do you report the length by giving the value of a metadata tag in the file, or do you actually calculate the length ?
[13:19] <Company> teuf: because in that case you dunno what you get
[13:19] Action: thomasvs sees vorbisdec not have a debug category and adds it
[13:20] <teuf> thomasvs: it's some kind of metadata actually, encoder generally put a special "xing header" frame, which contains info about the duration and the encoding process
[13:20] <Company> yeah, vorbisdec was so simple i didn't need one ;)
[13:20] <teuf> then you also have the TLEN id3 tag
[13:20] <bitshifter> what about giving 'mad' and other decoders properties for minimum-bitrate, nominal-bitrate etc. that can be queried?
[13:22] <thomasvs> teuf: so what happens if I change that value in the file ?
[13:22] <thomasvs> teuf: it shouldn't use that value to report the length through querying.
[13:23] <thomasvs> teuf: the length through querying should be the actual length of the stream, not some tag that can be changed
[13:23] <teuf> thomasvs: for the TLEN tag, it's easy to do and would screw things up. Someone changing the xing header tag would be a bit like someone hexediting a vorbis stream on purpose to make gstreamer report a wrong length imo
[13:24] <thomasvs> teuf: sure, but why not do it right the way ?
[13:24] <Company> editing the TLEN tag is the same as editing the xing header :o
[13:24] <thomasvs> teuf: consider you make a copy of the mp3, but only half of it
[13:24] <thomasvs> teuf: the file is still playable, but reports the wrong length
[13:24] <thomasvs> teuf: why not try reporting the right value instead of relying on the possibly wrong one to be right ?
[13:24] Nick change: markey|afk -> markey
[13:25] <teuf> "consider you do your best to screw things up"
[13:25] <teuf> thomasvs: this is the best value you can get for a vbr file if you don't iterate through it 
[13:25] <Company> the only correct way to do it is this:
[13:25] <Company> do 2 mp3 formats
[13:25] <Company> make mad only support the second
[13:25] <Company> typefind the first
[13:26] <Company> use mp3parse to actually parese the file
[13:26] <Company> parse
[13:26] <Company> use that length
[13:26] <teuf> "consider someone edit the mp3 frames and put wrong bitrate info in them"
[13:27] <thomasvs> teuf: broken downloads happen more often than you think
[13:27] <thomasvs> teuf: how many people have an avi without a header because the download was aborted ?
[13:27] <Company> no one
[13:27] <thomasvs> anyways, there are vbr mp3 without xing headers
[13:27] <Company> they only have avis without index ;)
[13:27] <thomasvs> well, yeah :) typo
[13:28] <bitshifter> Company: no, there are p2p apps that do not download files in consecutive order (e.g. overnet, edonkey, emule etc)
[13:28] <teuf> thomasvs: yeah, sure, but I don't really want to iterate throught the whole mp3 before knowing its length
[13:28] <bitshifter> s/files/bytes/
[13:28] <Company> bitshifter: if you don't have the header, you can't detect it's an AVI :p
[13:28] <bitshifter> Company: that's very true
[13:28] <teuf> thomasvs: anyway, as long as the xing/TLEN info is available one way or the other, I don't care at all :)
[13:28] <Company> you always have the header
[13:29] Action: Company found a bug in one of our headers
[13:29] <Company> (yay!)
[13:31] <thomasvs> teuf: which is why media-info should cache the result, so in cases where it's expensive to do so it only needs to do so once
[13:52] Nick change: markey -> markov
[13:53] Nick change: markov -> markey
[13:54] <teuf> what does "nominal" bitrate corresponds to ? it's something you specify at compression time which corresponds to the average bitrate you'd like to have in the resulting file ?
[13:56] foser ([email protected]) joined #gstreamer.
[14:02] kmaraas ([email protected]) left irc: "Leaving"
[14:04] <Company> teuf: yep
[14:10] wingo ([email protected]) joined #gstreamer.
[14:12] <Company> wingo!!!
[14:12] Action: Company makes wingo fix the segfault in opt
[14:12] <wingo> hi Company
[14:13] <wingo> there's a seggie there?
[14:13] <wingo> did I cause it?
[14:13] <Company> wingo: yeah, i reverted your opt commit because of it
[14:13] <wingo> 0.8.0 on monday?
[14:13] <Company> wingo: see mailing list
[14:13] <wingo> you mean last week?
[14:13] <Company> yeah
[14:13] <wingo> ah yes, yesterday I didn't commit
[14:13] <wingo> yeah I saw that last week
[14:14] <wingo> but now I hve some time :)
[14:14] <wingo> I guess it was the responsible thing to do, though -- sorry I'm not around more
[14:14] <Company> np
[14:14] <wingo> so yeah, I came around to see if I could look at that.
[14:14] <Company> but your fixes were good otherwise so i want em back :)
[14:14] <wingo> ok :)
[14:14] <wingo> btw, what was wrong with the patches to gstpad.c?
[14:15] <Company> wingo: _can_link_filtered was noisy, because it triggered _return_if_failed
[14:16] <Company> wingo: and _can_link_filtered (sinkpad, sinkpad) should just return FALSE where link_filtered should trigger return_if_fail
[14:17] <Company> wingo: btw: i just made audioconvert not do buffer-frames conversions anymore
[14:18] <Company> that should be done by a seperate element
[14:20] <Company> audioconvert should just do one buffer in, one buffer out
[14:20] <Company> it gets too complex if it does more
[14:20] <wingo> hm, ok. but I'm not sure what the legal arguments are to can_link_filtered are; like can you pass pads without parents? I'd say no...
[14:21] <wingo> anyway, that's ok. but i like mails to the list regarding reverts (I'm ok with the way the second revert worked)
[14:21] <Company> i'd say yes
[14:21] <Company> yeah, sorry
[14:21] <wingo> but if you can fix it, that's better than reverting ;)
[14:22] <iain> yey wingo
[14:22] <wingo> Company: wrt can_link_filtered, we need to specify that
[14:22] <wingo> hi iain
[14:22] <wingo> Company: did you make a buffer-frames-convert element? I didn't think it was that complex ;)
[14:22] <iain> wingo: would you know anything about why audioconvert always outputs mono even with stereo input?
[14:23] <Company> iain: fixate function madness
[14:23] <Company> wingo: not yet
[14:23] <iain> Company: ohhh you know now :)
[14:23] Nick change: Ura_shop -> Uraeus
[14:23] <Uraeus> iain: fixed Marlin compilation now?
[14:24] <iain> Uraeus: try it and see :)
[14:24] <iain> Uraeus: I fixed it so that marlin-file-selection.c wasn't built anymore, cos its not actually needed
[14:24] <iain> Uraeus: but unless you install the media-info stuff it won't build anyway
[14:24] <wingo> hopefully I'll have a more stable internet connection at the beginning of next month
[14:25] <Uraeus> thomasvs: are you fixing media-info today? and will media-info.h be installed due to those fixes?
[14:25] <iain> I might have to include media-info in marlin if thomasvs can't get it working right
[14:25] <Uraeus> wingo: how long before you leave Africa?
[14:25] <wingo> Uraeus: December, I think
[14:26] <Uraeus> wingo: would it be ok if I came for a visit in late july/august?
[14:26] <wingo> Uraeus: that would be fabulous :)
[14:27] <Company> wingo: the thing why audioconvert shouldn't do buffer-frames is not that it's too much now, but that it might become too much later on
[14:27] <Uraeus> wingo: ok, I try and make that a part of my travel plans/budget then :)
[14:27] <Company> wingo: and apart from that we want to seperate functionality into seperate elements anyway
[14:27] <wingo> I am working then, but if you let me know in advance I can see about taking off
[14:27] <Uraeus> wingo: I will
[14:28] <Company> hm, is there a way to force unblocking a device?
[14:28] dolphy ([email protected]) joined #gstreamer.
[14:28] <Company> i can'T access /dev/dsp because the app using it crashed
[14:28] <bitshifter> minor thing: someone might want to update the REQUIREMENT file and change the required glib version to '2.2.x' or something
[14:28] <wingo> Company: sounds ok. btw. some of the loops do dispatches-on-type for each sample -- probably should remove that at some point (in audioconvert)
[14:28] smoke ([email protected]) joined #gstreamer.
[14:29] <Uraeus> bitshifter: I try looking into that, the REQ file is getting rather outdated in lots of ways I think
[14:29] <dolphy> yo
[14:29] <Uraeus> hey dolphy
[14:29] <wingo> hey dolphy
[14:29] <Company> wingo: my idea was to have one slow, but easily understandable do_any_conversion function and later on add specific optimisations
[14:30] <wingo> right, but one should dispatch on type before the loops ;) anyway, it's just optimization.
[14:30] <iain> does anyone have the first sigur ros album that they could let me download by as flac or shn?
[14:31] <teuf> iain: I think you can send a mail at [email protected] with your full name and postal address, and they'll send you a copy ;)
[14:32] <iain> teuf: ah, excellent
[14:32] <iain> teuf: if its any excuse, its to replace my copy that is really really badly scratched
[14:33] <iain> although, I can burn oggs to a CD and have them gapless can't I?
[14:34] <teuf> I think it should work with oggs
[14:35] lupusBE ([email protected]) joined #gstreamer.
[14:36] <rvalles> iain: yeah... but audiocds are a waste of storage :)
[14:36] <rvalles> iain: search for "ape"
[14:36] <rvalles> iain: it's the most popular propietary lossless format nowadays
[14:36] <rvalles> iain: the one it's easier to find in p2p networks.
[14:37] <rvalles> iain: I usually get APEs, then convert them to FLAC.
[14:37] <iain> rvalles: I like cds better than oggs
[14:38] aldug ([email protected]) left irc: Client Quit
[14:38] <wingo> are GST_CAT_ERROR and GST_CAT_WARNING actually useful, now that we have proper error reporting?
[14:39] <rvalles> iain: I prefer FLAC oggs :)
[14:40] <rvalles> iain: you can fit more music in the same space, with exactly the same quality, and added decent error correction (you don't need cdparanoia to copy a FLAC from a DVD to your HD x)
[14:40] <iain> rvalles: I don't see any point in ripping CDs that I own
[14:40] <Company> wingo: sometimes an element can recover from an error itself
[14:40] <rvalles> iain: wait till they're scrached, then :)
[14:40] <rvalles> iain: oh, you already had THAT problem
[14:40] <iain> rvalles: then I'll find someone else with a copy and fix it
[14:41] <iain> rvalles: otherwise, ripping 500+ cds is going to take a very long time
[14:41] <iain> rvalles: and a lot of space
[14:41] <rvalles> iain: also, there's the instant access thingy. You can have your entire colection in a few DVDs or in some big HD :)
[14:41] Nick change: LeRaway -> LeRoutier
[14:41] <rvalles> 500+? 
[14:41] <rvalles> argh
[14:41] <iain> rvalles: seeing as I already have the physical CD and case taking up space, I miss the point
[14:41] <rvalles> iain: instant access?
[14:42] <teuf> iain: having your music collection on your computer is pretty nice because you can easily listen to whatever you want :)
[14:42] <rvalles> iain: you type your regexp, and that's it.
[14:42] Action: iain doesn't really give a shit about instant access
[14:42] <rvalles> iain: no need to search in the cdshelf
[14:42] <teuf> iain: using random on your whole music collection can also be fun :)
[14:43] <wingo> Company: It just seems that GST_ERROR and GST_WARNING serve the purpose of g_error and g_warning. What's the difference?
[14:43] <iain> teuf: often falls apart because a lot of my stuff is gapless, and so if you treat as individual songs rather than as collections it sounds wrong
[14:44] <iain> teuf: but I see your point for pop albums
[14:44] <teuf> iain: yep... I also prefer listening to whole albums, but when I'm uninspired about what to listen, random mode is fun :)
[14:44] <Company> wingo: not at all - they're all just debugging categories :)
[14:45] <Company> wingo: see the docs
[14:45] Action: wingo makes note to look through the code again, maybe mailing list.
[14:45] <Company> wingo: apart from that some parts of the code cannot use GST_ELEMENT_ERROR (schedulers for example)
[14:46] <iain> rhythmbox's random mode kinda sucks actually...
[14:46] <iain> it always seems to pick the same tracks every day
[14:50] <iain> Company: any good examples of how to write a fixate function?
[14:50] <teuf> iain: someone improved that in 0.7
[14:51] <teuf> you can choose between 3 or 4 different random modes 
[14:51] <rvalles> iain: I don't like rhythmbox...
[14:51] <rvalles> iain: xmms owns it. If only if someone did a xmms-style gstreamer player
[14:51] <Company> iain: osssink for example
[14:51] <Company> iain: (it's actually dead easy)
[14:52] Nick change: markey -> markey|afk
[14:52] <teuf> is GST_TAG_BITRATE reported in bps or in kbps ?
[14:52] <Company> i won't do a winamp clone
[14:52] <wingo> ds: there?
[14:52] <Company> teuf: bps
[14:52] <rvalles> Company: winamp3 sux
[14:52] <rvalles> Company: xmms is better than any winamp.
[14:52] <rvalles> Company: the interface... it's just it
[14:52] <teuf> rvalles: did you try muine ?
[14:52] <rvalles> Company: the way things should be done
[14:53] <rvalles> Company: and one touches j and does direct freetext incremental search...
[14:53] <rvalles> teuf: no
[14:53] <teuf> rvalles: adding type ahead find to rb would be nice imo
[14:53] Action: rvalles takes a look
[14:54] <rvalles> teuf: does muine use gstreamer?
[14:54] <Company> why would i push "j" for a search?
[14:54] <teuf> rvalles: yep
[14:54] <teuf> 0.6 though
[14:55] Action: wingo would like to declare a crusade against malloc in chain, loop, and get functions
[14:55] <rvalles> teuf: their website say nothing about it
[14:55] <rvalles> teuf: how lame.
[14:55] <teuf> about what ? about the fact it uses gstreamer ?
[14:55] <teuf> the website is pretty new I think
[14:55] <rvalles> teuf: It's interesting for people to know it
[14:56] <Company> wingo: gogogo ;p
[14:56] <rvalles> teuf: "based on gstreamer backend"
[14:57] <LeRoutier> who's the autotools master for gstreamer those days ?
[14:57] <dolphy> k hollidays time
[14:57] <dolphy> see you guys in a week
[14:58] <LeRoutier> bonnes vacances dolphy
[14:58] <dolphy> thx
[14:58] <dolphy> thomasvs: good luck for your bug fixing week end :)
[14:59] <dolphy> thomasvs: you can call me if you need to talk..
[14:59] <Company> LeRoutier: thomasvs is the build boss
[14:59] dolphy ([email protected]) left irc: "Network down, IP Packets delivered via UPS"
[14:59] <LeRoutier> k, thx Company
[14:59] <LeRoutier> thomasvs, my pkg-config-ification patch for gst-plugins is ready : see third patch on http://bugzilla.gnome.org/show_bug.cgi?id=131270
[15:00] <Company> we all speak m4 though
[15:00] <wingo> Company: are you familiar with alloca?
[15:00] <LeRoutier> yep, but why using bunches of m4 when a single PKG_CHECK_MODULES would do the job ...
[15:01] <rvalles> 14:55:45 <   Company> why would i push "j" for a search?
[15:01] <Company> wingo: not really
[15:01] <rvalles> argh, you sound like a HIG purist
[15:01] <Company> well, i never knew i could push j
[15:01] <rvalles> Company: then, read the manual
[15:02] <rvalles> I'm a power user and I don't fsking care about usability
[15:02] <Company> yeah
[15:02] <Company> and i don't fsking care about xmms and clones :p
[15:02] <rvalles> I do care about performance of UIs once learned
[15:02] <rvalles> it's all what matters for me.
[15:03] <rvalles> (J)ump rocks
[15:03] <rvalles> a few neat keyboard tricks, and I'm playing the song I want to... without having to touch the mouse (and without using a terminal, whohoo)
[15:04] <teuf> I generally don't really know what I want to play, so... :)
[15:04] <rvalles> xmms's got shuffle (tm) x)
[15:04] Action: rvalles truly likes xmms
[15:05] <rvalles> if only if they ported it to gtk2 and gstreamer... yikes.
[15:05] <Company> i'll use rb for now ;)
[15:05] <Company> yeah great
[15:05] <Company> jade doesn't compile with gcc-3.3
[15:05] <rvalles> Company: good for you (HIG zealot!)
[15:05] <Company> so no docs for me
[15:05] <rvalles> x)
[15:06] <teuf> rvalles: for my part, I find it much easier to find something I want to listen to using a library browser than a flat list
[15:06] <Company> i have a hard enough time learning all those APIs, I don't need to learn UIs ;p
[15:08] <rvalles> teuf: I prefer to search (tm)
[15:08] <rvalles> later x)
[15:08] Action: rvalles goes seek for some food.
[15:10] kwm ([email protected]) joined #gstreamer.
[15:10] <bitshifter> rvalles: beep media player (bmp) is a xmms port to gtk2 (and they are planning to use gstreamer in the future as far as I know)
[15:10] <bitshifter> rvalles: http://beepmp.sf.net
[15:12] Action: rvalles visits that website
[15:12] <rvalles> let's see.
[15:13] <bitshifter> rvalles: do get it via CVS though, the 0.9.6.1 release is ancient and fairly unstable
[15:13] <rvalles> bitshifter: you use it? :)
[15:14] <rvalles> bitshifter: what's your opinion in it, then? :) :)
[15:15] <bitshifter> rvalles: yeah, I use it. It's basically xmms with nice pango font rendering (and once you've seen the playlist, you'll never go back to xmms)
[15:15] <bitshifter> rvalles: xmms skins can be used with it as well, and most xmms plugins are easily ported to gtk2
[15:16] <bitshifter> it's quite okay if you like skinnable players
[15:16] <Company> bah
[15:16] <rvalles> "and they are planning to use gstreamer in the future as far as I know" -> where did you hear that?
[15:16] <Company> i'm not gonna install docbook 3.1 now
[15:17] <Company> it can'T be that gst requires docbook 3.1, 4.1, 4.1.2 and 4.2 to build docs
[15:17] <Company> ... and required tools
[15:17] <bitshifter> rvalles: on IRC, and it's also in the roadmap in the TODO file
[15:18] <bitshifter> lol
[15:18] <bitshifter> argh
[15:18] Action: bitshifter pledges to learn how window focusing works
[15:19] Nick change: markey|afk -> markey
[15:20] <rvalles> bitshifter: ok
[15:20] <rvalles> bitshifter: I'm checkouting CVS now
[15:20] <rvalles> U bmp/beep/defskin/Nums_ex.bmp
[15:20] <rvalles> eek
[15:20] <rvalles> bmps
[15:20] <rvalles> I assume is for xmms skin compat...
[15:20] <rvalles> but it's time to support png, damn x)
[15:21] <Company> fix it :p
[15:21] <Company> (it probably uses gtk image loaders, so it should do pngs)
[15:21] <bitshifter> yeah, dunno why they didn't convert it to png
[15:24] <Company> LeRoutier: i somehow get the feeling a GST_CHECK_PKG_CONFIG macro would be useful ;)
[15:24] <Company> or GST_CHECK_FEATURE_PKG_CONFIG
[15:26] <LeRoutier> Company, could be. i'm not a build master at all. this patch is just to clean some configure.ac/m4 code out
[15:26] <LeRoutier>  
[15:27] <LeRoutier> who's working on gst-ffmpeg usually ? ronald ?
[15:28] <LeRoutier> (got a compilation error because of missing header)
[15:28] wingo ([email protected]) left irc: Read error: 60 (Operation timed out)
[15:41] <Uraeus> rvalles: you are aware that we have APE plugins for Gstreamer?
[15:41] wingo ([email protected]) joined #gstreamer.
[15:42] Action: Uraeus still gets /usr/bin/ld: cannot find -lgstinterfaces-0.7 when compiling gnome-media, we must be not installing something
[15:44] kmaraas ([email protected]) joined #gstreamer.
[15:57] Uraeus ([email protected]) left irc: "Client exiting"
[15:59] <LeRoutier> bye bye
[15:59] LeRoutier ([email protected]) left irc: "Leaving"
[16:01] <wingo> folks, I'm stupid. how do I make an ascii export of my gpg public key?
[16:06] <pb_> gpg -a --export <keyid>
[16:07] <wingo> thanks pb_
[16:18] <wingo> Company: are you planning on doing rate conversion in audioconvert?
[16:21] <Company> wingo: no
[16:22] <Company> wingo: audioconvert should only do stuff that doesn't require saving state inbetween buffers
[16:22] <Company> so it should stay a "1 buffer in, 1 buffer out" element
[16:22] <wingo> that's a change. can you note that within the audioconvert element?
[16:23] <Company> i probably should
[16:23] <Company> i discussed that with ds and we came to the conclusion that doing everything would be non-gstreamer and too unreadable
[16:24] <wingo> otherwise we'll rely on my intercontinental mind-reading skills, which aren't so good ;)
[16:26] pr1ze ([email protected]) joined #gstreamer.
[16:26] <pr1ze> hyllo
[16:31] <Company> hyllo
[16:32] <pr1ze> I need a SUPER favour from someone
[16:33] <pr1ze> can someone please compile gstffmpegcodecmap.c with -E ( dont link, just show the entire pre-processed.c file ) and send it to me?
[16:33] <pr1ze> located in <your dir>/gst-plugins-0.7.4/ext/ffmpeg
[16:34] <pr1ze> i cant compile it because my version of gcc doesnt like the mimetype,blah...) macro.
[16:35] <pr1ze> or even just put it on www.pastebin.com
[16:35] <pr1ze> im not really concerned about the headers or anything, just the bulk of the code of gstffmpegcodecmap.c
[16:35] markey_ ([email protected]) joined #gstreamer.
[16:35] <pr1ze> so i can hack that into my gstffmpegcodecmap.c and compile away
[16:36] <Company> uhm
[16:36] <Company> what's the error?
[16:36] <Company> and what's the gcc version?
[16:36] <pr1ze> http://rafb.net/paste/results/H3002155.html
[16:37] <pr1ze> gcc -v = 2.95.3
[16:37] Nick change: markey_ -> markey|afk
[16:37] sjoerd ([email protected]) got netsplit.
[16:37] sublett ([email protected]) got netsplit.
[16:37] markey ([email protected]) got netsplit.
[16:37] ds ([email protected]) got netsplit.
[16:37] sack ([email protected]) got netsplit.
[16:37] hyriand ([email protected]) got netsplit.
[16:37] rvalles ([email protected]) got netsplit.
[16:38] sublett ([email protected]) returned to #gstreamer.
[16:38] sjoerd ([email protected]) returned to #gstreamer.
[16:38] ds ([email protected]) returned to #gstreamer.
[16:38] <pr1ze> thank you very much Company
[16:39] <Company> hmhm
[16:39] sack ([email protected]) returned to #gstreamer.
[16:39] hyriand ([email protected]) returned to #gstreamer.
[16:39] rvalles ([email protected]) returned to #gstreamer.
[16:43] markey ([email protected]) got lost in the net-split.
[16:43] <Company> pr1ze: does it work if you put a space between ##props and the comma?
[16:44] <wingo> hm. if we release 0.8.0 without a buffer-frames converter, dsp will be broken.
[16:44] <pr1ze> nah
[16:45] <Company> those are GNUC macros, they're supposed to work with gcc
[16:45] <Company> even 2.95
[16:46] <Company> that's why i'm a bit confused
[16:47] <Company> c99 macros would use __VA_ARGS__
[16:47] <wheels> Company: variadic macros?
[16:47] <Company> yeah
[16:48] Action: wheels -- as something of the gcc 2.95 czar -- goes to update...
[16:48] <pr1ze> hurm
[16:48] <wheels> Company: But I had problems with them in RB HEAD too...
[16:50] <Company> wheels: http://freedesktop.org/cgi-bin/viewcvs.cgi/gstreamer/gst-plugins/ext/ffmpeg/Attic/gstffmpegcodecmap.c?rev=1.41&content-type=text/vnd.viewcvs-markup
[16:50] <pr1ze> this works:
[16:50] <Company> wheels: those macros should compile with gcc 2.95, shouldn't they?
[16:50] <pr1ze>      41 #define ASS_TEST(dog, anus...)  \
[16:50] <pr1ze>      42    printf("%s%s%s\n",dog,##anus)
[16:50] <pr1ze>      85   ASS_TEST("meep","mo","fo");
[16:50] <pr1ze> so now im trying to recreate the problem, and from that fix it.
[16:51] <Company> does it work if you do this:
[16:51] <wheels> Company: Sadly I'm not really sure -- I just kind of figure things out as I go.  While my C knowledge is pretty good in that I basically never use them my knowledge of macro wizardry kind of sucks.
[16:51] <Company>      42    printf("%s%s%s\n",##anus,dog)
[16:52] <Company> i'll try some fixage with cvs HEAD
[16:53] <Company> it has the same issue and i don't have gcc 2.95
[16:53] <bitshifter> glib seems to do it a bit differently, see glib/glib/gmessage.h, ie.:   something like #define foo(format...)  g_print(format)  
[16:55] <wingo> Company: is that test program attached to the opt bug good for debugging the problem?
[16:55] <pr1ze> I think i got it
[16:55] <wheels> Argl.  I'm going to start breaking things if GStreamer requires me to upgrade yet another build tool.  ;-)
[16:56] <pr1ze> when the macro is passed with one arg, ##bleh doesnt exist so, for example #define FOO(seven,like...) func(seven,##like,"smeh") 
[16:56] <pr1ze> turns into
[16:57] <pr1ze> func(seven,,"smeh);
[16:57] <pr1ze> and we all know ".." = compile error.
[16:57] <pr1ze> right now im going through and chaging all my single arg macro calls to ... "orignaltext",NULL);
[17:00] <pr1ze> apply that to cvs and credit me ;-)
[17:00] <pr1ze> huhuhu ;-)
[17:03] Action: wheels is still screwing with libtoolize  ;-)
[17:03] <wheels> Hmm, thinking about it my glib is probably too old too...
[17:05] bilboed__ ([email protected]) left irc: Remote closed the connection
[17:06] <thomasvs> iain: I have all my cd's ripped, about 1500 albums, and 130 GB of disk space
[17:06] Nick change: wingo -> riaa
[17:06] <riaa> muahaha!
[17:06] <riaa> i subpoena thee!
[17:07] Nick change: riaa -> wingo
[17:07] <wingo> ah, sorry..
[17:07] <thomasvs> wingo: if they're my cd's, then what's the harm ? :)
[17:07] <thomasvs> of course, no one is going to believe I actually have that money
[17:08] <thomasvs> erhm, many
[17:08] <teuf> thomasvs: I'm sure you could find some record company dude who could explain that you are not allowed to do that ;)
[17:09] <thomasvs> teuf: I KNOW I'm allowed to do that, so he'd be wrong
[17:09] <pr1ze> w00t, thanks guys
[17:09] <pr1ze> its all built
[17:09] <pr1ze> and im all tired
[17:14] markey|afk ([email protected]) left irc: "Lost terminal"
[17:16] <Company> wingo: dunno, i only used rb for testing it
[17:18] <Company> i386/cputest.c:5:21: dsputil.h: No such file or directory
[17:18] <Company> do we still slurp ffmpeg?
[17:19] <Company> we do
[17:19] Action: Company reslurps
[17:23] Action: Company reslurps again
[17:25] jcsston ([email protected]) joined #gstreamer.
[17:26] Nick change: wingo -> wingo-away
[17:26] <wingo-away> back tomorrow, folks.
[17:31] <Company> grrrr
[17:32] <Misirlou> thomasvs: Fair use baby!
[17:34] <iain> TCP smells funny
[17:34] <Misirlou> iain: Not as badly as UDP.
[17:36] <pr1ze> after UDP does 5 laps on a olpimpic sized field, it still doesnt reek like IPX/SPX
[17:40] <pr1ze> what's SLLURRPPPP Company?
[17:45] <thomasvs> Company: how should layer/mode/emphasis be reported to an app ?
[17:47] jcsston ([email protected]) left irc: Read error: 60 (Operation timed out)
[17:48] <Company> thomasvs: dunno
[17:48] <thomasvs> ok, tags it is then
[17:48] <Company> nope
[17:49] <Company> we don't put anything in tags
[17:49] <Company> those are mp3 specific so tags is wrong
[17:50] <thomasvs> we had the discussion before, last time it was serial for ogg no ?
[17:50] <thomasvs> anyways, I want them reported, and I have two days left to do it, so unless we have a better plan ...
[17:51] <Company> we don't put anything in tags just because that would kinda work
[17:51] <thomasvs> I have no alternative.
[17:51] <thomasvs> anyway, it's no different from, say, nominal bitrate.
[17:51] <thomasvs> and the tag flags are there for that purpose.
[17:52] <Company> so instead of properties we use tags nowadays?
[17:52] <bitshifter> thomasvs: an alternative would be to add properties to the decoding element, wouldn't it?
[17:52] <Company> yeah, that would work
[17:52] <thomasvs> bitshifter: nobody wanted that before, so there's not really a reason to go back to that.
[17:52] <thomasvs> bitshifter: I can't rewrite every app I do every six months because we change our minds every six months :)
[17:52] lupusBE ([email protected]) left irc: "Bezig met verlaten"
[17:52] <Company> uh, no that's absolutely not true
[17:53] <Company> properties are for element-specific things
[17:53] <bitshifter> thomasvs: heh, I didn't know what people wanted before or not :)
[17:53] <Company> interfaces are for common interfaces
[17:53] <Company> tags are for signalling common metadata
[17:53] <thomasvs> Company: it very much is.  those things were properties in the past.
[17:53] <thomasvs> Company: remember streaminfo ?
[17:53] <Company> yes
[17:53] <thomasvs> and before streaminfo, they were actual named properties on the objects iirc
[17:53] <Company> yes
[17:54] <thomasvs> both of them were deprecated in favour of the newer system
[17:54] <Company> yes
[17:54] <Company> it's an unsolved problem
[17:54] <thomasvs> that newer system was tags no ?
[17:54] <Company> but i don't want all sorts of crap in the tagging system
[17:54] <thomasvs> well, that's too bad.  we had six months to solve the problem, today we need to punt and make it work.
[17:54] <thomasvs> I feel your pain.
[17:54] <Company> nope
[17:54] <thomasvs> but there's no alternative right now.
[17:54] <Company> we file a bug and mark it a regression
[17:55] <thomasvs> well, file away :) I'm adding it to fix the apps.
[17:55] <Company> i don't want all sorts of crap just because someone thinks we must have feature X _right now_
[17:55] <Company> i'm gonna revert it
[17:55] <Company> just because i don't like this "i do what i like" behaviour
[17:55] <thomasvs> no one thinks we must have it right now
[17:55] <thomasvs> it's a feature we had a year ago.
[17:56] <thomasvs> it's not going out just because someone decided the old way was crap but failed to come up with a new way.
[17:56] <Company> yeah
[17:56] <thomasvs> we can't just swing features around just because we don't care about them :)
[17:56] <Company> well, there was obviouly someone missing that that was important
[17:56] <thomasvs> there was no one missing that.  I said this was important for me from day one.
[17:56] <Company> why didn't you come up with that problem some time earlier?
[17:57] <thomasvs> and I'm not about to butt heads with you again :) let's not try to pretend you didn't know this was supposed to be in
[17:57] <thomasvs> Company: I was there from day one, when you deprecated it.  don't pretend I wasn't :)
[17:57] <thomasvs> anyways, it needs to be in there.
[17:57] <Company> this is some problem that is unsolved
[17:57] <thomasvs> it was solved before.
[17:57] <thomasvs> it is only unsolved in your head.
[17:57] <Company> ok
[17:57] <thomasvs> you should have thought about it before deprecating the old stuff.
[17:57] <Company> then use streaminfo again
[17:58] <thomasvs> oh no.
[17:58] <thomasvs> I spent six months waiting on a solution.
[17:58] <thomasvs> if the old system was crap, it was crap.
[17:58] <thomasvs> if you didn't replace it, though.
[17:58] <thomasvs> there are flags for tags, and they serve for this purpose.
[17:58] <thomasvs> if we had more time, I'd love discussing this all day.
[17:58] <thomasvs> but delaying doesn't mean dropping.
[17:58] <Misirlou> Crap doesn't belong in GStreamer. :)
[17:59] <Company> well, we nowadays have so many tags, even teuf doesn't understand all of them anymore
[17:59] <thomasvs> me neither
[17:59] <thomasvs> but we don't have much of an alternative
[17:59] <Company> and if we put any info from an element in there, too, it will just blow
[17:59] <Company> then _don't_ support
[17:59] <thomasvs> that doesn't work.
[17:59] <Company> crapping everything just because we want something stupid is not a solution
[17:59] <thomasvs> I've been stuck long enough to fix the apps.
[18:00] <thomasvs> Company: it's what all the projects do when they stick to a release cycle.
[18:00] <thomasvs> Company: let's just fix it properly for 0.9 then if it's this important.  but now we have to fix regressions.
[18:00] <Company> uh, no we don't have to
[18:00] <thomasvs> no, you *think* we don't have to :)
[18:00] <Company> yes
[18:00] <thomasvs> I understand your "no crap in gst" policy
[18:00] <Company> i don't think we do have to support everything we supported in 0.6
[18:00] <thomasvs> but there *are* limits to how far that can be stretched
[18:01] <thomasvs> Company: right, but that's just an opinion from one man.
[18:01] <Company> right
[18:01] <Company> you're another one man team
[18:01] <thomasvs> right.
[18:01] <thomasvs> so ? :)
[18:01] <Company> discuss it on the list?
[18:01] <thomasvs> you could have said six months ago you were planning on not supporting this, instead of leading me to believe you were coming up with a solution.
[18:02] <Company> do we "just do something that kinda works" if we want something in 0.8 or do we "just not support it"
[18:02] <thomasvs> Company: there's no discussion, the apps in GNOME need to work, period.
[18:02] <Company> they work without that info
[18:02] <thomasvs> Company: feel free to bring it up on the gst list, but I'm going to code it in because apps in GNOME need it.
[18:02] <Company> they don't
[18:02] <Company> they work well without
[18:02] <thomasvs> I'm sorry for you that you don't consider nautilus-media an app in GNOME, but it's in there, and it needs to work.
[18:03] <Company> it works without layer info
[18:03] <thomasvs> Sometimes I wish you would consider how the outside world and the GNOME community evaluates GStrreamer :)
[18:03] <thomasvs> anyways, I don't have time to waste, back to fixing it.
[18:03] <Company> k, please make sure it's not added to the core, elements are free to register their own tags
[18:05] <Company> where does nautilus media show the layer anyway?
[18:06] <Company> thomasvs: where does nautilus media show the layer anyway?
[18:06] <thomasvs> Company: it's in media-info
[18:06] <thomasvs> I cannot tell you where it shows it because it hasn't worked for the last six months.
[18:07] <Company> where did it show it?
[18:07] <thomasvs> Company: lemme check the shots
[18:08] <Company> thomasvs: i think you can just use the audio-codec tag, which is a string
[18:08] psyduck ([email protected]) left irc: Read error: 110 (Connection timed out)
[18:09] <thomasvs> damn, I only have ogg screenshots anymore
[18:09] <thomasvs> I'll check if I have an old rh9 install somewhere that still works
[18:10] <thomasvs> for the record, I don't like adding crap either
[18:10] <bitshifter> thomasvs: just out of curiosity: couldn't apps detect the layer, channels + rate from the pads? 
[18:10] <thomasvs> but I don't like people saying shit about gst either because we don't manage to deliver
[18:10] <thomasvs> bitshifter: they might if it worked
[18:10] <thomasvs> bitshifter: but even then, it's a poor interface.
[18:11] <thomasvs> bitshifter: the point of gstreamer is to abstract away specifics, allowing apps to write non-specialized code
[18:11] <Company> yeah, but layer, emphasis and friends are very specific
[18:11] <Company> nothing but mp3 has that
[18:12] <Company> so there's not a real point to abstract it
[18:12] <thomasvs> right.
[18:12] <thomasvs> but there's also no point in making an app special case it if it can be signalled somehow through a generic interface
[18:12] <thomasvs> btw, mode for example isn't necessarly mp3 specific
[18:13] <thomasvs> vorbis has stereo coupling too
[18:14] <Company> anyway, about the outside perception of gst: the most problematic thing both users and devs tell about gst is that it's buggy
[18:14] <Company> not that it's lacking features
[18:15] <thomasvs> yeah, so if we're not fixing buggy, let's not make it worse by telling them "we also didn't care about these features, sorry"
[18:16] <Company> i can't fix bugs if people punt everywhere, it just gets messier
[18:16] <thomasvs> I know it's hard.  we have to re-evaluate how tight we want our cycle to be.
[18:17] <thomasvs> I'm not sure six months is ok for us.
[18:17] <thomasvs> unless we limit the scope of our changes a bit.
[18:21] <teuf> you should aim for a 9 months release cycle, with an api/feature freeze after about 6 months imo
[18:23] <Company> we pretty much had that this time
[18:25] <Company> the difference between gnome and gstreamer is that gnome pretty much works at the core while gstreamer doesn't
[18:27] <Company> the parts where gnome doesn't work are very messy, too
[18:27] <Company> like vfs, IPC or .desktop files
[18:31] <thomasvs> what doesn't work about vfs ?
[18:32] <Company> mimetypes mainly
[18:34] <bitshifter> not to mention people getting violent because of fam-related things ;)
[18:34] <teuf> bitshifter: this is mainly fam's fault, not gnome-vfs's ;)
[18:34] <bitshifter> teuf: no doubt
[18:38] <teuf> hmm, will gst_pad_set_explicit_caps (gst_caps_new_simple (xxx)) leak memory, or am I not reading gst_pad_set_explicit_caps code properly ?
[18:44] wingo_ ([email protected]) joined #gstreamer.
[18:46] markey ([email protected]) joined #gstreamer.
[18:46] wingo-away ([email protected]) left irc: Read error: 113 (No route to host)
[19:05] steveb__ ([email protected]) joined #gstreamer.
[19:05] steveb_ ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[19:07] <Company> teuf: i think it'll leak mem, yes
[19:08] <teuf> Company: I'm looking at fixing the leaks in #134839 in the hope it will prevent rb from eating tons of mem ;)
[19:09] <Company> there's a gst_data_unref missing somewhere...
[19:09] <Company> i dunno where though ;)
[19:10] <teuf> I'm finding some caps leaks for now
[19:12] <teuf> cool, memprof output on this test program is mostly clean now
[19:16] <teuf> do http://cfergeau.free.fr/gst-plugins-leaks.diff and http://cfergeau.free.fr/gstreamer-leaks.diff look sane ?
[19:17] Uraeus ([email protected]) joined #gstreamer.
[19:17] <Uraeus> hello
[19:21] <Company> teuf: the spider fix is ok
[19:21] <Company> teuf: the mad one is ok, too, please commit
[19:22] <teuf> it still leaks like crazy though ;)
[19:23] <Company> hm
[19:23] <Company> valgrind won't show leaked buffers :/
[19:23] <teuf> yeah, memprof doesn't either
[19:23] <teuf> I'll try to narrow down the elements used in the test case though
[19:23] <teuf> maybe it leaks without spider
[19:27] <Company> try using gnomevfssrc instead of filesrc
[19:27] <Company> hm no, won't work either
[19:35] steveb__ ([email protected]) got netsplit.
[19:36] steveb__ ([email protected]) returned to #gstreamer.
[19:42] <teuf> hmm, even filesink!fakesink seem to leak a bit of mem
[19:42] <teuf> though the testcase is too big to be sure it's not a leak in its case
[19:44] <Company> filesink ! fakesink or filesrc ! fakesink ?
[19:44] mathrick ([email protected]) joined #gstreamer.
[19:44] <teuf> filesrc ! fakesink
[19:45] <mathrick> ho
[19:45] <Uraeus> thomasvs: the current spec still doesn't load the gconf schemas correctly, any idea why?
[19:46] <thomasvs> Uraeus: I cannot work on that spec much more, you're better off testing my fedora 1 rpms
[19:47] <Uraeus> thomasvs: ok, are they apt gettable?
[19:48] <teuf> actually it's not leaking that much
[19:48] Action: Uraeus wants URL :)
[19:49] jcsston ([email protected]) joined #gstreamer.
[19:50] <Uraeus> ping thomasvs
[19:51] <thomasvs> Uraeus: yep
[19:51] <Uraeus> thomasvs: gimme the sources entry :)
[19:52] <thomasvs> rpm http://gstreamer.freedesktop.org/pkg fedora/1/i386 deps gst
[19:52] Action: Uraeus apt-gets
[19:55] <Uraeus> thomasvs: btw, part of the reason for the exact splitting of files in the spec is that I wanted our gst-plugins package to no contain anything not in the official RH one, so that people could use our plugin rpms with their RH rpms
[19:56] <thomasvs> Uraeus: I changed the spec file in agreement with matthias
[19:57] <thomasvs> Uraeus: the new ones are usable on rh
[19:57] <Uraeus> thomasvs: I know, and I don't mind, I was just explaining why it was the way it was before
[19:57] <thomasvs> Uraeus: and matthias will basically have the same ones
[19:57] <thomasvs> Uraeus: yeah, I know, just explaining what I did :)
[19:59] <Uraeus> thomasvs: ok, some issues with your RPMS
[19:59] <Uraeus> first of all I get libdv_0%3a0.101-2_i386.rpm
[20:01] <Uraeus> the second issue turned out to be my own fault :)
[20:01] sublett ([email protected]) left irc: "Nice of you to put me on the money"
[20:03] apoc ([email protected]) joined #gstreamer.
[20:03] <apoc> hi
[20:03] <Uraeus> yo apoc
[20:04] <Uraeus> apoc: we have a mod playback bug in bugzilla and 0.8 on monday :)
[20:04] jcsston ([email protected]) left irc: Read error: 60 (Operation timed out)
[20:04] somex1 ([email protected]) joined #gstreamer.
[20:06] <apoc> Uraeus: aie 
[20:08] <apoc> Uraeus: do you have the bug number ?
[20:08] <thomasvs> Uraeus: what's the first issue ?
[20:08] <thomasvs> Uraeus: I mean, how is that my fault ?
[20:10] <Uraeus> thomasvs: sorry I thought it was from our repo, which mean the filename was a bit borked
[20:10] <Uraeus> apoc: actually it seems the bug was fixed by ronald some time ago :)
[20:10] <Uraeus> apoc: sorry about that :)
[20:10] <mathrick> Uraeus: what's wrong with that filename?
[20:10] <thomasvs> Uraeus: apt mangles the filenames on download
[20:10] <thomasvs> Uraeus: so I don't think it's a problem
[20:10] <thomasvs> Uraeus: anyways, does it work ? :)
[20:11] <Uraeus> thomasvs: had a ton of install conflicts with fdr and offical rh packages and freshmeat, finally sorted them out and will now test :)
[20:11] <apoc> Uraeus: it's fixed so no problem ;)
[20:12] <Uraeus> thomasvs: your RPMS doesn't install the gconf schemas either
[20:12] <thomasvs> Uraeus: how sure are you ? I have it here afaict
[20:13] <Uraeus> thomasvs: well I just installed all your packages and nothing shows in gconf-editor, I can create a bug with a screenshot if you want
[20:15] <Company>  492165 bytes in 4558 blocks are definitely lost in loss record 20 of 21
[20:15] <Company> whoops
[20:18] <Uraeus> thomasvs: http://bugzilla.gnome.org/showattachment.cgi?attach_id=25272
[20:18] <Uraeus> err
[20:18] <Uraeus> thomasvs: http://bugzilla.gnome.org/show_bug.cgi?id=136400
[20:20] <Company> teuf: found it
[20:20] <Uraeus> thomasvs: ok, can't compile gnome-media with your rpms either, cc'ed you on the bug I have on that
[20:20] <teuf> Company: rock :)
[20:21] <teuf> Company: where was it ?
[20:21] <Company> teuf: gst_buffer_merge doesn't take the first buffer (which I thought it did)
[20:21] <teuf> ok
[20:21] <Company> teuf: will commit when my brother is done playing UT
[20:21] <teuf> hehe
[20:21] <teuf> is he complaining about lag when you commit while he plays ?
[20:28] <thomasvs> ugh
[20:28] <thomasvs> what should I do when I'm trying to typefind an mp3 and it reports x-id3 instead of mp3 ?
[20:28] <thomasvs> retypefind with the appropriate id3 decoder ?
[20:31] <Company> teuf: prepare-changelog runs cvs diff and that causes lag ;)
[20:31] <Company> thomasvs: id3tag retypefinds itself
[20:36] The_Company ([email protected]) joined #gstreamer.
[20:36] Company ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[20:37] Nick change: The_Company -> Company
[20:46] <thomasvs> Company: [gst-head] [thomas@otto media-info]$ gst-typefind serge.mp3
[20:46] <thomasvs> serge.mp3 - application/x-id3
[20:46] <thomasvs> am I missing something ?
[21:03] BBB ([email protected]) joined #gstreamer.
[21:04] Action: thomasvs finds weird stuff in the id3tag src_link function
[21:04] Action: thomasvs wonders how to make filesrc ! id3tag ! typefind figure out that it's audio/mpeg
[21:05] <teuf> where is dsputil.h supposed to come from ?
[21:05] <BBB> ffmpeg
[21:05] <teuf> hmm, gst-ffmpeg didn't get it
[21:05] <BBB> CVS?
[21:06] <teuf> yep, fresh checkout
[21:06] Nick change: kh_out -> khalek
[21:06] <BBB> [rbultje@shrek gst-ffmpeg]$ find . -name dsputil.h
[21:06] <BBB> ./gst-libs/ext/ffmpeg/ffmpeg/libavcodec/dsputil.h
[21:06] <BBB> probably an incomplete checkout?
[21:06] Action: BBB winks @ thomasvs
[21:06] <teuf> how do I force a re checkout of ffmpeg ?
[21:07] <thomasvs> BBB: after the release :)
[21:07] <thomasvs> BBB: will be faster if you implement release-device properties on the audiosinks now :)
[21:07] <thomasvs> BBB: or fix the mpeg problem
[21:08] <BBB> release-device properties on audiosinks?
[21:08] <BBB> are you insane?
[21:08] <BBB> no way we're going to implement that
[21:08] <BBB> or well
[21:08] <BBB> maybe others
[21:08] <BBB> not me
[21:08] <BBB> if you want to release the device, simply close the element that opened the device
[21:08] <BBB> that's mho
[21:09] <thomasvs> BBB: that's completely wrong, that doesn't work at all for our apps
[21:09] <thomasvs> BBB: you say rhythmbox has to NULL the audiosink on pause ?
[21:11] <BBB> rhythmbox should use esdsink?
[21:12] <thomasvs> BBB: you are kidding right ?
[21:12] <thomasvs> sometimes I wonder if you guys really want us to look like the worst framework ever :)
[21:13] <BBB> I'm just saying that I don't think that a hack such as release-device is the right solution
[21:13] <BBB> if we use osssink, then we use the device. period
[21:13] <BBB> if we don't want that, we shouldn't fiddle with all sort of crap to get around issues that can be solved much easier by using a sound server
[21:13] <BBB> I see it as a hack
[21:13] <BBB> again: just mho
[21:13] <thomasvs> yeah
[21:14] <thomasvs> too bad all of our application developers AND their users disagree.
[21:14] <thomasvs> so our design is broken.
[21:14] <thomasvs> look
[21:14] <BBB> if you'd hire me, you could force me to do this... but for now, I don't like it ;)
[21:14] <thomasvs> if you use oss, there has to be a way to release the device temporarily.
[21:14] <BBB> <thomasvs> too bad all of our application developers AND their users disagree.
[21:14] <BBB> <thomasvs> so our design is broken. <- ?
[21:14] <thomasvs> it's not right to tell the users "quit the app if you want to use another app to play osmething"
[21:14] <thomasvs> BBB: yeah, I consider our design broken if it means all of our app developers aren't able to write their app.
[21:15] <BBB> they can
[21:15] <BBB> just not this tiny little feature
[21:15] <BBB> you know what? add it to bugzilla, mark it as enhancement so at least we can say it's a "known issue"
[21:16] <thomasvs> it's already decided we're putting in the hack
[21:16] kwm ([email protected]) left irc: "brb"
[21:16] <thomasvs> this isn't some tiny little feature
[21:16] <thomasvs> shall I tell you what happens now ?
[21:16] <thomasvs> a) user plays song in jamboree or rhythmbox
[21:17] <thomasvs> b) after 30 seconds, user presses pause
[21:17] <thomasvs> c) user presses play
[21:17] <thomasvs> d) complete app DOES NOTHING AND LOCKS UP for 30 seconds, then plays again.
[21:17] <thomasvs> now, the question
[21:17] <thomasvs> who do you think will get the blame for this ?
[21:17] <BBB> that is a totally different issue
[21:17] <BBB> it has nothing to do with release-device
[21:17] <mathrick> and, how do you plan to get away with saying "it's a known issue"?
[21:18] <mathrick> BBB: it has everything to do with this
[21:18] <thomasvs> BBB: it is *100%* the issues
[21:18] <BBB> guys, WAIT!
[21:18] <BBB> let me finish what I'm saying
[21:18] <mathrick> BBB: because RB is behaving nice, and releases device on pause
[21:18] <BBB> you're totally misunderstanding me
[21:18] <thomasvs> BBB: jamboree and rb both CHOOSE to set the sink to NULL to get the device released
[21:18] <BBB> _HOLD ON_
[21:18] Action: mathrick listens
[21:18] Action: thomasvs holds on :)
[21:19] <BBB> "known issue" isn't a way of saying that the issue is known and we won't fix it
[21:19] <BBB> I never said that either ;)
[21:19] Misirlou ([email protected]) left irc: "asdf"
[21:19] kwm ([email protected]) joined #gstreamer.
[21:19] <thomasvs> BBB: good.
[21:19] <BBB> it's simply a way of tracking feature requests or bug reports
[21:19] <thomasvs> BBB: it needs to be fixed before 0.8.0
[21:19] <BBB> I'm not sure which of the two this is, but either way, at least we know it needs doing
[21:19] <thomasvs> BBB: how do you propose we fix it ?
[21:19] <BBB> then, secondly:
[21:20] <BBB> release-device is a way of close(2)'ing the device when it is not in use... the issue that you are seeing is that the clock on the element (which has nothing to do with the device itself) waits for 30 seconds, which is a clocking bug
[21:20] Nick change: khalek -> kh_zZz
[21:21] <BBB> device<->clock, at least in OSS, are not related, except that they are implemented by one and the same device
[21:21] <BBB> er
[21:21] <BBB> element
[21:21] <BBB> in ALSA, they're partially related
[21:21] <BBB> but that's because ALSA has a nicer architecture concerning this... a bit like v4l2 vs. v4l
[21:22] <thomasvs> BBB: the issue I am seeing is not a clocking "bug", it's correct clocking behaviour.
[21:22] wheels ([email protected]) left irc: Read error: 104 (Connection reset by peer)
[21:22] <thomasvs> BBB: the app sets the sink to null, which resets the internal time of the sink to 0
[21:22] <mathrick> BBB: that's technically correct, too bad users won't want to hear all that. They simply want being able to pause releasing device. And this thing just pops in that context
[21:22] <thomasvs> BBB: the pipeline however is still at 30 secs
[21:22] <thomasvs> BBB: so when setting back to play, the sink does the correct thing - wait 30 seconds until the timestamps match the internal time
[21:23] <thomasvs> BBB: if there is a bug, it's in our definition of states, where releasing the device and resetting the internal time are both done between READY and NULL
[21:23] wheels ([email protected]) joined #gstreamer.
[21:23] Action: mathrick wonders if setting master clock to NULL shouldn't be DISCONT
[21:24] <thomasvs> personally, and I have always thought this, I consider grabbing the device from READY on a bug.
[21:24] <thomasvs> if it isn't, we need to add another state.
[21:24] <BBB> thomasvs: er... applications shouldn't do that... anyway, there's already a bug that we don't handle plugging-while-playing correctly
[21:24] Uraeus ([email protected]) left irc: "Client exiting"
[21:24] <BBB> er?
[21:24] <BBB> thomasvs: it has always been like that, it's one of the essentials
[21:24] <BBB> and there's very good reasons to do it like that
[21:25] <BBB> anyway, add it to bugzilla
[21:25] <BBB> we'll look at it
[21:26] Action: BBB has "no opinion" on the hacks that is apparently in rhythmbox
[21:26] <mathrick> thomasvs: on one hand, element cannot consider itself READY (to play) when it doesn't have device grabbed, can it?
[21:26] <thomasvs> BBB: no, it used to be between READY and PAUSED
[21:27] <mathrick> OTOH, there definitely _must_ be a way to release device when not using it
[21:27] <BBB> it cannot even do caps negotiation or basic getcaps() return values if the device isn't opened
[21:27] <thomasvs> mathrick: READY doesn't mean ready to play
[21:27] <BBB> because the return value depends on the device/instance
[21:27] <thomasvs> BBB: exactly, which is why it got moved.
[21:27] <thomasvs> because it was too hard to get right.
[21:27] <thomasvs> BBB: applications shouldn't do what exactly ?
[21:27] <BBB> thomasvs: and the fact that *drivers* lock if you open(2) it more than once is not a GStreamer bug
[21:27] <BBB> neither is it something we should care about
[21:27] <BBB> drivers are not our business
[21:27] <thomasvs> BBB: in any case, there is no way for an application currently to be able to release the device, and all apps want that.
[21:27] <thomasvs> nobody cares whose bug it is
[21:28] <BBB> ok, fine
[21:28] <BBB> again
[21:28] <BBB> add a bug report
[21:28] <thomasvs> all they care about is that the framework we try to get them to use doesn't do what they want
[21:28] <thomasvs> BBB: it's already been discussed, ds agrees, we're adding a release-device property
[21:28] Action: mathrick still wants transparent sound server built into kernel
[21:28] <thomasvs> but it'd be so nice if we were able to at least think about apps instead of ourselves :/
[21:30] Misirlou ([email protected]) joined #gstreamer.
[21:31] <sack> btw , BBB could you check http://bugzilla.gnome.org/show_bug.cgi?id=136392 ( v4l bug )
[21:34] Uraeus ([email protected]) joined #gstreamer.
[21:36] <BBB> mathrick: think again... never
[21:36] <BBB> mathrick: the kernel has a different task
[21:36] <BBB> sorry
[21:36] <BBB> I've always stopped anyone from adding such things like colourspace conversion to kernel v4l drivers
[21:38] <BBB> sack: changing MIN_BUFFERS_QUEUED to 1 is discouraged, it leads to other issues inside several drivers
[21:38] <BBB> I have a qc-usb cam and it works for me ;)
[21:38] <BBB> using the qcset dblbuf hack
[21:38] <BBB> I'll check again, but I'm quite sure it worked
[21:38] Action: BBB will test webcam stuff tonight
[21:38] <sack> BBB : not man ... is just a fake that and is not working i report it at the bug :-P
[21:39] <Company> <thomasvs> but it'd be so nice if we were able to at least think about apps instead of ourselves :/       that statement is wrong on a lot of points
[21:39] <sack> BBB: anyway i just one discuss if you want the best way to fix that issue
[21:39] <mathrick> BBB: you said it yourself - why should I worry about crappy drivers locking on multiple open(2)s?
[21:39] <Company> a) if we only think about what apps want we end with a mess (in fact gst was long enough developed only thinking about "apps" - gst-launch)
[21:39] <teuf> what should I do if I'd like a patch which plugs a few leaks to be reviewed ? 
[21:40] <teuf> put it in bugzilla and ask for a review ?
[21:40] <Company> b) we're thinking about apps, we did all the code we did just for specific apps, not for fun
[21:40] <thomasvs> Company: to give a concrete example - apps want to pause and release a device.
[21:40] <thomasvs> Company: all we can say is "don't do this, it is wrong by design, use a sound server"
[21:40] <Company> thomasvs: no, we say "gstreamer can't do this correctly, sorry" (at least that's what i say)
[21:40] <mathrick> BBB: my point isn't to suddenly add esd code into kernel, that'd suck a big time. But way to plug your server of choice and have it used transparently would be great
[21:41] <thomasvs> full well knowing that that is a) a bad answer b) there is no good sound server and c) it is not wrong by design to have this work and d) other frameworks do this without much problems.
[21:41] <Company> thomasvs: there's a lot of things we just don't do
[21:41] <Company> there is no other framework
[21:41] <BBB> sack: sorry, I'm not following you
[21:41] <thomasvs> Company: so, you think rb and jamboree just shouldn't use gstreamer ?
[21:41] <Company> no, i think they should be aware that there's a bug that doesn't work
[21:41] <BBB> mathrick: esd has a hacktoy for that
[21:42] <Company> if they think the bug is so bad they want to do the media stuff themselves, they may do so
[21:42] <BBB> the funny thing is that I was just notified of it
[21:42] <BBB> and now it's like the biggest issue ever
[21:42] <BBB> it was *never* reported on bugzilla here
[21:42] <thomasvs> Company: so you seriously think that it's better to have this incredibly visible and very silly end user bug for now, and tell everyone "we might fix it later" ?
[21:42] <Company> we are all 100% aware that this is very bad, but it just doesn't work
[21:43] <thomasvs> ok, then we shouldn't release 0.8 at all.
[21:43] <Company> thomasvs: unless we have a working solution now, yes, i think we should have this bug
[21:43] <thomasvs> in fact, I guess we'll take that route.
[21:43] <thomasvs> later guys
[21:43] Nick change: thomasvs -> thomasvs-out
[21:43] <mathrick> BBB: hmm? how much of hack is it? and how's it named?
[21:43] <Company> we don't even do threading correctly
[21:43] <Company> replugging totally screws you
[21:44] <thomasvs-out> btw, there are such frameworks.
[21:44] <thomasvs-out> xine does it
[21:44] <thomasvs-out> helix does too
[21:44] <Company> xine doesn't do metadata
[21:44] <thomasvs-out> and I wouldn't have too high hope that helix or xine will not be used in gnome if we can't even pause correctly.
[21:44] <BBB> mathrick: esddsp
[21:44] <Company> then let gnome use xine or helix
[21:44] <BBB> mathrick: it preloads symbols for open/close before libc
[21:44] <Company> if they think pausing is important enough to rewrite all their apps, so be it
[21:44] <BBB> mathrick: which is a fairly ugly hack
[21:45] <thomasvs-out> Company: sure.  if we want all developers to jump ship, that's a good way to do it.
[21:45] <teuf> Company: it's pretty easy to switch to use xine in rb ;)
[21:45] <mathrick> BBB: bleeh, ugly
[21:45] <thomasvs-out> Company: not sure though how you want to improve gst without any apps using it.  we're bad enough at getting features to apps as it is.
[21:45] <Company> i don't think we're that bad
[21:45] <BBB> mathrick: that's what I just said, hack :)
[21:46] <mathrick> BBB: what I want is solution, not hack, that's why it should be in kernel
[21:46] <Company> in fact i know a lot of apps that jumped ship earlier
[21:46] <Company> when adding not really supported features was the cool thing to do
[21:46] <BBB> mathrick: no... kernel is not meant for this
[21:46] <BBB> mathrick: you have a different picture of kernel than the kernel people
[21:47] <mathrick> BBB: why? it's entirely the same thing as userspace fs
[21:47] <BBB> mathrick: you want a framework for application building... that's what gnome provides (gtk, gst, gnome, ...)
[21:47] <BBB> the kernel is something else
[21:47] <Company> teuf: rb and xine has enough issues in itself ;)
[21:47] <BBB> mathrick: the kernel is supposed to be a sort of unified picture of your hardware so that apps can talk to them
[21:47] <mathrick> BBB: I want a way to do it, not actual code in kernel
[21:47] <teuf> Company: it works well here (apart from a few bugs when reaching end of songs)
[21:48] <BBB> it's not supposed to be a framework so that any sort of app and input can be used and the kernel will take care that the hardware understands it in some way
[21:48] <thomasvs-out> Company: not really - it's more used and more stable than the gst backend atm
[21:48] <Company> teuf: it needs a whole metadata backend ;)
[21:48] sack ([email protected]) left irc: Read error: 60 (Operation timed out)
[21:48] <BBB> mathrick: that's caled gnome :)
[21:48] <mathrick> BBB: exactly, that's why apps shoudln't care any about how shitty sound card is, and wether it supports mixing
[21:48] <teuf> Company: yeah, and the metadata backend doesn't leak too much, and is faster than gstreamer I think ;)
[21:48] <Company> teuf: but you still have to maintain it yourself :p
[21:48] <BBB> mathrick: so it shouldn't be in the kernel, that's my point :)
[21:48] <mathrick> BBB: it'd be as unified view as you can get
[21:49] <teuf> Company: it's not like I didn't have to hack on gstreamer when I need something wrt metadata ;)
[21:49] <Company> teuf: yeah, but at least you add it in the framework, so Muine can use it, too :p
[21:49] <BBB> cc1: warnings being treated as errors
[21:49] <BBB> media-info-priv.c: In function `tag_flag_score':
[21:49] <BBB> media-info-priv.c:162: warning: implicit declaration of function `gst_tag_get_flag'
[21:49] <mathrick> BBB: code should be in userspace, but kernel should allow for easy routing that into userspace
[21:49] <BBB> current CVS
[21:49] <BBB> what's that?
[21:50] <BBB> mathrick: oh, like that
[21:50] <BBB> mathrick: no... I don't think so
[21:50] <BBB> mathrick: too complicated
[21:50] <Company> gstreamer is not 1.0 for a reason...
[21:50] <mathrick> BBB: how is it more complicated than userspace fs?
[21:50] <Company> gstreamer is developed by 4 developers - including plugins
[21:51] <BBB> mathrick: not complicated
[21:51] <Company> part-time developers
[21:51] <teuf> can anyone look at http://cfergeau.free.fr/gst-plugins-buffer-merge.diff or should I put it in bugzilla ?
[21:51] <BBB> mathrick: tio explain you why the kernel is not the place to do these sort of hacks
[21:51] <BBB> that's complicated
[21:51] <BBB> because most people just don't understand the picture of what the kernel does and is supposed to do
[21:51] <Company> teuf: put it in :)
[21:51] <thomasvs-out> BBB: update core
[21:51] <BBB> thomasvs-out: oh, I just missed an update?
[21:51] <BBB> crap
[21:51] Action: BBB reupdates
[21:52] <Company> the kernel should essentially do nothing
[21:52] <Company> a bug in the kernel crashes my system, a bug in an app crashes the app
[21:52] <BBB> that's one of the reasons
[21:52] <BBB> a second is security
[21:52] <teuf> Company: well, I wouldn't be surprised if there were some things I overlooked
[21:52] <BBB> a third is efficiency
[21:52] <BBB> a fourth is design
[21:52] <teuf> and since I can't really test those changes...
[21:53] <Company> teuf: as long as it compiles, it's ok ;)
[21:53] <mathrick> ok, so you consider userspace fs bad thing, to stick to that example?
[21:53] <teuf> Company: I'm not even sure all those files are compiled here
[21:53] <mathrick> and I don't see how userspace daemon crashing would crash your kernel
[21:54] <Company> teuf: they look as if they should - you saure have flac and png
[21:54] <Company> teuf: just check it in and blame me if something fails
[21:54] <teuf> yeah, but I'm unsure about ac3, mikmod and stuff like that (unsure they are compiled)
[21:54] <Company> ac3 is in the gst subdir, so it's compiled
[21:55] <Company> i'll check mikmod :)
[21:59] <mathrick> BBB: security - you're not forced to enable this, efficiency - how is entirely userspace daemon more efficient than userspace daemon doing that work on kernel's request? design - how is rewriting all apps when you change sound server for some reason (like, I suddenly want all my sound relayed to network) better design?
[21:59] sack ([email protected]) joined #gstreamer.
[22:01] <mathrick> what I always hated about Linux kernel is that instead of being able to fine-tune it and recompile, I'm forced to do this on every trivial change
[22:02] <BBB> mathrick, kernel scheduling is completely unrelated to userspace scheduling
[22:03] <BBB> if you do those things in kernelspace, you basically break all that stuff
[22:03] <BBB> that's one reason
[22:03] <BBB> and sure, we all want ultra-fast media processing
[22:03] <mathrick> BBB: and you, as gst dev, should be especially able to understand this, as whole gst is about dynamic (re)plugging things :)
[22:03] <BBB> but I hope you see that this is not the way ;)
[22:03] <mathrick> <BBB> if you do those things in kernelspace, you basically break all that stuff <- what "things" ?
[22:03] <BBB> processing
[22:03] <BBB> like rerouting of data
[22:04] <BBB> and besides, don't yuo think it's bloat?
[22:04] Action: BBB likes that work in some contextx
[22:04] <mathrick> BBB: there is no processing, just passing data
[22:04] <BBB> anyway, fortunately I'm not the OSS maintainer
[22:04] <mathrick> BBB: no, it's functionality I miss very sorely
[22:04] <BBB> neither am I v4l maintainer
[22:04] <BBB> "it'd be nice", but "it doesn't belong there"
[22:04] <BBB> that's my opinion
[22:05] <mathrick> BBB: I don't think having n sound servers running is less bloat, for example
[22:05] <BBB> on e of the reasons why I like gst so much
[22:05] <Company> the kernel should grab data coming in and throw it to the app
[22:05] <mathrick> Company: exactly, that's what I'm asking for
[22:05] <Company> or for output the other way around
[22:06] <Company> it should not touch the data at all
[22:08] <Company> that's why i think that neither filesystems nor network stacks (like tcp) belong in the kernel
[22:09] <mathrick> BBB: it doesn't belong to gst :) gst shouldn't be substitute for hw, that's whoever provides access to that hw (ie kernel) to make it behave coherently
[22:09] <Company> no
[22:09] <Company> it's not the job of the kernel to add features to the hardware
[22:10] <mathrick> well, it's not adding feats, it's just abstracting it
[22:10] <Company> yeah
[22:10] <Company> so if only one access to the sound card is ok, it only allows one
[22:11] <BBB> mathrick: what's coherent?
[22:11] <mathrick> no, it turns some piece of hw, better or worse, into kind of magic box you can throw sound into
[22:12] <mathrick> BBB: all sound cards behaving the same
[22:12] <Company> that's not what the kernel should do though
[22:12] <BBB> no
[22:12] <BBB> the kernel abstracts the hardware
[22:12] <BBB> it doesn't *fix* your hardware
[22:12] <Company> that would mean there needs to be an opengl in the kernel
[22:12] <BBB> if your card only suports 48kHz, then the kernel properly reports that and refuses other samplerates
[22:12] <mathrick> Company: it's called DRI :)
[22:12] <Company> including a pixel shader language implementation
[22:12] <BBB> DRI is the kernel layer of hw openGL
[22:12] <BBB> if the videocard has no openGL, DRI does nothing
[22:12] <Company> mathrick: DRI would (according to your idea) only need 1 driver
[22:13] <BBB> that's how sound (OSS, ALSA) should work, too
[22:13] <mathrick> Company: no
[22:13] <Company> mathrick: yes
[22:13] <mathrick> Company: according to my idea, every DRI driver would behave the same
[22:13] <Company> mathrick: the kernel would make the graphics card a magic box you throw opengl at :)
[22:13] <mathrick> Company: and that's the whole point behind hw drivers
[22:13] <mathrick> Company: kinda
[22:14] <Company> mathrick: though throwing quake3 opengl data at a zaurus graphics card would certainly be nice if it worked
[22:14] <mathrick> Company: if you like access to raw hw feats, you can go back to DOS :P
[22:15] <Company> the kernel should never add features
[22:15] <Company> (though it does that for hard disks and network cards)
[22:15] <Company> that's the job of some deamons
[22:16] <mathrick> Company: it shouldn't add feats, it should let others easily do that
[22:16] <Company> yeah
[22:16] <mathrick> Company: that's exactly what I'm proposing :)
[22:16] <Company> that's exactly how it works
[22:17] <mathrick> Company: no, it doesn't work like that atm
[22:17] <mathrick> Company: unless I'm missing something
[22:17] <Company> where does it not work like that?
[22:17] <mathrick> Company: open(2)ing /dev/dsp twice blocks with my card, it shouldn't
[22:17] <Company> mathrick: hu?
[22:18] <Company> mathrick: the soundcard can't be opened twice
[22:18] <mathrick> Company: if it has hw mixer, it can
[22:19] <Company> mathrick: a hw mixer is an added feature in my book
[22:19] <mathrick> Company: hu?
[22:20] <Company> mathrick: ah, misunderstood you
[22:20] <Company> mathrick: you can open soundcards with hw mixer twice
[22:20] <Company> mathrick: (unless the driver sucks)
[22:20] <Company> mathrick: but cards without hw mixer can only be opened once
[22:20] <mathrick> Company: why?
[22:20] <Company> mathrick: because the cards don't support opening them twice?
[22:21] <mathrick> Company: ie, why should it be like that
[22:21] walters ([email protected]) joined #gstreamer.
[22:21] <Company> mathrick: because the kernel shouldn't add features
[22:21] <mathrick> <mathrick> Company: it shouldn't add feats, it should let others easily do that
[22:22] <Company> mathrick: others can easily do that
[22:22] <mathrick> Company: no
[22:22] <Company> why not?
[22:22] <mathrick> Company: how can I run app compiled for esd run easily with NAS?
[22:23] <Company> mathrick: uh, you're missing something there
[22:23] <Company> mathrick: you can'T run an app build for A with B
[22:23] <mathrick> Company: why should _any_ app besides sound server worry about hw feats? and act of choosing some server is instance of worrying about hw feats
[22:23] <Company> yes
[22:24] <Company> but there are multiple sound servers out there
[22:24] <mathrick> Company: and I propose to move that act to where it belongs - to user
[22:24] <mathrick> Company: the more of them, the more it sucks
[22:25] <Company> mathrick: yes - many $x apps prove that the best way to do $x has not yet been found - so people always start new apps trying to solve the problem
[22:25] <Company> examples are sound servers, mp3 players, text editors and so on
[22:26] <Company> examples for the right way has been found is X
[22:27] <mathrick> Company: ok, but why do you think patching every app that used previous, failed attempt at finding correct solution better than completely isolating them from that choice?
[22:27] <Company> how do you isolate them?
[22:27] <mathrick> Company: btw, right way for editors has been found ;)
[22:28] <mathrick> Company: by adding way to plug sound server into /dev/dsp
[22:28] <Company> uh, /dev/dsp is just an API
[22:28] <Company> if the API sucks, people write a new one
[22:28] <mathrick> Company: this way, app just opens /dev/dsp, it doesn't worry a single bit about my hw
[22:28] <mathrick> Company: yea
[22:29] <mathrick> Company: but switching API when hw is crappy doesn't suck?
[22:29] <BBB> pf
[22:29] <Company> switching API always sucks
[22:29] <BBB> even with ds' fixes yesterday, I still get nothing but a 16x16 window in totem
[22:29] Action: BBB cries
[22:29] <Company> that's why apps shouldn't use kernel API directly :)
[22:29] <BBB> I
[22:29] <BBB> I'm gonna give up on totem
[22:29] <mathrick> Company: one question - why _app_ writer should ever choose correct sound server for _me_ ?
[22:29] <BBB> that thing is doing something terribly wrong inside
[22:30] <Company> mathrick: app writer choses one API everytime
[22:30] <Company> mathrick: he has to
[22:30] <mathrick> Company: no
[22:30] <Company> mathrick: yes
[22:30] <mathrick> Company: choosing API is distinct from choosing its implementation
[22:31] <Company> yes
[22:31] <Company> but most of the timne the API is bound to the implementation
[22:32] <mathrick> Company: well, then we're doomed, and gst is pointless
[22:32] <Company> well, people always improve APIs
[22:32] <Uraeus> BBB: are totem picking up on your gconf keys?
[22:32] <mathrick> Company: because gst is just that - separating API from implementation
[22:32] <Company> and you get more implementations for them
[22:32] <Company> no, gst is just another API that abstracts something
[22:32] <BBB> Uraeus: no, but the default (ximagesink) should work
[22:33] <mathrick> Company: something == implementation :)
[22:33] <mathrick> Company: gst == magic box for media processing, /dev/dsp == magic box for playing sound
[22:34] <mathrick> Company: discussion on wether /dev/dsp is good API isn't related any to "what sound server I should link to"
[22:35] <Company> mathrick: /dev/dsp is a bad API, because it's bound to the implementation (in this case the Linux kernel)
[22:35] <Company> it just doesn'T work on windows
[22:36] <mathrick> Company: true, but you just keep saying that binding it ever closer (to specific hw model) is good
[22:36] <Company> no
[22:36] <mathrick> s/ever/even/
[22:36] <Company> apps should be programmed against the sound server API
[22:36] <Company> or against the media framework API
[22:36] <mathrick> Company: no, apps should be programmed against sound lib
[22:36] <mathrick> or against the media framework API
[22:37] <Company> yeah
[22:37] <Company> that's what alsalib tries to solve btw
[22:37] <mathrick> Company: but that doesn't mean that lib should care about my hw
[22:37] <BBB> DEBUG      videoscale(30476) gstvideoscale.c(209):gst_videoscale_link: gst_videoscale_link on sink video/x-raw-rgb, width=(int)16, height=(int)16, framerate=(double)1, bpp=(int)16, depth=(int)16, red_mask=(int)63488, green_mask=(int)2016, blue_mask=(int)31, endianness=(int)1234
[22:37] <BBB> ?
[22:37] <mathrick> Company: it's a job of driver to care about my hw, and when hw lacks, to let others fix it
[22:38] <Company> mathrick: someone has to care
[22:38] <Company> mathrick: it shouldn't be the app and it shouldn't be the kernel
[22:38] <mathrick> Company: exactly
[22:38] <Company> mathrick: but until there's some good solution in between we're stuck...
[22:38] <mathrick> Company: it's kernel allowing apps for fixing that
[22:38] <mathrick> Company: see? :)
[22:39] <Company> no
[22:39] <Company> kernel API is low level API
[22:39] <mathrick> Company: yes, and hw should never get higher than that
[22:39] <Company> yeah
[22:39] <Company> and apps should never need to use it
[22:39] <Company> so an app using /dev/dsp is just wrong
[22:40] <mathrick> Company: yeah, they should use something on the level of SDL
[22:40] <Company> yeah
[22:40] <mathrick> Company: or gst for that matter :)
[22:40] <Company> alsalib :)
[22:40] <mathrick> where gst in turn uses sdl or alsalib
[22:40] <Company> or that way
[22:40] <Company> but that still means you need to care somewhere
[22:40] <mathrick> Company: yes, sound server
[22:40] <Company> about features
[22:41] <Company> even in the app
[22:41] <mathrick> Company: remember that server isn't your ordinary app
[22:41] <Company> no, i meant the final app, not the server
[22:41] <Company> the server has to care a lot
[22:41] <mathrick> Company: and noone else
[22:41] <Company> but even apps using gtk need to care about X
[22:42] <mathrick> Company: and noone should also care about server's existance
[22:42] <mathrick> Company: huh? why do they?
[22:43] <Company> well, they need to know stuff about X - either implicitly or explicitly
[22:43] <mathrick> Company: like?
[22:43] <Company> not being able to have partial transparency
[22:43] <Company> or that communication isn't instantly
[22:44] sub_pop ([email protected]) joined #gstreamer.
[22:44] <Company> you can never abstract something perfectly
[22:44] <mathrick> Company: yep, but that's unfortunate effect of our world not being perfect. But you should try anyway :)
[22:44] <Company> you can abstract it well, but not perfectly
[22:44] <mathrick> Company: and plugging sound server into kernel is one attempt to do that
[22:44] <Misirlou> Hmm, running autogen.sh in gst-plugins likes to hang on "examples/gstplay/Makefile.am: installing `./compile'".
[22:45] <Company> yeah, but unless someone gets the middleware for sound right, we'Re stuck ;)
[22:45] <mathrick> Company: why do you think my proposal is not "right" ?
[22:46] <BBB> it doesn't belong there
[22:46] <mathrick> BBB: what is "it" ?
[22:47] <BBB> soundserver plugging in the kernel
[22:47] <Company> yeah
[22:47] <BBB> soundserver is one level higher than kernel
[22:47] <Company> the kernel is not the API for a sound server
[22:47] <BBB> you cannot "prepare" the lowlevel for that
[22:47] <BBB> the kernel is a kernel
[22:47] <BBB> and nothing more than a kernel
[22:47] <Company> it doesn't work on solaris or windows
[22:47] <mathrick> BBB: why? kernel's job is to determine who can get work done, and pass it there
[22:47] <BBB> it provides no plugs, and has no idea of anything beyond just that
[22:47] <BBB> the kernel
[22:47] <BBB> mathrick: no, untrue
[22:47] <Company> kernel's job is to abstract hardware
[22:48] <Company> figuring out who can do what is the job of DBUS ;)
[22:48] <mathrick> <Company> it doesn't work on solaris or windows <-- it does work on windows
[22:48] <Company> mathrick: opening /dev/dsp works on windows?
[22:48] <mathrick> Company: no, something similar to transparent server
[22:49] <Company> mathrick: you need an API for your app that's portable
[22:49] <mathrick> Company: you can open card mutliple times, you can send all sound to net - that's one thing windoze got right
[22:49] <mathrick> Company: that's the job of SDL for ex
[22:49] <Company> yeah
[22:49] <Company> but you want the kernel modified
[22:50] <Company> to pass the data back out
[22:50] <mathrick> Company: well, yes and no
[22:50] <mathrick> Company: I want it modified once to never have it modified again :)
[22:51] <Company> that's ok
[22:51] <Company> but that doesn't involve the kernel
[22:51] <mathrick> Company: kernel today is MPlayer, and I want gst :)
[22:51] <Company> it invloves all apps :)
[22:51] <mathrick> Company: using sound server involves them too, even more
[22:51] <Company> yeah
[22:51] <Company> sound servers are required, too
[22:52] <Company> someone tell the MAS guys to write an alsalib backend :)
[22:52] <mathrick> Company: required - yes, exposed - no
[22:52] <Uraeus> didn't Stefan write a generic sound library?
[22:52] <Company> alsalib is a generic sound library
[22:52] <BBB> does anyone have the image of gstplay
[22:53] <BBB> 's pipeline?
[22:53] <mathrick> Company: but still it shouldn't have to care about hw details
[22:53] Action: BBB is getting interesting results
[22:54] <mathrick> Company: like, saying dmix=true (or whatever) on cmdline is extremely ugly for me
[22:54] <BBB> videobalance ! ffcolorspace ! queue ! ... ! ximagesink
[22:54] <BBB> I need to know the ...
[22:54] <BBB> because the ... is f**cking up capsnego
[22:55] <Company> mathrick: edit .asoundrc :)
[22:56] <mathrick> Company: k, still I think lib caring about hw having mixer or not is too low level
[22:57] <mathrick> Company: I want exactly one piece of code worrying about it
[22:58] <Company> mathrick: the lib doesn'T worry about it
[22:58] <mathrick> Company: huh? so what is dmix=true then?
[22:59] <Company> mathrick: dmix is a sound server that alsalib uses
[23:00] <mathrick> Company: if it has to choose sound server, then it has to worry about it
[23:00] <Company> uhm right
[23:01] <Company> everybody has tro do that
[23:01] <Company> not really, you can just use the default
[23:01] <Company> but you can care about it
[23:01] <mathrick> ugh, default == you still choose some value :)
[23:01] <Company> true
[23:02] <Company> even gtk choses the X server
[23:02] <Company> :0
[23:03] <mathrick> I think there is some kind of provision for userspace drivers in new kernel, I probably need to drop by someplace where clueful ppl reside :)
[23:04] <mathrick> Company: you use server the same way, no matter what server you use, so it's not really the same. It's feature, not deficiency
[23:06] Action: BBB tracked down the totem bug!
[23:06] <BBB> yay! \o/
[23:06] Action: BBB moves on to the next bug, which appears to be slow audio playback
[23:06] <BBB> Company: we discussed that a few days ago... do yuo think you understand the exact problem of the one-thread pipelines?
[23:07] <BBB> I'd love to fix that issue
[23:07] <BBB> it's basically my second worst issue in gstreamer right now, and my main reason as for why totem it still useless to me
[23:07] <Company> i'm not gonna think about that
[23:07] <Company> right now
[23:07] <teuf> BBB: is totem usable with the gstreamer backend to watch divx ?
[23:08] <BBB> no, sound is still too slow
[23:08] <BBB> and since sound is actually the clock, video is slow too
[23:08] <BBB> once that's fixed, yes it is
[23:08] <teuf> ok :)
[23:08] <teuf> is divx playback working with gstplayer ?
[23:09] Action: BBB will try random stuff in osssink to fix this
[23:09] <BBB> yes, works for me
[23:09] <BBB> except that it's too slow, as I said
[23:09] <BBB> weird issue in divxdecore is that I get green blocks
[23:09] <BBB> ffdec_mpeg4 doesn't have that
[23:09] <BBB> I might even remove divxdec for that reason
[23:09] <BBB> it's fairly annoying
[23:09] <teuf> ah ok, the slow playback is generic. I thought it might be totem only
[23:09] <sxpert> crap, they want to tax upload to give money to universal
[23:10] <BBB> I'm working on it :)
[23:12] Action: BBB loves it
[23:12] <BBB> this is actually nice
[23:12] <BBB> I open a matroska movie trailer in totem and it just plays wonderfully well
[23:12] <BBB> same for divx
[23:12] <teuf> rock ;)
[23:13] <BBB> MPEG doesn't work really well yet, and quicktime currently crashes
[23:13] <BBB> and slow-sound everywhere
[23:13] <BBB> but this is really really nice
[23:13] <BBB> one bug remaining and we've got a pretty rock-solid player, imo :)
[23:14] Action: BBB will fix those two later
[23:15] <Uraeus> ...one bug remaining...and BBB will fix those TWO :)
[23:15] <sxpert> lol
[23:16] <BBB> should've been "too" ;)
[23:16] <BBB> :p
[23:20] Nick change: harshy -> harshyOut
[23:22] jcsston ([email protected]) joined #gstreamer.
[23:24] <ChrisHJW> BBB : i read your email to ffmpeg-devel
[23:24] <ChrisHJW> i was astonished about Niedermayers reaction
[23:24] <ChrisHJW> he seemed to be quite open
[23:33] sack ([email protected]) left irc: Read error: 54 (Connection reset by peer)
[23:38] kwm ([email protected]) left irc: "Leaving"
[23:45] <BBB> ChrisHJW: you're kidding, right?
[23:45] <BBB> ChrisHJW: niedermayer is an excellent hacker
[23:45] <BBB> ChrisHJW: I knew that he would accept it ;)
[23:46] <BBB> ChrisHJW: I was more astonished by the fact that felker or other sarcasts were so quiet... I think they actually saw that the code is quite good :)
[23:46] <BBB> but it's cool to see that they're willing to accept the patch... I'll finish it up right after GStreamer 0.8.0 is released (monday)
[23:47] <sxpert> BBB: what does the patch patch ?
[23:48] <Uraeus> night guys
[23:48] Uraeus ([email protected]) left irc: "Client exiting"
[23:48] <BBB> adds matroska support to ffmpeg
[23:48] <BBB> (ports the gstreamer ffmpeg demuxer to ffmpeg)
[23:49] <sxpert> ah, nice ;D
[23:49] <BBB> a favour to chris and the matroska team :) I sort of like their format and use it a lot internally
[23:49] <BBB> so it might turn out to be useful in the end
[23:49] <BBB> and it wasn't much work
[23:49] markey ([email protected]) left irc: "nite :)"
[00:00] --- Sun Mar  7 2004
[00:04] teuf ([email protected]) left irc: "Client exiting"
[00:04] ChrisHJW ([email protected]) left irc: Read error: 110 (Connection timed out)
[00:05] TD ([email protected]) joined #gstreamer.
[00:05] TD ([email protected]) left #gstreamer ("Leaving").
[00:32] <wheels> Hmm, what version of libtoolize do folks have that's actually working with currest Gst?
[00:33] <wheels> (It requires > 1.5 so it  won't build with the one that I had, but not it's not working with 1.5.2 either...)
[00:33] Action: bitshifter has 1.5.2 (debian sid) and it's working fine here (gstreamer and gst-plugins)
[00:33] <wheels> hmm
[00:37] Action: walters has 1.5 from FC1, it works fine
[00:40] <mathrick> nite
[00:41] Nick change: mathrick -> mathrick|sleep
[00:45] Action: wheels does a cvsclean to see if things improve...
[00:47] tromey ([email protected]) left irc: Client Quit
[00:47] tromey ([email protected]) joined #gstreamer.
[00:50] steveb_ ([email protected]) joined #gstreamer.
[00:50] BBB ([email protected]) left irc: Read error: 110 (Connection timed out)
[00:51] <wheels> ../../libtool: s%^.*/%%: No such file or directory
[00:51] <Company> ?!
[00:52] <Company> sounds weird
[00:52] <wheels> Yeah, I'
[00:52] <Company> you probably did rerun autogen?
[00:52] <wheels> ve never seen an error quite like it...
[00:52] <wheels> Company: Yeah, the "cvs-clean" script that I use removes all files not in the repository...
[00:54] <Company> i've built gst with both 1.5 and 1.5.2 libtool
[00:55] <wheels> Hmm, interesting -- if I remove the libtool in the gstreamer dir and link that to my installed libtool it works...
[00:56] <walters> wheels: shouldn't your script remove libtool, since it's not in the repo?
[00:56] <Company> i'll leave figuring that one out to you
[00:59] <wheels> Ah, it does -- but I think I figured it out.  I have a separate dir for buildutils that aren't shipped with my distro (/opt/buildtools) where I have libtool 1.5 -- however the Gtr build thinger doesn't copy the one from $PATH, but aparently prefers /usr/bin/libtool...
[00:59] <wheels> s/Gtr/Gst/
[01:05] <wheels> walters: Oh, and one thing that I meant to mention to you -- first -- thanks for the hack to make the debug line not barf on older GCCs, but since it defines the debugging line to nothing and there's an argument you get a warning with "statement has no effect", that combined with -Werror causes problems for fairly obvious reasons...
[01:06] bitshifter ([email protected]) left irc: "bye"
[01:08] steveb__ ([email protected]) left irc: Read error: 110 (Connection timed out)
[01:09] <walters> hmm
[01:09] <walters> oh
[01:09] <walters> bother.
[01:10] <walters> i can't think of an easy way to fix it
[01:14] <Company> i can
[01:16] <walters> what's that?
[01:18] <walters> Company: ok, that should work
[01:18] <Company> why don't you use #ifdef G_HAVE_ISO_VARARGS btw?
[01:19] <walters> dunno, didn't know about that :)
[01:19] <walters> oh
[01:19] <walters> one thing to consider is that other compilers might not know about inline
[01:20] <Company> you can use G_INLINE or something
[01:20] <walters> inline only appeared officially in C99 IIRC
[01:21] <Company> G_INLINE_FUNC
[01:22] <wheels> Are you just worried about the symbol being exported?
[01:22] <walters> well no, static should take care of that
[01:22] <wheels> That's what I thought...
[01:22] <walters> i was just worried about compilers barfing on an unknown keyword
[01:22] <Company> it's the normal way to fix varargs problems
[01:22] <Company> declare a static inline function in the header
[01:23] <Company> we need to do it with gst when we port it to windows
[01:23] Action: wheels doesn't really understand why one would usually prefer a macro to a static inline function, but that's the C++ guy in me coming out...
[01:23] <Company> s/we/they/ ?
[01:24] <walters> wheels: mostly because of differences in the way C compilers implement "inline"
[01:24] <Company> macros are more powerful, too
[01:24] <walters> hm also
[01:24] <walters> wouldn't __FUNCTION__ get clobbered by a static inline?
[01:25] <Company> yeah
[01:25] <Company> that's ehy I used "" in rb_debug :)
[01:25] <walters> actually i think that was the whole point of using a macro in the first place
[01:25] <walters> instead of just a varargs function
[01:26] <wheels> walters: Well, with C++ it's still mostly up to the compiler to decide when to optimize -- it just is kind of a request to consider it more carefully.  :-)
[01:27] <Company> yeah, and gcc added a "must_inline" thing for Linux
[01:27] Action: wheels notes that the biggest OSS flamewar that  he's ever seen was on the semantics on inline on the gcc list.
[01:27] <wheels> ~400 mails
[01:29] <walters> Company: do you want to send me a ssh v2 public key so i can give you direct arch commit access?
[01:29] <wheels> walters: But in KDE the way that we do it (well, not really, but close enough) is to have just the function name expanded out by a macro and do the debugging with a function.
[01:29] <wheels> So there's k_funcinfo:
[01:29] <wheels> #ifdef __GNUC__
[01:29] <wheels> #define k_funcinfo "[" << __PRETTY_FUNCTION__ << "] "
[01:29] <wheels> #else
[01:29] <wheels> #define k_funcinfo "[" << __FILE__ << ":" << __LINE__ << "] "
[01:29] <wheels> #endif
[01:29] <wheels> s/macro/define/
[01:29] <Company> walters: i think I sent you one already
[01:30] <Company> walters: but i'm still afraid of arch ;)
[01:30] <walters> Company: oh, you did, and you're already in the keyring.
[01:30] <walters> Company: do you have a gpg key?
[01:32] <Company> nope, not yet
[01:32] <walters> ok.  at the moment we're requiring commits to be signed
[01:32] <walters> but you should really have a gpg key anyways :)
[01:36] <Company> dunno, i never needed one
[01:36] ChriHJW_log ([email protected]) joined #gstreamer.
[01:39] <walters> Company: well, i'm a big crypto proponent :)
[01:39] <Company> i know
[01:39] <Company> i'm not against it i just never had the need
[01:39] pb_ (~pb@2002:5160:45ef:0:240:95ff:fe30:aa84) left irc: "Client exiting"
[01:40] <walters> signed revision control in particular solves the problem of people breaking into sites like savannah and trojaning source.
[01:40] ChrisHJW_log ([email protected]) left irc: Read error: 60 (Operation timed out)
[01:40] <walters> i use gpg to encrypt all my backups
[01:40] <Company> yeah
[01:40] <walters> and sign my mails
[01:41] <walters> i still hope for a future where everyone signs mail.  it makes spam filtering much easier :)
[01:42] <Company> as long as the tools are easy to install
[01:42] <wheels> walters: In the Linux world it's still getting to the point that the mail client really are just starting to make it easy...
[01:43] Action: wheels held out until about a year ago...
[01:43] <walters> i guess
[01:43] <walters> evo has done it for a while now
[01:43] <Company> i don't use evo
[01:43] <wheels> walters: Yeah, for KMail I still had to actually read the HOWTO when I set it up...
[01:43] <walters> gnus and mutt have both done it for a long time
[01:43] <Company> i use webmail, pine and sometimes evo
[01:43] <wheels> walters: Well, "support" is different from "making it easy"
[01:43] <walters> although mutt's support was kind of crappy for a while
[01:44] <wheels> walters: Like it's really easy once you have it setup in KMail, but it took me maybe an hour or two to get it up and going...
[01:45] <walters> looks like yours are still inline
[01:45] <Company> what people still don'T get is that i use email as a server based message store and not as an advanced IM tool
[01:46] <Company> so as much as possible must be serverside, because I use loads of different frontends to access it
[01:51] <iain> Company: so, this fixate function. the idea is that when the sink pad is connected, I store the number of channels, and then the srcpad's fixate function will fixate the caps to that number of channels?
[01:51] <Company> iain: the idea is that a fixate function selects the best caps out of all possible caps
[01:52] <Company> iain: if you have possible caps like audio/raw,channels=[1,2] you need to select somehow which is the best one
[01:53] <iain> Company: so the trick is to work out how to select the best one
[01:53] <Company> iain: the stupid core fixate function always fixates to 0 (or as close to as possible)
[01:53] <iain> okay, which is why channels == 1
[01:53] <Company> iain: yeah, that's basically what it does - audio fixate functions select 44100/2/16 most of the time
[01:54] <iain> so if I try to fixate to 2 channels, if the input is mono, then it'll fixate to 1?
[01:54] <Company> yeah
[01:55] <iain> shouldn't be too hard to do then
[01:55] <Company> yeah, it's dead easy to code
[01:55] <Company> there are those support functions like gst_caps_structure_fixate_nearest_int
[01:55] <iain> yeah, I saw that in the osssink one
[01:56] <Company> the only thing you need to make sure is that you return a more fixed caps then the one given to you
[01:56] <iain> should it be a fixate for the sink or the src?
[01:56] BBB ([email protected]) joined #gstreamer.
[01:56] <Company> normally only endpoints should fixate, and only when they know exactly what they do
[01:56] <Company> src fixate functions are called before sink fixate functions
[01:57] <Company> and apps can connect to the fixate signal
[01:58] <iain> it should be a src one then, because we need to know what the sink's channels are?
[01:58] <Company> where do you need it anyway?
[01:59] <iain> audioconvert
[02:00] <Company> audioconvert should try float first, if that's not possible, try 44100/2/16
[02:01] <iain> ok
[02:01] <iain> on the sink or the src? (I'm thinking src?)
[02:01] <Company> on both sink and src probably
[02:01] <iain> oh, ok
[02:02] <Company> in theory it shouldn't need one at all
[02:02] <Company> but in practice that looks different probably ;)
[02:05] <Company> audioconvert is supposed to be symmetric anyway
[02:08] <iain> right, I'll hack that up sometime and see
[02:08] <BBB> I like that idea, company
[02:08] <BBB> to only let 'src' and 'sink' *elements* have/allow fixation
[02:09] foser ([email protected]) left irc: "[ I want to believe ]"
[02:09] <BBB> that'd work as quite a nice fix for the issues we're seeing right now
[02:09] <BBB> :)
[02:09] <Company> not really
[02:09] <Company> it has some issues with converter elements
[02:11] <BBB> er... I think I get it, sort of, but can you still give an example of such an issue?
[02:11] Action: BBB trying to understand
[02:13] <Company> videodec ! colorspace ! ximagesink
[02:14] <Company> if the colorspace element doesn't fixate the colorspace ! ximagesink link, you might end up with something really bad
[02:14] <Company> it's not so bad with video, more with audio
[02:14] <Company> audiodec ! audioconvert ! osssink
[02:15] <BBB> 'bad' as in low-quality?
[02:15] <Company> i need to expand that example
[02:15] <Company> ... spider ! osssink
[02:15] <BBB> or 'bad' as in undefined results?
[02:15] <Company> plugged as:
[02:15] <Company> audiodec ! audioconvert ! spideridentity ! osssink
[02:16] <Company> the audioconvert ! spideridentity does a fixation for the converted format
[02:16] <Company> if neither has a fixate function, it fixates to 1 channel, 8 bit, 800kHz
[02:16] <Company> 8000kHz
[02:16] <Company> 8000Hz
[02:16] <Company> now i got it
[02:16] sub_pop ([email protected]) left irc: "Client exiting"
[02:17] <iain> maybe thats why rb decides that all my ogg files are like 16000 seconds long
[02:21] <BBB> Company: of course, but isn't that the reason that the osssink will fixate to 44,1kHz?
[02:21] <BBB> I mean, you 'forward' the fixation, right?
[02:21] <BBB> (I presume?)
[02:26] Action: BBB cheers
[02:26] <BBB> I've just played a first movie that actually *worked* in totem
[02:27] <Company> BBB: no, we don't forward fixations
[02:27] <Company> the fixation thingy is a bit in flux because it is a new idea
[02:29] <BBB> no no, I know we don't
[02:29] <BBB> but you *want* to do that, no?
[02:30] <BBB> or are there good reasons not to?
[02:30] <BBB> (forward *part* of the fixation is also forwarding in this terminology, just like converters implement getcaps functions)
[02:30] alley_cat ([email protected]) left irc: Read error: 60 (Operation timed out)
[02:30] <Company> dunno
[02:31] <Company> i'll leave coming up with an idea how to handle that to ds-work
[02:31] <Company> problem is that this needs to be threadsafe in the end...
[02:31] Action: BBB thinks he found a clocking problem in osssink
[02:32] Action: BBB hopes he can fix this so he solved his last libgstplay issue :)
[02:35] NFusi0n ([email protected]) joined #gstreamer.
[02:36] iain ([email protected]) left irc: "leaving"
[02:37] <walters> it'd be cool too if rb could start using the sink clock
[02:37] <walters> does libgstplay do that?
[02:38] <BBB> totem
[02:38] <BBB> er
[02:39] <BBB> dunno
[02:39] <BBB> for what?
[02:40] <walters> keeping track of the current song time
[02:41] <BBB> oh...
[02:41] <BBB> why don't you just query the source element?
[02:41] <BBB> that's what gstrec does
[02:41] <walters> hm
[02:41] <walters> query it like every second or something?
[02:41] <Company> yeah
[02:41] <BBB> no
[02:41] <walters> heh
[02:41] <BBB> on every iterate signal
[02:41] <BBB> sounds like a lot of overhead
[02:42] <BBB> but it's really lightweight, actually
[02:42] <Company> gst-player does that
[02:42] <BBB> gst-rec, too
[02:42] <BBB> it's a bit crappy maybe, but it works nice
[02:42] <Company> you need to figure out the correct sink from gconf though
[02:42] <walters> what i need to look into is converting rb to gstplay.
[02:42] <Company> gstplay is purely video atm
[02:42] <Company> i think
[02:43] <BBB> yeah
[02:43] Action: BBB thinks so too
[02:43] <Company> GstPlay needs a nice object hierarchy
[02:43] <BBB> gstplay is imo a bit too heavy (as in overhead, call it 'bloat' if you wish) for RB
[02:43] <walters> in what sense?
[02:44] <BBB> maybe you can make gstplay a nice set of objects, walters? :)
[02:44] <BBB> well, it's currently one big struct
[02:44] <BBB> it's a GstElement, which is good
[02:44] <BBB> it needs to behave as a pipeline, basically
[02:44] <BBB> GstRec, for example, *is* a GstPipeline
[02:44] <Company> i don't really like the fact that it's an element
[02:44] <BBB> it shouldn't be an element in that sense... it should be a GstPipeline imo
[02:44] <BBB> that's essentially what it does, no?
[02:45] <Company> even a GstPipeline is an element...
[02:45] <Company> dunno
[02:45] Action: BBB likes it
[02:45] <BBB> anyway, it needs more like that
[02:45] <Company> i would only make it an element if i wanted to put it in pipelines
[02:45] <BBB> and the whole pipeline as used internally is so full of stuff... in the end, it needs to be simplified
[02:45] <BBB> not 50 elements
[02:45] <Company> or at least if i thought of that as a possibility
[02:45] <BBB> pipeline is an element...
[02:46] <Company> yes
[02:46] <Company> but pipeline behaves like an element
[02:46] <Company> i dunno what GstPlay does if you call gst_element_* functions on it
[02:46] <BBB> I think the idea - in the end - is that you can do that
[02:46] <BBB> on gst-rec, you can
[02:47] <BBB> the application actually does gst_element_set_state (rec, GST_STATE_PLAYING) to start recording
[02:47] <Company> yeah
[02:47] <Company> but that's about it
[02:48] <Company> it intercepts all signals
[02:48] <Company> it manages the whole pipeline itself
[02:48] <Company> it exports no pads and you can't make it do that
[02:48] <BBB> so does a pipeline
[02:48] <Company> a pipeline can export pads and doesn't intercept signals
[02:48] <BBB> neither does gst-rec...
[02:48] <BBB> and neither *should* gst-play
[02:49] <Company> no, it shouldn't
[02:49] <BBB> (again, all imo)
[02:49] <BBB> (others might have different ideas)
[02:49] <Company> that's why i think it shouldn't be an element either ;)
[02:49] <BBB> heh :)
[02:49] <Company> elements are those building blocks that you connect
[02:49] <BBB> I see an element as more than that
[02:49] <BBB> also given that cdplay, bin, thread, pipeline are all elements
[02:50] <BBB> anywya
[02:50] <BBB> mayeb a nice discussion thing for 0.9.x
[02:50] <BBB> Company: I need your help a bit
[02:50] <Company> yeah
[02:50] <BBB> something that you might know
[02:50] <Company> you won't get much help
[02:50] <BBB> ?
[02:50] <Company> i'm in idle mode
[02:50] <BBB> you're not ;)
[02:50] <Company> it's 3am here ;)
[02:51] <Company> well, close to
[02:51] <BBB> oh, right
[02:51] <BBB> sorry, forgot about that
[02:51] <BBB> tomorrow then? ;)
[02:51] <Company> just ask, but don't expect me to dive in
[02:51] <Company> i'm away the next 2 days
[02:51] <Company> s/2/6/
[02:52] <Company> you can pretty much count work as being away, too :/
[02:52] <BBB> gstosssink.c:gst_osssink_get_delay() often returns negative values... I believe that's the reason that clocking breaks so easily in osssink... if I change the function to always return 0, all my failing test pipelines suddenly work... any idea on what's going on? :)
[02:54] <BBB> (and totem rocks if I change that function to return 0
[02:54] <Company> hm
[02:55] <Company> i dunno what SNDCTL_DSP_GETODELAY does
[02:55] Action: BBB looks in specs
[02:59] <BBB> anyway... this sucks ;)
[02:59] Action: BBB will try to fix
[02:59] <Company> uh
[02:59] <Company> in get_time


-------------------------------------------------------
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click