[FFmpeg-devel-irc] IRC log for 2011-03-12

[irc at mansr.com]

[00:02:05] <mru> hi j0sh, tsunami over?
[00:02:16] <j0sh> yep
[00:02:23] <mru> anything happen?
[00:02:28] <j0sh> i'm on oahu, didn't get hit as hard as maui or the big island
[00:02:32] <kierank> welcome back j0sh
[00:02:45] <j0sh> naw, the sea level is slightly higher and the marina a bit dirtier, otherwise its business as usual
[00:04:04] <j0sh> but apparently my building was on cnn last night
[00:04:27] <j0sh> and, inexplicably, it's also on honolulu's groupon today too
[00:05:37] <j0sh> it's no japan though
[00:11:39] <lu_zero> ^^;
[00:49:10] <mru> ruggles: were you running more tests or what?
[02:10:35] <Dark_Shikari> http://seclists.org/nmap-dev/2011/q1/767
[02:10:38] <Dark_Shikari> .... oh god this is hilarious
[02:28:30] <saintdev> Dark_Shikari: was just reading that on my way home, lol
[02:44:34] <asdf1234> what's hb gray?
[02:47:59] <saintdev> HB Gary is the company that got owned by Anon after their CEO attempted to
[02:48:07] <saintdev> 'expose' them
[02:48:25] * saintdev smacks his enter key
[02:49:03] <Sean_McG> o_O;
[03:07:46] <asdf1234> saintdev: what?
[03:08:18] <roxfan> asdf1234 has been living under a rock?
[03:08:31] <saintdev> roxfan: apparently
[03:08:34] <roxfan> http://arstechnica.com/tech-policy/news/2011/03/hbgaryanonymous-special-report.ars
[03:50:52] <Compn> the one thing that always makes me laugh out of the whole hbgary thing
[03:51:00] <Compn> was the line 'and remotely wiped his ipad'
[03:54:23] <Compn> if it was 'remotely wiped his laptop' it wouldnt be funny
[03:54:29] <Compn> but ipad ? laughs every time
[04:00:38] <ruggles> mru: sorry. dinner... bedtime... i'll get it done first thing in the AM
[04:38:37] <saintdev> peloverde: ping
[10:27:08] <_av500_> gm
[10:27:38] <_av500_> time for godzilla to get in action
[10:29:33] <lu_zero> uh?
[10:30:30] <thresh> _av500_: no, for mechagodzilla
[10:30:54] <_av500_> whoever can blow out the nuclear fire
[10:31:30] <ohsix> you can only blow out a fire if that's its oxidizer D:
[11:36:04] <CIA-36> ffmpeg: Mans Rullgard <mans at mansr.com> master * ra5444fee06 ffmpeg/ (configure libavcodec/Makefile libavcodec/x86/Makefile):
[11:36:04] <CIA-36> ffmpeg: Add CONFIG_AC3DSP symbol to simplify makefiles
[11:36:04] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:26:24] <lu_zero> lastlog mms
[12:31:42] <Kovensky> 09:28.25 Bocom: "If u add USA's 9-11-01 & Japan's 3-10-11 you get 12-21-12 ? WTF?" <-- mind blown
[12:39:53] <Tjoppen> numerology \o/
[12:40:52] <kshishkov> dynga
[13:42:32] <Tjoppen> does anyone know of a good binary diff tool? it needs to do a proper diff, not just byte for byte
[13:43:04] <Tjoppen> as in an edit distance type diff. my use case is comparing two mxf's
[13:43:26] <Dark_Shikari> mru: I'm waiting on a response to my patch 3/4 to commit the other 3, since there's dependencies
[13:50:13] <BBB> Dark_Shikari: vp8 patches are fine with me, don't expect a long review from me, working on vc1 ;)
[13:50:29] <Dark_Shikari> don't need one
[13:50:33] <Dark_Shikari> need approval on patch 3/4
[13:50:38] <Dark_Shikari> it's a trivial one
[13:50:40] <BBB> mans already gave one
[13:50:48] <Dark_Shikari> oh
[13:50:53] <Dark_Shikari> fast.
[13:50:54] <Dark_Shikari> thanks mru
[13:51:25] * Flameeyes <3 HE-AAC
[13:51:30] <BBB> patch 4/4 is insane magic btw
[13:51:33] <BBB> how do you do that?
[13:51:39] <BBB> do you use tools for that?
[13:51:55] <mru> brain?
[13:51:57] <Flameeyes> BBB: pahole (in dwarves) can help with that, not sure if Dark_Shikari is using it though
[13:52:00] <kierank> Flameeyes: why do you love he-aac
[13:52:17] <Dark_Shikari> BBB: brain
[13:52:22] <Dark_Shikari> and what do you mean insane magic?
[13:52:22] <mru> kierank: maybe it's the other way around
[13:52:28] <Dark_Shikari> I didn't even track offsets when I started
[13:52:30] <Flameeyes> kierank: sky.fm radio not glitching even if I'm downloading opensuse and another fuckload of stuff :D
[13:52:32] <Dark_Shikari> I just PUT THE IMPORTANT SHIT AT THE TOP
[13:52:32] <Dark_Shikari> lol
[13:52:37] <mru> kierank: maybe it's just he-aac f*cking him in the arse
[13:52:42] <Dark_Shikari> To track offsets during my fine tuning...
[13:52:44] <Dark_Shikari> offsetof()
[13:52:53] <Dark_Shikari> But PUTTING THE IMPORTANT SHIT AT THE TOP is generally enough
[13:52:59] <Flameeyes> Dark_Shikari: give a try to pahole.. quite nice
[13:53:05] <Flameeyes> I've been using it extensively on feng
[13:53:05] <Dark_Shikari> I'll try it sometime, on windows atm `-`
[13:53:09] <Dark_Shikari> But yeah, sounds cool
[13:53:29] <Dark_Shikari> oh, also, BBB
[13:53:32] <Dark_Shikari> to check binary size
[13:53:42] <Dark_Shikari> I configured with falign-functions, falign-labels, falign-loops, falign-jumps, all equal to 1
[13:53:48] <Dark_Shikari> which -Os does too, I guess
[13:54:01] <Dark_Shikari> This is useful to see if changing a variable's type hurts instruction size
[13:54:08] <Dark_Shikari> i.e. int -> uint8_t
[13:54:34] <BBB> right
[13:54:52] <BBB> ok, so PUT THE IMPORTANT SHIT AT THE TOP is what I should learn
[13:54:54] <Dark_Shikari> but there's no insane magic, it's basically all ad hoc
[13:54:55] * BBB remembers
[13:55:02] <Dark_Shikari> Now, if you want insane magic
[13:55:08] <Dark_Shikari> see my patch to use -128 byte struct offsets
[13:55:10] <Dark_Shikari> `-`
[13:55:19] * Flameeyes is the tools guy so would suggest codiff in pahole to track size difference in functions
[13:55:31] <Dark_Shikari> too bad there's only about one function
[13:55:35] <Dark_Shikari> everything except two functions is inlined
[13:55:43] <Dark_Shikari> I wonder if this makes gcc more dumb
[13:56:09] <Flameeyes> even more so?
[13:56:53] <BBB> Dark_Shikari: the function is frigging fast :-p
[13:57:03] <BBB> I never tested if the inlining helps or hurts
[13:57:04] <Dark_Shikari> BBB: http://pastebin.com/pEbAnGug
[13:57:06] <BBB> it seemed like it'd hlp
[13:57:18] <Dark_Shikari> think about that for a moment until you squirm
[13:58:40] <BBB> I don't get it
[13:58:50] <BBB> is this b/c an offset of 128 fits in 1 byte
[13:58:53] <BBB> and 256 does not?
[13:59:04] <BBB> so [-128,127] makes the instruction sizes one byte smaller?
[13:59:09] <BBB> (rough guess)
[13:59:10] <mru> 3 bytes
[13:59:17] <Dark_Shikari> [ptr+X] is 1 address byte for -128 to 127
[13:59:19] <mru> there's no 16-bit offset
[13:59:19] <Dark_Shikari> for X
[13:59:19] <BBB> oh it's not 1,2 or 4 bytes, it's 1 or 4 bytes?
[13:59:26] <Dark_Shikari> and 4 address bytes for larger
[13:59:27] <Dark_Shikari> yes
[13:59:29] <Dark_Shikari> there's only 1 vs 4
[13:59:30] <BBB> I didn't know, I always thought it was 1, 2 or 4
[13:59:32] <BBB> ok
[13:59:37] <Dark_Shikari> So you can access the first 128 bytes of a struct cheaply
[13:59:41] <Dark_Shikari> and the rest is 3 extra bytes.
[13:59:46] <mru> immediats for arithmetic can be 2 bytes iirc
[13:59:55] <mru> at least in some modes and for some operations
[13:59:58] <BBB> crazy shit dude
[13:59:59] <Dark_Shikari> But... if you offset your pointer by 128 bytes
[14:00:07] <Dark_Shikari> You can access the first 256 bytes of a struct cheaply.
[14:00:10] <BBB> why doesn't gcc do that?
[14:00:16] <BBB> for inlined or static functions at least
[14:00:18] <Dark_Shikari> There's a bit more to this.
[14:00:23] <Dark_Shikari> First, let's look at these functions we have here.
[14:00:30] <Dark_Shikari> func1() is compiled correctly on gcc 3.4.
[14:00:40] <Dark_Shikari> on gcc 4.0 through 4.5, it's compiled badly, because the constant folding is fucked up
[14:00:52] <Dark_Shikari> it does a redundant lea at the start to subtract 128 from the pointer
[14:00:57] <Dark_Shikari> i.e. "folding" up the operation
[14:01:02] <Dark_Shikari> this results in 12 bytes of extra pointless instruction coding
[14:01:10] <Dark_Shikari> 4.6... it's fixed again.
[14:01:17] <Dark_Shikari> Now, let's go back to using this optimization in a compiler.
[14:01:23] <Dark_Shikari> In gcc 1.46 or so... IT USED THIS OPTIMIZATION.
[14:01:32] <Dark_Shikari> on m68k at least.
[14:01:37] <BBB> :D
[14:01:38] <Dark_Shikari> It got lost in the transition to gcc 2
[14:01:44] <BBB> who cares about m68k
[14:01:46] * BBB runs
[14:01:52] <BBB> is it used on x86?
[14:01:52] <Dark_Shikari> This optimization is legal even in the general case in C (!)
[14:02:03] <Dark_Shikari> Because pointers are not guaranteed to be equal to their integer representations
[14:02:09] <Dark_Shikari> i.e. you're allowed to store pointers in an abnormal manner
[14:02:15] <Dark_Shikari> And that manner you store them in can differ per-type
[14:02:20] <Dark_Shikari> so you could choose to do it only for the structs of your choice.
[14:02:47] <Dark_Shikari> ... but no, gcc doesn't do this at all in any version in the past decade.
[14:02:52] <BBB> :(
[14:02:58] <Dark_Shikari> And in anything between 4.0 and 4.5, it OPTIMIZES OUT the optimization
[14:02:59] <BBB> you should fix gcc :p
[14:03:01] <Dark_Shikari> even if you do it yourself
[14:03:31] <kshishkov> BBB: what about applying JV decoder with the latest patches?
[14:04:43] <Tjoppen> xgcc?
[14:04:45] <Tjoppen> :)
[14:04:51] <Dark_Shikari> more like xcc
[14:04:59] <Tjoppen> right.
[14:05:16] <BBB> kshishkov: it's already approved
[14:05:18] <BBB> commit it anyone
[14:05:31] <BBB> kshishkov: I fixed ~50% of p frame postfilter bugs in vc1
[14:05:34] <BBB> still 50% remaining
[14:05:40] <Dark_Shikari> postfilter?
[14:05:44] <BBB> deblock
[14:06:05] <kshishkov> loop filter
[14:06:11] <BBB> oh yeah
[14:06:11] <Dark_Shikari> that isn't a postfilter
[14:06:15] <BBB> baby makes my brain go mushy
[14:06:30] <mru> Dark_Shikari: actually, you're only partially right about the validity of doing this in general
[14:06:38] <mru> C allows it, but the x86 abi does not
[14:06:50] <CIA-36> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * r628b48db85 ffmpeg/libavcodec/vp8.c:
[14:06:50] <CIA-36> ffmpeg: VP8: use a goto to break out of two loops
[14:06:50] <CIA-36> ffmpeg: A break statement was supposed to break out of two loops, but only broke out of one.
[14:06:50] <CIA-36> ffmpeg: Didn't affect output, just could have been marginally slower.
[14:06:55] <CIA-36> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * rb1d2f812c9 ffmpeg/libavcodec/vp8.h:
[14:06:55] <CIA-36> ffmpeg: VP8: token probs doesn't need padding
[14:06:55] <CIA-36> ffmpeg: prob[0] is the only prob array ever accessed, so prob[1] can serve as padding
[14:06:55] <CIA-36> ffmpeg: for prob[0].
[14:06:57] <CIA-36> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * r1eeca88691 ffmpeg/libavcodec/ (vp8.c vp8.h):
[14:06:57] <CIA-36> ffmpeg: VP8: optimize VP8Context struct ordering
[14:06:57] <CIA-36> ffmpeg: Shaves at least 3KB off code size on x86, should improve cache utilization.
[14:06:57] <CIA-36> ffmpeg: This would probably be useful to do for other decoders/encoders as well.
[14:07:08] <CIA-36> ffmpeg: Jason Garrett-Glaser <jason at x264.com> master * r3efbe13739 ffmpeg/libavcodec/vp8.c: VP8: fix function declaration
[14:07:10] <Dark_Shikari> mru: well, yes.
[14:07:16] <ruggles> is there a shortcut to 'git add' all modified files?
[14:07:22] <mru> ruggles: git add -a
[14:07:24] <mru> iirc
[14:07:25] <BBB> -a
[14:07:28] <mru> but be careful
[14:07:28] <BBB> right
[14:07:35] <ruggles> cool thanks. i'll check git status first.
[14:07:42] <BBB> or shell expand
[14:07:46] <BBB> git add file-*.txt
[14:07:54] <BBB> git gui is lovely also
[14:08:00] <Dark_Shikari> mru: you might also break some apps that violate that aspect of the C standard.
[14:17:07] <Tjoppen> re: git guis, a colleague recommended SmartGit
[14:17:23] <Tjoppen> haven't tried it yet though
[14:17:43] <mru> plain old "git gui" works nicely
[14:18:28] <ruggles> wow... the C version of ac3_rshift_int32() is the same speed as MMX when unrolled by 16
[14:18:41] <CIA-36> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r5dbe78bf91 ffmpeg/ffmpeg.c:
[14:18:41] <CIA-36> ffmpeg: ffmpeg: remove unused variable in ffmpeg_exit()
[14:18:41] <CIA-36> ffmpeg: Fix the warning:
[14:18:41] <CIA-36> ffmpeg: ffmpeg.c: In function ‘ffmpeg_exit’:
[14:18:41] <CIA-36> ffmpeg: ffmpeg.c:509: warning: unused variable ‘j’
[14:18:42] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:18:43] <CIA-36> ffmpeg: Hendrik Leppkes <h.leppkes at gmail.com> master * r0215006ab7 ffmpeg/libavcodec/ (avcodec.h vc1dec.c):
[14:18:43] <CIA-36> ffmpeg: VC1: Export profile/level
[14:18:44] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:18:45] <Dark_Shikari> on what cpu, ruggles?
[14:18:49] <ruggles> athlon64
[14:18:57] <Dark_Shikari> not surprising
[14:19:01] <Dark_Shikari> it probably has one simd shift unit
[14:19:04] <ruggles> and the sse2 is still slower of course
[14:19:04] <Dark_Shikari> and two scalar shift units
[14:23:20] <Tjoppen> speaking of putting important shit at the top, would that be something beneficial to do to AVCodecContext while bumping major?
[14:23:28] <ruggles> doh. scratch that. messed up the test. it is the same speed as the SSE2 version though...
[14:25:21] <elenril> Tjoppen: you just volunteered ;)
[14:28:48] <Tjoppen> :o
[14:38:45] <BBB> Tjoppen: first clean up to remove stuff that's only used in one encoder, and make them private as AVOptions
[14:53:01] <pengvado> Dark_Shikari: k8's 64bit scalar shift is 1/.33, its mmx shift is 2/.5, and its xmm shift is 2/1
[14:53:09] <pengvado> all of those will be memory bound
[15:08:00] <ruggles> that's weird. why would gcc use "sar m32,cl" for rshift_int32 but use "movswl/shl/mov" for lshift_int16?
[15:08:20] <ruggles> instead of "shl m16,cl"
[15:08:34] <mru> maybe the latter doesn't exist
[15:08:44] <ruggles> my docs say it does
[15:08:58] <mru> ignore me then
[15:16:35] <Kovensky> http://i.imgur.com/JuLxU.png lol
[15:17:11] <mru> maybe not everybody knows the origin of that word
[15:17:35] <mru> it's not like they teach it in school
[15:17:47] <mru> at least not any school I ever attended
[15:17:51] <Kovensky> it was taught in school here ._.
[15:18:10] <Kovensky> both about tsunamis and the origin of the word (no explanation of why 'tsunami' though, just that it's a japanese word)
[15:19:15] <mru> and even with the japanese origin, it's not necessarily called that in japanese
[15:19:50] <Kovensky> at least in every japanese TV channel I've seen it was written as 津波
[15:20:06] <Kovensky> TBS, NHK and Fuji that is
[15:20:11] <mru> I wouldn't be surprised either way
[15:20:44] <Kovensky> talking about TV channels, apparently TV Tokyo is broadcasting Letter Bee (with the tsunami warning overlay at all times)
[15:21:01] <Kovensky> all the other channels are still in constant news mode though
[15:21:37] <mru> isn't the immediate danger over?
[15:21:51] <mru> apart from those power plants
[15:21:56] <Kovensky> everyone is still on tsunami alert
[15:22:16] <mru> still risk of aftershocks?
[15:22:17] <Kovensky> specially since the aftershocks will continue for months
[15:22:41] <mru> I thought major aftershocks usually came within days
[15:22:49] <Kovensky> just 2h ago there was a shindo 5- aftershock
[15:22:50] <mru> which it hasn't been yet, come to think of it
[15:22:54] <Kovensky> 30m ago a shindo 4
[15:23:11] <Kovensky> (the shindo 5- one was rated at richter 6)
[15:28:33] <Kovensky> mru: http://dl.dropbox.com/u/1099186/viewtv.html if you wanna watch btw
[15:28:47] <Kovensky> (yohkosonews has english voiceover)
[15:29:07] <mru> I think bbc covers it well enough for me
[16:48:16] <Kovensky> 13:34.32 JEEB: http://folderman.tv/up/s/fotv13137.gif
[17:27:32] <mnzaki> Hello! I'm hoping to apply to GSoC for the libavfilter audio work and has some questions about the difficulty level and prerequisite knowledge I would need, and mentor availability of course
[17:28:28] <mru> stefano should be your man for that
[17:28:33] <mru> saste on irc
[17:30:09] <mnzaki> Thanks I will wait for him then! Are there usually a lot of appC[C[C[C[Clicants?
[17:30:27] <mnzaki> s/[C// stupid irssi
[17:30:43] <mru> slow terminal?
[17:31:05] <mnzaki> ssh :S long unrelated story
[17:31:20] <mru> yeah, irssi does that sometimes on slow links
[17:31:32] <mru> and no need to explain yourself
[17:32:00] <mru> so anyway, mind telling us a little about yourself?
[17:35:11] <mnzaki> Well, I'm a college freshman from Egypt. I started programming since about 5 years ago, but only a bunch of light stuff. The more recent and mroe interesting work was on a kernel driver for the N900 (but again nothing MAJOR) adding functionality for control of the hardware filters
[17:35:58] <mru> hmm, what filters?
[17:36:43] <mnzaki> audio filters :D The on-board chip had some interesting functionality that was not enabled, 2 cascaded IIR filters and a 3D stereo effect
[17:37:37] <mru> that's not part of the omap3 is it?
[17:37:37] <mnzaki> I actually got to the point where I could load IIR filter params from userland onto the chip, but then was too lazy to cook up some presets and a GUI
[17:37:41] <mnzaki> it is!
[17:37:45] <mru> what?
[17:38:01] <mru> which part?
[17:38:02] <mnzaki> the chip, I don't recall the name... but it's part of the omap
[17:38:05] <mnzaki> hold on
[17:38:16] <mru> I don't remember anything like that in the trm
[17:38:30] <mnzaki> the tlv320aic34
[17:38:36] <mru> that's not the omap
[17:38:43] <mnzaki> it isn't? oh well
[17:39:07] <mru> they're probably using an external audio processor
[17:39:11] <mru> makes sense
[17:39:13] <mnzaki> anyways, it's on the N900, which is what matters :D
[17:39:30] <mru> the omap3 doesn't have much dedicated audio stuff at all
[17:40:37] <mnzaki> I'm actually working on a little project right now involving rtmp broadcasting and I needed to do some ffmpeg and/or sox stuff when I ended up on GSoC
[17:41:54] <mnzaki> There's a slight problem though, I have only got the basics (wrt the math and implementation) down on filtering in general and I'm wondering just how much would I need to know to even attempt this task
[17:42:57] <wbs> lavfilter audio stuff is more about framework munging than actual lowlevel audio coding still, I think
[17:43:11] <mru> yeah
[17:43:44] <mnzaki> ah good to know I suppose. As I understood things from the wiki there would be a lot of porting from other frameworks/libs
[17:44:07] <mnzaki> btw anyone know where the soc svn is?? trying to pull it gets me redirected to the git repo and it's not on there
[17:45:13] <mru> are you trying to use svn over http?
[17:45:23] <mru> that doesn't work
[17:45:25] <mru> never did
[17:45:55] <mnzaki> really? ok I just pulled over svn:// thanks
[17:46:34] <wbs> it might be beneficial to check saste's git repos if you find some of the soc lavfi stuff there
[17:46:34] <mnzaki> is this outdated or have things that were moved over to git been removed from the soc svn?
[17:46:49] <wbs> probably not removed from soc svn, but I'm not sure if all of it was there
[17:47:25] <wbs> don't remember if lavfi soc audio stuff was in svn or in some git clone last summer, and saste might have worked on it further from that since then
[17:48:00] <mnzaki> ok, so need to wait for saste.
[17:48:46] <mnzaki> So, again, are there usually lots of applicants? What would I need to do/have for a chance at this?
[17:49:26] <wbs> I guess the most important point is showing that you're able to work with the code, and perhaps even more importantly, are able to work socially with the rest of the project
[18:16:08] <elenril> so any new and awesome ideas about a name for ff_get_v?
[18:16:19] <mru> ff_get_w
[18:16:32] <_av500_> ff_go_get_them
[18:16:55] <kshishkov> ff_get_radix7_vlc
[18:17:06] <mru> it's not radix 7
[18:17:09] <Tjoppen> wouldn't that be radix128?
[18:17:18] <_av500_> ff_get_bytes_from_memory_and_make_then_l33t_numberz
[18:17:42] * elenril stabs _av500_ 
[18:17:52] <elenril> where are my asf chapters
[18:18:15] <_av500_> chapter 1: patience is a virtue
[18:21:48] <kshishkov> mru: I think I got that name somewhere in MIDI-related specs
[18:22:20] * kshishkov curses since av_memcpy_backptr doesn't really work as expected
[19:47:58] <kierank> what's the reason behind lavf passing through wrapped around timestamps in TS. Shouldn't lavf be independent of container idiosyncrasies?
[19:49:13] <mru> wrapped or "randomly" reset?
[19:51:44] <kierank> well randomly reset timestaps would also get passed through if that's what you mean
[19:53:29] <_av500_> handling the wrap is a can of worms
[19:57:57] <kierank> _av500_: a can of worms for the calling app, lavf or both?
[19:58:10] <mru> in general
[19:58:44] <mru> you need to carefully track which pts/dts refer to old/new pcr etc
[19:59:16] <mru> and with a little bad luck, the reset will happen at different times in different streams
[19:59:36] <mru> you're likely to see new timestamps in video before audio, for instance
[19:59:47] <mru> once they pass through decoders they'll be in sync of course
[20:07:08] <kierank> btw do you know anything about the dvbsub timing model mru?
[20:07:14] <mru> no
[20:12:15] <_av500_> kierank: imagine 2 wraps in a file and seek to a certain timestamp
[20:12:22] <_av500_> which is it
[20:13:07] <kierank> yeah that's what i was thinking
[20:13:16] <kierank> but I don't need seeking so it's not a big deal for me :)
[20:14:49] <kshishkov> DVD images are not that popular ;)
[20:37:15] <_av500_> Flameeyes: usb charging is tricky
[20:37:34] <_av500_> the scheme that aapl uses differs from the one that everybody else uses
[20:38:03] <_av500_> the "chinese charger standard" is just to put 100ohm between DP and DM
[20:38:27] <_av500_> then devices know its a charger and they can pull more than 100/500mA
[20:38:48] <_av500_> aapl scheme is very elaborate and has diferent resistor values for different devices
[20:57:36] <Flameeyes> _av500_: yeah I remember reading about apple's "detection" — but not sure if it works both way or not
[21:32:37] <DonDiego> btw, where is cartman?
[21:33:09] <_av500_> lost in german customs
[21:33:24] <_av500_> or still looking for a flat
[22:10:11] <ruggles> mru: does this look ok for float version of scale_coefficients()?
[22:10:12] <ruggles> void ff_float_to_int32(int32_t *dst, const float *src, int len, uint8_t scale_bits);
[22:11:00] <mru> I really need the bits to be a constant
[22:11:20] <mru> the float-to-fixedpoint instruction takes an immediate for that
[22:11:49] <ruggles> hmmm. so you want ff_float_to_fixed24()
[22:12:10] <mru> it's not going to change, is it?
[22:12:26] <ruggles> no, just not as reusable for other things
[22:12:37] <mru> but twice as fast
[22:13:12] <mru> unless it checks for specific values and jumps
[22:13:13] <ruggles> it won't make much difference on x86, but if it's that much better on ARM it's worth having
[22:13:32] <mru> it's the difference between doing mul+conv and just conv
[22:17:46] <mru> anything holding back those latest patches now?
[22:17:57] <ruggles> mru: checking specific values might be ok. we probably only need 31 for sample format conversion and 24 for ac3. and a generic version for whatever else wants to use it.
[22:18:12] <mru> 31?
[22:18:17] <ruggles> someone to ok the x86
[22:18:57] <mru> for converting pre-scaled float to int16 I used some tricks
[22:19:05] <mru> BBB: review request
[22:20:01] <ruggles> well, we could require pre-scaled float for int32 as well i guess. but it might be a better fit for some decoders to have it done during conversion.
[22:20:33] <mru> we should do whatever is fastest
[22:20:50] <mru> we could add a field for requested scale
[22:20:57] <mru> and decoders can honour or ignore it
[22:24:37] <ruggles> that works. should we have 2 functions or just jmp to pre-scaled section if scale_bits is 0?
[22:26:48] <mru> we'll see when we actually write it
[22:30:03] <ruggles> ok
[22:31:54] <ruggles> hmm. videolan git repo allows non-fastforward merge?
[22:32:25] <mru> don't care
[22:33:23] <mru> I guess cherry-picking got boresome
[22:33:35] <mru> and writing code too hard
[23:05:30] <BBB> mru: ?
[23:05:39] <BBB> which patch?
[23:05:44] <BBB> I'll look at my review queue tomorrow
[23:05:48] <BBB> had to buy a baby crib today
[23:05:52] <mru> BBB: ruggles'
[23:05:54] <DonDiego> :)
[23:05:55] <BBB> he didn't fit the small cradle anymore
[23:20:42] <ruggles> mru: i'm leaning towards separate functions. float_to_int32() and float_to_fixed32()
[23:21:30] <mru> which functions are you talking about?
[23:22:47] <ruggles> pre-scaled float to int32 and [-1.0,1.0] float to int32 with adjustable scale
[23:23:00] <mru> but for what purpose?
[23:23:17] <mru> I though we were talking about the fixed24 one a while ago
[23:25:18] <ruggles> ah, well i guess on arm it might be better to have that separate too... on x86 the scale vs. no-scale leads to lots of code duplication if not separated.
[23:25:39] <mru> which functions are you talking about?
[23:26:34] <ruggles> scale_coefficients() for ac3 float. and to be reused in format conversion eventually.
[23:27:24] <mru> for neon any constant scale can be applied with the conversion
[23:27:35] <mru> well, power of two scale
[23:27:44] <mru> aka fixed-point fractional bits
[23:27:54] <mru> but it's a _constant_
[23:28:12] <ruggles> imm8?
[23:28:20] <mru> imm something at leat
[23:28:22] <mru> +s
[23:28:25] <mru> probably imm5
[23:29:53] <mru> the point is a runtime variable is useless
[23:31:51] <ruggles> but it could be done by comparison + jump. and a macro used to reduce code duplication.
[23:32:09] <mru> but in practice it will always be 24
[23:32:13] <mru> that's a useless jump
[23:33:07] <ruggles> what about format conversion when the decoder doesn't scale?
[23:33:15] <mru> use a different function
[23:33:40] <mru> there's only a handful of realistic cases here
[23:34:26] <mru> output will be int16, int32, or fixed24
[23:34:33] <mru> input can be scaled or not
[23:36:18] <ruggles> for fixed24 it will not be scaled. because you could just use the int32 function in that case.
[23:36:33] <mru> so it's one less case to consider
[23:37:01] <mru> if you're lazy you can always implement them all by calling a generic function
[23:37:41] <mru> for int32 output scaled or unscaled input doesn't really matter
[23:37:43] <ruggles> or just make a macro :)
[23:37:44] <mru> for neon
[23:38:15] <mru> for int16 output one can get clever with scaled input
[23:38:31] <mru> at least when also interleaving
[23:38:38] <mru> as in the asm we have currently
[23:39:42] <ruggles> ok, well i'll do more testing and cleanup and send a patch tomorrow. i'm out for the night.
[23:55:19] <peloverde> I feel like if it takes you 5 hours to compile FFmpeg you are doing it wrong: http://reviews.cnet.com/8301-19736_7-20042217-251.html
[23:57:00] <kierank> i remember it taking 5 hours to compile ffmpeg back in 2000 on a pentium pro