[FFmpeg-devel-irc] IRC log for 2010-09-02

[irc at mansr.com]

[01:31:05] <BBB> Dark_Shikari: what is deblock_strength?
[01:31:25] <BBB> Dark_Shikari: is that useful for FFmpeg?
[01:40:36] <BBB> oh, I see, it's inline also
[01:40:40] * BBB needs to learn to grep better
[01:41:08] <Dark_Shikari> BBB: ffmpeg has that, and there are two core problems
[01:41:19] <BBB> A) it's inline asm
[01:41:21] <BBB> and B)?
[01:41:23] <Dark_Shikari> 1) deblock strength depends heavily on the structure of the internals of how data is stored in the decoder
[01:41:30] <Dark_Shikari> Fortunately, ffmpeg and x264 do it much the same way.
[01:41:39] <Dark_Shikari> 2) deblock strength is Special (TM) in a very bad way
[01:41:43] <Dark_Shikari> ffmpeg's has no C equivalent
[01:41:47] <BBB> ?
[01:41:53] <BBB> isn't that problematic?
[01:42:02] <Dark_Shikari> filter_mb_fast is a version of filter_mb that:
[01:42:06] <Dark_Shikari> a) only works in common situations
[01:42:12] <Dark_Shikari> b) calls asm versions of deblock strength
[01:42:19] <Dark_Shikari> thus it is only used if the asm version exists
[01:42:30] <Dark_Shikari> if I had unlimited time, here's what I'd change about ffmpeg:
[01:42:49] <Dark_Shikari> 1) Make deblock strength a C function so that the asm version has a C equivalent.  Then we can bug mru to write the asm.
[01:43:05] <Dark_Shikari> 2) Port the x264 asm to replace it (I'd be willing to LGPL it... pengvado wrote a little bit of it but he'd probably be happy)
[01:43:22] <Dark_Shikari> 3) Make filter_mb_fast work in all non-mbaff cases
[01:43:45] <Dark_Shikari> 4) merge filter_mb_fast and filter_mb entirely
[01:44:02] <Dark_Shikari> 5) do deblock strength directly after decoding each MB, store it per-row, and then use it to deblock per-row later
[01:44:12] <Dark_Shikari> this will give at least a 5% overall perf boost
[01:44:21] <Dark_Shikari> it eliminates the deblock fill_caches
[01:44:36] <BBB> mostly better cache usage, like you did for vp8
[01:44:39] <Dark_Shikari> No
[01:44:47] <Dark_Shikari> Currently, here's what happens:
[01:44:52] <Dark_Shikari> 1) fill caches for decode
[01:44:53] <Dark_Shikari> 2) decode
[01:44:59] <Dark_Shikari> 3) go onto the next mb
[01:45:01] <Dark_Shikari> (repeat repeat)
[01:45:08] <Dark_Shikari> 4) fill caches for deblock
[01:45:10] <Dark_Shikari> 5) deblock
[01:45:13] <Dark_Shikari> 6) repeat repeat
[01:45:17] <Dark_Shikari> Note that step 4 is ENTIRELY REDUNDANT.
[01:45:25] <Dark_Shikari> If deblock strength was calculated in 2), step 4) would be eliminated.
[01:45:28] <BBB> right
[01:45:35] <Dark_Shikari> Note that this is slightly tricky for two reasons
[01:45:49] <BBB> you need undeblocked data for intra pred?
[01:45:52] <Dark_Shikari> the caches used for decoding are not always the same as for deblocking
[01:45:57] <Dark_Shikari> there are two corner cases
[01:46:02] <Dark_Shikari> 1) deblocking across slice edges
[01:46:15] <Dark_Shikari> if( Neighbors Not Considering Slices != Neighbors Considering Slices ) { you need to reload top and/or left }
[01:46:22] <Dark_Shikari> 2) 8x8dct + cavlc nnz munging
[01:46:28] <Dark_Shikari> oh, and 3) weightp ref crap
[01:46:32] <Dark_Shikari> x264 does all three
[01:47:07] <BBB> hm...
[01:47:21] <Dark_Shikari> this isn't horribly difficult, it just makes it not completely trivial.
[02:20:37] <BBB> ok, the lf stuff itself was easy
[02:20:43] * BBB will submit a patch and then sleep
[02:21:07] <BBB> I'll leave the lf strength code for tomorrow, it looks different enough that I think it's worth (for now) just porting the existing code over
[02:21:38] <Dark_Shikari> the existing code accesses struct offsets
[02:21:47] <Dark_Shikari> in a gigantic mega-struct
[02:25:29] <BBB> I don't see that
[02:25:40] <BBB> you mean filter_mb_fast? or filter_strength?
[02:25:47] <BBB> filter_strength has mega-arrays
[02:25:51] <BBB> but so does x264's
[02:25:54] <BBB> no struct afaics
[02:38:47] <Dark_Shikari> I mean filter strength
[02:38:52] <Dark_Shikari> ..
[05:41:02] <Tjoppen> god morgon
[05:41:11] <kshishkov> god morgon
[05:42:10] * kshishkov just drank a bottle of Trocadero bought here in Malmö
[05:52:45] <Tjoppen> :)
[05:53:08] <thresh> moroning
[05:53:23] <Tjoppen> I'm in stockholm this week
[05:53:59] <kshishkov> I'd also be there this week
[05:55:03] <Tjoppen> why not?
[06:01:41] <merbanan> Tjoppen: we have to meet sometime then
[06:01:55] <merbanan> but now work
[06:02:13] <kshishkov> indeed (except for work of course)
[06:05:50] <Tjoppen> yes, I was about to suggest beer
[06:07:30] * kshishkov doesn't drink alcohol
[06:08:12] <Tjoppen> coffee?
[06:09:26] * kshishkov is not a typical Swede so he doesn't drink cofee as well
[06:09:59] <kshishkov> tee or something with umbrella would be fine
[06:10:08] <kshishkov> *tea
[06:10:59] <_av500_> long island ice tea
[06:12:15] <Tjoppen> :)
[06:56:58] <Tjoppen> "DRM interoperability"
[06:57:02] <Tjoppen> now there's an oxymoron
[06:57:46] <kshishkov> if I can't play file with any DRM, they are interoperable
[06:57:47] <mru> drm in itself is an oxymoron
[06:57:57] <ohsix> its also an acronym
[06:58:06] <mru> it's many acronyms
[06:58:17] <ohsix> users being able to create stuff in /dev can cause a lot of trouble
[06:58:37] <ohsix> digital radio mondiale is my fav
[06:58:48] <ohsix> err, misfire on the other message
[08:21:53] <saintdev> peloverde: you're going to have fun with this patch ;)
[08:24:43] <saintdev> peloverde: preliminary patch http://pastebin.org/797167
[08:26:21] <saintdev> hasn't been rebased on master yet, needs tuned, needs cleanup, etc
[08:26:53] <saintdev> but it works :)
[08:27:27] <saintdev> oh, and PE calculation is b0rked
[08:27:32] <spaam> why do you remove a line on the second hunk ?
[08:27:58] <saintdev> spaam: where?
[08:28:04] <spaam> line 24 in the paste
[08:28:32] <saintdev> dunno why that's there
[08:29:22] <saintdev> must have been a rebase or merge artifact from one of my other branches
[08:29:27] <spaam> ok :)
[08:34:13] <saintdev> really hope gabriel gets back to me on PE calculation. :/
[08:56:42] <lu_zero> good morning
[09:21:51] <av500> lu_zero: yourock!
[09:25:05] <Tjoppen> today's hack: using av_codec_get_tag() on the wav demuxer to fill in WAVEFORMATEX::wFormatTag based on a CodecID
[09:26:02] <mru> what uses a WAVEFORMATEX?
[09:26:08] <mru> that's a windows thing
[09:26:44] <Tjoppen> yep
[09:30:56] <lu_zero> av500: ?
[11:52:30] <CIA-11> ffmpeg: cehoyos * r25023 /trunk/libavformat/avidec.c:
[11:52:30] <CIA-11> ffmpeg: Fix crash when decoding DV in AVI introduced in r24579 (issue 2174).
[11:52:30] <CIA-11> ffmpeg: Patch by Andrew Wason, rectalogic rectalogic com
[11:54:14] <CIA-11> ffmpeg: cehoyos * r25024 /trunk/libavformat/avidec.c: Cosmetics: Reindent after r25023.
[13:40:06] <BBB> wbs: are you on ffmpeg-soc-mentor?
[13:41:14] <wbs> BBB: no
[13:44:15] <wbs> BBB: sent subscription request
[13:44:20] <superdump> received
[13:44:23] <superdump> so you're martin?
[13:44:25] <wbs> yeah
[13:44:30] <superdump> are you a mentor?
[13:44:37] <wbs> yes
[13:44:48] <superdump> were you unaware of the list before? :)
[13:44:55] <wbs> nobody told me about it :-)
[13:44:55] <superdump> it seems like it's a bit late now
[13:44:57] <superdump> hehe
[13:44:59] <superdump> fair enough
[13:45:20] <superdump> one moment
[13:46:54] <superdump> done
[13:46:56] <wbs> thanks
[13:46:59] <superdump> welcome
[13:51:28] <wbs> thanks :-)
[14:20:52] <mru> rotfl, someone at nds is asking me about consulting
[14:20:55] <mru> that's irony
[14:21:07] <av500> why?
[14:21:15] <av500> that how it works
[14:21:27] <av500> make them pay dearly
[14:21:29] <mru> it's irony every time
[14:28:58] <BBB> what is nds
[14:29:19] <mru> my former employer
[14:30:50] <BBB> sounds like you didn't quite leave udner good terms?
[14:31:30] <mru> they all but asked me to leave
[14:35:01] <KotH> well, what would you do with someone who has a shotgun, a raised floor and a very short temper?
[14:35:03] <BBB> hm...
[14:35:23] <BBB> KotH: I'd be friends with him
[14:35:28] <BBB> then hopefully he'll shoot at someone else
[14:35:47] <BBB> mru: can you make configure output a config.asm in yasm style on x86?
[14:35:57] <BBB> when yasm is enabled I guess
[14:36:07] <mru> BBB: sure
[14:36:11] <BBB> \o/
[14:37:11] <mru> what do you need it for?
[14:39:07] <BBB> to enable compiler hacks in h264_deblock.asm, and it'd be nice if I could also use it to check for CONFIG_xyz_DECODER and disable particular parts of h264_chromamc.asm (e.g. rv40-specific mc funcs if RV40 is disabled, or same for vc1)
[14:39:42] <BBB> I guess the compiler-hack means we need a configure check to see if compiler-xyz aligns the stack to 16-bytes
[14:39:47] <superdump> mru: are they asking you for consultation because you're the only one who can fix it? :)
[14:39:57] <mru> BBB: impossible to check
[14:40:04] <BBB> ?
[14:40:26] <mru> you have to enumerate all known-good compilers
[14:40:35] <BBB> fine with me
[14:40:40] <BBB> gcc and icc>11 or so
[14:40:55] <BBB> oh shit I was going to check if clang -align-stack=16 works
[14:41:02] <BBB> or something
[14:42:19] <mru> do that first
[14:42:25] <mru> if it works we'll just add that
[14:48:31] <mru> superdump: no, this was apparently something ffmpeg-related
[14:48:47] <superdump> o rly? interesting
[14:49:21] <kierank_> they want a libvideoguard
[14:49:50] <mru> I doubt they're letting anywhere near the CA parts
[14:50:05] <mru> more likely they're adding support for random media file playback
[14:50:24] <mru> nds are always 5 years late with new features
[14:50:35] <mru> and then they pretend they invented it
[14:50:39] <mru> a bit like apple
[14:50:45] <mru> but with less style
[14:51:16] <kierank_> also they are big fans of the "walled garden" like apple
[14:51:46] <mru> kierank_: only way CA can work
[14:52:55] * av500 once made strange TS files from NDS play
[14:54:11] <kierank_> take the hdd out and feed the TS file through a decryption thingy
[14:54:31] <av500> no, they were not crypted, just somewhat strange
[14:55:04] <wbs> aka (unintentional?) security by obscurity ;P
[14:55:40] <mru> they do admit CA is nothing but security by obscurity
[14:56:00] <mru> which is probably why they make a rather good one
[14:56:04] <av500> no, something like no PAT inside and the PIDS in a separate text file
[14:56:13] <mru> that's not a TS then
[14:56:36] <av500> i guess it came out of a STB and the STB kept PIDs in a separate place
[14:57:27] <mru> STBs often keep PID tables for lots of channels so they don't have to wait for PSI when zapping
[14:57:58] <av500> it was not hard to make them play...
[14:58:34] <mru> I doubt making them hard to play was the intention
[14:58:57] <av500> no, it was for an IBC demo or so
[15:18:40] <BBB> astrange: what was the clang compiler option again for stack alignment?
[15:18:46] <BBB> sorry, I forgot
[15:40:40] <CIA-11> ffmpeg: cehoyos * r25024 /trunk/libavformat/avidec.c: Cosmetics: Reindent after r25023.
[15:40:41] <CIA-11> ffmpeg: mru * r25025 /trunk/tests/fate.sh: fate: delete log files ahead of each run
[16:14:04] <peloverde> BBB: Did you try "-mpreferred-stack-boundary"? That's what it is in gcc
[16:26:42] <BBB> trying now... takes a while
[16:28:49] <BBB> clang: warning: argument unused during compilation: '-mpreferred-stack-boundary'
[16:34:49] <Tjoppen> wait a minute..
[16:35:26] <Tjoppen> kshishkov: you said you were in malmö, but hinted at being in stockholm. or are you going there for tomorrow or something?
[17:54:08] <lu_zero> -stack-alignment ?
[17:54:44] <mru> with -mllvm probably
[17:57:52] <lu_zero> the manpange I'm reading probably is wrong
[17:58:12] <lu_zero> or at least doesn't match my clang
[18:16:59] <astrange> BBB: -mllvm -stack-alignment=16
[18:17:57] <astrange> the order of help lists for this is clang -cc1 -help (which is itself not documented) and lli -help (which needs llvm tools)
[18:19:12] <mru> and does it work?
[18:23:07] <cartman> astrange: whats -mllvm?
[18:23:17] <cartman> same as -emit-llvm ?
[18:23:21] <mru> no
[18:23:32] <mru> -mllvm passes the next option down to the internals
[18:23:37] <cartman> ah
[18:23:41] <cartman> thanks mru
[18:23:53] <cartman> btw why is stack alignment of 16bytes is needed?
[18:24:05] * cartman tries to learn
[18:24:16] <mru> sse load/store instructions need it
[18:24:36] <cartman> ah true, but you do the alignment trick yourself in the code, no?
[18:24:54] <mru> no need if the compiler does it for free
[18:25:02] <cartman> doesn't it slow down?
[18:25:17] <mru> no
[18:25:19] <cartman> I heard gcc will have SSE alignment by default
[18:25:26] <cartman> guess it'll do this automatically
[18:25:27] <astrange> no but it uses a little more stack space per function call
[18:25:38] <mru> if the compiler always allocates stack frames in multiples of 16, you get alignment for free
[18:25:39] <cartman> astrange: ok, also its the default for x86-64 right?
[18:25:44] <mru> if it is aligned at some point
[18:26:03] <astrange> yes
[18:26:05] <cartman> cheers :>
[18:26:11] <astrange> default on x86-64 and on darwin
[18:26:29] <cartman> but if gcc changes this, doesn't it change the ABI ?
[18:26:29] <mru> and ppc
[18:26:47] <mru> the x86_64 official ABI requires aligned stack
[18:26:50] <mru> x86_32 doesn't
[18:27:03] <mru> now some people take whatever gcc does as the ultimate truth
[18:27:04] <cartman> oh k
[18:27:08] <cartman> :>
[18:27:10] <mru> and call anything else broken or buggy
[18:27:34] <mru> imo we have to deal with whatever the abi says, whether we like it or not
[18:27:50] <cartman> one more question since you guys known this stuff
[18:28:05] <cartman> why do people implement Itanium ABI, the Itanium CPU was never widespread use
[18:28:31] <mru> who does?
[18:28:43] <cartman> I think gcc does implement it for C++ =
[18:28:46] <cartman> s/=/?
[18:28:57] <mru> gcc supports ia64 so it has to
[18:29:06] <cartman> ah
[18:29:10] <cartman> nothing special then
[18:29:22] <mru> for certain values of support
[18:30:04] <DonDiego> say
[18:30:18] <DonDiego> has anybody answered the grabnetworks consulting request?
[18:30:45] <mru> I have my hands full with serious clients
[18:31:17] <DonDiego> i'll drop them an email
[18:32:02] <kierank> lol grabnetworks make anystream
[19:02:19] <BBB> astrange: thank you
[19:02:32] <BBB> re-compiling and then on to testing
[19:06:24] <BBB> yes, fixes it also
[19:06:47] <BBB> mru: can you add that to configure in some acceptable way?
[19:07:52] <mru> I'll try
[19:08:01] <BBB> thanks
[19:08:04] <BBB> I can test patches
[19:08:07] <mru> what is the exact flag that's needed?
[19:08:15] <BBB> -mllvm -stack-alignment=16
[19:08:39] <BBB> that fixes about 60 fate tests related to h264
[19:18:37] <CIA-11> ffmpeg: reimar * r25026 /trunk/libavformat/matroskadec.c: Optimize/simplify ebml_read_num.
[19:33:05] <mru> BBB: does that work with llvm-gcc goo?
[19:33:06] <mru> too
[19:35:26] <BBB> what's llvm-gcc?
[19:35:56] <mru> llvm backend with gcc frontend
[19:36:50] <mru> we still have the inline asm problem too
[19:37:35] <astrange> which inline asm problem?
[19:37:41] <mru> the one that clang doesn't compile
[19:37:56] <astrange> dunno what to do about that one
[19:38:07] <BBB> neither do I :(
[19:38:22] <mru> my suggestion would be to fix it
[19:38:24] <BBB> michael doesn't appear to want to add a function call and, well, rewriting that stuff in yasm will take me a while
[19:38:26] <mru> but michael didn't want that
[19:38:28] <astrange> even newer clang won't compile most of the asm without -no-integrated-as because their new as doesn't support 3dnow
[19:38:41] <BBB> pff...
[19:38:43] <BBB> :-p
[19:38:55] <astrange> i think there's a bug on that one
[19:39:34] <mru> yes, but they won't fix it
[19:40:09] <BBB> they won't fix anything
[19:40:17] <BBB> "doesn't open source mean users submit patches?"
[19:40:25] <mru> they == apple?
[19:40:34] <BBB> I thought apple was leading llvm dev?
[19:40:42] <mru> apple isn't very open
[19:40:52] <astrange> llvm development is open
[19:40:57] <BBB> awesome
[19:41:03] <BBB> thanks mru
[19:41:08] <CIA-11> ffmpeg: mru * r25027 /trunk/configure: Add -mllvm -stack-alignment=16 to CFLAGS when using clang
[19:41:16] <BBB> let's see half of clang yellow go away in fate
[19:41:22] <mru> it won't
[19:41:25] <astrange> 3dnow will never be shipped again though so it's only needed to compile dsputil
[19:41:30] <mru> only one clang config has the problem
[19:41:40] <mru> the others are either red or green
[19:42:03] <BBB> I know
[19:42:08] <BBB> but half of that yellow will go away
[19:42:25] <BBB> on the linux clang, it fixes 60 of 131 fate failures
[19:42:31] <BBB> (if you bypass the mpegvideo compile problem)
[19:42:32] <mru> not until someone kicks the machine
[19:42:39] <BBB> update clang
[19:42:45] <BBB> maybe it's an old clang version bug
[19:44:43] <mru> all pass for me
[19:45:59] <BBB> depends on the clang version
[19:46:25] <BBB> clang trunk apparently has a problem, but older clang versions don't misuse ecx, instead use edi
[19:46:27] <BBB> then all tests pass
[19:46:38] <BBB> I couldn't quite trace it down to which version does what
[19:46:50] <mru> I used r112656
[19:47:33] <cartman> I use pretty recent clang too
[19:48:01] <BBB> hm... that's newer than the one showing the problem for me
[19:48:06] <BBB> that's 112587
[19:48:13] <BBB> ok, well, maybe fbsd will go green then
[19:48:13] <BBB> who knows
[19:48:26] <mru> not until michael kicks the machine back into action
[19:53:55] <BBB> I consider it fixed
[19:53:58] <BBB> next :-p
[19:54:08] <BBB> I guess I'll move h264 idct to yasm or so
[20:38:53] <mru> wtf, that magically made the inline asm compile too
[20:40:09] <mru> but it crashes on some tests
[20:45:36] <BBB> which?
[20:45:42] <BBB> and how many?
[20:45:59] <mru> bunch of h264 tests
[20:46:05] <mru> probably what you saw before
[20:46:12] <BBB> 70
[20:46:14] <BBB> that's the ecx bug
[20:46:22] <BBB> (probably)
[20:47:01] <BBB> try the same fix for gcc-llvm?
[20:47:04] <BBB> "fix"
[20:48:02] <BBB> http://fate.ffmpeg.org/i686-pc-cygwin-gcc-4.2/20100902152935 is broken
[20:48:05] <BBB> it says configure failed
[20:48:09] <BBB> but it did not fail
[20:48:25] <mru> it did
[20:48:37] <mru> the logs are bogus
[21:41:57] <CIA-11> ffmpeg: mru * r25028 /trunk/configure: Detect llvm-gcc and set appropriate flags
[22:45:08] <BBB> mru: you rock
[22:45:12] <BBB> only one red entry in fate