[gst-devel] Daily IRC logs

[wim.taymans at chello.be]

[07:10] omega_ (omega at omegacs.net) joined #gstreamer.
[07:40] <taaz> hey omega_ 
[07:40] <omega_> yo
[07:40] <taaz> get that dv stuff working?
[07:40] <omega_> mostly
[07:41] <omega_> odd bug right now
[07:43] <taaz> anything worth explaining?  you know as soon as you explain it the fix will be obvious ;)
[07:45] omega_ (omega at omegacs.net) left irc: Ping timeout for omega_[omegacs.net]
[08:33] Nick change: taaz -> taazzzz
[08:38] kevin_ (kevin at lyon-185-248.stures.iastate.edu) joined #gstreamer.
[08:39] kevin_ (kevin at lyon-185-248.stures.iastate.edu) left irc: [x]chat
[08:39] puetzk (kevin at lyon-185-248.stures.iastate.edu) joined #gstreamer.
[08:42] <puetzk> hmm, looks sleepy in here :-)
[08:44] <puetzk> anybody alive in here?
[09:08] steveb (steveb at node1ee31.a2000.nl) joined #gstreamer.
[09:15] steveb (steveb at node1ee31.a2000.nl) left irc: Ping timeout for steveb[node1ee31.a2000.nl]
[09:24] steveb (steveb at node1ee31.a2000.nl) joined #gstreamer.
[10:25] steveb (steveb at node1ee31.a2000.nl) left irc: Ping timeout for steveb[node1ee31.a2000.nl]
[10:27] steveb (steveb at node1ee31.a2000.nl) joined #gstreamer.
[11:17] puetzk (kevin at lyon-185-248.stures.iastate.edu) left irc: [x]chat
[11:35] steveb (steveb at node1ee31.a2000.nl) left irc: Ping timeout for steveb[node1ee31.a2000.nl]
[11:54] Nick change: richardb-away -> richardb
[12:07] Uraeus (cschalle at c224s9h5.upc.chello.no) joined #gstreamer.
[12:07] <Uraeus> hi
[12:10] <richardb> Morning.
[12:11] <richardb> How's the gnome summary stuff coming together?
[12:12] BBB-zZz (BBB at ucu-105-116.ucu.uu.nl) left irc: Ping timeout for BBB-zZz[ucu-105-116.ucu.uu.nl]
[12:14] <Uraeus> richardb: good, getting more submissions than I dared hope for
[12:20] Action: richardb breaks all plugins again
[12:20] <richardb> :)
[12:26] BBB-zZz (BBB at ucu-105-116.ucu.uu.nl) joined #gstreamer.
[12:29] <Uraeus> richardb: please don't break 'em when I am planning to put them into the GNOME summary :)
[12:51] Nick change: Uraeus -> Ura_away
[13:20] Ow3n (owen at ti34a80-0979.bb.online.no) joined #gstreamer.
[13:20] <Ow3n> yo.
[13:32] steveb (steveb at node1ee31.a2000.nl) joined #gstreamer.
[14:09] Nick change: BBB-zZz -> BBB-[away]
[14:09] Action: BBB-[away] is away: visiting parents
[15:11] richardb (richard at ixion.tartarus.org) left irc: 9) nanoseconds
[16:10] Ow3n (owen at ti34a80-0979.bb.online.no) left irc: [x]chat
[16:11] BBB-[away] (BBB at ucu-105-116.ucu.uu.nl) left irc: Ping timeout for BBB-[away][ucu-105-116.ucu.uu.nl]
[16:12] BBB-[away] (BBB at ucu-105-116.ucu.uu.nl) joined #gstreamer.
[16:22] steveb (steveb at node1ee31.a2000.nl) left irc: [x]chat
[16:23] <wtay-zZz> we need to test the wiki
[16:28] steveb (steveb at node1ee31.a2000.nl) joined #gstreamer.
[16:28] Nick change: wtay-zZz -> wtay
[16:28] <wtay> yo
[16:28] <steveb> hi
[16:28] <steveb> i have just bought a new camera
[16:28] <wtay> dv?
[16:28] <steveb> and am ready to test it
[16:28] <steveb> yeah - a dynalink webcam
[16:29] <steveb> CPiA driver (in theory :)
[16:29] <wtay> cool
[16:29] <steveb> whats the easiest way to test it with gstreamer?
[16:30] <wtay> v4lsrc?
[16:30] <steveb> bah, have to recompile gstreamer first
[16:46] richardb (richard at ixion.tartarus.org) joined #gstreamer.
[16:46] <wtay> hi
[16:46] <richardb> hi
[16:46] <richardb> had a chance to take a look at BRANCH_PLUGINVER1 yet/
[16:46] <richardb> ?
[16:47] <wtay> hmm, no...
[16:47] <steveb> what is the Xv library and where can I get it?
[16:47] <richardb> never mind. ;-)
[16:47] <wtay> it comes with XFree 4.0
[16:47] <wtay> richardb: but I agree with the way you do things
[16:47] <steveb> building xvideosrc says it can't find a shared version
[16:47] Action: wtay is working on mpeg encoding
[16:47] <wtay> steveb: what version do you have?
[16:49] <steveb> wtay: erm 4.something - how can I tell :?
[16:49] <wtay> xdpyinfo?
[16:50] <steveb> vendor release number 4002
[16:51] <wtay> hmm, same here, I remember early versions did not ship a .so lib
[16:53] <steveb>  /usr/X11R6/lib only contains a libXv.a
[16:53] <wtay> yeah, that's the problem
[16:53] <wtay> -rwxr-xr-x    1 root     root        14283 Feb 20 00:30 libXv.so
[16:54] Action: steveb doesn't want to upgrade X right now :(
[16:55] <wtay> steveb: what version of libtool do you have (libtool --version)
[16:56] <steveb> 1.3.5
[16:56] <wtay> what exactly is the error?
[16:58] <steveb> running gstreamer-register gives me an undefined symbol XvQueryExtension
[16:58] <wtay> oh
[16:59] <wtay> what does configure say about Xv?
[17:02] <steveb> XvQueryExtension in -lXv... (cached) yes
[17:02] <wtay> hmm
[17:03] <wtay> strange
[17:03] <steveb> would installing this help? I have RH6.2 http://rpmfind.net/linux/RPM/rawhide/1.0/i386//RedHat/RPMS//XFree86-devel-4.0.3-1.i386.html
[17:04] <wtay> I have no idea.. I think so
[17:04] <steveb> I guess I should just upgrade X proper from xfree86.org
[17:05] <wtay> yeah
[17:39] Nick change: taazzzz -> taaz
[17:39] <taaz> i think xfree86 tree still only builds a static Xv lib
[17:40] <taaz> one of the livid people convinced redhat to distributed a shared lib though.... i don't think they shuold be doing that
[17:41] <steveb> right now i'd just like to prove my camera works - i'm trying xawtv at the moment without success. any other suggestions?
[17:59] sienap (ircbak at ipc379c18b.dial.wxs.nl) joined #gstreamer.
[17:59] <sienap> wtay!
[17:59] <wtay> yo
[18:02] <sienap> hej is it possible to play avi with the current CVS ?
[18:02] <sienap> and better.. rip out the audio..
[18:02] <wtay> for me it is
[18:02] <sienap> he
[18:02] <sienap> nice ;)
[18:02] <wtay> you'll need Xv
[18:02] <sienap> then i will check it out tomorrow
[18:02] <sienap> he damn
[18:02] <sienap> why Xv ?
[18:02] <wtay> 'cause capsnego doesn't work
[18:07] <sienap> he
[18:07] <sienap> ic
[18:07] <sienap>  :)
[18:19] sienap (ircbak at ipc379c18b.dial.wxs.nl) left irc: sienap has no reason
[18:21] steveb (steveb at node1ee31.a2000.nl) left irc: [x]chat
[18:40] Nick change: wtay -> wtay-away
[18:53] hjames (hjames at proxy3.cc.stevens-tech.edu) joined #gstreamer.
[18:54] puetzk (kevin at lyon-185-248.stures.iastate.edu) joined #gstreamer.
[18:55] <puetzk> hi
[18:56] omega_ (omega at omegacs.net) joined #gstreamer.
[18:57] Action: puetzk looks at the mpg123 README - is this just really out of date, or is the mpg123 lib pretty dysfunctional?
[18:57] <omega_> it is
[18:57] <omega_> mpg123 is actually pretty dysfunctional, in general
[18:58] <omega_> it's got a lot off issues and fragility: endianness, alignment, floating-point, globals, etc.
[18:58] <puetzk> hmm, OK
[18:58] <puetzk> darn :-)
[18:58] Action: puetzk is working on an mpg123_artsplug for native artsd
[18:59] <puetzk> and your deglobalized lib seemed like such a nice touch
[18:59] <puetzk> hmm...
[18:59] <omega_> but it didn't work fully
[18:59] <omega_> there are still problems with runing two mpg123's
[18:59] <puetzk> OK
[18:59] <omega_> so the solution was libmad
[19:00] <puetzk> just to use a different one?
[19:00] <omega_> I'm inclined to not put any more work into mpg123, but focus on getting libmad optimized (both API and speed)
[19:00] <puetzk> does mad sound as good as mpg123?
[19:00] <omega_> decoders really have almost zero effect on playback quality
[19:01] <omega_> though I can dig out a link to a comparison for you, sec..
[19:01] <puetzk> well, mpeglib sounds like arse :_)
[19:01] <puetzk> which is the only one arts has native support for :-)
[19:01] <puetzk> which is what originally made me write an mpg123 artsplug
[19:01] <omega_> heh
[19:03] <omega_> hrm, not finding it with lynx (I'm stuck in text for the moment)
[19:03] <omega_> said link is in the mad-dev mailing list archives (mad.sourceforge.net)
[19:03] <omega_> somewhere in the last 3-4 months
[19:03] <puetzk> OK
[19:04] <puetzk> I've got my mpg123 plugin handling concurrent playback now, but my solution isn't pretty :-)
[19:05] <puetzk> instead of using a thread to decode, I used a full-blown fork() :-)
[19:05] <puetzk> would like to see that go away
[19:06] <omega_> ick
[19:06] <omega_> are you up to doing the same level of work I did to objectify mpg123?
[19:06] <puetzk> hehe
[19:06] <puetzk> I haven't yet
[19:06] <omega_> cause if you are, it's still a project that needs to be done
[19:06] <puetzk> as the fork() isolates it
[19:06] <omega_> it's a good week of work
[19:06] <puetzk> but in the long run, it would be nice
[19:06] <puetzk> tho maybe I'll look into mad
[19:07] Action: omega_ is goign to write up a document describing ideas on how to design codec APIs
[19:07] <puetzk> the real drive is not that specifically want mpg123, but that mpeglib suck horifically
[19:07] <omega_> every codec out there has a different and wholly incompatible API, afaict
[19:07] <puetzk> yeah
[19:07] <puetzk> mpg123's is miserable
[19:07] <omega_> it has some advantages, but IMO they can be folded into mad
[19:08] <puetzk> any specifics?
[19:08] <omega_> well, the asm for one
[19:08] Action: puetzk isn't on x86 anyway :-)
[19:08] <omega_> but I've got another project I think should be the basis of those speedups
[19:08] <omega_> see codecs.org
[19:08] <puetzk> but others are
[19:08] <omega_> the libcodec project
[19:09] <omega_> the idea is a single library with all the math kernels, implemented in as many optimized forms as possible
[19:09] <puetzk> could be good
[19:09] <omega_> then any codec can use those routines, and automatically specialize/optimize for a given arch, for as many kernels as there are faster impls of
[19:10] <omega_> I can speed up my ground-up MPEG1video decoder by 2-3x just by putting a couple lines of code in to turn on SSE
[19:10] <puetzk> does MAD do VBR, seeking, etc?
[19:11] <omega_> I dunno if it does seeking, but at least for gstreamer, that's not the decoder's job
[19:11] <omega_> VBR it does better than any other decoder
[19:11] <omega_> MAD is the only decoder that can fully implement free-rate mp3's
[19:11] <puetzk> oh, you feed it block at a time?
[19:11] <puetzk> so you seek for it?
[19:11] Action: omega_ doesn't know what the MAD api is yet
[19:11] <omega_> but with gstreamer, there's a separate element that's responsible for seeking, usually
[19:12] <omega_> though not always, it could be folded into the decoder
[19:12] <omega_> the key is VBR+seeking is very hard
[19:12] Action: puetzk reads the compliance tests
[19:12] <puetzk> omega_: not really.
[19:12] <puetzk> you just have to have a Xing header
[19:12] <omega_> to do it accurately, it is
[19:12] <puetzk> and interpolate based on that
[19:12] <puetzk> oh, too it accurately
[19:12] <omega_> Xing header only gives you 100 points with 1/256 accuracy
[19:12] <puetzk> but who cares about that
[19:12] <omega_> anyone doing editting
[19:13] <puetzk> it's close enough for users
[19:13] <puetzk> is not using mp3's :-)
[19:13] <omega_> for most users, yes, and that's why it'll be default
[19:13] <puetzk> for intermediate storage
[19:13] <omega_> not necessarily, there will be cases where frame-accurate seeking is required from mp3's
[19:13] <omega_> if you're mixing from external sources, you have no control over their format in many cases
[19:14] Action: omega_ starts looking into using reiserfs for root filesystem
[19:14] <omega_> upgrade from 12gb to 20gb drive, with the 12gb drive taking 5+ min to fsck... ;-(
[19:15] <puetzk> so how matures is MAD?
[19:15] <omega_> dunno, it seems relatively mature
[19:15] <puetzk> less the asm optimizations, is it ready to base off of?
[19:15] <omega_> but the author himself says that the API sucks
[19:15] <puetzk> coolness
[19:15] <puetzk> doh :-(
[19:15] <omega_> which is why I'm going to help
[19:15] <puetzk> can't be as bad as mpg123's tho
[19:15] <omega_> no
[19:16] <omega_> er, what mpg123 api?
[19:16] <omega_> <g>
[19:16] <puetzk> exactly
[19:16] <omega_> it is a little slower than mpg123 still, but that's because of the lack of x86 optimizations
[19:16] Action: puetzk ponders
[19:16] <omega_> but with libcodec and pulling bits from mpg123, that's trivially fixable
[19:17] <puetzk> wow, mpg123 isn't compliant as a decoder?
[19:17] <omega_> the trick is to officially pull the bits from xmms, since mpg123 isn't GPL'd, and the mpg123 derivative in xmms *is*
[19:17] <omega_> where are you reading this?
[19:17] <puetzk> omega_: a lot of the files in the CVS mpg123 these days have a /* GPL clean */ at the top
[19:17] <puetzk> I think he's gonna switch :-)
[19:17] <puetzk> http://www.mars.org/home/rob/proj/mpeg/compliance/
[19:17] <omega_> ok
[19:18] Action: puetzk wonders if this means that mpg123 is doing non-compliantthings in a way that happens to be pleasing to the ear
[19:18] Action: omega_ can't read that table in lynx ;-(
[19:18] <puetzk> yse links or 23m
[19:18] <puetzk> w3m
[19:18] <omega_> I doubt it
[19:19] <puetzk> they can render tables fine
[19:19] <omega_> hrm, and calling mpg123 an integer decoder is being a little kind
[19:19] <omega_> afaik
[19:19] <puetzk> hmm?
[19:20] <omega_> sec..
[19:20] <puetzk> a lot of it is fixed-point
[19:20] <puetzk> of course, the silliest part
[19:20] <puetzk> is that at the end, I have to convert it's truncated PCM output back to floats :-)
[19:20] <puetzk> since that's how arts works internally
[19:20] <omega_> there are plenty of doubles in use in mpg123
[19:20] <omega_> for performance, though, fixed point is much much better
[19:20] <puetzk> so the extra bits from mad wouldn't be entirely wasted
[19:20] dobey (dobey at dreadnought.ximian.com) joined #gstreamer.
[19:21] <omega_> for the vast majority of processors, at least
[19:22] Ura_away (cschalle at c224s9h5.upc.chello.no) left irc: syntax error - user imploded
[19:22] <puetzk> well, mebbe I'll try libmad for my streaming rewrite
[19:22] <omega_> yeah
[19:22] <puetzk> it looks promising
[19:22] <puetzk> and I can actually benifit (some) from it's 24bit output
[19:22] <puetzk> at least, I don't immediately truncate it to 16 :-)
[19:23] <omega_> ah, and /me could actually use some of those extra bits on my hardware
[19:23] <puetzk> well, my hardware doesn't do it
[19:24] <puetzk> it will stop later arts effect filters from introducing so many layers of quantization noise
[19:24] <puetzk> as artsd is all float-based internally
[19:24] Action: omega_ has studio sound hardware: 2x 16+16 optical cards, a 16x16 18bit A/D/A
[19:25] Nick change: wtay-away -> wtay
[19:25] <wtay> yo
[19:25] <omega_> yo
[19:25] Action: puetzk listens to the decode samples on the mad-winamp page
[19:25] <wtay> omega_: I've got an mpeg1 encoder ready..
[19:25] Action: omega_ is preparing to do the hd switch
[19:26] <puetzk> hmm... mad has a much more objectionable hiss :-)
[19:26] <omega_> um
[19:26] <puetzk> but sound clearer on top of that
[19:26] <omega_> hmmm
[19:26] <puetzk> (these are intentionally very crippled samples - 8bit)
[19:26] <omega_> ah
[19:26] <puetzk> both have a ton of hiss :-)
[19:27] <omega_> so wtay: there is an interesting issue with 1394...
[19:27] <wtay> omega_: ?
[19:27] <omega_> the way it works is that you give it a callback, and the chain() func calls raw1394_loop_iterate()
[19:27] Action: puetzk decides to give mad a try
[19:27] <omega_> in there, it does hardware I/O stuff, then passes the size/ptr to your callback
[19:27] <omega_> the lifetime of the buffer is *only* that callback
[19:28] <omega_> and a little more, but that's accidental
[19:28] <wtay> ok
[19:28] <omega_> which is a significant problem
[19:28] <wtay> you can't unref it?
[19:28] <omega_> the other issue is that if the 1394 stuff gets behind in any way, it seriously frags the machine
[19:28] <omega_> that's a flaw in raw1394, you don't get to own the buffer
[19:28] <wtay> memcpy?
[19:29] <omega_> and krasic thinks that that's a flaw that raw1394 needs to correct
[19:29] <omega_> yeah, memcpy for now, but that's significant (25mbps)
[19:29] <omega_> well, ok, not significant, but noticable
[19:29] <wtay> yup
[19:30] <wtay> does the playback work?
[19:30] <omega_> sorta
[19:30] <omega_> I have Xv working on my laptop now, btw
[19:30] <wtay> aha
[19:30] <omega_> but last night it hung my machine while quiting from mpeg2dec
[19:30] <wtay> wow
[19:31] <puetzk> Xv is good
[19:31] <wtay> no
[19:31] <omega_> Xv is a horrible design
[19:31] <omega_> the scale is:
[19:31] <wtay> too slow
[19:31] <puetzk> ok, it looks good :-)
[19:31] <omega_> nothing - Xv - ..... - ..... - ..... - ..... - DirectDraw
[19:32] <puetzk> heh
[19:32] <omega_> in terms of API complexity and completeness
[19:32] <puetzk> doh :-)
[19:32] Action: omega_ used DirectDraw for 2 months
[19:32] Nick change: taaz -> taaz-away
[19:32] Action: puetzk installs mad, to compare it's abilities to mpg123's
[19:33] <wtay> mad is pretty good IMO
[19:33] <puetzk> not bad :-)
[19:33] <puetzk> mpeglib is perceptibly bad
[19:33] <puetzk> even at 196 or even higher
[19:34] <wtay> I can't hear that wil my 2inch speakers :-)
[19:34] <wtay> s/wil/with
[19:34] <puetzk> for kde2.2 we have to replace it - period
[19:34] <puetzk> it makes noatun seem like crap
[19:34] <puetzk> wtay: I bet you could
[19:34] <puetzk> mpg123 with 128 or so sounds cleaner than mpeglib at 196+
[19:35] <omega_> so wtay: you have a firewire card yet?
[19:35] Action: puetzk slaps mpeglib
[19:35] <wtay> omega_: I have to go to a shop first...
[19:35] <puetzk> of course ogg sounds better than both
[19:35] <wtay> omega_: I have to leave this PC then :(
[19:35] <omega_> ah. you can get pond.dv from libdv.sourceforge.net, to start with
[19:35] <omega_> wtay: oh
[19:35] <wtay> just kidding :)
[19:35] <omega_> hehehe
[19:35] <puetzk> bass is really freakin sharp
[19:36] Action: puetzk should use one of the tracks he has  wav to go with :-)
[19:36] <omega_> I'll commit the dvdec stuff shortly, maybe 1hr
[19:36] Action: puetzk pets his $20 computer speakers :-)
[19:36] Action: wtay notices that sentences with "w3 n33d" will go to the wiki 
[19:36] <omega_> on no
[19:36] Action: puetzk loves ripping off staples
[19:37] <omega_> that happens live or every night?
[19:37] <puetzk> but god, I can tell mpg123 and mpeglib apart in my mac's internal speaker
[19:37] <wtay> every night, when the IRC logs are mailed
[19:38] <omega_> and they're cat'd onto the end?
[19:38] <omega_> so we can go and add comments to each one, and remove dups?
[19:38] <wtay> omega_: they are send to the wiki
[19:38] <puetzk> oh wow
[19:38] <puetzk> Duel of the Fates is not warbling!
[19:38] <omega_> hehe
[19:38] <wtay> that's how it is done now...
[19:38] <omega_> ok
[19:39] <puetzk> no encoder I've ever used could actually manage this track (I thought):-)
[19:39] <puetzk> maybe it was decoder bugs all along
[19:39] <omega_> hmmm
[19:39] <wtay> omega_: my mpeg1 muxer is broken :(
[19:39] <omega_> wtay: I'm going to try to fix up the HEAD scheduler quickly so it can deal with unconnected pads
[19:39] <puetzk> cpu usage is high though
[19:40] <wtay> omega_: good idea...
[19:40] <puetzk> even higher than mpeglib (which is insane on it's own)
[19:40] <omega_> ppc?
[19:40] <puetzk> yeah
[19:40] <puetzk> and mpg123 owns them all, as usual :-)
[19:40] <omega_> does it compile with any optimization options/
[19:40] <omega_> s/\//?/
[19:40] <puetzk> just -O2
[19:40] <puetzk> so I should tweak that up
[19:40] <omega_> hrm, try -O6
[19:40] Action: puetzk should try building it with gcc3 too
[19:41] <puetzk> gcc3's opt is *so* much better
[19:41] <omega_> you run gcc3 ?
[19:41] <puetzk> sometimes
[19:41] <puetzk> I have both installed
[19:41] <puetzk> so I can pick with CC=gcc-3.0 ./configure
[19:41] <omega_> how do you do that?
[19:41] <omega_> ok
[19:41] <puetzk> debian packages are setup for that
[19:41] <omega_> I might want do do that
[19:41] <omega_> where did you get it?
[19:42] <puetzk> apt-get install gcc-3.0 :-)
[19:42] <puetzk> fairly regular snapshots
[19:42] <wtay> oh cool
[19:42] Action: wtay is apt-getting gcc-3.0
[19:42] <puetzk> note that g++3.0 and g++2.95 are *not* binary compatible
[19:42] <omega_> g++ is *never* binary compatible
[19:42] <puetzk> so you'll have to rebuild any C++ stuff from the libs on up
[19:42] <puetzk> yes, as always
[19:43] <puetzk> but just reminding you that it's true this time again
[19:43] <puetzk> for the last time they're claiming
[19:43] <omega_> and people wonder why I don't use c++.....
[19:43] <puetzk> thankfully
[19:43] Action: omega_ will believe it when he sees it
[19:43] <puetzk> having versioned all the symbols and redone the mangling to be more extensible
[19:43] <puetzk> yeah
[19:44] Action: puetzk tweaks the mad options
[19:44] <puetzk> it shouldn't need twice the CPU of mpg123
[19:44] <puetzk> not on an arch where mpg123 has no asm
[19:44] <wtay> is gcc v3 supposed to be faster?
[19:44] <puetzk> builds (somewhat) slower, but codegen is much faster
[19:44] <wtay> nice
[19:44] <puetzk> mem usage when building C++ is way better
[19:45] <puetzk> ymmv on x86
[19:45] <puetzk> on powerpc it's night and day
[19:45] <wtay> hmm ok
[19:45] <puetzk> it should be better on x86 too
[19:45] <puetzk> but I've yet to really try it there
[19:46] <omega_> great, g++ even slower.......
[19:46] <puetzk> g++ is not slower
[19:46] <puetzk> g++ is faster
[19:46] <puetzk> gcc is slower
[19:46] <omega_> hmm, ok
[19:46] <puetzk> the codegen side of it is slower and better, but g++'s frontend is so greatly improved as to offset that
[19:46] <puetzk> at least for me
[19:46] <omega_> Overflow (620KB tarball) takes 2+hrs to build up to 420MB build tree
[19:46] <puetzk> and the VM usage of g++ is better :-)
[19:47] <wtay> Overflow fails to build here
[19:47] <puetzk> no longer must I have 300 megs of VM to build kapp.cpp :)
[19:47] <puetzk> now it needs like 25
[19:47] <wtay> pff
[19:47] <omega_> what's in kapp.cpp?
[19:47] <puetzk> KApplication class
[19:47] <puetzk> not much
[19:47] <omega_> eesh
[19:47] <puetzk> it has to be some kind of corner case where gcc 2.95.3 just tips over
[19:47] <puetzk> and dies
[19:48] Action: omega_ is going to call Maxtor and get a replacement drive shipped for the one that started squealing
[19:48] Action: puetzk builds with some decent opt flags and gcc3
[19:49] <omega_> maybe maxtor will screw up and give me a 100gb drive <g>
[19:49] <wtay> oh yeah, right
[19:49] <omega_> heeheh
[19:49] Action: omega_ can dream
[19:49] <omega_> just imagine the time it'll take to copy an 80gb drive <g>
[19:49] <omega_> a full one, at that
[19:50] <wtay> omega_: how can I get pond.dv?
[19:50] <wtay> scp?
[19:50] <omega_> that's where I'd be very tempted to a) try a BIOS update, and b) switch down to a Permedia video card; to get the ata100 channels working
[19:50] <omega_> ftp
[19:50] <wtay> from where?
[19:50] <omega_> should be a link on the page, else follow sf's ftp link
[19:50] <wtay> ok
[19:52] <wtay> grr, sf search is broken...
[19:53] <omega_> sourceforge.net/projects/libdv/
[19:53] <omega_> there's also a link to that page from the homepage
[19:53] <omega_> it's 100MB, though <g>
[19:54] <wtay> download has started
[19:54] <wtay> well, not really but..
[19:54] <omega_> not really?
[19:54] <wtay> stalls
[19:54] <omega_> hmm
[19:54] <wtay> pff
[19:55] Action: wtay is using wget now..
[19:56] <wtay> ok, much better now
[19:57] <wtay> hmm, this will take a while :-)
[19:58] <omega_> yup
[19:59] Action: wtay is resuling the download in a small window..
[19:59] <wtay> s/resuling/resuming
[19:59] <wtay> when I get the gst codec/libdv and the test file, I'll try to encode it to mpeg1..
[20:00] Action: puetzk notes that gcc3 bit the big one when confronted with madplay.c
[20:00] <puetzk> what a weird place to die
[20:01] Action: wtay is going to rebuild gst with gcc3
[20:02] <omega_> * wtay is going to have significant amounts of fun
[20:03] <puetzk> nah, c is pretty solid now
[20:03] <wtay> perhaps...
[20:03] <puetzk> c++ is scarier
[20:04] Action: puetzk tries to understand the set of opt optizations on for libmad, and fails
[20:05] <puetzk> he's even got the main scheduler pass off
[20:05] <wtay> hmm, a lot more warnings now...
[20:05] <puetzk> yeah
[20:05] <wtay> nothing serious though
[20:05] <omega_> hrm, /me wonders if we should run lint on gstreamer <g>
[20:06] <omega_> we /me can find lint
[20:06] <wtay> lint?
[20:07] <omega_> yeah, super-anal code checker, picks the lint off of code
[20:08] <wtay> lintian?
[20:08] <puetzk> no, lint
[20:08] <puetzk> the program for which lintian is named in honor
[20:08] <puetzk> scans C code for common errors
[20:08] <wtay> what package name?
[20:08] <wtay> debian I mean
[20:08] <puetzk> basically, the most warning-happy tool it will ever go through
[20:08] <puetzk> 'lint' or 'clint' I'd think
[20:09] <wtay> I have lclint
[20:09] <omega_> lclint from mit
[20:09] <wtay> got it
[20:11] <wtay> grr the padfactory macros don't work...
[20:12] Action: omega_ can't get tar | tar to save *all* the filetimes
[20:13] <omega_> oh well, only a few files got changed, I'll leave it
[20:15] <omega_> ok, now as soon as I get my kernel compiled, installed, and reboot, I put the 20gb drive in and start building that up
[20:15] <wtay> going to use ReiserFS?
[20:15] <dobey> hah
[20:15] <omega_> yeah
[20:15] <dobey> please don't
[20:15] <omega_> why?
[20:15] <dobey> use XFS
[20:15] <dobey> reiser sucks
[20:15] <omega_> is xfs stable and usable daily yet?
[20:16] <dobey> uh, we use it to serve 80 gigs of oggs
[20:16] <omega_> that's nowhere near as hard use as a developer's laptop that crashes a lot due to a buggy laptop BIOS
[20:16] <dobey> heh, we've had to push the reset button a bunch of times
[20:17] <omega_> yes, and how often do you *write* files to this drive?
[20:17] <dobey> uh, like 24/7
[20:17] <omega_> regardless, that's not even the same league
[20:17] <dobey> it's distributed ripping/encoding
[20:17] Action: omega_ can do that on FAT without problems
[20:18] <dobey> and like everyone here who uses exp. fs's uses XFS
[20:18] <omega_> I know reiser works, I've used it, I have never used XFS
[20:18] <wtay> gotta go now, cya later
[20:18] Nick change: wtay -> wtay-snooker
[20:18] <omega_> wtay: already??
[20:18] <omega_> oh
[20:18] <wtay-snooker> yup
[20:19] <wtay-snooker> and I'm allready late...
[20:19] <omega_> hmm
[20:19] Action: dobey cries for omega
[20:20] <omega_> I use what I know works, I'm not gonna go find/install XFS just because
[20:20] <omega_> I'll give it a try later, if it works better, I might switch when I get a new drive
[20:20] <omega_> I have two 80GB drives to try it out on, so..
[20:22] Action: omega_ goes to swap out drives and reboot to 2.4.3
[20:22] omega_ (omega at omegacs.net) left irc: Leaving
[20:48] rdj (rdj at a37030.upc-a.chello.nl) left irc: proud member of the anti movement...
[20:48] omega_ (omega at omegacs.net) joined #gstreamer.
[20:50] hadess (hadess at pc121-gui14.cable.ntl.com) joined #gstreamer.
[20:50] <omega_> yo
[20:50] <hadess> hi gang
[20:51] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[20:52] <dobey> sup foo
[20:53] <hadess> yo dobey
[20:53] <omega_> rdj: how's the bonobo stuff coming?
[20:54] <dobey> sigh
[20:56] <hadess> finally, i have an account on the gnome-cvs =)
[20:57] <dobey> good
[20:59] <hadess> i just need to learn more about _using_ cvs...
[20:59] <omega_> details, details...
[21:00] <dobey> hadess: yeah
[21:12] Action: puetzk profiles mad
[21:12] <hadess> hey puetzk =)
[21:12] <puetzk> hey
[21:12] <hadess> what you doing here ?
[21:13] <puetzk> I came to ask about your cleaned-up mpg123
[21:13] <puetzk> and was told it's dysfunctional and essentially abandoned
[21:13] <hadess> my ?
[21:13] <puetzk> gstreamer's
[21:13] <hadess> oh
[21:13] <hadess> well, yeah, it will need to be cleaned up badly to be usable on ppc
[21:14] <puetzk> so I'm looking into mad
[21:14] <puetzk> no, it's fine on ppc (mpg123 is)
[21:14] <puetzk> but
[21:14] <puetzk> the abuse-of-globals had been cleaned up
[21:14] <omega_> gstreamer's mpg123 is broken on ppc
[21:14] <puetzk> oh :-)
[21:14] <omega_> hadess: you've tried mad ?
[21:14] Action: puetzk wishes mad wasn't *quite* so much slower
[21:14] <puetzk> then this would be a no-brainer
[21:15] <hadess> gstreamer-register crashes on me every time
[21:15] <omega_> where?
[21:15] <hadess> i need to clean up my system
[21:15] <omega_> yes
[21:15] <hadess> lemme check
[21:15] <omega_> do you have installed plugins somewhere?
[21:15] <hadess> INFO(610:-1):gst_plugin_load_absolute:368: loading plugin "/usr/local/lib/gst/libmp3parse.so"...
[21:15] <hadess> ** ERROR **: file gstprops.c: line 216 (gst_props_newv): should not be reached
[21:15] <hadess> aborting...
[21:15] <hadess> Aborted
[21:15] <omega_> rm -rf /usr/local/lib/gst
[21:16] <omega_> if you're running from builddir, *never* install
[21:16] <omega_> all it does is confuse things by having old and new plugins around
[21:16] Action: puetzk compares the synth calls
[21:18] <puetzk> hmm...
[21:19] Action: puetzk sees an opportunity here :-)
[21:19] Action: omega_ sees many opportunities in mad
[21:19] <puetzk> yeah
[21:19] Action: omega_ will spend significant time looking through the mad code to see what kind of structural, API, and speed improvements can be made
[21:19] Action: puetzk tries to remember how postincrement vs. displacement addressing work on PPC (speed wise)
[21:20] <puetzk> cuz that seemt to be the only major differnce between the way mad writes  synth_full
[21:20] <puetzk> and mpg123 writes synth_1_1
[21:20] <omega_> hmmm
[21:20] <puetzk> yet, the former takes 7 seconds longer
[21:20] <omega_> eesh
[21:20] <omega_> well then.
[21:20] <puetzk> (total, while decoding a 5-6 minute song)
[21:21] <omega_> thre's also the dct, which doesn't look very optimal at all
[21:21] <puetzk> the gap there isn't nearly as dramatic though
[21:21] <puetzk> synth_full accounts for almost they entire difference in decode time here
[21:21] <omega_> it will be with mmx dct...
[21:21] Action: puetzk is looking at profiling data
[21:21] <puetzk> yeah, but I don't get mmx dct :-)
[21:22] <puetzk> in either
[21:22] <omega_> true, but you have other options
[21:22] <puetzk> not really
[21:22] <omega_> ppc has a SIMD instr set
[21:22] <puetzk> not on a G3
[21:22] <omega_> oh?
[21:22] <puetzk> for a G4, altivec would be cool
[21:22] <puetzk> but no SIMD on a G3
[21:22] Action: omega_ is confused by the fact that mad has dct32 and mpg123 has dct64
[21:22] <hadess> puetzk: you know ppc assembly ?
[21:23] <puetzk> mpg123 has dcx{12,32,64}
[21:23] <puetzk> hadess: not really
[21:23] <puetzk> oh, wait
[21:23] <puetzk> mpg123 is doing this math floating-point
[21:23] <puetzk> so there's a huge difference
[21:24] <puetzk> that wasn't apparent in the beginning
[21:24] <omega_> puetzk: mpg123 doesn't have dc*32
[21:24] <puetzk> 36
[21:24] <puetzk> sorry
[21:24] <puetzk> 12/36/64
[21:24] <omega_> hrm, ok
[21:24] <omega_> right
[21:24] <omega_> so why does mad have dct32 ?
[21:25] <puetzk> mad also has no others
[21:25] <omega_> um
[21:25] <puetzk> obviously it must do all that math in 32
[21:25] <omega_> dct* is the width of the dct, not the sample size
[21:25] Action: puetzk is looking at his profile graph, not at code
[21:25] <puetzk> so if there are others, mad must never have called them
[21:26] Action: omega_ needs to read up on mp3 again
[21:26] <puetzk> what's III_imcdt_l got in it?
[21:26] Action: puetzk ponders
[21:26] <omega_> hrm, ok, there are imdct_*'s
[21:27] <puetzk> hmm... they must have been inlined
[21:27] <omega_> so what's the dct32 for?? that's the subband count, maybe he's doing filter with the dct??
[21:27] <puetzk> as I'm not seeing them :-)
[21:27] <omega_> III_imdct_l? that's an mpg123 thing
[21:28] <omega_> I thought...
[21:28] <puetzk> eh? that symbol is in my mad profile graph...
[21:28] <puetzk> yeah, it's in mad
[21:28] <omega_> you sure?
[21:28] <puetzk> just checked with grep
[21:28] <omega_> 'III_imdct_' not found
[21:28] <omega_> what file?
[21:29] <omega_> hrm, something isn't working right, it's staring me in the face
[21:29] <puetzk> layer3.c
[21:29] <omega_> ah, grep imcdt....
[21:30] Action: omega_ thinks those could be much optimized
[21:30] <omega_> but /me has to trace all the preprocessor stuff before understanding it
[21:31] Action: puetzk points the finger at synth_full on his machien tho
[21:31] <puetzk> the DCT a close second mind you :-)
[21:31] Action: puetzk oughta profile this on an x86 too
[21:31] Action: puetzk points to his roomate's computer and ambles over
[21:41] omega_ (omega at omegacs.net) left irc: Ping timeout for omega_[omegacs.net]
[23:33] Nick change: taaz-away -> taaz
[00:00] --- Sun Apr 22 2001
[00:08] <richardb> who
[00:08] <richardb> oh, hello. ;-)
[00:08] <puetzk> hi
[00:08] jack (jack at i.cantcode.com) left #gstreamer.
[00:09] <richardb> hadess: did removing your installed version of gstreamer fix the segfault in gstreamer-register?
[00:10] <hadess> i haven't tried it again yet
[00:10] <richardb> I was having that kind of problem, but without installed plugins.
[00:10] <hadess> i think some of the plugins are foobar'ed
[00:10] <richardb> You may need to delete some out of date plugin libraries, too.
[00:11] <richardb> If it segfaults again, delete the one its crashed while trying to load.
[00:11] <richardb> I've added versioning code which fixes this, but it's only in a branch at the moment.
[00:13] <hadess> INFO(6064:-1):gst_plugin_load_absolute:368: loading plugin "/usr/local/lib/gst/libgstparseau.so"...
[00:13] <hadess> Segmentation fault
[00:14] <hadess> and then after removing the libparseau libs
[00:14] <hadess> INFO(6067:-1):gst_plugin_load_absolute:368: loading plugin "/usr/local/lib/gst/libmp3parse.so"...
[00:14] <hadess> ** ERROR **: file gstprops.c: line 216 (gst_props_newv): should not be reached
[00:14] <hadess> aborting...
[00:14] <hadess> Aborted
[00:15] <hadess> and does that for every plugin after if i remove them one by one
[00:15] <richardb> Um, didn't you rm -rf /usr/local/lib/gst/ ?
[00:16] <richardb> I was expecting you to have out of date plugins in the build tree
[00:16] <richardb> as opposed to installed.
[00:17] <richardb> Never mind: it should get fixed with versioning soon, anyway.
[00:17] <richardb> Got to go.
[00:17] Nick change: richardb -> richardb-away
[00:20] <hadess> yep
[00:50] hadess (hadess at pc121-gui14.cable.ntl.com) left irc: mooooh!
[00:51] dobey (dobey at dreadnought.ximian.com) left irc: eh
[00:56] omega_ (omega at omegacs.net) joined #gstreamer.
[00:58] <puetzk> omega_: hi
[00:58] <omega_> yo
[01:05] Action: puetzk pulls out his PPC asm guide
[01:07] <puetzk> if I can get anywhere near the FPM_DEFAULT implementation for MAD_F_MLA for PPC (while retaining more precision) I've essentially caught up to mpg123
[01:07] <puetzk> for PPC :-0
[01:07] <puetzk> fox x86, it will be much harder :-)
[01:08] <omega_> not really...
[01:08] <puetzk> well, mpg123 is more optimized on x86 :-)
[01:08] <omega_> so?  take that code...
[01:08] <puetzk> true :-)
[01:14] rdj (rdj at a37030.upc-a.chello.nl) left irc: Ping timeout for rdj[a37030.upc-a.chello.nl]
[01:15] <omega_> um, how did you get profiling info?? I turned on profiling and get no gmon.out
[01:15] <puetzk> his configure script is broken
[01:15] <puetzk> I added it to the makefile myself
[01:15] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[01:15] <puetzk> (-pg)
[01:16] <omega_> hmm, ok
[01:16] <omega_> I have -pg in my makefile here
[01:16] <puetzk> ?
[01:16] <puetzk> I dunno
[01:16] <puetzk> you have it in the linker flags too
[01:16] <puetzk> ?
[01:17] <omega_> oh?
[01:17] <omega_> I don't think so, maybe
[01:17] rdj (rdj at a37030.upc-a.chello.nl) left irc: proud member of the anti movement...
[01:18] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[01:18] <omega_> oh, I know what I did....
[01:18] <omega_> I used madplay, not ./madplay
[01:18] <puetzk> :-0
[01:19] Action: puetzk ponders
[01:22] <puetzk> ahh...
[01:22] <puetzk> hmm, could be harder to meet this than I thought
[01:22] <omega_> yeah, with the fixed point done the way it is
[01:22] <puetzk> the reason the C FPM_DEFAULT implementation was such a *huge* win over the PPC asm one that was there
[01:22] <puetzk> is that by dropping so much precision of the constants
[01:23] <puetzk> it became possible to use the immediate mode multiply
[01:23] <puetzk> and ditch a load
[01:23] <puetzk> doh :-)
[01:24] <puetzk> I wonder where gcc is putting the constants then, and if they're grouped together well for cache hits
[01:30] <puetzk> wow
[01:30] <puetzk> that can't be a healthy memory access pattern
[01:30] <omega_> which?
[01:30] <puetzk> some of them are getting loaded from scattered points all over th estack
[01:31] <omega_> them?
[01:31] <puetzk> some are getting build up with or immediates...
[01:31] <puetzk> the constants for the DCT
[01:31] <puetzk> (ie, the last thing I was talking about)
[01:31] <omega_> hmmm
[01:31] <puetzk> how they got on the stack is a whole seperate issue
[01:31] <omega_> (you didn't mention dct since I got my laptop up...)
[01:32] <puetzk> oh :-)
[01:32] <omega_> are you getting familiar with the whole structure of mad?
[01:32] <puetzk> somewhat
[01:32] <omega_> we should write up a high-level doc on its structure, then we can optimize from there
[01:32] <puetzk> ther's really only two hot points
[01:32] <puetzk> on PPC
[01:32] <puetzk> and one would fix the other, so there's really only one
[01:33] <puetzk> MAD_F_MLA is behind all evil
[01:33] <puetzk> the C verion of it is ~4 times as fast as the provided PPC asm one
[01:33] <puetzk> but loses too much precision to be a good fix
[01:34] <puetzk> the reason for this appears (the guilty party in III_imdct_l anyway) to be that the second arg to it is often a 32bit constant
[01:34] <puetzk> and that's too long to be an immediate to the multiply instruction
[01:35] <puetzk> so we are spending as many cycles putting those constants together as we are actuallu doing calculations
[01:35] <omega_> too long??
[01:35] <puetzk> ppc's mul instruction only can take a 16bit immediate
[01:35] <puetzk> not a 32
[01:35] <omega_> eew
[01:35] <puetzk> 32, it has to come from a reg
[01:35] <puetzk> RISC, fixed instruction word size
[01:35] <puetzk> 32 is the whole instruction word
[01:35] <puetzk> can't do that
[01:36] <omega_> right, ok
[01:36] <puetzk> and GCC is doing a miserable job of organizing those constants
[01:36] <omega_> afaik alpha has a big enough instr size to hold a 32bit immed for most instructions
[01:36] <puetzk> some are coming from stack, some from sti/ori, they are scattered to the wind
[01:36] <omega_> ick
[01:36] <puetzk> so I assume the cache miss rate is something awful
[01:36] <puetzk> which is probably the core problem :-)
[01:36] <omega_> too bad we don't have good code to figure that out
[01:37] <puetzk> alpha is a 64bit chip
[01:37] <omega_> part of the perf section of libcodec, eventually
[01:37] <puetzk> what cache hit/miss rate?
[01:37] <omega_> yeah, most chips these days have perf regs
[01:37] <puetzk> for that you gotta ask the kernel, and I'm not sure there's an API
[01:37] <omega_> no, you ask the chip
[01:37] <puetzk> maybe you could get it exposed in /proc tho
[01:37] <puetzk> hmm
[01:37] <puetzk> I'd think that was a supervisor reg
[01:37] <puetzk> maybe not
[01:37] <omega_> the problem is that the kernel needs to do per-process save/restore of them if you're going to get accurate numbers
[01:37] <puetzk> anyway
[01:38] <omega_> there exists an x86 patch for that
[01:38] <puetzk> it looks like maybe moving all those constants into a table would be a big win
[01:38] <puetzk> at least then the cache would have a chance
[01:39] <puetzk> to realise that the constants for the DCT deserve a permanent home :-)
[01:39] <omega_> yup
[01:43] <puetzk> hmm...
[01:44] <puetzk> looks like on intel, he only does partial precision too
[01:44] <puetzk> maybe that's more acceptable than I orignally thought
[01:45] <omega_> the implementation of the API is a mess
[01:46] <puetzk> heh, nothing like mpg123's :-)
[01:46] <omega_> what mpg123 api?
[01:46] <omega_> <g>
[01:46] <omega_> well, with the two of us going at it from either end, mad won't suck for long
[01:47] <omega_> geez, this is nasty
[01:47] <puetzk> I'm working mostly on PPC stuff now
[01:47] <puetzk> but once I nail that
[01:48] <omega_> yes, but you are getting familiar with the low-level implementation stuff
[01:48] <puetzk> I'll know enough to identify where others should pounce
[01:48] <puetzk> yeah
[01:48] <puetzk> his DCT ain't half bad
[01:48] <puetzk> if I can fix the multiply
[01:48] <puetzk> I still don't understand how it works, but with a fast (if somewhat inaccurate) mul implementation, it's nearly as quick as mpg123's
[01:49] <omega_> I want to get something like that into libcodec, but the fixed point thing is touchy
[01:49] <omega_> you've measured?
[01:49] <puetzk> yeah, I've got the profiler results
[01:49] <omega_> wow
[01:49] <puetzk> now, it's not quite fair :-)
[01:50] <puetzk> the fast mul I gave it was much faster than the floating point one mpg123 was using :-)
[01:50] <puetzk> mpg123 was still using far less ops :-)
[01:50] <omega_> for the dct? yeah, probably
[01:52] rdj (rdj at a37030.upc-a.chello.nl) left irc: Ping timeout for rdj[a37030.upc-a.chello.nl]
[01:54] rdj (rdj at a37030.upc-a.chello.nl) joined #gstreamer.
[01:55] Action: puetzk times it with -DFPM_64BIT
[01:55] <puetzk> we'll see what gcc can generate
[01:56] <puetzk> OK, GCC's is better than the handwritten one, not by a lot
[01:56] <puetzk> still haven't tried a lookup table
[01:56] <puetzk> so that's up next :-)
[02:24] Nick change: wtay-snooker -> wtay
[02:25] <omega_> yo
[02:25] <wtay> hello again
[02:26] <wtay> gcc3 cannot build the caps macros :(
[02:26] <omega_> oops
[02:26] <wtay> trying to find out why now
[02:29] <omega_> anyone remember what the glibc header is that has glib-style definitions of known-size types (int16, etc.) ?
[02:30] <omega_> stdint.h
[02:33] <wtay> strange... removing the ## from the arg substitution works
[02:33] <omega_> which?
[02:34] <taaz> or inttypes.h
[02:34] puetzk (kevin at lyon-185-248.stures.iastate.edu) left irc: Ping timeout for puetzk[lyon-185-248.stures.iastate.edu]
[02:34] <wtay> in the GST_CAPS_NEW macro definition
[02:34] <omega_> which ## ?
[02:35] <wtay> right before the "a" in gstcaps.h
[02:35] <omega_> hmmmm
[02:35] <omega_> oh, yeah, that makes sense
[02:35] <omega_> sorta
[02:35] <wtay> why?
[02:35] <omega_> um, dunno <g>
[02:35] <wtay> what does the ## mean?
[02:35] <omega_> that's concatenation stuff
[02:36] <wtay> oh yes
[02:36] puetzk (kevin at lyon-185-248.stures.iastate.edu) joined #gstreamer.
[02:36] <puetzk> hmm...
[02:36] <puetzk> OK, table helped there, but not as much as I expected
[02:36] <wtay> -mpentium is deprecated...
[02:36] <omega_> good
[02:37] <puetzk> took off maybe 1/2 second out of 15 or so
[02:37] <omega_> better than nothing
[02:37] <puetzk> yeah
[02:37] <puetzk> but I had the whole process < 8 seconds with the low-precision multiply :-)
[02:37] <puetzk> and I couldn't tell the sound apart
[02:38] <puetzk> I'm almost inclined to take that :-)
[02:38] <omega_> heh
[02:38] <omega_> the problem is that you can't select any time except compile-time
[02:38] <omega_> which is a problem I'll be fixing
[02:38] <puetzk> heh
[02:41] <wtay> omega_: I'd like to mail the mpeg2enc guy too about making a real library out of his code..
[02:41] <omega_> ok
[02:41] Action: omega_ hasn't thought about encoder API, but that's the next logical step
[02:42] <wtay> can you explain in short how you see the ideal API (in general)?
[02:42] <omega_> for an encoder? I have no idea yet
[02:42] <omega_> certainly easier than a decoder API
[02:43] <wtay> hmm
[02:43] <wtay> you prefer callbacks?
[02:43] <omega_> for which?
[02:43] <wtay> like for getting an input frame and for notifying an output buffer etc..
[02:44] <puetzk> omega_: maybe there's still hope
[02:44] <omega_> not for input
[02:44] <omega_> puetzk: ?
[02:44] <puetzk> gcc had betrayed me :-)
[02:44] <omega_> ah
[02:44] <puetzk> and had not built that code at all how I had intended it to
[02:44] <omega_> oops
[02:44] <puetzk> I'd marked the data table static
[02:44] <wtay> hmm, not for input... just send it frames then...
[02:44] <puetzk> static const rather
[02:44] <omega_> wtay: yes
[02:44] <puetzk> and it went ahead and inlined all the constants back in
[02:45] <puetzk> and got rid of my table :-)
[02:45] <omega_> wtay: for video that's easy, since there's a well-defined quantum of data (a frame)
[02:45] <omega_> for audio that's less obvious, and the only examples I know of are vorbisenc and lame
[02:46] <wtay> omega_: mpeg2enc needs the frames in another order than they are displayed, so the encoder should swap them internally?
[02:46] <omega_> yes
[02:46] <omega_> definitely
[02:46] <omega_> just like the decoder swaps them internally
[02:46] <wtay> ok
[02:46] <puetzk> hmm... guess gcc knew best too
[02:46] <omega_> puetzk: heh
[02:47] <wtay> gstreamer still works with gcc3
[02:47] <omega_> good
[02:49] Nick change: omega_ -> omega_dinner
[02:49] Action: wtay is trying libdv on pond.dv
[02:50] <wtay> hmmm
[02:51] <wtay> plugins/Makefile.am:97: required directory plugins/DV does not exist
[02:51] <wtay> fixed
[02:58] Nick change: taaz -> taaz-away
[02:58] <wtay> wow, this is image quality!
[03:20] <omega_dinner> which?
[03:20] Nick change: omega_dinner -> omega_
[03:20] <omega_> fix committed
[03:20] <wtay> cool
[03:21] <wtay> can you also commit the gst_buffer_copy code?
[03:21] <omega_> do you get a mangled image?
[03:21] <omega_> oh, right <g>
[03:21] <wtay> first things first :)
[03:21] <wtay> I also have a fix for the configure.in file
[03:21] <omega_> ok
[03:21] <omega_> commit it
[03:21] <wtay> libm and glib should be linked too for the dv_init check
[03:22] <omega_> ah, ok
[03:22] <omega_> committed
[03:22] <wtay> commited the configure.in
[03:23] <wtay> you also added GST_STR_FOURCC to the caps?
[03:23] <omega_> yes
[03:24] <omega_> committing... <g>
[03:24] <wtay> playdv uses 95 CPU time :-)
[03:24] <omega_> onnly?
[03:24] <wtay> yeah, plays nice
[03:25] <omega_> committed
[03:25] <omega_> btw, _copy in CVS is fragged, dunno how it worked on my machine....
[03:25] <omega_> maybe it didn't <g.
[03:26] <wtay> what do you mean?
[03:26] <omega_> blatantly wrong code
[03:26] <omega_> SIZE(buf) = DATA(buf)
[03:26] <wtay> oh
[03:27] <wtay> fixed
[03:27] Action: omega_ will commit
[03:27] <omega_> hrm, are there *any* uses of GstBuffer->type ?
[03:27] <wtay> I added the _MAKE_FOURCC so that you also could specify bytes like 0x00 etc.. instead of \000 with strings...
[03:28] <omega_> um, that's never used, is it?
[03:28] <omega_> fourcc == four *character* code
[03:28] <wtay> 00000000 is rgb
[03:28] <omega_> then use GST_PROPS_FOURCC(0x00000000)
[03:28] <wtay> true
[03:29] <omega_> see above question ?
[03:29] <wtay> not that I know
[03:29] <omega_> I can't see any cases
[03:29] <omega_> removing
[03:29] <wtay> yup
[03:29] <wtay> pff, full compile
[03:30] <omega_> yeah, well, lemme get _copy fixed up first
[03:30] <wtay> gcc-3.0 feels faster
[03:30] <omega_> at compiling or running?
[03:30] <wtay> both (it's just a feeling)
[03:30] <wtay> I guess that's always the case when you have a new toy :-)
[03:31] <omega_> quite
[03:31] <wtay> do you have a test program for playing something from libdv?
[03:32] <omega_> test/dvshow (update)
[03:34] <wtay> oops failed to link
[03:34] <omega_> which?
[03:34] <wtay> dvshow
[03:35] <wtay> oh and libdv out of the box doesn't work here...
[03:35] <omega_> eh?
[03:35] <omega_> libdv or dvdec ?
[03:35] <wtay> libdv
[03:35] <omega_> how does it break?
[03:35] <wtay> dv.h includes dv_types.h
[03:35] <omega_> and?
[03:35] <omega_> did you get a tarball?
[03:35] <wtay> but the path for _types.h is not in the include path
[03:36] <wtay> it's in /usr/local/lib/libdv/
[03:36] <omega_> what?
[03:36] <wtay> it's in /usr/local/include/libdv/
[03:36] <omega_> ok
[03:36] <wtay> I modified dv.h to include <libdv/dv_types.h>
[03:36] <omega_> libdv shouldn't have any trouble, since it *provides* the header...
[03:37] <wtay> yes, dvdec.c fails to compile
[03:37] <omega_> hmm, ok
[03:37] <omega_> odd
[03:37] <omega_> works for me
[03:37] <omega_> but it does point out an issue with libdv that I'll have to bring up with krasic
[03:37] <omega_> and he's not gonna like it
[03:37] <wtay> maybe a gcc3 issue
[03:38] <omega_> include paths? hardly
[03:38] <wtay> not gonna like it? :)
[03:38] <omega_> the fact that for libdv/dv_types.h to be found by dv.h, the entire libdv source code needs to be in a subdirectory in the libdv package
[03:38] <omega_> just like gstreamer/gst/gst*.h
[03:39] <wtay> true
[03:39] <omega_> or... #ifdef IN_LIBDV_BUILD #include "dv_types.h" #else #include <libdv/dv_types.h>
[03:39] <omega_> never though of that solution before....
[03:39] <wtay> ouch
[03:39] <wtay> hmm, so dvshow isn't linked to gtk/gnome libs...
[03:39] <omega_> yeah
[03:40] <omega_> um, hmm
[03:41] <wtay> strange
[03:42] <wtay> my problem, I only ran configure, not autogen
[03:43] <omega_> oops
[03:43] <wtay> grmbl; full build again...
[03:45] <omega_> you grmbl about a 5min build???
[03:46] <wtay> 5+5+5 = 15
[03:46] <wtay> heh, is the audio wav?
[03:46] <omega_> that'd be, um, your fault
[03:46] <omega_> no audio yet
[03:47] <wtay> I mean in libdv
[03:47] <omega_> oh, um
[03:47] <omega_> you mean in the dv format or output?
[03:47] <omega_> output should be s16le stereo
[03:47] <wtay> the format
[03:47] <omega_> very very custom
[03:48] <wtay> oh
[03:48] <omega_> not compressed, but mangled
[03:48] <wtay> great
[03:48] <omega_> the problem with libdv right now is that it doesn't have channel-stride capabilities, so you get two buffers, one per channel
[03:48] <omega_> I can work around this for now, eventually fix it
[03:49] Action: omega_ just ordered a firewire camera
[03:49] <omega_> but it'll be shipped to pdx, and I'll be in Boise all next week ;-(
[03:50] <wtay> I now see a seriously mangled image in dvshow
[03:51] <omega_> ok, that's what I see
[03:51] <omega_> I need to ping krasic
[03:51] <omega_> did you need to make any build changes, or does current CVS work?
[03:51] <wtay> it looks like some blocks are moved, like a puzzle
[03:51] Action: puetzk wonders if he will understand mpg123's imdct or go insane first
[03:51] <wtay> CVS works
[03:51] <omega_> that's part of the DV standard
[03:51] <omega_> I put my money on insane
[03:51] <puetzk> heh
[03:52] <wtay> omega_: any idea why thr blocks are like this?
[03:52] <omega_> yes, there's something wrong with libdv
[03:52] <omega_> you can uncomment the top line of dvdec.c...
[03:52] <wtay> hmm, playdv works...
[03:52] <omega_> and swap the comments around in dvshow (to add the cspace converter)
[03:53] <omega_> and it'll play properly
[03:53] <omega_> but it's slow, because it goes from yuv to rgb24 to screen format
[03:53] <puetzk> why not use XVideo for direct yuv?
[03:53] <puetzk> (at least for those who can support that)
[03:53] <omega_> well, because in that mode the dv decoder has a shuffling problem right now
[03:53] <puetzk> ah :-)
[03:53] <omega_> as soon as we get it fixed, you'll be able to use either
[03:54] <omega_> mail sent to krasic
[03:54] <wtay> playdv uses Xv, no?
[03:55] <omega_> yes
[03:55] Action: omega_ doesn't understand it, krasic might
[03:56] Action: puetzk thinks whoever invented the MDCT is one sick puppy
[03:56] <omega_> amen.
[03:57] <wtay> ouch, but it works now...
[03:57] <omega_> what video card do you have?
[03:58] <wtay> Matrox G450
[03:58] <omega_> ok
[03:58] <omega_> dh?
[03:58] <wtay> yup
[03:58] <wtay> unused though
[03:58] <omega_> oh
[03:58] <wtay> no space for a second monitor on my desk :(
[03:59] <omega_> that's no excuse
[03:59] <wtay> if you would see my desk, you'll know it is :)
[03:59] <omega_> btw, I noticed that there's a dshow plugin directory in lame now....
[03:59] <omega_> could be of some use
[03:59] <omega_> are the avi decoder .dll's dshow, or not?
[04:00] <wtay> possibly
[04:00] <wtay> hmm no
[04:00] <wtay> the old plugin types...
[04:00] <omega_> ick
[04:00] <omega_> even the divx one?
[04:00] <wtay> direct media or something
[04:00] <wtay> yup
[04:00] <omega_> dm is ds
[04:01] <wtay> the version before that then
[04:01] <omega_> um
[04:01] <omega_> hmmm
[04:01] <wtay> it's old
[04:02] <wtay> did you try YV12 output too?
[04:03] <omega_> no
[04:04] <omega_> it's a libdv problem
[04:04] <wtay> yeah, but maybe only with YUY2
[04:04] <omega_> it only outputs yuy2
[04:04] <wtay> hmm ok
[04:05] <omega_> it should also be able to output Y41P as well
[04:05] <omega_> but....
[04:06] <omega_> and there's a missing fourcc for planar 4:1:1
[04:07] <wtay> where?
[04:07] <omega_> there is no fourcc
[04:08] puetzk (kevin at lyon-185-248.stures.iastate.edu) left irc: Ping timeout for puetzk[lyon-185-248.stures.iastate.edu]
[04:08] <wtay> pff
[04:09] <wtay> hmm
[04:09] <wtay> i420?
[04:09] <wtay> 4:2:0 planar
[04:09] Action: wtay never understood the x:y:z meanings
[04:09] <omega_> nope, that's for mpeg
[04:10] <omega_> I don't understand them either, but I know what they all are <g>
[04:10] <wtay> is it the way the Crs are subsampled that distinguishes them you think...
[04:10] <omega_> yes
[04:11] <omega_> but I cannot derive a relationship between the numbers and the patterns
[04:11] <wtay> me neither
[04:11] <omega_> you know what they are?
[04:12] <wtay> no
[04:12] <omega_> you want to know?
[04:12] <wtay> sure
[04:12] <omega_> 420:
[04:12] <omega_> l l  c
[04:12] <omega_> l l
[04:12] <omega_> er, cr and cb for each 'c'
[04:12] <omega_> 422:
[04:12] <omega_> l l   c
[04:12] Last message repeated 1 time(s).
[04:12] <omega_> 411:
[04:12] <omega_> l l l l    c
[04:12] <omega_> 444:
[04:13] <omega_> l l   c c
[04:13] Last message repeated 1 time(s).
[04:13] <omega_> those are the common ones, there are many higher variants, including things like 8:4:4:8
[04:13] <omega_> which makes even less sense to me, though I do know that the fourth channel is alpha
[04:15] <wtay> when you draw them like that I can see a pattern
[04:15] <omega_> oh?
[04:15] <wtay> sorta
[04:15] <omega_> I guess I should have done:
[04:15] <omega_> l l   c .
[04:16] <omega_> l l   . .
[04:16] <omega_> for 420
[04:16] <omega_> even more clear
[04:16] <omega_> though there is such a thing as:
[04:16] <omega_> l l   . .
[04:16] <omega_>        c
[04:16] <omega_> l l   . .
[04:16] <omega_> this is what mpeg2 uses
[04:16] <wtay> the 0 means, no Cr on the second line...
[04:16] <omega_> mpeg1 uses the other
[04:16] <omega_> ah, ok
[04:17] <omega_> I think I get it, sorta
[04:17] <wtay> 411 still puzzles me
[04:17] <omega_> yeah
[04:17] <omega_> oh well, don
[04:17] <omega_> don't puzzle too hard
[04:17] <omega_> I'm not worried
[04:31] <wtay> omega_: found the bug...
[04:31] <omega_> which
[04:31] <omega_> ?
[04:31] <wtay> YUY2 mangle image
[04:31] <omega_> oh?
[04:31] <omega_> where?
[04:31] <wtay> dvdec.c line 298
[04:31] <wtay> pitch = width * 2
[04:31] <omega_> for which?
[04:32] <wtay>     outframe_pitches[0] = 720*2;
[04:32] <omega_> why?
[04:32] <wtay> plays perfect
[04:32] <omega_> um
[04:32] <wtay> I looked at playdv
[04:32] <wtay> plydv.c line 701
[04:32] <wtay>     outframe_pitches[0] = 720*2;
[04:32] <omega_> ok, that's screwed up
[04:33] <omega_> that's a bug deeper in libdv then
[04:33] <wtay> well if they are not planar it does make sense
[04:33] <omega_> they are planar
[04:34] <wtay> hmm
[04:34] <wtay> Xv: using port 58 for video
[04:34] <wtay>   image format list for port 59
[04:34] <wtay>     0x32595559 (YUY2) packed
[04:34] <wtay>     0x32315659 (YV12) planar
[04:34] <wtay>     0x30323449 (I420) planar
[04:34] <wtay>     0x59565955 (UYVY) packed
[04:34] <omega_> where do you get that?
[04:35] <omega_> um
[04:35] <wtay> from xawtv, it lists the Xv capabilities to stdout
[04:35] <omega_> that's screwed up
[04:36] <omega_> um
[04:37] <wtay> webarts says it's packed too..
[04:37] <omega_> hmm, ok, then I'm confused, and libdv needs to be mangled somewhat
[04:38] <omega_> I'm going to commit the ## fix to gstcaps.h at the same time I put in even more fixes to gstbuffer.[ch]
[04:38] <wtay> ok, I'm going to sleep..
[04:38] <omega_> ok
[04:39] <omega_> um
[04:39] <wtay> will try to make an mpeg1 out of pond.dv tomorrow
[04:39] <omega_> um
[04:39] <wtay> ?
[04:39] <omega_> all the sudden libdv/dv.h doesn't exist
[04:39] <wtay> oops
[04:39] <omega_> hrm
[04:39] <wtay> configure.in?
[04:40] <omega_> nope
[04:40] <wtay> on your disk ?!?
[04:40] <omega_> checking
[04:40] <omega_> it does not, it didn't seem to before
[04:40] <omega_> except...
[04:40] <omega_> um
[04:40] Action: omega_ decides to forget about the whole thing
[04:40] <omega_> and I'm still getting strange failures
[04:41] <wtay> ReiserFS ?
[04:41] <omega_> better not be
[04:41] <wtay> hmm
[04:41] <omega_> um
[04:41] <omega_> I can't connect dvdec to videosink again
[04:41] <omega_> or wait
[04:41] <omega_> no, something else is wrong
[04:41] <wtay> ?
[04:41] <omega_> we need to make things fail a little more gracefully....
[04:42] <wtay> err, yeah, you could say that..
[04:42] <omega_> I just did.  for the record <g>
[04:42] Action: omega_ is confused
[04:43] <omega_> it's as if nego is failing somewhere
[04:43] <wtay> dvshow is at 98% CPU..
[04:43] <omega_> yea
[04:43] <omega_> why is nego happening during element construction?  is it because of the set_caps() ?
[04:44] <wtay> no
[04:44] <omega_> for some reason it claims I don't have Xv
[04:44] <wtay> can't be, the pad is not connected yet
[04:44] <wtay> hmm
[04:44] <omega_> it's failing the first nego saying no peer
[04:44] <omega_> but the real nego says rgb <!> yuy2
[04:45] <omega_> afaict
[04:45] <omega_> why can't we have the videosink print out all possible formats?
[04:45] <wtay> GST_INFO
[04:45] <wtay> GST_CAT_PLUGIN_INFO
[04:45] <omega_> I have that all turned on
[04:46] <omega_> btw, how does videosink know how to nego before it's in READY ?
[04:46] <wtay> the probe happens at plugin load
[04:47] <omega_> hrm
[04:47] <omega_> ick
[04:47] <wtay> I know..
[04:47] <omega_> we'll have to change that once incsched works
[04:47] <omega_> and why does this work sometimes and not otheres?
[04:47] <wtay> I have no idea...
[04:48] <omega_> could have something to do with the fact that Xv isn't working at all right now
[04:48] <omega_> plaympeg scaled eats 100+%
[04:48] <wtay> that could explain
[04:48] <omega_> grmbl
[04:49] <omega_> brb
[04:49] omega_ (omega at omegacs.net) left irc: xv fun
[04:57] omega_ (omega at omegacs.net) joined #gstreamer.
[04:57] Action: omega_ is a complete imbecile
[04:57] <wtay> ?
[04:58] <omega_> I copied my hard drive (minus /home) to sonic yesterday morning
[04:58] <omega_> then I went to OGI
[04:58] <omega_> came back, and copied /home to sonic, then put root and /home onto the new drive
[04:58] <omega_> somewhere between yesterday morning and today, surprise, surprise, I did stuff to my root filesystem contents
[04:58] puetzk (kevin at lyon-185-248.stures.iastate.edu) joined #gstreamer.
[04:59] Action: omega_ is an utter moron
[04:59] <puetzk> how so?
[04:59] <omega_> I copied my hard drive in pieces (root, and /home), but did so at different times, and made changes between those
[04:59] <puetzk> hehe
[05:00] <puetzk> hopefully you didn't lose anything...
[05:00] <omega_> so somehow I surprise myself by not having things like the Xv-enabled X server I installed yesterday
[05:00] <wtay> 5am here, going to sleep, cya
[05:00] Nick change: wtay -> wtay-sleeping
[05:00] <omega_> ok, l8r
[05:00] Action: omega_ goes to install that X server again
[05:00] Action: puetzk ponders the mess he's waded into
[05:00] omega_ (omega at omegacs.net) left irc: killall -9 omega
[05:03] <puetzk> MAD is reasonable, and reasonably clean, but slow beyond my will/ability to optomize. mpg123 is a freakin disaster, but good and very very fast
[05:03] Action: puetzk sighs
[05:04] omega_ (omega at omegacs.net) joined #gstreamer.
[05:04] <puetzk> hiya omega_
[05:04] Action: omega_ is still an idiot, but he's an idiot with Xv
[05:05] <omega_> what did you say just before I /quit ?
[05:05] <puetzk> I was desparing at mp3 decoding :-)
[05:05] <puetzk> despairing
[05:05] <omega_> ah
[05:05] <omega_> of course
[05:05] Action: puetzk wishes a fairy would make mpg123 clean or mad fast
[05:07] <puetzk> or finish mpglib :-)
[05:08] <omega_> hmmm
[05:10] <puetzk> but even mpglib has a ton of static globals
[05:10] <omega_> then it's not a lib, by any modern definition.....
[05:10] <puetzk> yeah :-)
[05:10] <puetzk> mpglib is the mpg123 upstream's half-assed cleanup :-)
[05:11] <puetzk> if mad's MDCT didn't suck, it would be a serious contender. But 10% CPU on a 466 is just too slow
[05:11] <puetzk> and that's the best I could manage
[05:11] <omega_> ick
[05:12] <puetzk> mpg123's imdct combines the idct and the overlapping calcs together, so it's not a drop in by any stretch, and I couldn't follow it well enough to disentangle them
[05:12] <puetzk> to use it's (vastly faster) MDCT
[05:13] <puetzk> maybe I'll have to stick to mpg123 and a fork() to protect it's globals :-)
[05:13] <omega_> a good design/structure document is neded for MAD, and I think a refactor
[05:13] <puetzk> that's what I've currently got, but what an ugly solution
[05:13] <omega_> quite
[05:13] <puetzk> sinec I do have to support concurrent playback
[05:13] <puetzk> noatun's gonna be doing that very soon
[05:13] <puetzk> to crossfade
[05:13] <omega_> ah
[05:15] Action: puetzk tries to decide if these static globals are per-frame or just const
[05:18] <puetzk> I'd like to get mpg123 producing float output too, but that also seems quite hard
[05:18] <omega_> yup
[05:19] <puetzk> since it's all floats internally
[05:19] <puetzk> and my plugin is supposed to spit out floats
[05:19] <puetzk> quantizing it seems quite retarded
[05:20] <omega_> yup
[05:20] Action: puetzk wonders if there are any other good choices around
[05:20] <puetzk> probably not :-)
[06:12] puetzk (kevin at lyon-185-248.stures.iastate.edu) left irc: [x]chat
[06:12] puetzk (kevin at lyon-185-248.stures.iastate.edu) joined #gstreamer.