[FFmpeg-devel-irc] IRC log for 2010-04-26

[irc at mansr.com]

[09:17:06] <KotH> http://xkcd.com/732/
[09:22:32] <kshishkov> yep, good for HDTV advertising ;)
[09:22:53] <kshishkov> still, http://xkcd.com/730/ touched something in my soul too
[09:23:53] <KotH> kshishkov: do you know electronics?
[09:24:00] <av500> KotH: HD is about buying *big* TVs, never mind the resolution
[09:24:02] <pJok> god middag, kshishkov :)
[09:24:20] <kshishkov> god dag, pJok
[09:24:59] <kshishkov> KotH: yep, a bit. Not to mention that our schematics slightly differ since they were stolen fron DIN looong time ago
[09:25:50] <KotH> eh..
[09:25:54] <KotH> kshishkov: dont worry about that
[09:26:04] <KotH> kshishkov: europe uses a mix between din and us symbols
[09:26:13] <KotH> kshishkov: though mostly din
[09:26:32] <kshishkov> well, resistors are drawn like rectangles here
[09:26:58] <KotH> there is no other way to draw resistors ;-)
[09:27:05] <av500> here too
[09:27:31] <kshishkov> americans use wiggly lines
[09:27:38] <av500> americans...
[09:27:57] <kshishkov> av500: "here too" means you actually know about DIN
[09:28:16] <KotH> kshishkov: you know what din stands for? ;)
[09:28:22] <av500> I din nothing wrong
[09:28:53] <kshishkov> KotH: av500_current_country Institute fuer Nationalstandarten oder etwas
[09:29:07] <av500> industry norm
[09:29:49] <KotH> s/y/ie/ ;)
[09:30:12] <av500> iees!
[09:30:58] <KotH> da war kein g hinten drann!
[09:31:31] <av500> achso
[09:34:15] <kshishkov> hmm, wikipedia says it's "Deutsches Institut fuer Normung" and "industy norm" is wrong explanation
[09:35:00] <av500> kshishkov: bah, wikipedia :)
[09:35:05] <KotH> who says taht wikipedia is right?
[09:35:29] <kshishkov> wikipedia does
[09:35:58] <av500> kshishkov: quick survey among 3 coworkers yield "... Industrie Norm" :)
[09:35:58] <kshishkov> IIRC some Ukrainian laws are like that too - they have higher priority because they say so
[09:36:09] <av500> kshishkov: but I guess wiki is still right
[09:36:23] <KotH> av500: cow-orkers?
[09:36:24] <KotH> ;)
[09:37:55] <av500> yes, we milk orcs
[09:37:56] <janneg> http://de.wikipedia.org/wiki/Din says formerly „Deutsche Industrie-Norm“, today DIN-Norm
[09:38:28] <KotH> deutsche industrie norm norm?
[09:38:32] <KotH> sounds wrong
[09:39:04] <av500> no, deutsches inst. für Normung norm
[09:39:08] <janneg> deutsches institut für normung norm still sounds wrong
[09:39:21] <kshishkov> not at all
[09:39:52] <av500> hmm, maybe kshishkov should be german language maintainer too
[09:39:59] <av500> he knows more than me about it :)
[09:40:01] <janneg> it sounds very much like LCD display
[09:43:13] <kshishkov> av500: looks like I manage without German lanuage knowledge even here
[09:44:45] <av500> I trust you'll do fine :)
[10:12:59] <Kovensky> we saw a bit of electronics @ HS
[10:13:19] <Kovensky> I was like lolconfused because the symbols used were completely different from US symbols (which I had studied before on my own)
[10:13:50] <Kovensky> well, s/electronics/electric circuits/
[10:18:51] * KotH thinks that for all but logic symbols, the german ones are easier
[10:19:22] <KotH> for logic the usian symbols are more clear... unless you have to draw a lot of or/xor gates :)
[10:36:26] <siretart> KotH: can you disable the whitespace enforcment hook for mplayer's svn branches (i.e. not trunk)?
[10:37:00] <KotH> probably
[10:37:02] <KotH> why?
[10:37:23] <siretart> KotH: I wanted to backport some fixes from trunk to rc3, but the commit hook complained about trailing whitespace
[10:37:39] <KotH> why dont you remove those whitespaces then ?
[10:37:57] <siretart> that would be an unrelated change to the file
[10:38:14] <KotH> and how come files in trunk contain white spaces?
[10:38:20] <KotH> er.. trailing whitespaces
[10:38:35] <siretart> I don't backport the file. I backport a change
[10:38:45] <siretart> the whitespace cleanup is not part of the change I want to backport
[10:39:20] <KotH> why not do it anyways?
[10:39:36] <KotH> there is no reason to keep trainling whitespace in c code
[10:40:04] <siretart> main reason: fear of an angry diego ;-)
[10:40:31] * KotH thinks that entering trainling whitespace would anger him even mroe
[10:40:34] <KotH> more*
[10:40:58] <siretart> it does not enter, it is already in the file
[10:41:14] <KotH> huh?
[10:41:33] <KotH> you mean, there is a file that diego missed?
[10:41:53] <siretart> of course, he applied the restriction to the whole repo, but only cleaned up trunk
[10:42:16] <KotH> ^^'
[10:42:46] <KotH> then the correct thing to do is, backport the whitespace fix first, then beat diego, then backport the real fix
[10:43:02] <siretart> I see
[10:43:05] <av500> git-beat-diego?
[10:43:18] <siretart> perhaps I should switch the first two items
[11:08:10] <twnqx> hi guys, would you happen to know if mplayer is using ffmpeg for rtsp, or does it have its own implementation?
[11:10:48] <twnqx> ok, seems it uses librtsp...
[11:11:48] <wbs> which librtsp is that, btw?
[11:12:14] <twnqx> ./mplayer/stream/librtsp/rtsp_session.c
[11:12:20] <wbs> ah
[11:36:27] <Compn> mplayer has its own rtsp (real media) code
[11:36:49] <Compn> and it uses live555 for rtsp:// (anything else except .rm)
[11:37:03] <Compn> or you can use mplayer ffmpeg://rtsp:// if you want to use ffmpegs rtsp :)
[11:37:20] <wbs> ah, ok :-)
[11:37:33] <wbs> I tried live555 for some stuff earlier, but wasn't really too fond of it
[11:37:41] <Compn> why twnqx is asking in #ffmpeg-devel i dunno
[11:39:18] <Compn> live555 doesnt support the X-perimental streams
[11:39:34] <Compn> which is some quicktime streams, all wmv/asf streams, and some random others
[11:40:18] <twnqx> because i wasn't sure if it uses libavf for that, since i remember some recent work on ffmpeg's rtsp support
[11:46:01] <Compn> rtsp://stream.diffusion.ens.fr/2008_10_03_albarede.mov
[11:46:09] <Compn> does that stream work in ffplay? it crashes here ;\
[11:46:48] <twnqx> my ffplay claims it doesn't find the file
[11:47:04] <twnqx> rtsp://stream.diffusion.ens.fr/2008_10_03_albarede.mov: No such file or directory
[11:47:14] <Compn> you dont have network support? :\
[11:47:14] <twnqx> gah
[11:47:18] <twnqx> --disable-network
[11:47:21] <twnqx> :(
[11:47:56] <wbs> Compn: hmm, doesn't seem to crash here, do you have the latest version?
[11:48:04] <Compn> wbs : no, i do not
[11:48:15] <wbs> I think BBB fixed something some time ago that could lead to crashes if it was fed an unsupported format
[11:48:30] <Compn> wbs : does that url play ?
[11:49:12] <wbs> nope, it doesn't... i think that's stuff that j0sh will implement in gsoc, though
[11:49:35] <wbs> is that url permanently available? that would be a good test case for gsoc :-)
[11:49:51] <Compn> i dunno
[11:50:07] <Compn> its been in mplayer bugzilla since 2009-06
[11:52:14] <ohsix> doesn't crash here, with debug prints the following then hangs, after ^c it sez could not find codec parameters; [rtsp @ 0x141b4f0]hello state=0
[11:52:44] <Compn> http://bugzilla.mplayerhq.hu/show_bug.cgi?id=1486
[11:52:48] <wbs> ah, I've got access to other samples with similar content already
[11:52:56] <wbs> but yes, that's part of j0sh's soc proposal
[11:53:13] <Compn> wbs : http://wiki.multimedia.cx/index.php?title=RTSP
[11:53:18] <Compn> theres a bunch of rtsp samples for testing
[11:53:30] <Compn> i think BBB got a few of them working (at least with gstreamer) :)
[11:53:50] <ohsix> that sounds like a challenge
[11:54:14] <Compn> wbs : if you have more sample streams, put them on the wiki (or msg me, and i'll put them up) so other projects can test
[11:54:35] <ohsix> it works with gstreamer
[11:54:54] <wbs> Compn: the ones I've got aren't available on any public server, but available in the darwin streaming server distribution
[11:54:58] <Compn> ah
[11:55:10] <Compn> well those are some 'real-world' samples for you and josh :)
[11:55:15] <wbs> yeah :-)
[11:55:19] <ohsix> just played it in totem :[
[11:55:41] <Compn> hehehe
[11:59:36] <KotH> ohsix: YOU HAVE BEEN TAINTED!
[11:59:38] <KotH> ;)
[12:00:05] <ohsix> too bad ffmpeg running out of free frames keeps me from my mkvs
[12:00:47] <Kovensky> o_O
[12:00:55] <Kovensky> there are paid ffmpeg frames?
[12:00:58] * Kovensky ducks
[12:01:32] <ohsix> theres a list of unused frames that is finite in size
[12:01:45] <ohsix> so if you queue too many in your renderer they run out
[12:02:56] <Kovensky> isn't that a renderer problem rather than a libavcodec one
[12:03:20] <kshishkov> ohsix, so you are a very greedy man graabing all possible frames at once
[12:03:28] <twnqx>     Stream #0.0: Video: mpeg4, yuv420p, 176x144 [PAR 1:1 DAR 11:9], 12.50 tbr, 90k tbn, 12.50 tbc
[12:03:28] <twnqx>     Stream #0.1: Audio: 0x0000, 8000 Hz, 1 channels
[12:03:38] <twnqx> wouldn't one expect ffplay to open a window at some point, then? :X
[12:03:55] <ohsix> bursty saves power :>
[12:03:56] <kshishkov> for such a small video? unlikely
[12:04:18] <twnqx> heh
[12:04:22] <twnqx> it's for mobile tv
[12:04:28] <ohsix> Kovensky: that its static and not knowable at runtime its a problen
[12:04:34] <twnqx> also, the audio doesn't work either
[12:06:44] <wbs> do normal video codecs like mpeg4 or h264 work with anything else than 4:2:0-video?
[12:06:56] <wbs> on some platforms, there are encoders that accept 4:2:2 as input
[12:07:07] <Kovensky> H.264 supports 4:4:4 on the lossless profile
[12:07:13] <Kovensky> don't know about others
[12:07:18] <Kovensky> (or other profiles)
[12:07:27] <wbs> ok
[12:07:41] <wbs> well, I guess I'll find out when I get it all hooked together
[12:09:44] <lu_zero> hi
[12:10:02] <Kovensky> x264 doesn't produce 4:2:2 or 4:4:4 video yet though (it's a GSoC task though)
[12:11:11] <kierank> there is also not a decoder apart from the jm
[12:11:23] <kierank> s/a/a free
[12:11:34] <wbs> for h264 with 4:2:2?
[12:12:00] <kierank> yes for h264 w/ 4:2:2 and 4:4:4
[12:14:22] <wbs> ok
[12:27:06] <lu_zero> sigh
[12:27:16] <lu_zero> dhcpcd seems to have a _bit_ of problems
[12:29:31] <kshishkov> use somthing else, for example static IPs then
[12:30:28] <ohsix> you cab flag it with -S too
[12:31:52] <mru> what's the problem with dhcpcd?
[13:12:21] <hyc> hm, I just noticed that ffmpeg has an SWF decoder
[13:12:28] <hyc> and it doesn't support compressed SWFs
[13:12:44] <hyc> it just so happens that librtmp *does* support compressed SWFs
[13:12:47] <kshishkov> we have a tool to decompress them though
[13:13:16] <JEEBsv> wait, _decoding_ of swf? Isn't that more like scripts to be rendered?
[13:13:30] <hyc> I guess it's a demux
[13:13:32] <JEEBsv> ah
[13:13:38] <JEEBsv> yeah, video-in-swf
[13:14:36] <hyc> well, all it takes to do it is zlib, and ffmpeg already has zlib dependencies
[13:14:48] <hyc> matroskadec.c and mov.c
[13:15:30] <kshishkov> here it's whole file compressed, may be quite different situation
[13:15:58] <hyc> no, a compressed SWF has a header that is not compressed
[13:16:11] <kshishkov> 8 bytes
[13:16:15] <hyc> yep
[13:16:24] <hyc> it's trivial to use zlib here
[13:16:50] <kshishkov> IIRC, mov/mkv have rather small chunks compressed while cws is a whole file compressed at once
[13:17:15] <hyc> excluding those first 8 bytes, yes.
[13:17:33] <hyc> but zlib can operate on a buffer-at-atime
[13:17:46] <mru> tools/cws2fws.c
[13:18:43] <hyc> so, no need for a patch for this then?
[13:19:01] <wbs> if you're able to do it neatly I guess it's most welcome
[13:19:41] <kshishkov> oh, that's easy - implement zlib:// protocol and use it as an intermediate level for reading ;)
[13:19:55] <hyc> it's probably no more than 20 lines of additional code. haven't written it yet of course, but judging from how long it took to add to librtmp.
[13:20:11] <av500> hyc: how do you seek in compressed SWF?
[13:20:16] <av500> :)
[13:20:33] <hyc> doh....
[13:20:50] <hyc> hah, that was a trick question
[13:20:56] <hyc> swfdec.c has no seek implemented
[13:21:04] <av500> doh
[13:24:03] <hyc> but still a good question. I'm not gonna touch it.
[13:34:50] <BBB> mornin'
[13:35:01] <av500> 'jour
[13:37:08] <CIA-7> ffmpeg: rbultje * r22965 /trunk/libavutil/common.h:
[13:37:08] <CIA-7> ffmpeg: Fix broken 32-bit clipping, and write numbers in hex instead of decimal so
[13:37:08] <CIA-7> ffmpeg: they are easier to understand. Also give the add a 'u' postfix to silence
[13:37:08] <CIA-7> ffmpeg: a pre-c99 compiler warning.
[13:43:38] <BastyCDGS> greetz to all
[15:11:22] <superdump> want a new video format with samples? http://www.3xlogic.com/aztech
[15:13:17] <kshishkov> my BS detector gives some warnings
[15:13:34] <kierank> the things it says about h.264 make no sense
[15:14:03] <kshishkov> exactly
[15:15:01] <superdump> maybe shitty h.264 encoders don't do well with low framerates
[15:16:19] <superdump> because they don't do well with anything
[15:17:00] <kshishkov> by definition
[15:17:56] * KotH defines kshishkov as 3.1415
[15:18:46] <kshishkov> KotH, I can now visit Switzerland
[15:19:27] <janneg> approximations of PI don't need a visum?
[15:19:48] <av500> "When you record at less than 30fps with H.264 you end up with a lot of overhead in your video due to this flaw..."
[15:19:50] <av500> wtf?
[15:20:24] <KotH> janneg: he'll still need a visum, but people will imediatly see that he is country-challanged
[15:21:02] <kshishkov> av500: you HD-video will be full of NALs
[15:23:04] <av500> "omg, it is full of NALs"
[15:23:10] <KotH> NALs? not FNORDs?
[15:23:26] <kshishkov> KotH: 3/5 of it
[15:52:55] <BastyCDGS> yeah, was able to speedup 24bpp plane decoding by over 200%
[15:53:04] <BastyCDGS> patch just submitted to ml
[15:54:50] <jai> if only this was for h.264 ... ;)
[15:55:35] <kshishkov> well, just wait for 24bpp support in H.264 ;)
[15:55:41] <BastyCDGS> lol
[15:55:58] <jai> i meant the speedup
[15:55:58] <BastyCDGS> I required 4 lut's for that
[15:56:27] <BastyCDGS> interestingly, the decodeplane8 is much faster with inline statement while it's the opposite with decodeplane32
[15:58:35] <BastyCDGS> btw
[15:58:59] <BastyCDGS> is there a way in ffmpeg to determine if CPU is 64 independent of architecture instead of doing a if (sizeof(void*) >= 8) ?
[15:59:22] <BastyCDGS> I want to optimize decodeplane8 if the CPU is 64-bit by doing unroll of 8 instead of 4
[15:59:34] <Dark_Shikari> hmm.  in x264 we do if(WORD_SIZE == 8)
[15:59:41] <Dark_Shikari> .... of course WORD_SIZE is #defined to sizeof(void*)
[15:59:43] <BastyCDGS> I search sth. like #ifdef HAVE_64BIT_CPU
[16:00:01] <BastyCDGS> does the compiler optimize such things out?
[16:00:09] <BastyCDGS> you should not do == 8
[16:00:11] <BastyCDGS> do a >= 8
[16:00:21] <BastyCDGS> because it won't use 64-bit then on 128-bit CPUs ;)
[16:00:56] <BastyCDGS> this is far into the future of course, but someday this will happen they'll appear
[16:00:56] <Dark_Shikari> yes, 128-bit cpus made out of unicorn dust
[16:02:07] <BastyCDGS> ahh now I know why unicorns died out, they killed them to make CPUs out of them :D
[16:02:31] <JEEBsv> that sounds very probable
[16:02:38] <BastyCDGS> hehe
[16:02:57] <BastyCDGS> btw, the guys of you having a 64 bit CPU could you check my latest patch using AV_64WNA?
[16:03:03] <BastyCDGS> this is slower for my 32-bit CPU
[16:03:10] <kshishkov> there are always 1024-bit CPUs made from marketing dust
[16:03:12] <BastyCDGS> but maybe this differs to a 64-bit CPU
[16:03:29] <Dark_Shikari> BastyCDGS: get yourself a 64-bit cpu to bench on
[16:03:36] <Dark_Shikari> yes this may mean getting an ssh account somewhere
[16:03:53] <BastyCDGS> good you're mentioning this...I could do this at our university cluster
[16:04:09] <BBB> 200% is at least worth it
[16:04:13] <BBB> unlike the 1-2% of yesterday
[16:04:43] <BastyCDGS> for the 8bpp decoder it's even more than this, almost 400% ;)
[16:05:28] <BastyCDGS> or even, is there a better way writing this in ffmpeg?
[16:05:29] <BastyCDGS> AV_WN64A(dst+i, AV_RN64A(dst+i) | ((uint64_t) lut3[mask] << 32) | (uint64_t) lut2[mask]);
[16:05:40] <BastyCDGS> AV_WN64A(dst+i+2, AV_RN64A(dst+i+2) | ((uint64_t) lut1[mask] << 32) | (uint64_t) lut0[mask]);
[16:06:04] <BastyCDGS> this slows down on 32-bit
[16:06:08] <Dark_Shikari> of course it does
[16:06:12] <Dark_Shikari> gcc sucks ass with 64-bit math on 32-bit
[16:06:12] <BastyCDGS> as opposed to:
[16:06:18] <BastyCDGS> dst[i]   |= lut3[mask];
[16:06:18] <BastyCDGS>         dst[i+1] |= lut2[mask];
[16:06:18] <BastyCDGS>         dst[i+2] |= lut1[mask];
[16:06:18] <BastyCDGS>         dst[i+3] |= lut0[mask];
[16:06:28] <Dark_Shikari> Also, whether or not that code is faster is going to heavily depend on the ALU of the particular CPU
[16:06:46] <Dark_Shikari> if the ALU has much faster arith than load/store, it will help
[16:06:51] <Dark_Shikari> if it has slower arith, it will hurt
[16:07:14] <Dark_Shikari> which means such optimizations are generally a bit dubious as their effect varies wildly depending on the cpu and the phase of the moon
[16:07:28] <BastyCDGS> BBB, what about the patches from yesterday...I think they'll go to mainline repo?
[16:07:43] <BastyCDGS> well, my CPU is a Athlon XP+ 2100
[16:08:01] <BBB> I'll getthem in
[16:08:04] <BBB> busy with something else
[16:08:11] <BBB> mru basically says the const does nothing
[16:08:15] <BBB> which is my impression also
[16:08:15] <BBB> t
[16:08:15] <BBB> he
[16:08:16] <BBB> c
[16:08:16] <BBB> om
[16:08:16] <BBB> p
[16:08:17] <BBB> 
[16:08:18] <BBB> ?
[16:08:26] * BBB kicks IRC client
[16:08:47] <jai> BBB: which one?
[16:08:52] <BBB> I'd suggest to remove it, still, the compiler won't do anything with it, unless you can actually show me that the compiler output (disassembly) changes as a result
[16:09:09] <BBB> which I find hard to believe
[16:09:21] <BBB> jai: his const b = ...bufsize/bps...;
[16:09:44] <jai> right
[16:09:57] <BastyCDGS> there isn't a division there anymore ;)
[16:10:46] <BBB> uhm, well, it's easier to build your patches on previous patches if you want to get patches in
[16:10:53] <BBB> now I have to review it back from the beginning
[16:11:04] <BastyCDGS> if you don't dare me, I'ld like to keep it, since I want to prevent that someone changes b after initialization...
[16:11:11] <BastyCDGS> this will break the decoding seriously
[16:11:32] <BastyCDGS> it's a new patch not touching the other one
[16:11:53] <BBB> I get that
[16:11:57] <BBB> but nobody will ever change it
[16:12:02] <BBB> seriously, we're quite good programmers :)
[16:12:14] <BBB> we understand that if you change a buffer halfway the printf(), things go bad
[16:12:16] <BBB> we get that :)
[16:12:50] <BBB> so again, show me that the disassembly changes as a result of the const (in a postive way), and it's ok
[16:12:55] <BastyCDGS> also don't wonder why I did remove that DECLARE_PLANE stuff...they're really two separate functions now
[16:12:58] <BBB> otherwise it's six characters of wasted space in the source code
[16:13:01] <BastyCDGS> not using that #define hack anymore
[16:13:10] <BBB> that's probably ok
[16:13:13] <BBB> but separate patch
[16:13:22] <BastyCDGS> this was necessary because the new code differs to much, also the fact the one being inlined and the other not
[16:13:23] <BBB> you shouldn't mix 20 things in a patch
[16:13:26] <BBB> they're quite big already
[16:14:00] <BastyCDGS> so you mean, I should do one patch, which just removes #define stuff and keeps everything else as it was and then adding my high-optimization stuff?
[16:14:13] <BBB> first the two patches you submitted yesterday
[16:14:18] <BBB> then a new patch for the remove-#define
[16:14:18] <BastyCDGS> also I updated the function parameter descriptions should this be done in a separate patch also?
[16:14:25] <BBB> and then another one for whatever new opts you came up with today
[16:14:38] <BBB> the two yesterday should be kept as-is, so I can apply them as-is
[16:14:44] <BBB> eptying a patch-queue is important
[16:14:48] <BBB> emptying*
[16:15:08] <BastyCDGS> well the today decodeplane32 patch also includes my yesterday decodeplane8 patch, since I changed both
[16:15:53] <BastyCDGS> I'll summarize up now:
[16:16:15] <BastyCDGS> first I do a patch which separates decodeplane##suffix stuff into decodeplane8 and decodeplane32 based on the original git code
[16:16:36] <BastyCDGS> then I'll do a patch for updating the function descriptions
[16:16:59] <BastyCDGS> then I'll apply a patch which optimizes decodeplane8
[16:17:08] <BastyCDGS> and finally one with optimizes decodeplane32
[16:17:15] <BastyCDGS> any disagreements about this?
[16:17:21] <BBB> that sounds good
[16:17:28] <BBB> so I can apply yesterday's patches?
[16:17:59] <BastyCDGS> yes, because they only work with my micro-op patch right now...
[16:18:19] <BBB> ok
[16:18:25] <iive> BastyCDGS: may I ask you something. I assume you are working on some kind of decoder. Does this decoder support video encodings of different bit depths.
[16:18:26] <BBB> give me until this afternoon and I'll do it
[16:18:48] <iive> or your decoder can output same bitstream decoded into different bitdepths?
[16:18:50] <BastyCDGS> yes anything from 1-24bpp
[16:18:59] <BastyCDGS> IFF-ILBM
[16:19:05] <BastyCDGS> HAM6/8 support will be added very soon ;)
[16:19:14] <BastyCDGS> both will also decode to 24bpp
[16:19:41] <BastyCDGS> iive the decoder can output to 8bpp and 32bpp right now
[16:19:47] <BastyCDGS> input is 1-24bpp
[16:20:12] <BastyCDGS> but I was thinking of adding 16bpp support too...or isn't that necessary?
[16:20:22] <BastyCDGS> (maybe 15bpp also)
[16:20:23] <iive> i believe that there is notion that the decoder should decode into the native format, and let swscale handle the rest
[16:20:39] <BastyCDGS> both 8bpp and 32bpp are ffmpeg's native ones ;)
[16:20:51] <iive> bitstream native
[16:21:14] <BastyCDGS> but separating the 2 decoders gives a 200-300% speed up to 8bpp as opposed to 32bpp
[16:21:47] <BastyCDGS> iive, does swscale have a planar2chunky handler?
[16:21:49] <iive> if it is palette... you can decode the palette into 32bpp, it won't be the native format.
[16:22:09] <BastyCDGS> there's palette also, and palette is decoded to 32bpp
[16:22:35] <iive> chunky?
[16:23:08] <BastyCDGS> read this:
[16:23:10] <BastyCDGS> http://amiga.nvg.org/amiga/amigafaq/AmigaFAQ_16.html
[16:23:44] <iive> bitplanes?
[16:24:19] <BastyCDGS> suppose we have a image with 3 bitplanes:
[16:25:30] <BastyCDGS> for each set bit in the plane
[16:25:59] <BastyCDGS> do a chunky |= (1 << plane); // plane = plane number from 0..2
[16:27:04] <av500> so chunky = "normal", bitplane = err, "bizzare" :)
[16:27:23] <BastyCDGS> av500, you can explain this way hehe
[16:27:26] <kshishkov> av500: bitplane = "not used in moder h/w"
[16:27:30] <kshishkov> *modern
[16:27:32] <BastyCDGS> chunky = VGA type pixel mode
[16:27:55] <kshishkov> BTW, don't forget to download some stull illegally, it's the day
[16:27:57] <Dark_Shikari> http://www.confessionsofacheapskate.com/wp-content/uploads/2010/01/campbellschunky.jpg
[16:27:59] <kshishkov> *stuff
[16:27:59] <iive> bitplane = cga/ega
[16:28:01] <Dark_Shikari> chunky?
[16:28:26] <av500> kshishkov: I will not download any "stuhl"
[16:28:28] <BastyCDGS> bitplanes can be very effective though depending on what you're doing, thanks to bitplanes the amiga was able to do smoother parallax scrolling than a pentium 1 with a SVGA card...even the amiga just had a CPU with 7MHz
[16:28:50] <kshishkov> av500: download something pirated anyway, it's the day
[16:28:59] <av500> I do every day
[16:29:07] <av500> what makes this one special?
[16:29:09] <kshishkov> download more then
[16:29:18] <av500> gee, ok ok
[16:29:24] <kshishkov> it's World Intellectual Property Day
[16:29:38] <iive> BastyCDGS: not really I've always thought that these scrolling games are done by stride(linesize) and startoffset tricks.
[16:29:41] <BastyCDGS> WIPD? ok then I'll download the whole pirate bay archive :D
[16:30:23] <BastyCDGS> http://en.wikipedia.org/wiki/Parallax_scrolling
[16:30:42] <Dark_Shikari> oh shit, WIPD
[16:30:49] <Dark_Shikari> well ok, so I have a pirated game open
[16:30:54] <Dark_Shikari> and a pirated image editor open
[16:31:02] <Dark_Shikari> and a music player open containing pirated songs
[16:31:07] <av500> you pirated gimp?
[16:31:11] <BastyCDGS> lol
[16:31:13] <Dark_Shikari> maybe I can open pirated source code in notepad++
[16:31:23] <BastyCDGS> I just pirated linux
[16:31:29] <Dark_Shikari> YARRRRRRR
[16:31:40] <iive> BastyCDGS: aha, so unlike bitplanes, these are allowed to overlap.
[16:31:56] <BastyCDGS> what's allowed to overlap?
[16:32:41] <iive> i mean, if we have B&W (1 bit) and we have 4 planes, if any of the planes have 1, there would be visible 1
[16:33:19] <iive> unlike the bitplanes, where the presense of 1 in one plane would give different result than presence of 1 in another plane (aka 0001 vs 0010)
[16:33:20] <av500> BastyCDGS: how does bitplanes help with parallax scrolling?
[16:33:30] <BastyCDGS> if plane 0 has set bit we have color index 1, if plane 1 is alone set we have color index 2, if plane 2 is alone set we have color index 4, etc.
[16:33:48] <BastyCDGS> if plane 0+1 are set, we have color index = 3;
[16:34:00] <av500> right
[16:34:42] <BastyCDGS> av500, I don't know this really, I just read 10 years ago in a scene magazine about that where this was claimed by a TRSi member
[16:34:45] <iive> so, 4 planes form 4 bit palette.
[16:34:50] <BastyCDGS> and I guess these guys know what they do ;)
[16:34:50] <av500> iive: yes
[16:35:03] <av500> its just 4 bits left to right or front to back
[16:35:13] <BastyCDGS> iive, exactly
[16:35:21] <BastyCDGS> n planes form 1 << n palette ;)
[16:35:37] <iive> how many planes do you have max?
[16:35:48] <av500> 0 is ash_cloud is set
[16:35:50] <av500> if
[16:35:57] <BastyCDGS> in my decoder? there is support upto 24bpp
[16:36:12] <iive> 2^24 palette?
[16:36:15] <BastyCDGS> yes
[16:36:47] * iive checks if his PC have enough memory for the whole palette.
[16:36:57] <kshishkov> 2^24 is mere 16Mb
[16:37:14] <av500> iive: you could cleverly create a natural pallette that maps to 24bit RGB :)
[16:37:16] <BastyCDGS> using HAM you can get upto 4096 colors to be displayed at once using 6bpp, and 262144 colors using 8bpp
[16:37:31] <BBB> spyfeng: thanks :)
[16:38:32] <iive> yep 3*16mb, i think the video card have enough ram for it.
[16:39:10] <BastyCDGS> BBB, one question for the patches...as already said I have commented out two WN64A lines...should I keep or remove them in the patch?
[16:39:22] <BBB> remove, for now
[16:39:26] <BastyCDGS> ok
[16:39:29] <BBB> we don't want disabled code in here
[16:39:32] <BBB> it's generally messy
[16:42:00] <saintdev> <BastyCDGS> I just pirated linux <-- I just downloaded Ubuntu off the pirate bay. Where is the crack????
[16:42:44] <BastyCDGS> I found it somewhere on cracks.am
[16:42:46] <iive> BastyCDGS: so my questions go on. I can imagine 8 bit palette lookup table, but how do you handle bigger index tables.
[16:42:47] <BastyCDGS> :D
[16:42:57] <iive> i suspect that HAM have something to do with it.
[16:43:20] <av500> HAM is delta compression basically
[16:43:21] <BastyCDGS> http://en.wikipedia.org/wiki/Hold_And_Modify
[16:43:28] <BastyCDGS> this is a very good explanation of HAM
[16:43:32] <BastyCDGS> better than I could describe it
[16:43:33] <av500> hold last pixel data and change only part of it
[16:45:28] <saintdev> i wonder what results do show up for ubuntu on cracks.am, lol
[16:46:27] <saintdev> hmmm, only two hits for mainactor
[16:46:53] <kshishkov> saintdev: probably full iso and download via usenext
[16:47:25] <saintdev> kshishkov: huh?
[16:47:53] <kshishkov> saintdev: that's what usually shown on most of crack search sites
[16:48:01] <BastyCDGS> lol
[16:48:08] <saintdev> oh yeah, lol
[16:48:15] <BastyCDGS> yes can't see that usenext stuff anymore
[16:48:22] <iive> BastyCDGS: if i grokked the summary correctly, the palette is giving not the color itself, but the delta (difference) of the color, compared the the previous pixel.
[16:48:28] <saintdev> i've got a blind spot in my vision for those :P
[16:49:59] <BastyCDGS> BBB, just another question, should I change the function prototypes also when doing the separation patch for decodeplane8/32?
[16:50:08] <BBB> ?
[16:50:10] <BastyCDGS> i.e. in one patch? I have to change these lines anyway
[16:50:13] <BBB> you mean void->uint8/32?
[16:50:16] <BBB> sure, why not
[16:50:20] <BastyCDGS> for example and that const stuff
[16:50:27] <BastyCDGS> +unsigned
[16:50:51] <BastyCDGS> and already making decodeplane8 inline
[16:51:12] <BastyCDGS> the other one is MUCH slower with inline keyword, while dp8 ist MUCH faster with inline keyword
[16:52:23] <av500> iive: there are 16 pallette entries, then from them you update R,G or B component directly per pixel
[16:53:01] <BastyCDGS> BBB, with unsigned I mean the function declaration, not the body...
[16:53:12] <iive> so you still have 4bit palette, but it works in delta mode.
[16:53:42] <av500> hmm, I think you have RGB444, but you can only change 4bit per pixel
[16:53:46] <BastyCDGS> but if you like I can also integrate int i, b => unsigned i, b
[16:54:01] <BastyCDGS> but I think you'd prefer that to be in another patch (latter one)
[16:54:06] <BBB> BastyCDGS: split it all as much as possible
[16:54:13] <BBB> keep the original patches as is
[16:54:17] <BBB> and do the rest in a new patch
[16:54:36] <BBB> I'd say do split + changes in a separate patch
[16:54:48] <BBB> so it's clear and confirmable that the split didn't do anything funky (binary should be the same before/after)
[16:57:48] <iive> 2^6 palette encoded as rgb444.
[16:57:56] <BastyCDGS> BBB, how can I choose the mainline git reposity with git diff?
[16:59:02] <BBB> I have no idea :-p
[17:03:03] <BastyCDGS> I have found out that I can reference to master
[17:03:18] <BastyCDGS> but I don't get it a file not into repository comparing with master
[17:04:38] <janneg> I'm not sure what you want but it might be git diff origin/master
[17:07:21] <BastyCDGS> I want git diff on a local file not in repository with mainline repository
[17:07:30] <BastyCDGS> e.g. git diff /tmp/myfile.c origin/master
[17:08:56] <Rigolo> good afternoon ...
[17:09:14] <BastyCDGS> hi rigolo, how are u?
[17:09:19] <BBB> BastyCDGS: sorry, I have no idea, either wait for more git gurus to help or go use some google magic
[17:10:00] <Rigolo> I am fine ... but I have a quesion about vdpau in relation to ffmpeg/xbmc/tvheadend
[17:10:40] <Rigolo> on the tvheadend trac we have a ticket open about enabling vdpau acceleration for tvheadend datastreams on xbmc
[17:11:18] <Rigolo> as far as I can understand xbmc needs to have the video dimensions before it can determine if vdpau acceleration can be enabled
[17:11:36] <Rigolo> but these dimensions are contained inside the mpeg data it self ..
[17:12:22] <Rigolo> then I understood that there will be/is a new framework were the way vdpau works is going to be changed?
[17:12:33] <Rigolo> anybody can give me some information about that?
[17:13:28] <Rigolo> ideally you would like ffmpeg to see what kind of mpeg data it is receiving .. and based on that determine if it can use hw accel for decoding/displaying it
[17:13:39] <Rigolo> and not give dimensions upfront
[17:14:06] <Rigolo> with live TV these might be changing .. (well .. most likely only the aspect .. not the dimensions it self)
[17:15:31] <BastyCDGS> BBB, first patch submitted to ml
[17:15:33] <BBB> __gb__ could help you, I think you want to set AVCodecContext->pix_fmt to a hardware-based pixfmt, and then the decoder will reset it to a software pixfmt if it couldn't do hw, or reset it to its default
[17:15:33] <janneg> Rigolo: the playing application should be able to decide whether it can use vdpau without outside help
[17:16:23] <Rigolo> janneg: as far as I can understand it can do that by determine the dimensions upfront
[17:16:24] <janneg> BastyCDGS: you want to diff a single file against awhole repository or against a single file in the repository?
[17:16:53] <Rigolo> janneg: this might work for "recorded" data .. where the dimensions are available in the container .. but for live mpeg data that might be tricky to do
[17:16:58] <BastyCDGS> a single file outside repo against a single file inside repository
[17:17:29] <janneg> Rigolo: no, the video dimensions are also in the video data
[17:18:39] <Rigolo> janneg: correct .. in the sequence headers .. but i understood that in order to use vdpau as a decoder you need to have the dimensions available
[17:19:02] <Rigolo> janneg: and in order to get the dimensions you need a decoder (like vdpau) to get those
[17:19:55] <Rigolo> janneg: are you suggesting that the first mpeg data should be analysed with a non vdpau decoder .. in order to determine that vdpau can work?
[17:21:11] <janneg> BastyCDGS: git diff origin/master:file_a file_b
[17:23:43] <janneg> Rigolo: ffmpeg has parsers for that
[17:24:00] <BastyCDGS> janneg, git always says couldn't access file from master / origin, I tried origin:iff.c origin:libavcodec/iff.c and origin:/libavcodec/iff.c
[17:24:10] <BastyCDGS> the same with master instead of origin
[17:24:27] <Rigolo> janneg: okee ... but the idea is to analyse the mpeg data and based on that result start the vdpau decoder or not?
[17:24:48] <Rigolo> and how about this new framework for harware assisted acceleration?
[17:25:18] <kierank> mpc-hc does the same as well btw
[17:26:50] <janneg> BastyCDGS: git diff origin/master:ffmpeg.c ffmpeg_4k.c works as expected
[17:27:56] <janneg> Rigolo: I mainly wanted to point out that not using vdpau or any other (special) decoder is the players application fault
[17:28:27] <Rigolo> kierank: okee ... but this means an extra delay when you want to switch/watch HD encoded live TV .. because you need to parse a few frame's of mpeg data and based in that result start a specifc decoder
[17:29:23] <janneg> Rigolo: which data format do you stream to xbmc?
[17:29:45] <Rigolo> janneg: unaltered mpeg data from a dvb provider
[17:29:57] <Rigolo> janneg: so this can me mpeg2 or mpeg4
[17:30:14] <janneg> Rigolo: you can't prevent a couple of frames delay with b-frames
[17:30:29] <janneg> and the parser should only neeed the first frame
[17:31:00] <Rigolo> janneg: possibly ... but what if the aspect is changing later on?
[17:31:17] <Rigolo> janneg: like the station is going to a commercial break or something like that?
[17:31:21] <janneg> and we will be always a short delay after channel switches since you have to wait for keyframes
[17:31:23] <kierank> that's aspect ratio
[17:31:34] <kierank> resolution generally doesn't change that often
[17:31:45] <Rigolo> kierank: okee .. so aspect change is not a real problem with vdpau?
[17:31:46] <janneg> Rigolo: aspect ratio changes shouldn't cause problems
[17:32:31] <Rigolo> janneg: correct, but ideally you would to give ffmpeg the datastream .. and let ffmpeg figure out the best way to decoded/display that data
[17:32:42] <kierank> tv streams may also have AFDs so that AR changes don't have to lie on a i-frame
[17:34:19] <janneg> Rigolo: I still don't see how this is related to tvheadend
[17:34:52] <Rigolo> janneg: well .. people ask us to provide correct dimension data to xbmc so that xbmc can start the correct decoder
[17:35:20] <Rigolo> janneg: I also told them that we are not the "problem" as we just pass the data to xbmc
[17:35:22] <janneg> ignore them
[17:35:53] <Rigolo> janneg: but I like to give them a correct answer .. and determine where in the chain it should/can be solved
[17:36:50] <janneg> or if you're evil provide random/bogus data so that xbmc crashes if it relies on it
[17:37:23] <janneg> Rigolo: it's a problem within xbmc
[17:37:24] <Rigolo> janneg: well ... we try to play nice .. and stick to standards :-)
[17:37:46] <Rigolo> janneg: I can understand it is either within xbmc or with ffmpeg ...
[17:38:09] <janneg> or whatever xbmc uses for decoding
[17:38:11] <Rigolo> like i said .. ideally you would like ffmpeg to always use the best available decoder for specific content
[17:38:36] <Rigolo> xbmc is using ffmpeg
[17:38:51] <BastyCDGS> BBB: all 3 patches now on ml
[17:39:22] <janneg> Rigolo: it's not as simple as that, vdpau is not decoder in the classical sense
[17:39:57] <Rigolo> janneg: that I also understood .. and the whole hardware accelerated decoding is also still moving ...
[17:40:13] <janneg> it's a decoding and display system, i.e. it has to be setup correctly to be used
[17:40:48] <janneg> Rigolo: the player application has to do that
[17:41:35] <Rigolo> janneg: because it is both (decode and display)?
[17:42:12] <janneg> using vdpau if possible and otherwise falling back to software decoding works well in mythfrontend (without support of the backend)
[17:42:21] <janneg> yes
[17:44:03] <Rigolo> janneg: but that means that mythfrontend also parses the mpeg data before it starts vdpau?
[17:44:25] <kierank> and?
[17:44:28] <Rigolo> janneg: because in order to start vdpau you need dimensions?
[17:44:43] <Rigolo> kierank: no and .. just curious if that is the way it is implemented?
[17:59:36] <Rigolo> thx for the feedback and pointers/details ..
[17:59:54] <Rigolo> we will go back to xbmc developers and see what they would like to implement
[19:01:34] <j0sh> just got my gsoc acceptance *high five*
[19:02:33] <jai> don't want to leave you hanging ;)
[19:02:39] <jai> good for you
[19:02:52] <_av500_> \\\ooo///
[19:03:12] <jai> _av500_: so mentoring begins eh
[19:03:32] <_av500_> not me, but yes :)
[19:03:35] <Bagder> how many slots did ffmpeg get this year?
[19:03:48] <_av500_> 9 or so
[19:03:57] <Bagder> nice
[19:04:01] <_av500_> and rb?
[19:04:02] <j0sh> cool, that's pretty big compared to other projects?
[19:04:26] <Bagder> 4, and one of them is gonna be interesting to you guys too: "new WMA audio codecs"
[19:06:37] <_av500_> new and improved formula?
[19:07:11] <Bagder> I'm not a codec guy but its about fixed-pointing some of the WMA variations
[19:09:37] <jai> i guess wmapro mainly
[19:09:58] <jai> also, maybe this time we could try and get this upstream?
[19:09:59] * elenril throws RAS syndrome at Bagder 
[19:10:15] <mru> wmapro needs some serious optimisation work
[19:10:22] <Bagder> jai: ...
[19:10:24] <jai> j0sh: not really that huge a number
[19:11:02] <jai> Bagder: the work could be done as a clean patch which can be applied to trunlk
[19:11:05] <jai> *trunk
[19:11:18] <Bagder> no it can't
[19:11:27] <jai> why?
[19:11:32] <Bagder> it's a project for rockbox and we can't use ffmpeg codecs as-is
[19:11:51] <Bagder> we also have not even started discussing how to merge
[19:11:57] <jai> :/
[19:12:24] <Bagder> remember I was here like a month or two ago and tried to get some feeling for how to proceed on that...
[19:13:36] <Bagder> in general Rockbox hackers want to contribute back and ideally we could end up with something that would be useful for both project without custom hacks
[19:13:51] <jai> that would be awesome
[19:16:25] <Bagder> the rockbox guys I've talked to have however not felt any dedication from ffmpeg to receive this work, ie the words are mostly just "send us the patch", and that's not enough to motivate these guys
[19:17:08] <Bagder> (I'm not personally involved in codec development)
[19:21:33] <jai> Bagder: that sucks, i'm sure something somewhere was misinterpreted
[19:21:40] <jai> Bagder: was this discussion on the ML?
[19:21:47] <Bagder> no, here
[19:21:48] <jai> Bagder: or purely on irc?
[19:22:00] <Bagder> and it was just brief
[19:22:04] <jai> Bagder: maybe we can get a discussion going on the ML
[19:22:08] <jai> Bagder: ah
[19:22:51] <BBB___> jai, isn't it like 3AM for you?
[19:22:55] <BBB___> as in, shouldn't you sleep?
[19:23:07] <jai> BBB___: more like 01:00 :)
[19:23:17] <BBB> well I was close :)
[19:23:20] <jai> BBB: caffeine ;)
[19:23:52] <Bagder> the other day I got emailed from a 3rd party project wanting better ffmpeg fixed-point support that reminded me about this
[19:26:07] <jai> Bagder: if someone (saratoga?) does have time, it would be great if we can run a merge proposal on the ML
[19:26:17] <jai> more visibility too :)
[19:29:13] <Bagder> yes, but it'd have the drawback that we'd have to get all the interested parties join your mailing list, and I bet that gets a lot of stuff that isn't related to this
[19:29:28] <Bagder> ie people will hesitate
[19:30:08] <Bagder> I would suggest a dedicated list for the effort
[19:32:55] * mt joins the discussion
[19:33:34] <Bagder> mt: what do you think is a good way forward on this?
[19:34:49] <BBB> for fixedpoint codecs?
[19:34:50] <mt> I like the suggestion of a dedicated ML
[19:35:16] <Bagder> BBB: yes for fixed-point, getting rockbox stuff back in but also for making it more future-proof
[19:35:22] <BBB> there's a problem
[19:35:24] <BBB> too many MLs
[19:35:29] <BBB> that's great for fragmentation
[19:35:38] <BBB> but it also has the side-effect that many main (or new) developers won't sign up
[19:35:39] <Bagder> yes, but the opposite is also a problem
[19:35:45] <BBB> so you'll lose broad developer support
[19:35:52] <BBB> i.e. I won't read it
[19:36:03] <BBB> for ffmpeg, you sort of have to cherry-pick emails from the list
[19:36:09] <BBB> like LKML
[19:36:15] <Bagder> yes, but that's major downside
[19:36:35] <Bagder> for most mortals at least
[19:36:36] <mt> I'll be working on wma pro soon, so if there's any interest in rb-ff collaboration, we'd better move quickly
[19:39:24] <BBB> Bagder: I'm just telling you what others might tell you as well
[19:39:30] <BBB> be aware of it while asking/hoping for a new ML
[19:39:32] <Bagder> I realize that
[19:39:39] <BBB> and if the main developers aren't on the new list
[19:39:42] <BBB> nothing will ever happen
[19:39:50] <Bagder> but you and the others need to understand the other side
[19:40:19] <Bagder> the rockbox guys won't just a list with 95% unrelated matters flying by at high speed...
[19:40:22] <BBB> people like Michael tend to be more important because without them, the project wouldn't move - at all
[19:40:25] <Bagder> s/just/joun
[19:40:31] <Bagder> darnit, I can't type
[19:40:42] <BBB> so the question is, should it be convenient for you or for him/us? :)
[19:40:48] <BBB> anyway, just a thought
[19:40:50] <Bagder> exactly
[19:40:55] <Bagder> you always say YOU
[19:40:55] <BBB> feel free to propose the new list :)
[19:41:00] <BBB> haha :-p
[19:41:06] <CIA-7> ffmpeg: stefano * r22966 /trunk/libavdevice/v4l2.c: Return meaningful error codes, rather than always -1.
[19:41:07] <Bagder> and then we react with a kneejerk
[19:41:17] <mt> and then silence ..
[19:41:20] <Bagder> exactly
[19:41:37] <Bagder> so its a question if ffmpeg wants this to happen
[19:41:50] <BBB> probably
[19:41:51] <Bagder> and how we can meet to make it so
[19:43:03] <mt> I'm now thinking it's a little bit too early to discuss the matter of a mailing .. we should first gather the interested devs from both sides and they would decide how things should go.
[19:43:09] <mt> *mailing list
[19:43:25] <Bagder> you mean like an IRC meeting?
[19:43:30] <BBB> which codecs are we talking about here?
[19:43:41] <BBB> you guys have a fxp wma1/2dec right?
[19:43:44] <kierank> irc meetings are hillarious
[19:43:45] <mt> Bagder:  That's what I was thinking yes.
[19:43:47] <BBB> so this is about wmapro now?
[19:43:59] <Bagder> kierank: so what's the alternative?
[19:44:12] <kierank> nothing wrong with them per se, just funny to watch
[19:44:19] <kierank> esp. the mozilla ones with their agendas
[19:44:24] <kierank> run like it's a proper meeting
[19:44:58] <mt> I don't find that funny, I think it's effective. :)
[19:45:35] <mt> BBB: Mainly wma pro for now, as this is the one that should receive work soon.
[19:47:00] <jai> mt: where do you plan on hosting the code?
[19:47:05] <mt> Then in the future, new codecs would follow the same workflow (assuming one is ever  decided), but I'm not sure yet if there could be anything done regarding the old codecs.
[19:48:08] <mt> jai:  public git repo + rockbox trunk. But I guess rockbox trunk would be enough to follow the work.
[19:49:26] <jai> mt: okay
[19:54:10] <mt> Who - or about how many - would be interested to work on this anyway ? from ffmpeg devs I mean.
[20:01:54] <jai> i'm sure quite a few :)
[20:06:10] <bcoudurier> hi guys
[20:08:22] <janneg> bcoudurier: hi
[20:08:40] <BastyCDGS> damn have bad news
[20:08:57] <BastyCDGS> anyone read the idea about moving the calculation of the tables outside of the loop?
[20:09:19] <BastyCDGS> well I tried almost everything and it's either as fast as my first solution in the patch or slower
[20:09:22] <BastyCDGS> I dunno understand why
[20:09:44] <_av500_> ash cloud!
[20:09:51] <BastyCDGS> lol that it must be ;)
[20:10:26] <BastyCDGS> the overall result is: wasting 6,5 kb of memory for the static const tables for gain of absolutely nothing
[20:11:56] <BastyCDGS> anyone experienced here with L1/L2 cache stuff?
[20:12:16] <BastyCDGS> could it be the issue that each lut for each plane is exactly 64 bytes long (which is usually L1 cache line)
[20:12:57] <mru> cache aliasing isn't much of a problem anymore
[20:13:04] <mru> it was only an issue with old direct-mapped caches
[20:13:53] <BastyCDGS> if all these tables are loaded in the same cache line it has to flush everytime...should I try to make them 68 bytes long for a simple test and see if this changes anything?
[20:14:17] <mru> as I said, that's not an issue on a modern cpu
[20:14:35] <BastyCDGS> does the athlon xp+ count into this?
[20:14:43] <mru> on old cpus you had aliasing of addresses the size of the cache apart
[20:14:48] <mru> the full cache, not line
[20:15:03] <mru> I would think the xp+ has at least a 4-way L1
[20:15:22] <BastyCDGS> I'll just make a short test with 68, ok?
[20:15:45] <mru> if anything, that will make it slower
[20:17:21] <BastyCDGS> didn't change much
[20:17:35] <BastyCDGS> so what we do now?
[20:17:44] <BastyCDGS> do you accept my initial patch regarding this?
[20:17:55] <mru> not until I've understood what's going on
[20:17:57] <BastyCDGS> or should I provide a new one using static const table for all precalc?
[20:18:40] <mru> it just seems wrong to keep recalculating something that doesn't change
[20:20:03] <BastyCDGS> I wonder here as same as you probably do here...I can't really explain
[20:21:34] <iive> BastyCDGS: show us the code
[20:21:49] <BastyCDGS> ok will prepare a patch with the new
[20:21:55] <BastyCDGS> what method do you provide?
[20:22:05] <BastyCDGS> s/provide/prefer
[20:22:13] <iive> but have in mind that byte operations are usually painfully slow.
[20:22:28] <BastyCDGS> memcpy to local stack, pointer on local stack to static const or direct access to static const table?
[20:22:39] <BastyCDGS> these are all DWORD operations
[20:22:48] <BastyCDGS> it was byte before ;)
[20:22:54] <mru> please don't use microsoft-speak
[20:22:57] <BastyCDGS> that's why we got the huge speedup ;)
[20:23:06] <BastyCDGS> m$ this is asm
[20:23:13] <BastyCDGS> dword ptr
[20:23:14] <iive> masm :P
[20:23:53] <BastyCDGS> so tell me for which of these 3 methods I shall provide the patch?
[20:24:38] <mru> never memcpy
[20:25:32] <BastyCDGS> remains local stack pointer to static const table or direct access static const table
[20:28:15] <BastyCDGS> direct access okay?
[20:30:50] <CIA-7> ffmpeg: mru * r22967 /trunk/configure: Set ARCH=c with --disable-asm, fix build
[20:41:54] <BastyCDGS> both patches sent to ml
[20:59:10] <mru> BastyCDGS: what files do you use for benchmarking this?
[21:00:52] <BastyCDGS> just START/STOP_TIMER pair
[21:01:05] <mru> yes, but what file did you decode?
[21:01:22] <CIA-7> ffmpeg: rbultje * r22968 /trunk/libavutil/common.h: Write clip-related decimal numbers into hex, where they make more sense.
[21:01:36] <BastyCDGS> always the same, 24bpp = Ooze.iff, 8bpp = Heart.ILBM
[21:01:54] <mru> and where are those?
[21:02:00] <CIA-7> ffmpeg: rbultje * r22969 /trunk/libavutil/common.h: Reindent after r22968.
[21:02:51] <BastyCDGS> http://roundup.ffmpeg.org/issue1727
[21:02:58] <BastyCDGS> http://roundup.ffmpeg.org/issue1796
[21:23:05] <BastyCDGS> mru, what do you think about aligning the static const tables to a 64-byte boundary?
[21:23:15] <BastyCDGS> so it starts exactly at a cache line on most cpus?
[21:23:26] <BastyCDGS> have read that this can be a very good optimization?
[21:23:31] <mru> it can help
[21:24:32] <BastyCDGS> oh just read that my optimize-separation patch is commited to git ;)
[21:24:58] <BastyCDGS> what do your benchmarks say?
[21:25:06] <mru> haven't done them yet
[21:29:23] <BastyCDGS> lol just another hardy ffmpeg only update ;)
[21:29:41] <BastyCDGS> really funny that I'm getting this from the point on where I started developing at ffmpeg ;)
[21:35:03] <BastyCDGS> btw, I have thought of to make TuComposer officially be a part of ffmpeg
[21:36:07] <BastyCDGS> like with libswscale as an external repository
[21:36:55] <BBB> then we'd first have to review the whole thing
[21:37:08] <mru> no more externals please
[21:37:18] <BastyCDGS> of course, I will prepare the HDF files for uae soon
[21:38:15] <BastyCDGS> btw, BBB what's with my patches you wanted to commit? are they ok now?
[21:39:32] <BBB> they're good
[21:39:37] <BBB> I'm a little usy with things
[21:39:41] <BBB> but I hope to commit them sometime today
[21:40:20] <BastyCDGS> just want to get this stuff out of my head and go forward with a clean head ;)
[21:40:49] <BBB> so what was the final judgement on the const?
[21:40:56] <BBB> mru: let's vote
[21:41:05] * BBB wonders whether he's still awake
[21:41:32] <kierank> only 2240 over here
[21:41:48] <BBB> he might b watching some soccer match in a pub or so
[21:41:53] <BBB> never know for sure with those brits
[21:42:15] * BastyCDGS wonders how a simple const can be such a topic :P
[21:42:23] <mru> this is ffmpeg
[21:42:30] <mru> the smaller the topic, the hotter it gets
[21:42:33] <BBB> ah there he is
[21:42:39] <BastyCDGS> lol
[21:42:39] <BBB> mru: your vote decides: kill or keep?
[21:42:50] <BBB> if you're indifferent I'll keep it
[21:43:15] <mru> I don't care
[21:43:17] <BBB> ok
[21:50:58] <saintdev> mru: especially the bikeshed, that one is HOT
[21:50:59] <saintdev> =p
[22:01:51] <CIA-7> ffmpeg: cehoyos * r22970 /trunk/libavcodec/iff.c:
[22:01:51] <CIA-7> ffmpeg: Make two functions out of #define hackery.
[22:01:51] <CIA-7> ffmpeg: Patch by Sebastian Vater, cdgs D basty A googlemail
[22:03:02] <BBB> huh?
[22:03:03] <BBB> shit
[22:03:07] <BBB> now I have to recheckout
[22:03:13] <BastyCDGS> oh why?
[22:03:35] <BBB> cehoyos messed up my patches just before I was about to apply
[22:03:52] <BBB> anyway...
[22:03:52] <BBB> l
[22:03:53] <BBB> et'
[22:03:53] <BBB> s retry
[22:03:57] * BBB kicks IRC client
[22:08:07] <CIA-7> ffmpeg: stefano * r22971 /trunk/libavdevice/v4l2.c:
[22:08:07] <CIA-7> ffmpeg: Implement v4l2 input size autodetection in v4l2_read_header().
[22:08:07] <CIA-7> ffmpeg: Move check on frame size after the device is opened and after
[22:08:07] <CIA-7> ffmpeg: device_try_init() is attempted. If the provided size value is 0x0,
[22:08:07] <CIA-7> ffmpeg: perform a VIDIOC_G_FMT ioctl() on the device, which sets size to the
[22:08:07] <CIA-7> ffmpeg: current settings.
[22:24:12] <BastyCDGS> btw, before somebody forgets again, didn't you want to give me voice rights here now?
[22:24:42] <mru> there you go
[22:24:53] <BastyCDGS> merci ;)
[22:24:58] <astrange> it won't bring you much fame
[22:25:12] <Kovensky> now you have the DAU symbol! (according to #mplayer lore)
[22:25:30] <BastyCDGS> I know
[22:25:48] <Kovensky> and mru has the donut of the power
[22:25:49] <Kovensky> ._.
[22:26:38] <BBB> mru is our overlord, err, protector
[22:26:46] <kierank> defender of the faith
[22:27:39] <BBB> BastyCDGS: working on it...
[22:27:46] <BBB> compile takes a while on my crappymac
[22:28:22] <BastyCDGS> BBB, you must be telepathic, I was just thinking on how far you are with it
[22:28:39] <BBB> :)
[22:34:51] <BBB> still working...
[22:35:12] <BBB> ok, all works now
[22:35:53] <BastyCDGS> oh just got the invitation to gsoc students list
[22:41:12] <BBB> congratulations, you're in the program :)
[22:41:17] <BBB> so the patches are in now
[22:41:23] <BBB> somehow CIA-* didn't get that
[22:41:25] <BBB> (yet?)
[22:41:36] <BBB> if any patches are missing, let me know
[22:41:38] * BastyCDGS bows gracefully
[22:41:44] <BastyCDGS> *bong*
[22:41:48] <BastyCDGS> *ouch* :)
[22:41:50] * BBB kicks CIA-7 
[22:41:50] <CIA-7> ow
[22:41:57] <BastyCDGS> lol
[22:41:59] <BBB> hm, it didn't hang
[22:42:02] <BBB> ohwell
[22:42:05] <BBB> it's probably just slow
[22:42:31] * saintdev hugs CIA-7 
[22:42:31] * CIA-7 hugs saintdev
[22:42:58] * BastyCDGS greets CIA-7
[22:43:12] <BastyCDGS> no reply, pah
[22:43:31] * BBB slaps CIA-7
[22:43:38] <BBB> I guess the bot isn't very smart
[22:43:49] <saintdev> BBB: no, but...
[22:43:52] * saintdev eats CIA-7 
[22:43:52] * CIA-7 tastes crunchy
[22:43:57] <saintdev> it is crunchy :)
[22:43:59] <BBB> hehe :)
[22:44:21] * BastyCDGS greetz CIA-7
[22:44:24] <BastyCDGS> this way maybe?
[22:44:36] * _troll_ trolls CIA-7 
[22:44:44] * BastyCDGS gives fish to CIA-7
[22:44:50] <BastyCDGS> doesn't work also hmm
[22:45:58] * saintdev rubs CIA-7's tummy
[22:45:58] <CIA-7> *purr*
[22:48:12] <BastyCDGS> BBB, well my patches seem to be in:
[22:48:13] <BastyCDGS> http://git.ffmpeg.org/?p=ffmpeg;a=shortlog
[22:48:20] <BastyCDGS> it's just CIA...
[22:48:59] <BBB> that's ok
[22:49:05] <BBB> now how's that iff/anim patch coming along?
[22:50:41] <astrange> hmm vlc has 3 different projects to rewrite their mkv demuxer
[22:50:48] <BastyCDGS> as said before I go on with anim I will fix EHB/HAM
[22:50:58] <Kovensky> astrange: they have an mkv demuxer?
[22:51:03] <BastyCDGS> maybe I also fix 8SVX before
[22:51:40] <astrange> it might be a lavf wrapper, i haven't looked
[22:51:57] <saintdev> astrange: it uses libebml/libmatroska
[22:53:08] <BastyCDGS> BBB, you have applied the patch where I optimized decodeplane8/32 to a single-loop but still byte
[22:53:26] <BastyCDGS> should I redo my current patches with the newer opts then? since they expect the very old code
[22:53:31] <BastyCDGS> i.e. the double-loop
[22:54:47] <_troll_> yes, please updated your patches against current svn
[22:56:40] <BBB> patches should be against svn
[22:56:41] <BBB> so yes
[22:56:48] <BBB> and maybe start a new thread
[22:56:49] <BBB> I'm confused
[22:56:55] <Kovensky> git rebase ftw
[22:57:28] <BastyCDGS> good idea ;)
[22:57:41] <BastyCDGS> fuck
[22:57:41] <BastyCDGS> libavcodec/iff.c: needs update
[22:57:41] <BastyCDGS> fatal: Entry 'libavcodec/iff.c' not uptodate. Cannot merge.
[22:57:41] <BastyCDGS> Merge with strategy recursive failed.
[22:57:55] <BBB> welcome to merge hell ;)
[22:58:13] <BastyCDGS> just did git pull ;)
[22:58:14] <BBB> ok, good luck on that one, I'm going home, family's waiting :)
[22:58:20] <Kovensky> BastyCDGS: yes, that's why you don't just `git pull`, you do `git pull --rebase` :)
[22:58:35] <_troll_> and commit your changes first
[22:58:47] <Kovensky> undo the merge (`git checkout HEAD`), then do `git rebase origin/master`
[22:58:57] <Kovensky> and yes, make sure you have no non-stashed or committed changes
[23:20:41] <BastyCDGS> looked like i screw up my local repo...
[23:20:49] <BastyCDGS> just did rm -rf and doing a git clone
[23:20:53] * BastyCDGS looks ashamed
[23:27:35] <BastyCDGS> mru, shall I resend both patches? i.e. the one before the static const table outside and the other as well I did before this?
[23:45:39] <BastyCDGS> submitted all 4 patches to ml into a new thread as suggested
[23:45:43] <BastyCDGS> good night, goto bed now