[FFmpeg-devel-irc] IRC log for 2010-09-18
irc at mansr.com
irc at mansr.com
Sun Sep 19 02:00:52 CEST 2010
[07:04:15] <superdump> benoit-: ping? there's a mail from marcelo about amr-wb pending authorisation on ffmpeg-devel because of its size
[07:13:14] * superdump -> out
[07:47:24] <Vitor1001> Any ffmpeg-devel moderator here to approve Marcelo's message?
[10:23:44] <DonDiego> x86/fft_mmx.asm:47: warning: section flags ignored on section redeclaration
[10:30:44] <DonDiego> jannau: i notice you're procrastinating on latm again..
[10:30:47] <DonDiego> tsk, tsk
[10:36:39] <lu_zero> yawn
[14:40:07] <BBB> Dark_Shikari: ping
[15:05:05] <cartman> since this channel is silent...
[15:05:10] <cartman> "I have embedded the Google Map in my site but I dont know how to locate my Factoryâs Location.Can you please help me in including the address of my Factory."
[15:05:13] <cartman> lol
[15:05:51] <kshishkov> has he ever heard about longtitude and latitude thingies at school?
[15:06:08] <mru> maybe he should try using a LocationFactory object
[15:06:11] <cartman> not sure ;)
[15:06:41] <mru> BBB: working on xvp8 yet?
[15:07:16] * kshishkov has better chances writing wvp decoder first, it seems
[15:07:25] <BBB> kshishkov: let's do a contest
[15:08:13] <kshishkov> BBB: well, you can also ask pross-au to finish implementing BIKb decoder
[15:12:38] <cartman> no useful decoder left to write?
[15:15:19] <kshishkov> cartman: depends on your definition of "useful"
[15:15:55] <cartman> used by >%1 of audio/video files
[15:16:42] <kshishkov> where's the table?
[15:17:18] <kshishkov> (otherwise how I'd know if it's used by >=1% of files or not)
[15:17:56] <cartman> even google doesn't know wtf BIKb is
[15:17:59] <cartman> thats a good start :P
[15:18:52] <kshishkov> that's beta version of Bink decoder used in several NWC games
[15:19:31] <cartman> you guys never get bored of this game audio/video stuff
[15:19:34] * cartman blames Mike
[15:20:07] <kshishkov> well, that's kind of stuff you can't play easily with some other player
[15:22:11] <cartman> true
[15:26:05] <jannau> DonDiego: not again, still!
[16:23:28] <Vitor1001> mru: Is there any reason we don't have anymore a ICC/x86_32 fate conf?
[16:23:50] <mru> I can't figure out how to make it work on a 64-bit linux host
[16:24:05] <Vitor1001> :p
[16:24:28] <Vitor1001> mru: Doesn't it have completely separated binaries for both?
[16:24:34] <kshishkov> it's not better on Windows though
[16:24:43] <mru> no idea how it's meant to work
[16:24:46] <Vitor1001> Something like bin/ia{32,64}/icc ?
[16:25:11] <mru> icc -m32 aborts with some error about the 32-bit something missing
[16:25:38] <Vitor1001> Ok, I see...
[16:26:55] <Vitor1001> Maybe Michael Kostylev has a x86_32 host, I'll ask him...
[16:27:07] <mru> or maybe it can be installed somehow
[16:27:29] <mru> but I'm not in the mood for sifting through miles of hacky scripts to figure out how
[16:27:46] <Vitor1001> If it works out-of-the-box for him, we save developer time ;)
[16:28:11] <Vitor1001> Do you have "bin/ia32/icc" somewhere in your box?
[17:23:40] * mru likes beating people with the C spec
[17:24:00] <BBB> /nick _troll_?
[17:24:07] <mru> Vitor1001: did you send that request to pgi btw?
[17:24:09] * kshishkov prefers beating people with something heavier
[17:24:15] <mru> shovel
[17:24:56] <cartman> one of the knuth's books
[17:25:04] <kshishkov> that'd be good
[17:25:10] <cartman> too heavy
[17:25:17] <kshishkov> nope
[17:25:36] * kshishkov has three tomes of TAoCP in .ua
[17:26:16] <kshishkov> though I'd prefer printout of specs and/or source code produced by people in metal cover
[17:26:53] * kshishkov has something to say to DTS creators, maybe with shovel
[17:43:58] <BBB> hm...
[17:44:57] <mru> mh?
[17:57:08] <cartman> kshishkov: dts spec that bad?
[17:57:43] <mru> cartman: you have no idea
[17:57:47] <mru> dts-hd
[17:57:49] <cartman> possibly :D
[17:57:52] <cartman> I am glad :D
[17:58:14] <mru> the etsi spec for plain dts is almost readable
[18:02:23] <Vitor1001> mru: Yes, I sent it
[18:08:05] <kierank> mru: don't forget dts-hd ma and dts-lbr ;)
[18:09:53] <kshishkov> kierank: dts-hd ma is the worst part of it
[18:10:33] <kshishkov> not to mention that you can't implement decoder with it - it omits both data and algorithms
[18:10:43] <kshishkov> and lies in very creative ways
[18:11:17] <kierank> write a corrected spec ;)
[18:11:48] <kshishkov> too lazy to write specs
[18:12:21] <cartman> kshishkov: what kinda people write a lying spec?
[18:12:21] <kierank> if you submit it as an erratum etsi or whoever will have to acknowledge it
[18:12:37] <kshishkov> cartman: DTS creators, for instance
[18:12:47] <cartman> kshishkov: what would be the motive really?
[18:12:48] <kshishkov> kierank: I don't think it's ETSI
[18:12:52] <cartman> just don't write a spec damn it
[18:13:18] <kierank> cartman: like NUT
[18:13:25] <kshishkov> well, some people think it's for creating illusion of openness while not allowing you to create independent decoder
[18:13:27] <cartman> kierank: LOL
[18:13:43] <cartman> kshishkov: bleh :)
[18:13:52] <cartman> stupid people
[18:16:07] <kshishkov> even mru should remember that wonderful gem from it with variables named M, N, 0 (that's zero)
[18:16:37] <cartman> hahah :D
[18:18:25] <kierank> basty seems to have disappeared from the face of the earth
[18:22:32] * mru does not miss him
[18:30:35] <jenk> 0 is not such a bad name if it contains zero
[18:30:39] <jenk> like $zero on mips
[18:30:39] <kierank> kshishkov: you should make a dts-hd decoder that decodes just the core but reports that the audio's lossless just to read the reviews from the audiophiles
[18:31:14] <cartman> $zero is good
[18:33:42] <kshishkov> kierank: feel free to "upgrade" lavc decoder.
[18:34:01] <kshishkov> cartman: it's used as loop variable
[18:34:11] <cartman> kshishkov: LOL
[18:34:41] <kierank> michael would probably allow the patch under AUDIOPHILE_KIDDY_MODE
[18:35:38] <kshishkov> first send a patch to make it global configuration variable
[18:36:11] <kshishkov> so all audio would produce true 32-bit sound, etc
[18:36:18] <kshishkov> *audio decoders
[18:39:57] <BBB> Dark_Shikari: ping
[18:40:10] <BBB> kierank: I'm not susprised
[18:40:26] <BBB> kierank: he basically didn't get much done during soc, had this huge tree which he expected us to import into svn
[18:40:33] <BBB> kierank: and then we say no and he disappears
[18:40:47] <BBB> it's one of those things where it's sad the project didn't succeed, but it just wasn't even a tenthway done
[18:43:31] <BBB> or pengvado: ping
[18:43:55] <kshishkov> BBB: it wasn't tenthway done with tenfold ratio of unneeded code too
[18:44:14] <BBB> pengvado, Dark_Shikari: if a function in yasm has more than 7 arguments (yeah yeah I should fix the caller), how do I access the remainder of the arguments?
[18:44:34] <kshishkov> from stack
[18:44:42] <BBB> on x86-64 too?
[18:44:56] <kshishkov> could be
[18:44:57] <BBB> I was hoping yasm had some useful helper macros for that
[18:45:35] <pengvado> x86inc has macros up to r8m
[18:46:43] <BBB> hm, this function ha 10 arguments
[18:48:42] <BBB> ok that's easy enough
[18:48:44] <BBB> pengvado: thanks
[18:59:34] <mru> BBB: args after some number are on stack on x86_64
[18:59:40] <mru> don't remember how many are in regs
[18:59:52] <kshishkov> four
[18:59:58] <_av500_> 54
[19:00:20] <mru> _av500_: your cpu must have many regs
[19:00:29] <kshishkov> _av500_: tomorrow I'm going to the town where the biggest FFmpeg contributor lives
[19:00:44] <_av500_> kshishkov: ah cool
[19:00:50] <_av500_> why did you not say before
[19:01:05] <cartman> kshishkov: who is it?
[19:01:05] <kshishkov> well, I decided that today
[19:01:27] <kshishkov> cartman: he's active on this channel right now ;)
[19:01:55] <cartman> kshishkov: some av guy? :P
[19:02:06] <kshishkov> cartman: bingo
[19:02:17] <_av500_> cartman: id guess one can hide the rest of ffmpeg behind kshishkov and me
[19:02:23] <cartman> kshishkov: kick him for me, for all the damn jokes :P
[19:02:52] <kshishkov> cartman: you know, I'm rather on Serbian side of affairs with Turkey
[19:02:57] <kierank> troll his town too
[19:03:10] <_av500_> kshishkov: :)
[19:03:12] <cartman> kshishkov: I am a global guy, assume I am a Martian
[19:03:16] <cartman> any better now?
[19:03:24] <_troll_> hmm, maybe I should join
[19:03:29] <cartman> lol
[19:03:52] <kshishkov> cartman: the only known Martian serves his term as a mayor of Kiev (capital of Ukraine if you forgot)
[19:03:59] <cartman> kshishkov: what grudge do you hold against Turkey anyway? :D
[19:04:13] * cartman has his own reasons
[19:04:21] <_av500_> _troll_: thing is, i am a bit occupied, since the mrs is taking casre of the 3d old
[19:04:39] <cartman> _av500_: you win this round
[19:04:51] <_troll_> _av500_: ah, so he arrived
[19:04:56] <_av500_> she did
[19:05:01] <_troll_> oh, it's a she
[19:05:05] <cartman> 3D kids
[19:05:06] <cartman> nice
[19:05:19] <kshishkov> cartman: nothing particular, except all that Turkish stuff (i.e. low-grade crap) that was sold in .ua in 90s
[19:05:26] <_av500_> yeah, works without shutter glasses
[19:05:31] <cartman> kshishkov: we can be friends again!
[19:05:56] <_av500_> cartman: i dont hold a grudge either, you left good food and coffee when you left...
[19:06:08] <kshishkov> cartman: also believe me, av500 is quite 3-dimensional, you can see that without special glasses
[19:06:18] <cartman> kshishkov: lol
[19:06:22] <cartman> _av500_: good good :)
[19:06:29] * cartman is not fund of Ottomans though
[19:06:30] <_troll_> _av500_: what about next weekend?
[19:06:54] <_av500_> _troll_: need to check, there is a trip to paris in planning to
[19:07:00] <kshishkov> _av500_: I'd believe in good coffee but food?
[19:07:16] <_av500_> kshishkov: yes
[19:07:29] <_troll_> kshishkov: they left all the good food there
[19:07:41] <cartman> _troll_: you got kebab
[19:07:48] <cartman> thats not what I would call good though ;)
[19:07:49] <kshishkov> cartman: that's his point
[19:07:55] <_av500_> its for a reason that i can read half of a turkish menu
[19:08:01] <cartman> _av500_: lol :(
[19:08:02] <cartman> :)
[19:08:22] <cartman> kshishkov: Kebab is like fast-food to us
[19:08:34] <_troll_> cartman: it is here too
[19:08:39] <_av500_> +1
[19:08:41] <kshishkov> _av500_: and I can read both halves of serbian menu
[19:08:46] <_troll_> "here" being rather vague when /me speaks
[19:08:50] <_av500_> ocourse
[19:08:50] <cartman> if you ever visit Turkey, I can have better recipes
[19:09:11] <_troll_> I've had nice turkish food too
[19:09:15] <_troll_> even KotH approved of it
[19:09:19] <cartman> oh nice
[19:09:31] <cartman> KotH knows the right stuff of course
[19:09:46] <_troll_> I trust KotH's judgement when it comes to food
[19:09:50] <_troll_> and chocolate
[19:10:01] * cartman is too fat to be trusted on that
[19:10:07] * kshishkov prefers his stomach to judge
[19:10:22] <_av500_> _troll_: ah, just had some of KotH judgement too
[19:11:03] * cartman notes KoTH is not a typical Turkish guy, thats being a good thing :P
[19:11:27] <_troll_> cartman: he's lived in .ch his entire life
[19:11:42] <_av500_> hes a pretty typical swiss for a turk
[19:11:57] <kshishkov> cartman: I heard that in .de typical guys from Russia are worse than Turks. I can believe that too
[19:12:24] <_av500_> kksthey are not russian, they had a german shephard once
[19:12:31] <kshishkov> _av500_: says our guys born in Flugplatsdorf
[19:12:31] <_av500_> kshishkov: they are not russian, they had a german shephard once
[19:13:00] <kshishkov> _av500_: not necessarily, could be "Jewish"
[19:13:11] <_av500_> jewish shepherd?
[19:14:18] <_av500_> kshishkov: flugwat?
[19:14:47] <kshishkov> when I lived in .ua I got such "Jewish" neighbour (kicked out) from Germany, he was bad even by local standards
[19:15:13] <kshishkov> _av500_: sorry, Flughafendorf - a village near airport
[19:15:33] <cartman> kshishkov: when we go to the south for summer holidays, we avoid hotels who have lots of Russians
[19:15:41] <cartman> if they drink heavily thats bads
[19:15:42] <cartman> -s
[19:16:12] <kshishkov> yes, nowadays even Turks grow tired of Russians
[19:16:23] <cartman> yeah amazing
[19:16:35] <cartman> they outfoxed Turks :P
[19:16:49] <_av500_> _troll_: btw, i nudged rob to sumit
[19:16:50] <kshishkov> I heard that the only thing worse than Russian tourist is German tourist though I don't know why
[19:16:52] <_av500_> err, submit
[19:17:20] <cartman> kshishkov: lol
[19:17:21] <_troll_> _av500_: as if that will speed up the review
[19:17:38] <Vitor1001> BBB: I'm getting a segfault on ff_hadamard8_diff_sse2() on ICC, do you have any idea of what might be happening?
[19:17:54] <_troll_> Vitor1001: 32-bit?
[19:18:07] <cartman> more bits needed
[19:18:10] <Vitor1001> 32-bit
[19:18:56] <_av500_> _troll_: sure, but out in the open is better than someplace
[19:19:02] <kshishkov> _av500_: BTW, what you can say about your native town except that it's purpose to serve airport with idiotic layout and banks?
[19:19:12] <Vitor1001> ff_hadamard8_diff_mmx works fine
[19:19:16] <BBB> Vitor1001: can you send me a backtrace, disass of the crashing function, info all-registers and put it on roundup?
[19:19:24] <_av500_> kshishkov: you go visi
[19:19:34] <BBB> or send it by email
[19:19:39] <_troll_> Vitor1001: does it need aligned stack?
[19:19:39] <_av500_> kshishkov: you ignore city centre and just head up to mathildenhöhe
[19:19:49] <kshishkov> _av500_: I will, but I was warned that I may dislike it
[19:19:56] <_av500_> blame to us for firebombing most of it
[19:20:04] <_av500_> blame the US ...
[19:20:16] <Vitor1001> _troll_: No idea :(
[19:20:22] <BBB> hadamard_sse2 indeed requires aligned stack
[19:20:24] <_troll_> Vitor1001: ask gdb
[19:20:25] <BBB> what version of icc?
[19:20:36] <BBB> doesn't icc have some arg to make it align stack?
[19:20:43] <BBB> (like clang)
[19:21:04] <BBB> Vitor1001: sorry for breaking, I can imagine debugging this isn't too much fun...
[19:21:07] <Vitor1001> BBB: 11.1
[19:21:08] <kshishkov> _av500_: well, German bombing was the most horribble, for example some parts of St.Putinsburg are still not rebuilt. And look at München.
[19:21:17] <_av500_> kshishkov: most of what was rebuilt after 45 is of course fugly
[19:21:20] <Vitor1001> BBB: I have no idea if it was working before ;)
[19:21:27] <_av500_> kshishkov: i am not blaming
[19:21:34] <_av500_> just explainig why it looks like that
[19:21:36] <BBB> 11.1 is the one with breakage in stack alignment
[19:21:46] * cartman is going to Munchen hopefully
[19:21:49] <BBB> see h264dsp_mmx.c
[19:22:05] <BBB> it enables deblock sse2 only for icc>11.1 also
[19:22:11] <BBB> we might have to do the same for hadamard_sse2
[19:22:27] <Vitor1001> BBB: Ok, I see. Maybe indeed it would be needed.
[19:22:28] <BBB> it'd be better if we could figure out how to align the stack though
[19:22:32] <kshishkov> _av500_: I just giving you facts to compare. And I've seen photos of several cities after bombing - was FaM ugly before '39 ?
[19:22:43] <BBB> Vitor1001: is there some developer mailinglist for icc?
[19:22:46] <BBB> we could ask
[19:22:55] <cartman> BBB: intel has forums
[19:23:00] <BBB> ah, fantastic
[19:23:02] <BBB> where?
[19:23:05] <cartman> "forums" rather lol
[19:23:29] <cartman> BBB: http://software.intel.com/en-us/forums/intel-c-compiler/
[19:24:05] <_av500_> do they call each other idiots at these forums?
[19:24:14] <_av500_> if not, i wont read them
[19:24:26] <cartman> no, its not a Linux forum
[19:24:35] <Vitor1001> BBB: -falign-stack=xxx
[19:24:39] <BBB> ooo
[19:24:40] <cartman> mostly paid developers hang there
[19:24:42] <BBB> try that
[19:24:48] <BBB> -falign-stack=16 should work quite well
[19:24:48] <_av500_> cartman: get hanged there?
[19:24:56] <kshishkov> "mostly paid"?
[19:24:58] <cartman> _av500_: they hanged me for reporting bugs
[19:25:07] <cartman> kshishkov: mostly, paid
[19:25:18] <BBB> Vitor1001: then we can remove the #if version checks from h264dsp_mmx.c also
[19:26:03] <kshishkov> _av500_: you should read Russian forums, it's a rule for them: you ask question and receive answer explaining why you're an idiot
[19:26:06] <Vitor1001> BBB: I'll try, if it works I'll send a patch to configure
[19:26:22] <Vitor1001> BBB: BTW, the flags are "-falign-stack=maintain-16-byte"
[19:26:27] <cartman> kshishkov: sounds like #debian
[19:26:31] <_av500_> lol
[19:26:45] <_troll_> icc: command line warning #10148: option '-falign-stack' not supported
[19:26:51] <_av500_> russian mod took over debian too?
[19:26:52] <Vitor1001> BBB: But it will take forever to recompile it in my atom to check
[19:26:54] <kshishkov> cartman: or _any_ Russian forum
[19:26:55] <_av500_> mob
[19:27:02] <cartman> kshishkov: did you know all of my life I wondered who was behind damn.ru (now a dead domain)
[19:27:12] <Vitor1001> _troll_: In 32-bit, no warnings
[19:27:32] <kshishkov> cartman: no, and I couldn't care less
[19:27:45] <cartman> kshishkov: bah, you .ua guy I forgot :P
[19:27:50] * cartman needs a .ru guy
[19:28:03] <kshishkov> cartman: take thresh
[19:28:13] <cartman> thresh: do you remember damn.ru ?
[19:28:40] * kshishkov feels it's time to quote lu_zero
[19:28:43] <kshishkov> yawn
[19:28:53] <kshishkov> g'night everyone. Happy trolling
[19:29:04] <cartman> kshishkov: gnight, see _av500_ in your dreams
[19:31:18] <_av500_> err
[19:34:46] <BBB> Vitor1001: it does sound like this is the issue, so yeah, thanks for testing :)
[19:44:05] <BBB> gcc is a little weird
[19:44:14] <BBB> to unroll a for (i=0;i<2;i++){..}
[19:44:16] <BBB> it does this:
[19:44:53] <BBB> i=0; label; if i==1 goto label1; do first case; i++; goto label; labelret: return; label1: do second case;
[19:45:22] <BBB> that's so completely illogical that it just baffles me how they invented this
[19:45:25] <Vitor1001> BBB, mru: --extra-cflags="-falign-stack=maintain-16-byte" does fix it
[19:45:28] <BBB> \o/
[19:45:40] <BBB> Vitor1001: can you also check that it fixes h264 deblock sse2 code?
[19:45:51] <BBB> (just remove the icc-related #if at the end of h264dsp_mmx.c)
[19:46:17] <mru> it should fix that
[19:46:25] <Vitor1001> BBB: I can't, I don't have a 64-bit cpu
[19:46:29] <BBB> ?
[19:46:32] <BBB> it's not 64-bit
[19:46:37] <mru> it's disabled for icc on 32-bit
[19:46:44] <BBB> right, because of this bug
[19:46:50] <mru> it's not a bug
[19:47:00] <BBB> carl eugen added the #if, I think
[19:47:05] <mru> yes, wrongly
[19:47:07] <BBB> right
[19:47:10] <BBB> so remote the #if
[19:47:12] <Vitor1001> "#if ARCH_X86_64 || !defined(__ICC) || __ICC > 1110"
[19:47:15] <BBB> _remove
[19:47:16] <mru> the one
[19:47:25] <Vitor1001> ow, indeed
[19:47:39] <mru> and those icc version checks just seem backwards to me
[19:47:41] <mru> all of them
[19:47:49] <BBB> that's irrelevant
[19:47:54] <BBB> they should never have been there
[19:48:03] <mru> I mean others
[19:48:06] <mru> too
[19:48:11] <BBB> there's more like this?
[19:48:13] <BBB> ...
[19:48:15] <BBB> :(
[19:48:20] <mru> grep __ICC
[19:48:49] <BBB> this is the only hit I see
[19:49:12] <mru> I get 8 matches for __ICC
[19:50:52] <BBB> oh in libavutil headers
[19:50:52] <Vitor1001> "make fate-h264" pass :D
[19:50:55] <BBB> \o/
[19:50:58] <BBB> send a patch
[19:51:03] <BBB> or, no
[19:51:04] <BBB> just apply
[19:51:38] <mru> apply what?
[19:51:45] <Vitor1001> I don't have much time now
[19:51:57] <mru> I'll try to install 32-bit icc
[19:52:31] <Vitor1001> mru: Michel will add a fate test for it tomorrow
[19:53:47] <mru> I'd like to have it nonetheless
[19:54:03] <mru> I've just been too lazy to install it
[19:54:26] <mru> the gentoo ebuild doesn't want to install both 32- and 64-bit
[19:54:38] <Vitor1001> mru: But you agree that a patch adding that flag for icc32 is correct, no?
[19:54:45] <mru> yes
[19:58:12] <BBB> we did the same for clang
[19:58:19] <BBB> it's obviously the correct thing to do
[20:02:15] <Vitor1001> mru: http://ffmpeg.pastebin.com/x1hdgyBT
[20:03:06] <mru> why so much whitespace?
[20:03:13] <mru> I know the answer...
[20:03:18] <mru> you copied a line that had it
[20:03:25] <Vitor1001> Exactly
[20:03:32] <BBB> /nick _troll_
[20:03:34] <mru> probably because it lined up nicely there
[20:03:41] <Vitor1001> patch ok after trimmed?
[20:03:46] <mru> drop the quotes too
[20:03:53] <BBB> Vitor1001: can you also remove the #ifdef in h264dsp_mmx.c?
[20:03:56] <mru> and use a _sensible_ commit message
[20:03:57] <BBB> imo can be done in the same patch
[20:04:01] <mru> no
[20:04:03] <mru> separate
[20:04:08] <Vitor1001> ok.
[20:04:12] <BBB> ok, separate then
[20:04:21] <Vitor1001> First, I'll test it. Will take some time :p
[20:04:23] <BBB> does that fix all icc fate failures?
[20:04:28] <mru> no
[20:05:03] <Vitor1001> BBB: atrac3-1 remains
[20:05:06] <Vitor1001> Compiler bug
[20:07:29] <BBB> what about the x86-64 one?
[20:10:13] <mru> unrelated to alignment
[20:18:01] <CIA-63> ffmpeg: jbr * r25143 /trunk/ffmpeg.c:
[20:18:01] <CIA-63> ffmpeg: Change remaining ost->st->codec and ist->st->codec to enc and dec in
[20:18:01] <CIA-63> ffmpeg: do_audio_out().
[20:20:12] <CIA-63> ffmpeg: jbr * r25144 /trunk/ffmpeg.c: 10l: error in last commit. use decoder channels not encoder channels.
[20:21:41] <kierank> http://durian.blender.org/news/3622/
[20:22:37] <mru> divx... professional... rotfl
[20:24:37] <kierank> "The ogg video files are about 3x bigger than the quicktimes, even with stereo sound"
[20:25:09] <mru> did he use the quick and dirty muxer we had before?
[20:25:26] <mru> the one that did one page per packet
[20:26:27] <kierank> the dvd versions are pretty bad
[20:28:16] <mru> lol "please use DIRAC! the only trully FOSS codec at HD quality"
[20:28:45] <BBB> I thought bbc ditched dirac because h264 was better and cheaper?
[20:29:01] <mru> not quite that simple
[20:29:31] <BBB> elaborate
[20:29:31] <mru> they kept some variant for internal use only
[20:29:39] <mru> with insanely high bitrates
[20:30:10] <BBB> oh boy
[20:30:11] <kierank> the internal use was so they could do hd video down non HD-SDI cabling
[20:30:28] <BBB> "use pitivi, requires gstreamer developer version"
[20:30:34] <BBB> "can do webm!!11"
[20:30:57] <mru> pitiful
[20:32:36] <BBB> the sad thing is that if someone uses pitty lies to promote a new technology, and it doesn't deliver...
[20:32:47] <Dark_Shikari> BBB: pong
[20:32:50] <BBB> ... then zealots like above will use this punchline forever and ever after as if it were the ultimate truth
[20:33:02] <BBB> Dark_Shikari: too late, pengvado already helped :)
[20:45:22] <CIA-63> ffmpeg: mru * r25145 /trunk/configure: Request 16-byte aligned stack with icc on x86_32
[20:45:22] <CIA-63> ffmpeg: mru * r25146 /trunk/libavcodec/x86/h264dsp_mmx.c: x86: remove hack disabling sse2 h264 loop filter with 32-bit icc
[20:46:28] <Dark_Shikari> mru: oh sweet, icc supports that?
[20:46:34] <mru> sure
[20:46:35] <Dark_Shikari> Does it support arg_align_whatever?
[20:46:43] <mru> guess we'll find out
[20:46:44] <Dark_Shikari> that thing we use to make sure that lavc aligns the stack even if the callee isn't?
[20:46:48] <Dark_Shikari> No we won't
[20:46:50] <Dark_Shikari> FATE doesn't test that
[20:47:00] <Dark_Shikari> you can't test that unless you compile another app with MSVC (or some other app) and then link to lavc
[20:47:02] <mru> we'll find out when someone complains
[20:47:04] <Dark_Shikari> *some other app that doesn't align
[20:47:11] <Dark_Shikari> Also, even then, there's a 25% chance of it working anyways.
[20:47:24] <BBB> 25% per function
[20:47:36] <BBB> so in total that's 1/4rd to the power of the number of functions
[20:47:38] <BBB> should be safe...
[20:48:07] <Dark_Shikari> no, just the decode function
[20:48:09] <Dark_Shikari> i.e. just the one that calls simd
[20:48:29] <mru> the entry point of lavc
[20:48:38] <Dark_Shikari> yeah
[20:48:46] <mru> internally alignment is preserved
[20:49:01] <Dark_Shikari> exactly.
[20:49:12] <mru> but we don't support icc on windows
[20:49:18] <BBB> pengvado: one more ping
[20:49:25] <mru> so it's unlikely to cause any trouble
[20:49:30] <mru> even if it doesn't realign
[20:49:32] <Dark_Shikari> mru: ok, linking from icc on linux
[20:49:42] <Dark_Shikari> i.e. I compile my app with icc, without that option
[20:49:45] <Dark_Shikari> then I link to ffmpeg, with that option
[20:49:50] <Dark_Shikari> But yes, odds are this won't happen very often.
[20:49:59] <Dark_Shikari> It would be nice to test though.
[20:50:30] <mru> easy enough for the app to fix
[20:52:39] <BBB> fate doesn't test icc-x86-32, does it?
[20:52:50] <mru> it does now
[20:52:58] <mru> just added
[20:53:00] <mru> hasn't run yet
[20:53:01] <BBB> I just checked five seconds ago :-p
[20:53:17] <BBB> your computers must be running fate all day now
[20:53:25] <mru> the smaller ones, yes
[20:53:37] <mru> the i7 manages to take a break once in a while
[20:53:48] <Dark_Shikari> I wonder how common this is.
[20:53:49] <Dark_Shikari> http://cnra.ci/fichetech/htpasswd.htpasswd
[20:53:57] <Dark_Shikari> plaintext passwords in a public directory.
[20:56:52] <mru> BBB: try reloading now
[20:57:16] <BBB> damn you one more yellow
[20:57:28] * mru blames intel
[20:59:04] <BBB> 18 yellow and 1 red
[20:59:12] <BBB> and all of them are compiler bugs or broken hardware...?
[20:59:23] <mru> or lazy ramiro
[20:59:35] <BBB> ?
[20:59:40] <BBB> which one is lazy ramiro
[20:59:44] <mru> cygwin
[20:59:55] <mru> he fucked up the installation and hasn't fixed it
[20:59:58] <BBB> the red one
[21:00:05] <mru> all
[21:00:14] <BBB> oh right they're not refresing
[21:00:21] <mru> that's why they're grey
[21:00:55] <BBB> armv5te and avr32_ap are also grey
[21:01:00] <mru> yes
[21:01:03] <mru> they need a reset
[21:01:09] <mru> but I'm in the wrong country
[21:08:04] <BBB> another fun gcc one:
[21:08:20] <BBB> aligned uint64_t mask = dir ? 0 : -1;
[21:08:28] <BBB> pand [mask], m0
[21:08:33] <BBB> guess what gcc makes of that
[21:09:17] <BBB> (pand is gcc syntax, so src, dest)
[21:09:26] <mru> is this c or asm?
[21:09:34] <BBB> the first line is c, the second line is inline asm
[21:09:44] <mru> that's not inline asm syntax
[21:10:04] <BBB> DECLARE_ALIGNED(8, const uint64_t, mask_dir) = dir ? 0 : 0xffffffffffffffffULL;
[21:10:04] <BBB> __asm__ volatile(
[21:10:04] <BBB> "pand %0, %%mm0 \n\t"
[21:10:05] <BBB> ::"m"(mask_dir)
[21:10:07] <BBB> that
[21:11:34] <mru> enlighten us
[21:11:38] <BBB> it actually stores 0xffffffff in eax, edx
[21:11:47] <BBB> then saves it in memory to save the regs for some other purpose
[21:12:02] <BBB> then goes back and does the pand which has no effect
[21:12:33] <mru> 32-bit?
[21:12:36] <BBB> yeah
[21:12:40] <BBB> I wonder what it does on 64-bit
[21:12:42] <BBB> I dare not watch
[21:12:59] <mru> gcc does horrible things with int64_t on 32-bit
[21:13:19] <mru> it also likes to multiply numbers by a constant zero, then compare the result to zero
[21:13:19] <BBB> since gcc unrolled the loop, where dir is the loop counter, it should just've removed the 0xffff pand, and the 0x0 pand should've become a pxor mm0, mm0
[21:13:40] <BBB> that would also have saved several stack writes and so on
[21:13:43] <BBB> but ohwell...
[21:13:51] <drv> it can't optimize inline assembly, it just includes it directly
[21:13:54] <BBB> maybe gcc is not as smart as we all hope it culd be
[21:14:05] <drv> like text inclusion
[21:14:15] <mru> gcc is worse than we could imagine it might be
[21:14:22] <BBB> clearly
[21:14:46] <BBB> I'll rewrite this (last h264 inline asm function in h264dsp_mmx.c)
[21:14:54] <BBB> and then write a sse2 version also without the loop
[21:15:41] * BBB goes home first...
[22:21:23] <Vitor1001> mru: Saw the new conf on fate, sweet!
[22:22:05] <Vitor1001> mru: BTW, if you are wondering what is making atrac3-1 to fail, it is the inlining of getChannelWeights()
[22:22:19] <Vitor1001> If you mark it as av_noinline, everything works
[22:51:16] <mru> what a weird function
[23:03:18] <Vitor1001> mru: There are a lot of weird functions on atrac3.c...
More information about the FFmpeg-devel-irc
mailing list