[FFmpeg-devel-irc] IRC log for 2010-07-29

[irc at mansr.com]

[00:00:53] <CIA-92> libswscale: stefano * r31847 /trunk/libswscale/swscale.h:
[00:00:53] <CIA-92> libswscale: Revert commit:
[00:00:53] <CIA-92> libswscale:  r31772 | stefano | 2010-07-23 01:01:31 +0200 (Fri, 23 Jul 2010) | 2 lines
[00:00:53] <CIA-92> libswscale:  Prefer impersonal form over third person, for consistency with the
[00:00:53] <CIA-92> libswscale:  rest of FFmpeg.
[00:00:54] <CIA-92> libswscale: The change was not approved by the maintainer.
[01:26:04] <efriedma> roughly 1% faster h264 decoding on my mobile core i5: http://paste.pocoo.org/show/242904/
[01:48:44] <Compn> vitor isnt in here is he ?
[01:48:53] <Compn> oh , just not now , nm
[01:49:07] * Compn replies on list
[02:27:43] <Dark_Shikari> efriedma: you can do that with pmaddubsw
[02:27:43] <Dark_Shikari> iirc
[02:27:45] <Dark_Shikari> see x264
[02:28:05] <efriedma> Dark_Shikari: yeah, just wrote an implementation using that
[02:28:56] <efriedma> i'll do some more benchmarking in a bit
[02:33:36] <Dark_Shikari> x264 has an implementation of these, so compare yours to it
[02:36:02] <Compn> hmm
[02:36:04] <Compn> http://www.bealecorner.com/trv900/DVD/Maxell-DVDR-spots.html
[02:36:13] <Compn> neat dvdr information there
[02:36:28] <Compn> freezing = no good, baking = smart? hmm
[02:47:08] <efriedma> Dark_Shikari: it looks nearly identical
[02:47:57] <Dark_Shikari> you don't need two paddsw
[02:48:14] <Dark_Shikari> oh wait nvm you do.
[02:48:29] <Dark_Shikari> you should see if you can use another free register to pipeline it a bit better
[02:48:36] <Dark_Shikari> i.e. do two rows at once or similar
[02:48:39] <Dark_Shikari> you aren't using m2
[02:48:56] <Dark_Shikari> Then you can do packuswb m0, m2
[02:48:58] <Dark_Shikari> and movh/movhps
[02:59:56] <efriedma> Dark_Shikari: is log2_denom a constant?
[03:00:16] <efriedma> (in this context)
[03:15:53] <Dark_Shikari> efriedma: no.
[03:16:32] <efriedma> then could you explain how the x264 versions get away with "psraw     m0, 6"
[03:16:34] <efriedma> ?
[03:17:43] <Dark_Shikari> x264 only uses implicit weighted bipred
[03:17:51] <Dark_Shikari> it doesn't have to worry about supporting explicit mode
[03:18:02] <efriedma> oh
[03:18:12] <Dark_Shikari> explicit is rare atm, so you could make asm versions only for the regular mode.
[03:18:16] <Dark_Shikari> If it helped a lot.
[03:23:10] <efriedma> the only reason it might help is that it frees up a register
[03:23:34] <Dark_Shikari> and variable shifts are slower than constant shifts on some x86 chips
[03:23:41] <Dark_Shikari> like core 2 iirc
[03:23:50] <Dark_Shikari> You could branch.
[03:26:30] <Dark_Shikari> You could do a jump table and have one for each shift value.
[03:26:39] <Dark_Shikari> Under the assumption that nobody changes much within a frame (sane)
[03:29:15] <efriedma> not worth it to save 1 clock cycle per 8 pixels
[03:31:03] <Dark_Shikari> that's all the unroll saves?
[03:31:47] <efriedma> my instruction tables say on core i7, constant shift is 1 cycle, variable shift is 2
[03:31:56] <Dark_Shikari> I meant the unrolling due to extra reg
[03:32:05] <Dark_Shikari> Or maybe you could make the instruction ordering better on x86_64
[03:32:08] <Dark_Shikari> and worse on x86_32
[03:32:16] <Dark_Shikari> to make up for the missing extra reg
[03:32:21] <efriedma> oh... actually, i can unroll it with 1 reg
[03:34:27] <efriedma> current version: http://paste.pocoo.org/show/242923/
[03:36:13] <Dark_Shikari> the 8x8 one should do two rows
[03:36:24] <Dark_Shikari> via unroll
[03:36:32] <Dark_Shikari> but yeah looks good
[03:36:36] <Dark_Shikari> now write 8x8 and ssse3
[03:54:37] <efriedma> current: http://paste.pocoo.org/show/242927/
[03:56:54] <efriedma> umm, any ideas to speed up the bit before the loop?  my profile shows it taking a non-trivial amount of time
[04:00:14] <Compn> Dark_Shikari : btw is there any vp8 / h264 mmx routines that could be asm'd by vitor that would be useful for x264 ?
[04:00:24] * Compn guesses not
[04:03:03] <Dark_Shikari> why vitor
[04:04:19] <Dark_Shikari> and what do you mean, mmx routines
[04:04:25] <Dark_Shikari> if it's already an asm routine why does it need mmxing
[04:10:13] <Compn> er good point
[04:10:20] <Compn> vitor was asking what needed to be mmx > asm'd
[04:10:24] <Compn> i think?
[04:10:39] <Compn> not important, nm
[04:11:27] <efriedma> Dark_Shikari: any comments on my patch?
[04:13:44] <Dark_Shikari> looks fine to me.
[04:16:12] <Dark_Shikari> oh, the new patch
[04:16:13] <Dark_Shikari> didn't look
[04:16:31] <Dark_Shikari> OPERATION is too long, pick a shorter word
[04:16:32] <Dark_Shikari> STEP
[04:16:33] <Dark_Shikari> OP
[04:16:54] <Compn> bzzzt
[04:17:00] <Dark_Shikari> 182 looks unnecessary, why not do that in scalar
[04:18:23] <efriedma> Dark_Shikari: i don'
[04:18:44] <efriedma> i don't know how to use cl with the cglobal macro
[04:19:01] <Dark_Shikari> why do you need cl?
[04:19:12] <Dark_Shikari> remove add r3, 1
[04:19:13] <efriedma> shift?
[04:19:18] <Dark_Shikari> and then remove psrld m5, 1
[04:19:51] <efriedma> and then use padd?
[04:19:57] <efriedma> i suppose that works
[04:21:24] <Dark_Shikari> er, why padd?
[04:21:30] <Dark_Shikari> I'm confused here
[04:21:31] <Dark_Shikari> you are doing
[04:21:35] <Dark_Shikari> (x << a) >> 1
[04:21:36] <Dark_Shikari> why not do
[04:21:39] <Dark_Shikari> (x << (a+1)) >> 1 ?
[04:21:44] <Dark_Shikari> er, I mean
[04:21:48] <Dark_Shikari> (x << (a-1))
[04:22:19] <efriedma> i need r3+1 in an xmm register for the loop
[04:23:24] <Dark_Shikari> ahhhh
[04:23:27] <Dark_Shikari> I see.
[04:24:19] <efriedma> so what do you suggest?
[04:24:24] <Dark_Shikari> current is fine imo
[04:24:46] <Dark_Shikari> for 16x16 the setup isn't very costly.
[04:24:55] <Dark_Shikari> don't worry too much about it.
[04:25:06] <efriedma> k
[04:43:46] <efriedma> patch sent to ffmpeg-devel
[04:49:23] <Dark_Shikari> passes regressions?
[04:56:49] <Dark_Shikari> er, regression tests
[05:04:27] <efriedma> Dark_Shikari: umm, how do i run h264 regression tests?
[05:05:45] <Dark_Shikari> the fate tests?  make fate or whatever
[05:05:47] <Dark_Shikari> you have to have them downloaded
[05:06:10] <Dark_Shikari> or
[05:06:11] <Dark_Shikari> http://www.mediafire.com/download.php?mi2zjoynymi
[05:06:15] <Dark_Shikari> decode every file here, compare md5 to old ffmpeg
[05:09:31] <Compn> fate samples are on samples.mplayerhq.hu
[05:09:35] <Compn> no need to mediafire ?
[05:09:43] <Dark_Shikari> mediafire is faster, only one file to download
[05:10:09] <Compn> faster than mphq? ehe
[05:10:49] <Dark_Shikari> I mean yo udon't have to download 90 things...
[05:11:16] <Compn> right
[05:11:47] * Compn wonders what kind of bad browser doesnt have support for multiple downloading of files
[05:11:59] <Compn> firefox needs downthemall, opera has links
[05:12:06] <Compn> chrome ... well, chrome sucks
[05:12:14] * Compn sleeps before he starts browser war
[05:19:20] <efriedma> Dark_Shikari: k, thanks; passes regression tests
[05:19:25] <Dark_Shikari> good.
[06:11:08] <thresh> moroning
[06:37:07] <mru> moins
[06:37:19] <kshishkov> your name does not sound like that
[06:37:45] <mru> in skåne it does
[06:37:50] <mru> ask pJok
[06:38:06] <kshishkov> crazy near-Danish people
[06:39:09] <cartman> moin
[07:14:26] <KotH> günaydin arkadaslar
[07:16:38] <kshishkov> same to you
[07:18:39] <cartman> ehlo KotH
[07:18:45] <cartman> I see you miss Turkish ;)
[07:19:03] * kshishkov tries to watch how cartman is going to fetch mail from KotH
[07:19:14] <cartman> fetch mail? :)
[07:19:44] <xxthink> Hi, I use ffmpeg -i x.264 x.yuv to decode the yuv file
[07:20:06] <xxthink> but this x.yuv file is different from the recon yuv file
[07:20:26] <xxthink> Are there some postprocessing method used by ffmpeg
[07:20:33] <xxthink> or it's a ffmpeg bug?
[07:20:35] <kshishkov> cartman: if you greet somebody with "EHLO" it looks like POP
[07:20:45] <Honoome> I just love when the tinderbox gets stuck for SEVEN HOURS on the same package because the test suite freezes X_X
[07:20:47] <cartman> kshishkov: yeah indeed :P
[07:21:31] <kshishkov> cartman: also you may be pleased to know that "bikeshed" in Russian is "saray"
[07:21:37] <cartman> kshishkov: lol :D
[07:21:38] <cartman> nice
[07:21:49] <kshishkov> xxthink: it may be different YUV format after all
[07:22:10] <xxthink> kshishkov: why
[07:22:28] <xxthink> can I output the raw decoded yuv file by ffmpeg?
[07:22:37] <kshishkov> because you can pack YUV into many different ways
[07:22:47] <cartman> KotH: btw I wonder if there are any job opportunities in .ch for a C++/Qt/Python programmer with Linux/Win/WinCE background ;)
[07:23:02] <KotH> cartman: i'm quite sure there are
[07:23:13] <xxthink> kshishkov: I use jm to verify that the x.264 file is correct
[07:23:18] <KotH> cartman: good people are always sought
[07:23:27] <xxthink> but when I use ffmpeg to dump it, it doesn't match
[07:23:30] <cartman> KotH: anything you can refer for your good old friend me? :D
[07:23:44] <KotH> cartman: actually, i would like someone who knows how to code linux and windows at our comp :)
[07:23:45] <kshishkov> KotH: he said C++/Qt/Python, nothing about being good :P
[07:23:58] <KotH> kshishkov: öh.. i know cartman for some time already :)
[07:24:01] <cartman> kshishkov: I am good, trust me :)
[07:24:06] <cartman> not as good as you guys but
[07:24:08] <xxthink> kshishkov: my yuv is 4:2:0, Y, U, V
[07:24:08] <cartman> good ;)
[07:24:14] <xxthink> why it doesn't work
[07:24:26] <cartman> KotH: I can send you a CV so you could maybe check it out? :)
[07:24:42] <KotH> kshishkov: and i know turkish people well enough not to trust anything they say unless i've verified myself ;)
[07:24:48] <cartman> LOL
[07:24:52] <cartman> good thinking KotH
[07:25:06] * KotH always thinks good
[07:25:07] <kshishkov> xxthink: I really cannot say anything without knowing how your reference YUV file was created
[07:25:24] <KotH> cartman: you can send me your cv, but i'm quite sure that we currently will not hire you :-(
[07:25:24] <kshishkov> KotH: I'll try to verify your words
[07:25:33] <xxthink> my reference yuv file is the yuv file dumped by x264 when I encode it
[07:25:38] <cartman> KotH: oh well, why not! :)
[07:25:43] <KotH> cartman: there might be an opening in 2-3 months though
[07:26:00] <kshishkov> xxthink: ask Dark_Shikari then
[07:26:06] <xxthink> :)
[07:26:12] <cartman> KotH: it would be OK if you could forward the CV to somewhere which might have an opening
[07:26:22] <KotH> cartman: sure
[07:26:40] <cartman> I just want to work somewhere in EU ;)
[07:26:41] <xxthink> Dark_Shikari: do you know my problem?
[07:26:46] <KotH> err..
[07:26:51] <KotH> cartman: .ch is _not_ EU
[07:26:52] <xxthink> I use ffmpeg -i x.264 x.yuv to dump a x.yuv file
[07:26:58] <KotH> cartman: which is not a bad thing, though ;)
[07:26:59] <cartman> KotH: not as in union
[07:27:05] <cartman> I mean as in Europe :)
[07:27:10] <xxthink> but this yuv file is different from the recon file dumped by x264
[07:27:21] <kshishkov> cartman: I know one guy with the same dream
[07:27:22] <KotH> cartman: .ch is not in europe either... if you believe some local parties
[07:27:23] <xxthink> Dark_Shikari: do you know why?
[07:27:50] <KotH> kshishkov: did you ever stand in front of the masses and started a speach with "i have a dream..."?
[07:27:51] <av500> gm
[07:27:51] <cartman> KotH: switzerland is not in Europe?!
[07:28:06] <cartman> kshishkov: what dream? I am gonna make this a reality soon ;)
[07:28:13] <kshishkov> KotH: I'm not black enough to do that
[07:28:15] <KotH> m' av500
[07:28:17] <cartman> my dream would be lying down in Bahamas
[07:28:18] <Honoome> cartman: by any definition minus the physical one
[07:28:18] <cartman> not EU
[07:28:29] <kshishkov> cartman: to work in Europe
[07:28:37] <xxthink> Dark_Shikari: my x.264 is verifyed by jm
[07:28:43] <cartman> kshishkov: bad dream ;)
[07:28:56] <xxthink> the decoded yuv of jm is the same as the recon yuv dumped by x264
[07:29:05] <mru> cartman: there are bad dreams, and there are nightmares
[07:29:09] <kshishkov> cartman: as a means of escaping from certain country by Black Sea
[07:29:17] <cartman> kshishkov: ah lol
[07:29:19] <cartman> true that
[07:29:27] <mru> cartman: .ua would be the latter if kshishkov is to be believed
[07:29:40] <cartman> .ua is a touch place
[07:29:54] <cartman> though many people go there from Turkey to work
[07:29:56] <cartman> tough*
[07:30:09] <mru> kshishkov: ehlo is smtp, not pop
[07:30:17] * kshishkov points out that Turkey also has Black Sea coast
[07:30:20] <mru> or maybe both, I don't know pop
[07:30:30] <kshishkov> mru: I don't know both
[07:30:34] <cartman> I used ehlo for smtp
[07:30:39] <cartman> remember using-
[07:30:49] <kshishkov> or for KotH
[07:31:24] <cartman> ;=
[07:31:35] <cartman> kshishkov: you are in the .ua btw?
[07:32:26] <kshishkov> cartman: no, I'm next to mru
[07:32:48] <cartman> nice place
[07:34:26] <KotH> kshishkov: next to mru? when did you move to .uk?
[07:34:47] <kshishkov> KotH: it's mru moved, not me
[07:34:57] <KotH> huh?
[07:35:04] <cartman> lol
[07:35:06] <KotH> mru: when did you move to .de?
[07:35:06] <cartman> :>
[07:35:17] <cartman> so kshishkov  is in .de
[07:35:18] <cartman> aha :P
[07:36:19] * av500 saw both mru and kshishkov yesterday
[07:36:21] <mru> KotH: I didn't move
[07:36:29] <mru> .de came to me
[07:37:03] * cartman waits for .se to come to him
[07:38:19] * kshishkov would gladly swap .de for .se too
[07:38:58] * cartman connects to his Windows CE 6 tablet for another boring day
[07:39:24] <kshishkov> double lie - it's not "CE" and it's not 6
[07:41:35] <cartman> kshishkov: I got Windows CE 5 and Android tablets too
[07:41:37] <cartman> happy now?
[07:43:05] * pJok swaps kshishkov with .se
[07:43:08] <kshishkov> cartman: it's called "Windows Mobile" and it's really 5.1 or 5.2
[07:43:29] <cartman> Mobile != CE
[07:43:31] <cartman> kernel is different
[07:44:58] * cartman even got ffmpeg encoding working at some point
[07:45:08] <cartman> I should try again
[07:45:08] <cartman> !
[08:12:17] <saintdev> peloverde: well i got lame windowing to almost match itunes :)
[08:12:53] <av500> the itune leading the lame?
[08:14:01] <saintdev> except for a couple of false positives on our side, but we also eliminate cases where itunes incorrectly stays short for long periods
[08:24:51] <peloverde> thats good
[08:26:34] <saintdev> *on castanets
[08:26:40] <saintdev> peloverde: latest dump http://pastebin.org/427402
[08:26:45] <saintdev> and i'm off to bed.
[08:49:24] <lu_zero> yawn
[08:49:35] * av500 gives lu_zero coffee
[08:49:44] <av500> or was it diet coke?
[08:50:14] <cartman> I thought I was the only one drinking coke in the morning
[08:50:49] <av500> better than doing coke in the morning
[08:51:23] <cartman> nice
[08:51:32] <cartman> I see some thedailywtf-worthy code in our codebase
[08:51:35] <cartman> refreshing
[08:51:40] <lu_zero> I prefer tea, iced
[08:51:56] * lu_zero should do something simple thus boring
[08:52:43] <kshishkov> try to do it in the most convoluted way then
[08:53:09] * kshishkov sighs as he remember "The Incredible Machine" game series
[08:55:24] <KotH> cartman: share it with us :)
[08:55:41] <cartman> 	if(	this->backendRootPath.size() == 0 || this->backendRootPath.size() == 0 ||
[08:55:41] <cartman> 		this->backendRootPath.size() == 0 || this->backendRootPath.size() == 0 ||
[08:55:41] <cartman> 		this->userId.size() == 0)
[08:55:46] <cartman> 4 times the charm it seems
[08:57:29] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/DepartmentOfRedundancyDepartment
[08:57:36] <kshishkov> (ExtractBits(1) == 1) ? true : false
[08:59:04] <mru> for (n = 0; n < 0; n++) ...
[08:59:33] <cartman> I bet this was ClipboardInheritance
[08:59:37] <cartman> CTRL-V multiple times
[09:00:09] <av500> it's a fourfold redunancy, making sure it is really 0
[09:00:17] <mru> shortly before: M = foo; N = bar; 0 = baz; ...
[09:00:35] <kshishkov> the same source!
[09:00:44] <mru> we're not making this up
[09:01:00] <kshishkov> but certain company did
[09:03:46] <cartman> it would be nice if the code said, workaround a compiler bug
[09:03:47] <cartman> :p
[10:54:21] <siretart> god morgon
[11:06:25] * kshishkov looks at siretart and still does not believe it
[11:11:38] <mru> siretart: btw, the new fate can test branches
[11:11:55] <mru> although only ones created after the test system overhaul
[11:16:29] <siretart> kshishkov: it's 7am here
[11:16:49] <siretart> mru: yay! who deserves the beer and kudos?
[11:18:09] <mru> http://fate.mansr.com/
[11:20:19] <mru> it's still not quite complete
[11:22:36] <siretart> wow, that looks really neat :-)
[11:44:14] <kierank> lol rv9 had an interlace mode
[11:44:23] <lu_zero> http://fate.mansr.com/report.cgi?slot=x86_64-linux-clang&time=20100728235201
[11:44:27] <lu_zero> x86?
[11:44:41] <mru> it says so
[11:45:09] <lu_zero> x86_64-linux-clang
[11:45:23] <mru> yes
[11:45:24] <lu_zero> doesn't compute well
[11:45:33] <mru> what is not clear?
[11:45:35] <lu_zero> x86_64-linux-clang building for x68?
[11:45:37] <mru> no
[11:45:50] <mru> which part of 64 is unclear?
[11:46:28] <lu_zero> what got passed to configure made me uncertain
[11:46:59] <kshishkov> kierank: and dquant, but I'm yet to see files with it
[11:49:31] <lu_zero> mru: cf --arch=mips64
[11:49:32] <av500> omg, it leeked: http://multimedia.cx/eggs/official-realvideo-specifications/
[11:49:38] <mru> lu_zero: good point, that flag is unnecessary
[11:49:41] <mru> removed now
[11:51:15] <mru> lu_zero: --arch=x86 covers all x86
[11:51:23] <mru> configure figures out what it really is
[11:51:52] <kshishkov> av500: personally I don't care
[11:52:03] <av500> so you said
[11:56:12] <kshishkov> av500: you know, full format docs would be more useful
[13:11:00] <thresh> lol @ http://seclists.org/oss-sec/2010/q3/106
[13:13:01] <spaam> haha nice
[13:13:06] <thresh> and it works.
[13:13:23] <mru> annoying but harmless
[13:13:55] <thresh> and funny
[13:15:32] <mru> for one of the involved parties, yes
[13:18:06] <kshishkov> isn't it fixed by general rule of staying away from KDE?
[13:18:32] <thresh> Qt, you mean
[13:19:11] <cartman> bleh
[13:19:18] <cartman> its an implementation bug :)
[13:48:48] <lu_zero> pfff
[13:49:00] <mru> fffp
[13:49:30] <BBB> lu_zero: do we have a LATM depacketizer?
[13:49:38] <BBB> I have a LATM rtsp stream here that doesn't work
[13:49:47] <lu_zero> latm
[13:49:50] <lu_zero> yawn...
[13:50:19] <BBB> maybe I should ask "the other luca" :-p
[13:50:29] <lu_zero> http://www.rfc-editor.org/rfc/rfc3016.txt
[13:50:47] <lu_zero> iff we don't have one is quite easy to get
[13:51:08] <lu_zero> the generic mpeg4es doesn't support it already?
[13:51:15] * lu_zero is sleepy
[13:51:42] <BBB> it didn't work here
[13:52:18] <funman> iirc i used the packetizer of vlc because there is none in ffmpeg
[13:52:49] <kierank> janneg is writing a latm demuxer
[13:53:11] <mru> or so he says
[13:54:36] <merbzt> http://lolpics.se/pics/682.jpg
[13:57:42] <lu_zero> what's inside latm btw?
[13:57:53] <mru> aac usually
[13:58:08] <lu_zero> the sdp says that?
[13:58:20] <mru> no idea
[13:59:05] <funman> can you put something else at all?
[13:59:22] <funman> latm is described in mpeg4 part 3, isn't it?
[14:06:02] <lu_zero> funman: apparently you can
[14:06:31] <lu_zero> rfc3016 is a sort of catchall
[14:06:33] <kierank> xiph would probably put ogg in it
[14:06:42] <lu_zero> so it states much about it
[14:06:54] <lu_zero> kierank: do not remind me ogg please ;_;
[14:06:57] <funman> vorbis in ogg in latm in ts ?
[14:07:04] <lu_zero> in rtp
[14:07:07] <lu_zero> in http
[14:07:10] <lu_zero> in atm
[14:07:22] <lu_zero> in udp
[14:07:25] <lu_zero> in tls
[14:07:31] <kierank> over umts
[14:07:36] <funman> take that, 'low overhead' !
[14:07:37] <lu_zero> I think that's the longest valid totem pole
[14:08:25] <lu_zero> switch udp and tls
[14:08:48] <mru> you can put ip in mpegts
[14:08:51] <mru> over rtsp
[14:09:07] <mru> over ip
[14:09:09] <lu_zero> funman: you might serialize network traffic in xml
[14:09:31] <lu_zero> mru: so you can do that recursively
[14:09:38] <funman> real world use: vorbis in ogg in avi
[14:09:42] <lu_zero> and have the end product as xml
[14:09:58] <lu_zero> funman: excusable somehow
[14:10:14] <lu_zero> by that time you had avi and ogg
[14:10:32] <lu_zero> it's the quickest way pick one and fit the other inside
[14:10:41] <lu_zero> the other way round would be worse
[14:15:01] <BBB> lu_zero: you want the link to play around with?
[14:15:14] <BBB> rtsp://qt-ar.as34763.net/ar32.sdp
[14:24:59] * kierank wonders how utorrent is suddenly using ipv6
[14:28:39] <lu_zero> BBB: uhm
[14:31:32] <BBB> lu_zero: ?
[14:33:51] <BBB> wbs: you can put that one function declaration of rtpdec_asf.h in it also imo
[14:38:34] <lu_zero> ffmpeg cannot reach it from here?
[14:38:41] * lu_zero is puzzled
[14:38:43] <lu_zero> btw
[14:38:58] <lu_zero> those header were used in just one point, isn't it?
[14:39:09] <lu_zero> why not merge those defs directly into the file?
[14:57:34] <_skal_paris_> BBB: here?
[15:02:21] <wbs> BBB: mmkay
[15:03:25] <wbs> lu_zero: that's one option, too, but declaring a long list of "extern RTPDynamicProtocolHandler ff_theora_dynamic_handler;" etc looks a bit ugly there
[15:06:52] <_skal_paris_> BBB: http://pastebin.org/428089
[15:07:05] <_skal_paris_> BBB: and before you ask, yes it passes FATE :)
[15:07:50] <spaam> o/
[15:13:37] <lu_zero> we could copy allcodecs
[15:32:13] <BBB> _skal_paris_: uh, that's a rather long read, give me a bit to go through it ;)
[15:32:25] <BBB> what's the summary? you replace uint8_t[] by a bitmask?
[15:32:34] <BBB> there appear some unrelated changes in it also...
[15:38:18] <_skal_paris_> BBB: yeah, it replaces storing the number of non-zero by just a bit
[15:38:29] <kierank> roozhou: what do you know about the new chinese audio codec for blu-ray?
[15:38:32] <_skal_paris_> on both top_nnz/left_nnz and non_zero_count_cache
[15:38:50] <_skal_paris_> and that simplifies the loop somehow
[15:39:59] <roozhou> kierank: nothing
[15:40:40] <kierank> roozhou: ok
[15:40:44] <roozhou> kierank: you mean CBHD?
[15:41:37] <kierank> roozhou: no, there's been a new audio codec approved for blu-ray called DRA
[15:42:17] <kierank> though I think cbhd also uses dra as well
[15:42:28] <BBB> dra sounds like drm
[15:42:31] <BBB> that's a pr failure
[15:42:54] <mru> DRAt
[15:43:14] <funman> Digital Restriction (is) Awesome!!
[15:43:30] <kierank> [16:42] <@mru> DRAt --> dick dastardly's drm
[15:44:29] <kshishkov> anybody thought about "Disguised Real Audio"?
[15:44:45] <av500> lol
[15:44:54] <av500> Dynamic Real Audio
[15:45:11] <roozhou> dra looks like aac
[15:45:26] <roozhou> frame size = 1024?
[15:45:37] <av500> dra = dra resembles aac
[15:46:12] <kshishkov> do we have specs for it?
[15:46:29] <av500> kshishkov: since when do you need specs?
[15:46:56] <kshishkov> av500: it's hard to implement codec without specs. Even binary ones
[15:47:18] <mru> dra = dts ridiculous audio
[15:47:24] <av500> kshishkov: screenshots must do...
[15:48:10] <kshishkov> av500: yes, for audio
[15:48:15] <funman> digital rifle association?
[15:48:53] * kshishkov had REd one codec with specially crafted input for encoder
[15:57:11] <BBB> _skal_paris_: I'll have a good look at it
[16:03:03] <BBB> _skal_paris_: looks mostly ok to me, please fix alignment (style, not memory)
[16:03:17] <BBB> in various places it'd be more readable with a few more spaces to align lines vertically
[16:03:29] <BBB> the patch itself is straightforward
[16:03:42] <BBB> why are the current left_nnz and non_zero_count_cache mem-aligned?
[16:04:01] <BBB> is that just optimization for gcc memory access on certain archs? or is it used in asm?
[16:06:58] <_skal_paris_> not sure
[16:07:23] <BBB> should be ok then, as long as testsuite is ok
[16:07:26] <BBB> did you fix and re-commit that?
[16:07:32] <BBB> because at least the first of those two patches was fine
[16:07:38] <BBB> the second broke the testsuite, not the first
[16:07:47] <_skal_paris_> yeah, the quant one was totally wrong
[16:07:58] <_skal_paris_> half of it
[16:08:11] <_skal_paris_> BBB: i can recommit a fixed version of both, yeah
[16:08:41] <_skal_paris_> BBB: i will send a revised version (that works!)
[16:09:02] <_skal_paris_> BBB: let me fix the alignment
[16:12:00] <roozhou> kierank: i just downloaded DRA spec
[16:13:11] <roozhou> kierank: it's a scanned PDF and chinese only
[16:13:26] <kierank> hahahaha i had a feeling it was going to be in chinese
[16:16:08] <roozhou> it contains watermark in every page so it is not easy to use OCR
[16:16:56] <kierank> transcribing all the codebook tables will be fun
[16:17:04] <funman> is the watermark scanned or inside the pdf?
[16:17:20] <kierank> does dra have conformance vectors?
[16:17:32] <kierank> or a reference decoder
[16:17:54] <funman> some watermarks can be removed by pdf -> ps -> edit -> pdf
[16:18:16] <kierank> presumably it's a scanned watermark
[16:18:51] <roozhou> scanned
[16:19:47] <roozhou> the good news is a large part of the spec is written in C
[16:20:20] <mru> better than chinese I guess
[16:20:25] <mru> if you don't read chinese
[16:21:01] <funman> ask the guys who sent the cavs patch
[16:21:29] <kierank> that was one of the most bizzare mailing list threads i've ever seen
[16:21:34] <roozhou> I speak Chinese
[16:22:08] <mru> then you can traslate it for us
[16:22:10] <mru> +n
[16:22:17] <funman> kierank: why?
[16:22:42] <kierank> that guys random soliliquy about why he loves open source, the whole amanda thing, etc
[16:23:17] <roozhou> who sent the cavs patch?
[16:23:30] <kierank> soliloquy*
[16:23:47] <kierank> roozhou: they modified x264 to write avs files
[16:24:04] <roozhou> xavs?
[16:24:24] <kierank> yes
[16:24:37] <roozhou> one of xavs developers was my classmate
[16:24:48] <roozhou> in college
[16:25:09] <kierank> jianwen chen  was the guy
[16:25:32] <roozhou> i don't know this guy
[16:38:33] <_skal_paris_> BBB: shall i send to the ML?
[16:38:52] <_skal_paris_> BBB: for some second look..
[16:39:59] <Dark_Shikari> BBB: left_nnz is aligned for AV_WN64A
[16:40:04] <Dark_Shikari> same with nonzero cache
[16:40:10] <Dark_Shikari> er, for AV_ZERO I mean
[16:41:31] <Honoome> for LU_ZERO?
[16:45:09] <_skal_paris_> BBB:http://pastebin.org/428179
[16:49:13] <Dark_Shikari> _skal_paris_: are you sure it's worthwhile to pack bits like that
[16:49:14] <Dark_Shikari> ?
[16:49:18] <Dark_Shikari> I don't think it is
[16:49:25] <Dark_Shikari> too much extra calculation to save a tiny bit of memory
[16:49:56] <Dark_Shikari> it looks ugly too
[16:50:55] <lu_zero> ....
[16:51:09] <_skal_paris_> Dark: i don't like the [9]
[16:51:43] <Dark_Shikari> What's wrong with (9)? That's the strongest array.
[16:51:50] <Dark_Shikari> But more seriously, I don't see how yours is going to make things any faster
[16:51:53] <Dark_Shikari> it has more logic
[16:52:03] <Dark_Shikari> and [9] makes perfect sense
[16:52:04] <_skal_paris_> Not really
[16:52:06] <Dark_Shikari> 4 luma AC
[16:52:10] <Dark_Shikari> 4 chroma AC
[16:52:11] <Dark_Shikari> 1 luma DC
[16:52:17] <Dark_Shikari> er... it has way more logic
[16:52:20] <Dark_Shikari> extracting bits from a mask is many ops
[16:52:24] <Dark_Shikari> you have needless conditionals too
[16:52:33] <Dark_Shikari> #
[16:52:34] <Dark_Shikari> if (nnz)
[16:52:34] <Dark_Shikari> #
[16:52:34] <Dark_Shikari> +                s->has_non_zero_ac |= block_bit;
[16:52:36] <_skal_paris_> it's always tests to zero
[16:52:43] <Dark_Shikari> It's far better to do s->has_non_zero_ac |= nnz
[16:53:02] <lu_zero> what's DRA?
[16:53:07] <Dark_Shikari> "it's always tests to zero"?
[16:53:18] <_skal_paris_> extrating the bits
[16:53:23] <_skal_paris_> tract
[16:53:50] <Dark_Shikari> your extracting takes like 6+ ops
[16:53:54] <Dark_Shikari> current takes 1 op
[16:53:55] <Dark_Shikari> my question is
[16:53:56] <Dark_Shikari> what does this save?
[16:54:04] <Dark_Shikari> what are you saving that justifies a hundred extra ops per mb?
[16:54:44] <kierank> 17:53] <@lu_zero> what's DRA? --> a new chinese audio codec that was included in the blu-ray spec recently
[16:54:49] <_skal_paris_> i could time
[16:54:57] <_skal_paris_> but in doubt, i prefer compactness
[16:55:13] <Dark_Shikari> yours is less compact!
[16:55:14] <Dark_Shikari> it's more code
[16:55:26] <Dark_Shikari> and yes, time optimizations please
[16:58:21] <lu_zero> kierank: anything interesting there?
[16:58:46] <Honoome> lu_zero: beside "it's chinese" and "it was included in a spec"?
[17:04:12] <BBB> _skal_paris_: could you add a few START/STOP_TIMERS to make sure it doesn't get slower?
[17:04:16] <BBB> I don't thnk it will be
[17:04:18] <BBB> but always good to prove
[17:04:57] <_skal_paris_> BBB: on it
[17:05:06] <Dark_Shikari> I personally reject the patch even if it's neutral.
[17:05:07] <BBB> j0sh: how do you manually enable http-rtsp tunneling? is there a ?keyword?
[17:05:17] <Dark_Shikari> i.e. if all else is equal, pick the simpler code.
[17:05:29] <BBB> Dark_Shikari: I think it's ok, memory saving (even a few bytes) is useful for phones etc.
[17:05:30] <Dark_Shikari> Only if it's faster will I consider it.
[17:05:35] <BBB> which we will eventually target
[17:05:43] <Dark_Shikari> BBB: um...
[17:05:55] <BBB> (I agree it's minimal)
[17:05:57] <Dark_Shikari> 2.5 kilobytes?
[17:05:59] <Dark_Shikari> for CIF?
[17:06:03] <Dark_Shikari> >_>
[17:06:05] <_skal_paris_> Dark: i think the has_non_zero* logic is clearer
[17:06:10] <Dark_Shikari> that's not even worth bothering with
[17:06:16] <Dark_Shikari> _skal_paris_: maybe, but the bitmask bullshit is unreadable
[17:06:17] <BBB> I agree, it's small
[17:06:26] <BBB> but 2 cycles gain is small also
[17:06:32] <Dark_Shikari> but it won't be 2 cycles gained
[17:06:34] <Dark_Shikari> it'll be 200 cycles lost
[17:06:35] <BBB> if we do it all over the place it may eventually add up to something noticeable
[17:06:51] <BBB> that's why he has to test performance ;)
[17:06:52] <Dark_Shikari> there is simply far more logic  here.
[17:07:10] <Dark_Shikari> even if it's faster I still reject it.  he would need to make it not ugly as sin
[17:07:23] <BBB> I actually did the same "trick" in wmavoice :-p
[17:12:06] <_skal_paris_> old:
[17:12:07] <_skal_paris_> 908550 dezicycles in block, 1 runs, 0 skips
[17:12:07] <_skal_paris_> 480380 dezicycles in block, 2 runs, 0 skips
[17:12:07] <_skal_paris_> 251070 dezicycles in block, 4 runs, 0 skips
[17:12:07] <_skal_paris_> 132810 dezicycles in block, 8 runs, 0 skips
[17:12:07] <_skal_paris_> 85013 dezicycles in block, 16 runs, 0 skips
[17:12:07] <_skal_paris_> 48212 dezicycles in block, 32 runs, 0 skips
[17:12:08] <_skal_paris_> 28723 dezicycles in block, 64 runs, 0 skips
[17:12:08] <_skal_paris_> 18145 dezicycles in block, 127 runs, 1 skips
[17:12:09] <_skal_paris_> 12540 dezicycles in block, 255 runs, 1 skips
[17:12:09] <_skal_paris_> new:
[17:12:14] <Dark_Shikari> um, not enough runs
[17:12:16] <_skal_paris_> 738570 dezicycles in block, 1 runs, 0 skips
[17:12:16] <_skal_paris_> 436205 dezicycles in block, 2 runs, 0 skips
[17:12:16] <_skal_paris_> 224652 dezicycles in block, 4 runs, 0 skips
[17:12:16] <_skal_paris_> 116723 dezicycles in block, 8 runs, 0 skips
[17:12:16] <_skal_paris_> 61858 dezicycles in block, 16 runs, 0 skips
[17:12:16] <_skal_paris_> 33809 dezicycles in block, 32 runs, 0 skips
[17:12:16] <_skal_paris_> 20217 dezicycles in block, 64 runs, 0 skips
[17:12:17] <_skal_paris_> 13782 dezicycles in block, 128 runs, 0 skips
[17:12:17] <_skal_paris_> 9817 dezicycles in block, 256 runs, 0 skips
[17:12:21] <Dark_Shikari> that's far too few runs
[17:12:26] <Dark_Shikari> we need at least 100k+ runs
[17:12:36] <Dark_Shikari> your time is dominated entirely by the initial run
[17:12:43] <Dark_Shikari> which is completely random
[17:12:53] <Dark_Shikari> I also need stdev
[17:13:04] <Dark_Shikari> furthermore, you haven't even made it clear what you are timing
[17:13:19] <_skal_paris_> old: 32488 dezicycles in block, 261916 runs, 228 skips
[17:13:24] <_skal_paris_> new: 31840 dezicycles in block, 261924 runs, 220 skips
[17:13:28] <Dark_Shikari> what are you timing?
[17:13:37] <Dark_Shikari> and what is the stdev?
[17:14:00] <_skal_paris_> timing the whole mb-reconstruction loop
[17:14:21] <Dark_Shikari> er... you're not decoding the entorpy decoding?
[17:14:24] <Dark_Shikari> you know, the part that'll get slower?>
[17:15:10] <BBB> hi efriedma
[17:15:14] <_skal_paris_> ?
[17:15:18] <BBB> Dark_Shikari: calm down, he needs some coffee
[17:15:22] <_skal_paris_> Dark: decode_mb_mode()
[17:15:36] <efriedma> BBB: hi
[17:15:44] <_skal_paris_> decode_mb_coeffs()
[17:16:01] <_skal_paris_> int{ra,er}_predict()
[17:16:05] <_skal_paris_> seems the full monthy to me
[17:16:26] <Dark_Shikari> decoding an entire mb is only 3k clocks?
[17:16:38] <Dark_Shikari> do you have a magical future computer from space?
[17:16:40] <BBB> brb
[17:18:01] <_skal_paris_> Dark: i'm timing 1547->1588
[17:18:23] <Dark_Shikari> for what?
[17:19:08] <_skal_paris_> ?
[17:19:52] <Dark_Shikari> something is going from 1547->1588 clocks
[17:19:53] <Dark_Shikari> what is it?
[17:20:12] <_skal_paris_> that's the line numbers in vp8.c where i put START/STOP TIMER :)
[17:20:39] <Dark_Shikari> oh.
[17:20:46] <Dark_Shikari> ok, I'll do testing in a moment.
[17:21:00] <_skal_paris_> k
[17:54:52] <BBB> bug report on webm bug tracker: "libvpx is slow" (issue156)
[17:55:38] <mru> there are a lot of such complaints
[17:55:57] <Honoome> RESO WONTFIX → use ffvp8
[17:56:04] <mru> it's the encoder
[17:56:52] <Honoome> RESO UPSTREAM → write ffvp8enc :P
[17:57:05] <Dark_Shikari> BBB: link?
[17:57:32] <peloverde> http://code.google.com/p/webm/issues/detail?id=156
[17:58:07] <Dark_Shikari> lol
[18:00:34] <BBB> it's a little funny ;)
[18:00:49] <BBB> is there interest in adapting x264 to output webm compatible streams?
[18:00:57] <BBB> that'd be a fun project
[18:01:08] <Dark_Shikari> You mean vp8 ?
[18:01:12] <BBB> yes
[18:01:20] <BBB> toomanybuzzwords
[18:01:25] <Dark_Shikari> "webm compatible" is a stupid phrase
[18:01:29] <Dark_Shikari> that doesn't even make sense
[18:01:29] <BBB> I agree
[18:01:37] <BBB> I meant vp8 streams
[18:02:09] <Dark_Shikari> and yes, I think that would be interesting =p
[18:02:11] <BBB> wbs: do you remember how to maually enable http tunneling in rtspdemuxer?
[18:02:16] <Dark_Shikari> it would troll the shit out of the freetards
[18:02:24] <Dark_Shikari> and further the x264/vp8 conspiracy
[18:02:26] <BBB> that's exactly why it's interesting
[18:02:36] <Dark_Shikari> even better... let's do it on runtime, not compile time
[18:02:39] <mru> that would be rather hilarious
[18:02:40] <BBB> I think people in general don't appreciate how similar all these fuzzy video codecs are
[18:02:42] <Dark_Shikari> so you can't distribute it without distributing an x264 encoder
[18:02:47] <BBB> of course runtime
[18:02:51] <BBB> -o h264 is default
[18:02:55] <BBB> -o vp8 makes it "free"
[18:03:03] <BBB> we'll call it "free" mp3^d^d^dh264
[18:03:36] <mru> how much work would it be?
[18:03:43] <Dark_Shikari> If we start by implementing the minimum necessary
[18:03:44] <funman> sell x264 to FSF
[18:03:50] <Dark_Shikari> i.e. not the whole spec but just the parts that are easiest conversions
[18:03:53] <Dark_Shikari> it wouldn't be too hard
[18:03:56] <Dark_Shikari> a week or two of hacking
[18:04:09] <mru> obviously no altref and shit
[18:04:28] <mru> how does libvpx use altref?
[18:04:42] <funman> what i wonder is, how does libvpx use shit?
[18:04:48] <Dark_Shikari> I suspect that without using any vp8-unique features, we could beat the crap out of libvpx
[18:05:01] <mru> btw, I found a few h264 files where ffmpeg differs from jm
[18:05:07] <Dark_Shikari> yes, we know they exist
[18:05:12] <Dark_Shikari> patches welcome
[18:08:43] <_skal_paris_> intra-only should be easy
[18:10:12] <mru> here's a troll plan: first make a simple encoder, clearly inferior to libvpx (although faster)
[18:10:27] <mru> this will fuel the conspiracy theories
[18:10:38] <Dark_Shikari>  no, let's just make it better.
[18:10:38] <mru> the, a week or two later, make it _better_ than libvpx
[18:10:48] <mru> which shouldn't be too hard
[18:10:50] <BBB> like the decoder
[18:10:52] <BBB> that's great
[18:10:55] <Dark_Shikari> _skal_paris_: http://pastebin.org/428232
[18:10:56] <Dark_Shikari> coefficient loop
[18:10:57] <BBB> because it's two slashdot stories
[18:10:58] <BBB> not one
[18:10:59] <Dark_Shikari> new/old/new/old/etc
[18:11:03] <mru> it's also the natural way of doing development
[18:11:09] <mru> start with I-frames, etc
[18:11:20] <Dark_Shikari> 6-8% slower
[18:11:32] <mru> put it on /. when it encodes I and P frames
[18:11:35] <BBB> Dark_Shikari: hm, that's unacceptable :(
[18:11:52] <Dark_Shikari> that's decode_mb_coefficients
[18:11:58] * funman can't find lego testers
[18:12:12] <Dark_Shikari> the new code is also 400 bytes larger
[18:12:22] <mru> funman: no kindergarten nearby?
[18:12:47] <funman> i'd expect today kids to facebook, not play lego!
[18:14:03] <Dark_Shikari> BBB: btw, if you want to do it
[18:14:07] <Dark_Shikari> I would say do two things:
[18:14:19] <Dark_Shikari> 1) add vp8 option, have it auto-disable everything that isn't in vp8 _or_ we haven't converted yet
[18:14:34] <Dark_Shikari> e.g. bframes, trellis, etc
[18:14:40] <Dark_Shikari> 2) convert cabac and header writing
[18:14:46] <Dark_Shikari> however, everything would stay as h264-like as possible
[18:14:53] <Dark_Shikari> so we still use h264 syntax element names, etc
[18:14:55] <mru> that's the entire point
[18:14:57] <BBB> of course, that was always my plan
[18:14:58] <Dark_Shikari> to minimize the amount of code necessary to be changed
[18:15:01] <mru> maximum troll effect
[18:15:07] <Dark_Shikari> because pengvado will not like it if we fuck with x264 needlessly
[18:15:10] <Dark_Shikari> to appease the gods of vp8
[18:15:11] <BBB> it should be minimal and "upstreamable"
[18:15:21] <Dark_Shikari> so in short:
[18:15:24] <Dark_Shikari> 1) add vp8 option (3 minutes)
[18:15:28] <Dark_Shikari> 2) disable nearly everything (5 minutes)
[18:15:33] <Dark_Shikari> 3) new header writing (a few hours)
[18:15:37] <Dark_Shikari> 4) new cabac (a few hours)
[18:15:49] <Dark_Shikari> bam, one day of hacking and you have a working encoder that produces a valid output stream
[18:15:52] <funman> 5) ???
[18:15:57] <BBB> 0) get familiar with where stuff is in x264 (a few days)
[18:15:59] <mru> 6) TROLL
[18:15:59] <Dark_Shikari> then, you fix intra
[18:16:08] <Dark_Shikari> then  you fix inter (new get_ref and mc_luma functions)
[18:16:23] <Dark_Shikari> and predict mv
[18:16:32] <Dark_Shikari> the best part is most of the work is already done for you ;)
[18:16:46] <Dark_Shikari> ref off the frame == -2
[18:16:50] <Dark_Shikari> intra ref (CURRENT) == -1
[18:16:56] <Dark_Shikari> prev frame (LAST) == 0
[18:16:58] <Dark_Shikari> golden == 1
[18:17:00] <Dark_Shikari> etc
[18:17:33] <peloverde> I think Vorbis and AAC have shown making something that spits out a valid output stream is much harder than making it not suck
[18:17:49] <Dark_Shikari> peloverde: most of the code that makes it "good" is already there.
[18:17:59] <BBB> right, that's why you'd use x264
[18:18:02] <Dark_Shikari> x264 is already good.
[18:18:02] <funman> peloverde: missing psycho accoustics?
[18:18:05] <BBB> rather than developing ffvp8enc
[18:18:15] <Dark_Shikari> ok, so I endorse this trolling scheme.
[18:18:19] <BBB> peloverde: and that's why ffaacenc is so exciting, I wish I could give you money for it
[18:18:42] <BBB> peloverde: because stuff is shareable
[18:18:47] <mru> BBB: sue some more gpl violators and you'll be able to
[18:18:53] <BBB> true
[18:18:56] <BBB> working on it
[18:19:23] <funman> 1/ --disable code written by people suing
[18:19:32] <funman> 2/ ship a new gpl violating ffmpeg
[18:19:52] <Dark_Shikari> michael gave permission for sflc to sue on behalf of him
[18:19:53] <Dark_Shikari> iirc
[18:19:57] <Dark_Shikari> which means "lol you're screwed"
[18:20:10] <funman> ah it's nice
[18:20:12] <peloverde> The SFLC has agrements from contributors deemed essential (i.e. michael)
[18:20:12] <BBB> no he didn't
[18:20:22] <BBB> but we have enough to sue anyone
[18:20:24] <peloverde> it's like a patent pool ;-p
[18:20:33] <peloverde> he didn't?
[18:20:37] <BBB> not that I know
[18:20:48] <BBB> Michael, please reply to the irc log list if you read this, did you? :-p
[18:21:09] <funman> i don't believe there's something that michael doesn't know
[18:21:18] <Dark_Shikari> he doesn't know how to make a good video encoder
[18:21:20] * Dark_Shikari runs
[18:21:29] <funman> :)
[18:21:40] <_av500_>  /undo!!!!
[18:21:46] <funman> what did he wrote: ffv1 and mpeg4 asp ?
[18:21:52] <Dark_Shikari> mpegvideo and ffv1
[18:22:00] <Dark_Shikari> mpegvideo ---> all lossy encoders in ffmpeg
[18:22:15] <funman> also snow
[18:22:20] <BBB> I thought mpegvideo was decent?
[18:22:27] <Dark_Shikari> ok, it's decent.
[18:22:39] <mru> what's the fabrice/michael ratio in mpegvideo?
[18:22:41] <BBB> look, mpeg isn't gonna beat h264 (e.g. x264)
[18:22:45] <Dark_Shikari> I'm just trolling him.
[18:22:47] <BBB> so don't compare it to that
[18:22:51] <Dark_Shikari> BBB: that isn't what I mean
[18:22:55] <BBB> I'm not comparing vp8 and h264 either, it'd be unfair ;)
[18:23:00] <Dark_Shikari> the encoders have no sensible defaults, require months of code investigation to come up with them
[18:23:01] * BBB runs
[18:23:04] <funman> mru: in number of codecs?
[18:23:06] <Dark_Shikari> and have crap psy opts
[18:23:11] <Dark_Shikari> mru: good question
[18:27:04] <iive> mru: i doubt there is any code left from fabrice
[18:27:13] <mru> there's quite a bit
[18:27:37] <funman> mpegaudio?
[18:27:42] <Compn> iive doesnt trust svn blame?
[18:27:47] <mru> and even if few lines are directly attributable to him, he did much of the underlying work
[18:27:58] <Compn> someone did a count of lines in ffmpeg
[18:28:09] <funman> svn blame doesn't see moved lines, does it?
[18:28:15] <Compn> michael was either #1 or #2 and fabrice was top 10 at least
[18:28:16] <peloverde> git does
[18:28:47] <iive> ^_^
[18:29:06] <peloverde> http://archives.free.net.ph/message/20100216.113913.8a0b7e89.it.html
[18:30:08] <Dark_Shikari> whoa.  kshishkov .
[18:30:45] * funman goes run that on rockbox
[18:32:55] <_av500_> funman: count the negative lines removing all my code :)
[18:33:22] <funman> _av500_: what was your committer name?
[18:33:36] * funman can't find git-blame-stats equivalent anyway
[18:34:07] <_av500_> funman: no, the original jb6000 + jbr os :)
[18:35:11] <peloverde> tmmm is also mike?
[18:35:40] <funman> _av500_: hm?
[18:36:08] <mru> peloverde: yes
[18:40:29] <pengvado> Dark_Shikari: that is sufficiently hilarious that it almost overrides me not wanting to encourage vp8 encoding.
[18:40:58] <funman> _av500_: http://www.jbros.co.kr/ ?
[18:41:12] <funman> is that a birthday cake or a vlc logo imitation?
[18:45:16] <_skal_paris_> Dark: ah yeah, the bit-munching thing is slower here too
[18:49:32] <Dark_Shikari> pengvado: lol
[18:50:15] <Dark_Shikari> _skal_paris_: fyi, I really do like hacks that involve bitmasks/etc
[18:50:21] <Dark_Shikari> especially for dealing with dct coeffs
[18:50:26] <Dark_Shikari> but here it doesn't really _get_ you anything
[18:50:36] <Dark_Shikari> i.e. it doesn't let you do larger-scale compare magic or something that you couldn't do before.
[18:50:52] <mru> make a mode where it encodes as both h264 and vp8, then mocks the user at the end
[18:50:56] <Dark_Shikari> (example of bit masking magic in x264: coeff_level_run, where we convert the dct block to a bitmask and iterate over it with count-trailing-zeroes to do run-level coding)
[18:51:28] <Dark_Shikari> pengvado: the best part is where patent FUD conflicts with making good vp8 encodes
[18:51:42] <Dark_Shikari> i.e. where our encodes look much better than libvpx
[18:51:51] <_skal_paris_> Dark: i managed to get rid of the update_nz_bit() and get_nz_bit()
[18:51:52] <Dark_Shikari> but "omg x264"
[18:52:07] <Dark_Shikari> _skal_paris_: I don't think getting rid of those will fix the problem
[18:52:11] <_skal_paris_> Dark: and get similar speed, but the code get .. well..
[18:52:16] <Dark_Shikari> lol
[18:52:19] <_skal_paris_> even less showable, let's say
[18:52:51] <Dark_Shikari> btw
[18:52:55] <Dark_Shikari> one thing I think might be worthwhile
[18:53:11] <Dark_Shikari> do decode_mb_coeffs, then idct, repeatedly, for each block at a time
[18:53:17] <Dark_Shikari> one and then then other
[18:53:21] <Dark_Shikari> instead of all decode, then all idct
[18:53:24] <_skal_paris_> Dark: i think the small overall speed-up was because i was testing block[y][x][0] for the DC
[18:53:28] <Dark_Shikari> but of course that naively appears to break the idct_dcy4
[18:53:30] <_skal_paris_> instead of just nnz
[18:53:38] <_skal_paris_> (*if* there was a speed-up)
[18:53:53] <Dark_Shikari> _skal_paris_: oh, you mean that some dct blocks were marked as dc, but had nothing?
[18:53:59] <_skal_paris_> yeah
[18:54:10] <_skal_paris_> or, the WHT generated zeros on some sub-4x4
[18:54:18] <Dark_Shikari> that's what I mean
[18:54:24] <wbs> BBB: yes, add ?http to enable it
[18:54:29] <Dark_Shikari> you should go do some testing and see how common that is
[18:54:45] <_skal_paris_> yeah, but that's independant of this nnz thing
[18:54:58] <_skal_paris_> could be done anyway, separately
[18:54:58] <Dark_Shikari> I know
[18:55:11] <_skal_paris_> ok, time to head home
[18:55:33] <Dark_Shikari> home from paris?
[18:55:34] <_skal_paris_> i'll fiddle more with the bit thing later (just because i like it)
[18:55:56] <_skal_paris_> yup, small pit-stop for summer
[18:56:00] <_skal_paris_> then back to sun
[18:56:40] <_skal_paris_> later!
[18:57:13] <Honoome> Dark_Shikari: you find misnomers annoying?
[18:58:07] <Dark_Shikari> ?
[18:58:16] <Honoome> the "webm compatible" vs vp8 before :P
[19:00:07] <Dark_Shikari> yes
[19:00:19] <Honoome> because if you find those annoying, I know somebody in here that talks about "html5 pseudostreaming" ¬_¬
[19:02:18] <Dark_Shikari> pseudostreaming at least has an accepted definition
[19:02:25] <Honoome> but html5?
[19:02:30] <Dark_Shikari> even if it's just buzzwordspeak for progressive download
[19:02:35] <Dark_Shikari> progressive download is what html5 video does
[19:02:50] <Honoome> it has nothing to do with html5
[19:03:03] <Honoome> it's http at best, not html5
[19:03:14] <mru> it's what current browsers support
[19:03:28] <wbs> there's nothing saying you could add an rtsp:// or mms:// or whatever url in the html5 video tag
[19:03:49] <mru> couldn't?
[19:03:58] <wbs> couldn't, yes
[19:04:24] <Honoome> just like there's nothing saying you can't add a gopher:// sftp:// git:// itms:// link in an x?html4? <a> tag :P
[19:04:34] <wbs> yeah
[19:05:01] <Honoome> I'm fine with http pseudosteam, but html5.. that's the worst marketing speak I heard in a while
[19:05:36] <wbs> I've seen people request html5 streaming video for mobile phones where the actual browser doesn't support html5
[19:05:47] <Dark_Shikari> Honoome: how else do you want to express <video>
[19:05:49] <Dark_Shikari> it didn't exist before html5.
[19:05:52] <wbs> people just take html5 == non-flash
[19:06:10] <Honoome> Dark_Shikari: progressive download existed before html5
[19:06:18] <Dark_Shikari> er...
[19:06:19] <mru> flash does it
[19:06:25] <Dark_Shikari> but they explicitly mean html5 pseudostreaming
[19:06:29] <Dark_Shikari> i.e. with <video>
[19:06:32] <Dark_Shikari> which did not exist before html5
[19:06:33] <Dark_Shikari> durhrhrhrh
[19:06:57] <Honoome> the fact that you use it with <video> has nothing to do with the technique used behind, it's protocol-level, not format level
[19:07:00] <Dark_Shikari> um...
[19:07:01] <mru> so it means "progressive download invoked with <video> tag"
[19:07:03] <Dark_Shikari> but they're not talking about the technique used
[19:07:10] <Dark_Shikari> they're just saying "I am using technique X with tag Y"
[19:07:14] <Dark_Shikari> X == progressive download
[19:07:16] <Dark_Shikari> Y == <video>
[19:07:27] <Honoome> Dark_Shikari: when describing a streaming server behaviour?
[19:07:29] <Dark_Shikari> is it wrong to say "I have a red honda"?
[19:07:35] <Dark_Shikari> I'm saying it's both red, AND it's a honda!
[19:08:02] <funman> i'm ok with red, but having a honda is clearly wrong
[19:08:27] <Honoome> funman: you'd prefer a uawei? [okay this was far-fetched and unfunny]
[19:10:37] <Honoome> Dark_Shikari: what about a "red honda engine"?
[19:11:04] <mru> obviously a honda engine in a red car :-)
[19:11:44] <Honoome> so you go to an engine shop and ask for a "red honda engine" and they give you... what? :P
[19:11:55] <Honoome> an engine stripped from a stolen red honda?
[19:21:01] <Dark_Shikari> "red honda engine"?
[19:21:03] <Dark_Shikari> well that's important
[19:21:08] <Dark_Shikari> everyone knows that if it's red, it's three times faster.
[19:22:13] <elenril> <insert relevant trope here>
[19:22:38] <Honoome> Dark_Shikari: that's about how html5 feels :P
[19:22:47] <Honoome> elenril: you're growing lazy!
[19:23:08] <funman> ferrari effect
[19:23:35] <Dark_Shikari> Honoome: but it IS three times faster
[19:24:29] <Dark_Shikari> http://tvtropes.org/pmwiki/pmwiki.php/Main/LawOfChromaticSuperiority
[19:36:47] <pengvado> http://www.overcomingbias.com/2009/09/seeing-red.html <-- yep, red is faster
[19:39:09] <funman> ☭ is not always faster
[19:40:27] <funman> is rgb655 faster than rgb565 ?
[19:41:24] <Dark_Shikari> Yuvi: any status on finishing up edge emulation?
[19:42:20] <pengvado> funman: depends whether you use the extra red bit to increase the range or only the precision
[19:42:37] <Dark_Shikari> why not just apply a gamma to the red channel
[19:50:11] <funman> pengvado: the extra bit could be used as 'fast': > 0x1f = fast red
[19:50:51] <Dark_Shikari> but all red is fast.
[19:51:09] <funman> brighter red is faster
[19:51:11] <Dark_Shikari> now, what I want is RGBV
[19:51:16] <Dark_Shikari> 32-bit
[19:51:22] <Dark_Shikari> red, green, blue, violet
[19:51:22] <funman> V = ?
[19:51:37] <funman> RVB is french RGB
[19:51:40] <Dark_Shikari> or we could go further and do RYGBV
[19:59:19] <mru> CMYUV
[19:59:36] <Dark_Shikari> that doesn't even make sense
[19:59:56] <funman> RAINBOW
[20:08:37] <Dark_Shikari> ugh.  so much stupid
[20:08:45] <Dark_Shikari> the 3d craze has led to people asking on doom9 how to "convert their movies to 3D"
[20:09:07] <BBB> awe s o m e
[20:09:38] <mru> we obviosly need an output feeding http://makerbot.com/
[20:09:41] <BBB> is doom9 really that fantastic?
[20:09:56] <BBB> I always wonder, because webforums inherently fall into chaos given enough time
[20:10:19] <Dark_Shikari> doom9 is fine
[20:10:26] <mru> doom10 is better
[20:10:28] <mru> it's one more
[20:10:32] <Dark_Shikari> it has its quota of stupid, but it's not particularly liked
[20:34:00] <Yuvi> Dark_Shikari: fixed some bugs, works most of the time but still some bugs remaining :/
[20:34:27] <BBB> oh boy I'll be offline for a while
[20:34:32] <BBB> just got my sc2 box :-p
[20:34:40] <Dark_Shikari> lol
[20:34:44] <BBB> thank god vp8 wasn't released 4 weeks later
[20:34:48] <Dark_Shikari> Snape kills Kerrigan with Dumbledore.
[20:34:52] <Dark_Shikari> now you don't have to play
[20:35:06] <Dark_Shikari> Raynor is her father
[20:35:28] <Dark_Shikari> Arcturus Mengsk isn't real
[20:35:34] <Dark_Shikari> Zeratul is Keyser Soze
[20:35:49] <Dark_Shikari> Hyperion was his sled
[20:35:52] <mru> are you guys _all_ insane?
[20:36:00] * funman hits mru with a pylon
[20:36:08] <Dark_Shikari> mru: http://addisonrd.com/WordPress/wp-content/uploads/2007/05/spoilers.gif
[20:36:44] <funman> verbal kint :)
[20:36:50] <BBB> /me pokes mru
[20:36:54] <BBB> wanna play on bnet?
[20:36:57] * BBB hides
[20:37:07] <Yuvi> jekyll and hyde were the same person
[20:37:22] <funman> no
[20:38:23] <funman> physical person perhaps?
[20:38:36] <Dark_Shikari> oh god this isn't umineko
[20:38:39] <Dark_Shikari> no more DID!
[20:38:44] <Dark_Shikari> personas are not people!
[20:39:13] <funman> Dark_Shikari: so which race are you playing in sc2?
[20:39:20] <Dark_Shikari> I've mostly been playing protoss
[20:39:23] <Dark_Shikari> though I haven't played for over a month
[20:39:27] <Dark_Shikari> other than singleplayer
[20:39:36] <funman> in sc1, terran: marines+tanks > protoss: dragoons
[20:39:45] <Dark_Shikari> marines are useless against dragoons
[20:39:48] <Dark_Shikari> once the dragoons have range at least
[20:39:53] <Dark_Shikari> also, reavers
[20:40:01] <Dark_Shikari> the only purpose of marines in TvP is for cheese rushes
[20:40:05] <funman> tanks blow them before marines can reach them
[20:40:10] <Dark_Shikari> which, honestly, works pretty well if the protoss is just blindly 14-nexusing or something
[20:40:11] <peloverde> dragoons are useless in teh presence of stairs
[20:40:20] <funman> reavers suck big times
[20:40:28] <Dark_Shikari> yes, they suck if you're terran
[20:40:29] <funman> i can't fight them, and i can't use them :)
[20:40:34] <mru> guys, this isn't #ffmpeg-kindergarten
[20:40:44] <mru> go play your games elsewhere
[20:40:54] <Dark_Shikari> mru: coding on ffmpeg is a game just like any other
[20:41:01] * funman sends a starcraft CD to mru
[20:41:09] <Dark_Shikari> life is just a game.  have fun.
[20:41:16] * mru has no optical drive in his laptop
[20:41:18] <peloverde> it's no game, it is the number 1 esport worldwide, a multimillion dollar industry
[20:41:27] <Dark_Shikari> peloverde: esports are still games
[20:41:31] <Dark_Shikari> no more or less games than, say, football
[20:41:37] <mru> football is a game
[20:41:48] <mru> ever heard of the olympic games?
[20:41:50] <funman> mru: you've got loop devices?
[20:42:09] <peloverde> They use theora in their cutsecenes and the quality was sub par, is that back on topic?
[20:42:22] <Dark_Shikari> it's better than bink =p
[20:42:35] * Dark_Shikari remembers starcraft 1 cutscenes
[20:42:36] <Dark_Shikari> oh wait
[20:42:37] <Dark_Shikari> those were not bink
[20:42:39] <Dark_Shikari> those were SMACKER.
[20:42:41] <peloverde> smacker
[20:42:42] <Dark_Shikari> Now _that_ goes back.
[20:42:58] <Yuvi> I thought sc1 was mpeg4
[20:42:58] <funman> 'starcraft' goes back already
[20:43:03] <Yuvi> it's been too long
[20:43:04] <funman> 1998?
[20:43:05] <Dark_Shikari> mpeg-4 didn't exist
[20:43:09] <Dark_Shikari> when they developed it
[20:43:13] <Yuvi> makes sense
[20:43:17] <Yuvi> must be thinking of some other game
[20:43:28] <Dark_Shikari> march 1998, yes
[20:43:44] <Dark_Shikari> fuck that was ages ago.
[20:43:59] <peloverde> 12 years
[20:44:12] * funman still did serious playing last year
[20:44:18] <Dark_Shikari> damn, they're even slower than Valve
[20:44:20] <mru> so Dark_Shikari has wasted half is life on it
[20:44:29] <mru> *his
[20:44:31] <Dark_Shikari> mru: actually I've only really watched starcraft for the past year or so
[20:44:43] <mru> you _watch_ it???
[20:44:47] <Dark_Shikari> and I probably only played a few dozen games of the original
[20:44:47] <mru> not play?
[20:44:51] <funman> ah
[20:44:55] <Dark_Shikari> well, not counting the use map settings games back in the day
[20:44:56] <Dark_Shikari> when I was like... 12
[20:44:59] <Dark_Shikari> matrix defense, bunker wars, etc
[20:45:04] <Dark_Shikari> but that was ages ago
[20:45:15] <peloverde> bunker command was the best
[20:45:17] <funman> Dark_Shikari: i defy you to sc1
[20:45:17] <Dark_Shikari> I spent my younger half of childhood mostly playing starcraft, Age of Empires 2
[20:45:21] <Dark_Shikari> etc
[20:45:22] <Dark_Shikari> homeworld
[20:45:27] <Dark_Shikari> civ2
[20:45:36] <Dark_Shikari> colonization
[20:45:44] <Dark_Shikari> ~1995-2000 strategy era
[20:45:52] * funman just needs a bnet key
[20:45:53] <mru> booooring
[20:45:55] <Dark_Shikari> funman: I haven't played in ages :>
[20:46:01] <Dark_Shikari> mru: it's boring because it involves your brain ?
[20:46:12] <Dark_Shikari> as opposed to shoving your massive throbbing gun down the mouths of your enemies
[20:46:20] <mru> it's boring because a games drags on for fucking ever
[20:46:23] <Dark_Shikari> of what?
[20:46:34] <Dark_Shikari> a game of what
[20:46:35] <mru> any strategy game
[20:46:38] <Dark_Shikari> er...
[20:46:43] <Dark_Shikari> starcraft games rarely last more than 15 minutes
[20:46:46] <Dark_Shikari> homeworld, probably no more than 30-45
[20:46:49] <peloverde> Most pro starcraft games are pretty short
[20:46:51] <Dark_Shikari> civ2, ok, that lasts 5-10 hours, but that's civ
[20:46:57] <peloverde> except stork v ggplay
[20:46:58] <Dark_Shikari> and that's not intended to be a one-sitting game
[20:47:01] <Dark_Shikari> peloverde: oh god
[20:47:03] <funman> my games lasted more like 60 mins
[20:47:07] <Dark_Shikari> AoE2 was usually 10-20 minutes
[20:47:18] <BBB> sc1 cutscenes?
[20:47:19] <Dark_Shikari> 30 minutes if you insisted on getting to imperial age and making 20 trebuchets before losing
[20:47:20] <BBB> those were divx
[20:47:23] <BBB> the first big use of divx iirc
[20:47:25] <Dark_Shikari> BBB: divx didn't exist when sc1 came out
[20:47:28] <mru> you must have played in a different way from anything I ever saw
[20:47:29] <Dark_Shikari> they were smacker
[20:47:42] <mru> divx didn't exist until ~2002
[20:48:01] <Dark_Shikari> Note how they are 256-color.
[20:48:06] <Dark_Shikari> DivX didn't have a 256-color mode.
[20:48:18] <mru> depends
[20:48:33] <mru> you can code mpeg4 as luma only
[20:48:43] <mru> and shove it on a palette display
[20:48:57] <peloverde> I thought AOE2 was bink?
[20:49:10] <Dark_Shikari> AoE2?  No idea
[20:49:19] <Dark_Shikari> It had a pretty damn good opening movie for its time though
[20:49:30] <Dark_Shikari> It was also the last really good game by ensemble, I think
[20:50:03] <peloverde> Where is mike when we need him, he knows every codec that any game ever used
[21:09:42] <funman> peloverde: who won in stork v ggplay: zerg or protoss ?
[21:10:49] <funman> (replay ETA: 45mins)
[21:11:13] <Dark_Shikari>  why spoil it?
[21:11:19] <Dark_Shikari> wait, was stork vs ggplay the one that ended up with crazy dark archon stuff?
[21:11:26] <Dark_Shikari> and a heavily fortified base at the top?
[21:11:34] <Dark_Shikari> I can remember a couple games that went insanely long
[21:11:53] <Compn> youtube stork v ggplay 85 mins ?
[21:11:54] <funman> i don't understand the start
[21:12:00] <funman> Compn: that's the one i'm watching
[21:12:03] <Compn> ah
[21:13:36] <Dark_Shikari> http://gurupreet.com/stork-vs-ggplay-aka-english-commentary-the-movie/
[21:13:41] <Dark_Shikari> there's one with english commentary
[21:13:53] <Dark_Shikari> no idea how good it is
[21:14:08] <funman> commentary = shit
[21:14:27] <Dark_Shikari> it's useful if you're not already a pro
[21:14:32] <Dark_Shikari> i.e. 99% of viewers
[21:14:52] <funman> why does mplayer mute all other audio players :'(
[21:14:58] <Dark_Shikari> I mean, I can watch most any game and get a lot out of it without commentary, but that's only because I've watched a couple hundred games _with_ commentary to learn enough to do that
[21:15:29] <funman> did you make battle.net tournaments or so?
[21:15:35] <Dark_Shikari> and even then, I'd rather have commentary.
[21:15:38] <Dark_Shikari> Though really only if it's from someone good.
[21:15:42] <Dark_Shikari> Like, say, Tasteless or Day9.
[21:17:03] <Compn> day9 is good :)
[21:17:20] <Dark_Shikari> tasteless was pretty awesome.  I want to see more gomtv tournaments
[21:17:30] <Dark_Shikari> the tournaments are always better because the players are more likely to try batshit crazy stuff
[21:17:38] <Dark_Shikari> that they're not willing to go for during normal league games
[21:17:44] <Compn> i want to play sc2 once or twice
[21:18:23] <funman> there's no single player beta on torrents?
[21:18:31] <Compn> probably
[21:18:36] <Compn> i'm just reminding myself
[21:18:42] <Dark_Shikari> there was no singleplayer beta
[21:18:47] <Compn> or that
[21:19:18] <funman> i'm pretty sure seeing single player games some months ago
[21:19:34] <Dark_Shikari> oh, you mean against the computer?
[21:19:36] <Dark_Shikari> yes those were available
[21:19:41] <Dark_Shikari> just not the campaign
[21:20:05] <funman> yeah, although AI was shit it seems
[21:20:19] <Dark_Shikari> less than shit, it did basicalyl nothing
[21:20:21] <Dark_Shikari> it was just for testing
[21:21:12] <funman> i only remember terran farms
[21:21:22] <funman> which could be buried to let units go through
[21:21:59] <Dark_Shikari> >farms
[21:22:03] <Dark_Shikari> go back to warcraft 3!
[21:22:19] <funman> didn't play much
[21:22:31] <funman> i played warcraft 2 recently
[21:22:44] <funman> still can't understand how one could enjoy it.
[21:23:02] <funman> 1/ no right click
[21:23:09] <funman> was it designed for macos ? :/
[21:23:21] <Dark_Shikari> welcome to 1995
[21:26:37] <spaam> thank you :D
[21:51:27] <Yuvi> gah, I kept forgetting about topright
[21:51:51] <Yuvi> now to make it less complicated
[21:52:26] <Dark_Shikari> now once we've done that, would anything get faster if we turned off edge emulation?
[21:52:37] <Dark_Shikari> i.e. if edge emulation isn't necessary
[21:53:21] <Yuvi> probably not, since it means that we have to copy the top/left edges for each of the top/left macroblocks, then copy the intra prediction back into the frame
[21:53:34] <Dark_Shikari> why would we have to copy them?
[21:53:40] <Dark_Shikari> just memset to 129
[21:53:51] <Dark_Shikari> i.e. what we're currently do
[21:53:52] <Dark_Shikari> *doing
[21:54:07] <Yuvi> you have to copy the left edge for each macroblock on the top except 0,0
[21:54:59] <Dark_Shikari> why
[21:55:51] <Yuvi> because you can't intra predict directly into the frame (since it might read 1 row above), so you need a temp buffer where -1 is valid
[21:56:01] <Dark_Shikari> why?
[21:56:06] <Dark_Shikari> isn't that what the xchg border is for?
[21:56:38] <Dark_Shikari> -1 is valid in the frame, too
[21:56:47] <Yuvi> dst[-linesize] is not valid to write or read from without an edge
[21:57:00] <Yuvi> same with dst[-1] on the left
[21:57:12] <Dark_Shikari> um
[21:57:14] <Dark_Shikari> that's why I said
[21:57:16] <Dark_Shikari> when edge emulation is off
[21:57:18] <Dark_Shikari> ...............
[21:57:31] <Dark_Shikari> dst[-1] on the left is perfectly valid if edge emulation is off
[21:57:35] <Yuvi> oh, no, all of this code is conditional on edge emulation being on
[21:57:50] <Dark_Shikari> I was asking if there's other stuff we can do in the case that it's off.
[21:57:52] <Yuvi> I'm not changing the current behaviour
[21:57:55] <Dark_Shikari> Such as, say, padding the edges for MC.
[21:58:20] <Yuvi> yeah, that'd buy you a bit less time in emulated_edge_mc
[21:58:39] <Dark_Shikari> no, it'd eliminate time in emulated_edge_mc.
[21:58:47] <Dark_Shikari> you wouldn't even have to check
[21:58:52] <Dark_Shikari> because vp8 includes its own built-in mv clamping
[21:58:57] <Yuvi> we only have an edge of 16 pixels for luma and 8 for chroma
[21:59:03] <Yuvi> that's not enough with a 6 tap filter
[21:59:08] <Dark_Shikari> So, make it larger.
[21:59:19] <Dark_Shikari> Do what x264 does.
[21:59:22] <Dark_Shikari> Make it 32 for luma, 16 for chroma.
[21:59:25] <Yuvi> it's a #define in dsputil.h
[21:59:28] <Dark_Shikari> Only pad the pixels necessary of course.
[21:59:31] <Dark_Shikari> .... that is retarded
[21:59:37] <Dark_Shikari> Why the fuck can't each codec pick how much padding it needs?
[21:59:49] <Dark_Shikari> In fact, what's stopping us from requesting frames of the size we want?
[22:00:03] <Dark_Shikari> when we allocate pictures?
[22:00:05] <Yuvi> the get_buffer API wasn't designed that way
[22:00:15] <Dark_Shikari> huh?
[22:00:19] <Yuvi> it rounds the width/height up to 16
[22:00:21] <Dark_Shikari> SOMEONE has to tell lavc what size frame it wants
[22:00:25] <Dark_Shikari> Well duh
[22:00:28] <Dark_Shikari> so we increase width and height by 32.
[22:00:30] <Dark_Shikari> Done.
[22:00:37] <Yuvi> you can't decrease it later
[22:00:43] <Dark_Shikari> And?
[22:00:55] <Dark_Shikari> Why do we care if the buffer is a bit too large?
[22:01:25] <Yuvi> because it's the same width/height that's used to determine how large a frame is displayed
[22:01:32] <Dark_Shikari> No it isn't
[22:01:42] <Yuvi> avctx->width, avctx->height
[22:01:43] <Dark_Shikari> copy_picture is run before returning a frame
[22:01:49] <Dark_Shikari> You can modify the height in the returned picture.
[22:01:57] <Dark_Shikari> iirc.
[22:02:06] <Dark_Shikari> i.e. to put a frame in the reference list, it's copied.
[22:02:36] <Dark_Shikari> width/height are properties of an AVPicture, not of the buffer itself
[22:02:44] <Dark_Shikari> so you can make a new AVPicture that aliases the old one
[22:02:47] <Dark_Shikari> and modify the internals.
[22:02:50] <Yuvi> we don't use copy_picture
[22:03:26] <Yuvi> and width/height aren't AVFrame properties, they're AVCodecContext properties
[22:03:42] <Dark_Shikari> ok, so we can increase them before calling get buffer
[22:03:45] <Dark_Shikari> and then decrease them.
[22:06:19] <Dark_Shikari> yes, this is getting really evil.
[22:09:43] <Yuvi> who was koorogi so I can yell at him for not giving avcodec_get_edge_width any parameters...
[22:11:16] <CIA-92> ffmpeg: aurel * r24578 /trunk/libavformat/assdec.c: add seeking support in ASS demuxer
[22:13:35] <Yuvi> j-b: does vlc ever not use CODEC_FLAG_EMU_EDGE when using a custom get_buffer?
[22:14:15] <j-b> Yuvi: ENO_NOIDEA
[22:14:50] <j-b> if( p_sys->b_direct_rendering )
[22:14:54] <j-b>     {
[22:14:58] <j-b>         msg_Dbg( p_dec, "trying to use direct rendering" );
[22:15:02] <j-b>         p_sys->p_context->flags |= CODEC_FLAG_EMU_EDGE;
[22:15:07] <j-b> oops
[22:15:49] <j-b> Yuvi: http://git.videolan.org/?p=vlc.git;a=blob;f=modules/codec/avcodec/video.c;hb=HEAD#l305 is the relevant code
[22:16:18] <Yuvi> and ffmpeg_GetFrameBuf uses avcodec_default_get_buffer if b_direct_rendering is false
[22:17:09] <Yuvi> so possibly nothing uses direct rendering + edge except maybe ffplay+libavfilter?
[22:17:37] <Dark_Shikari> you mean direct rendering + no edge emulation?
[22:17:47] <Yuvi> yeah
[22:18:20] <CIA-92> ffmpeg: aurel * r24579 /trunk/libavformat/avidec.c: avidec: demux ASS and SRT tracks out of GAB2 chunks
[22:18:29] <Yuvi> well, more no edge emu + custom get_buffer that doesn't use avcodec_default_get_buffer to allocate stuff
[22:19:30] <Yuvi> I think making avcodec_get_edge_width2 would be better
[22:19:36] <Yuvi> than changing width/height
[22:20:47] <CIA-92> ffmpeg: vitor * r24580 /trunk/libavcodec/x86/idct_mmx.c: Translate libmpeg2 MMX IDCT to plain asm
[22:21:00] <Yuvi> the whole buffer allocation API is a mess anyway
[22:36:39] * Vitor1001 breaks building in x86_64 :p
[22:38:14] <Vitor1001> Does anyone have a 64-bit x86 box to test my fix?
[22:38:14] <Vitor1001> http://ffmpeg.pastebin.com/rKqq5FRQ
[22:39:17] <CIA-92> ffmpeg: stefano * r24581 /trunk/cmdutils.c: Extend show_protocol() to make it print more information.
[22:40:32] <funman> Vitor1001: i can test
[22:40:39] <Vitor1001> funman: Great, thanks
[22:40:53] <j-b> Vitor1001: never ever trust funman :D
[22:41:04] <Vitor1001> Just see if it unbreak my compilation after my commit
[22:41:08] <Vitor1001> j-b: ;)
[22:41:31] <funman> commit, if it doesn't work on the build bots, just git push --force
[22:42:22] * Vitor1001 know nothing about git :(
[22:44:18] <funman> Vitor1001: it builds
[22:44:26] <Vitor1001> funman: nice!
[22:45:30] <Vitor1001> Let's see if fate goes green...
[22:46:15] <CIA-92> ffmpeg: vitor * r24582 /trunk/libavcodec/x86/idct_mmx.c: Fix compilation in x86_64. I broke it with r24580.
[23:45:47] <CIA-92> ffmpeg: stefano * r24583 /trunk/ (6 files in 2 dirs):
[23:45:47] <CIA-92> ffmpeg: Move fill_image_linesize() and fill_image_data_ptr() from
[23:45:47] <CIA-92> ffmpeg: libavcodec/imgconvert.c and make them public in libavcore/imgutils.h,
[23:45:47] <CIA-92> ffmpeg: with the names av_fill_image_linesizes() and av_fill_image_pointers().
[23:58:55] <CIA-92> ffmpeg: stefano * r24584 /trunk/doc/APIchanges: Add APIchanges entry for the libavcore/imgutils.h addition.