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

[irc at mansr.com]

[00:39:56] <peloverde> Is this grammar shit really still being discussed?!
[00:57:49] <saintdev> peloverde: how are input samples laid out? interleaved for each channel?
[00:58:03] <peloverde> yes
[00:59:06] <saintdev> well it seems stereo is at best broken, and anything more is fubar :P
[00:59:40] <peloverde> yes, stereo has issues
[00:59:43] <saintdev> la       = samples2 + (448+64) * avctx->channels + start_ch;
[00:59:51] <saintdev> peloverde: what is the 448+64 for?
[01:00:18] <peloverde> read the commit message in the blame log for that line
[01:01:18] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff;h=08bffe794ed67c24b49ae3c805c0bb0a78008357
[01:01:37] <saintdev> also, start_ch gets added twice
[01:01:47] <saintdev> samples2 already is offset by start_ch
[01:02:10] <peloverde> good catch
[01:02:22] <saintdev> peloverde: so what is the 64 about then?
[01:03:03] <peloverde> First short window begins at 448
[01:03:20] <peloverde> short window length is 256
[01:03:26] <peloverde> quarter window is 64
[01:03:52] <saintdev> yeah, didn't the entire message because of gitweb making it the title
[01:03:58] <saintdev> didn't notice
[01:06:37] <saintdev> peloverde: also, inside psy_3gpp_window where the iir is calculated, la is indexed as:
[01:06:40] <saintdev> la[(i*128+j)*ctx->avctx->channels]
[01:06:56] <saintdev> which doesn't take into account the current channel
[01:07:25] <peloverde> The current channel is already taken into account in the la base pointer (twice even as we just discussed)
[01:07:37] <saintdev> no, start_ch is, but the current channel is not
[01:08:04] <saintdev> so for stereo start_ch is always 0
[01:08:31] <saintdev> but then we loop over the individual channels calling suggest_window for each one
[01:08:52] <saintdev> but la is not adjusted for the current channel in aacenc, or aacpsy
[01:09:11] <peloverde> The call to to ff_psy_suggest_window() is buggy then
[01:09:40] <peloverde> That whole section is still mostly wrong for multichannel as previously discussed
[01:10:20] <saintdev> so would it be better to offset la in aacenc, or inside suggest_window?
[01:10:28] <peloverde> in aacenc
[01:25:03] <saintdev> argh, samples2 isn't offset by the current channel either :/
[01:25:11] <saintdev> not that it's used in the current code :P
[01:45:49] * Honoome starts to have a huge headache and a tremendous feeling for destruction
[01:50:18] <saintdev> peloverde: check ML
[01:56:11] <peloverde> Doesn't that break apply_window_and_mdct()?
[02:01:03] <saintdev> ugh, yes.
[02:01:31] <peloverde> IMHO apply_window_and_mdct() shouldn't take an offset
[02:02:03] <saintdev> which means it can be simplified
[02:02:07] <peloverde> yes
[02:13:13] <saintdev> peloverde: this look correct: http://pastebin.org/403836
[02:23:10] <peloverde> yes
[02:24:26] <peloverde> but the patches should be applied seperately so one of the apply_window_and_mdct() lines is wrong (either the before or the after depending on which patch is applied first)
[02:25:29] <saintdev> eek, almost hit send, LOL
[02:32:34] <peloverde> Whatever the outcome, the apply_window_and_mdct() patch should be a pure refactor with identical output
[02:44:50] <saintdev> peloverde: do you mean make it so the change of the function definition is in the other patch?
[02:45:24] <peloverde> I  mean before and after the MDCT patch the outputs hould be identical
[02:45:33] <peloverde> *output should
[03:17:31] <saintdev> did i break something then?
[03:17:42] <saintdev> i get different results before and after, but that is because it decides on different window types.
[03:18:06] <saintdev> everywhere it uses the same window types the coefficients are identical
[03:31:33] <peloverde> There are two patches, but only one should change output
[03:34:27] <peloverde> the MDCT refactor patch should be a pure recfactor patch that changes nothing
[03:54:34] <saintdev> peloverde: http://pastebin.org/404016
[03:57:18] <jenk> o hi
[03:57:40] <peloverde> saintdev: That's moving in the wrong direction
[03:58:32] <peloverde> now you have a patch that plays with both at the same time
[03:59:05] <peloverde> Take the MDCT patch you had, which was almost perfect and just make it a pure refactor
[04:03:24] <peloverde> All you have to do is change the function call to make it clean
[04:10:16] <saintdev> i will have to modify both at some point to not change output
[04:15:32] <saintdev> if i add the current channel to samples2 i will have to change apply() to not add the offset itself
[04:16:14] <saintdev> if i don't add the current channel, then the next patch when i do i'll have to modify apply()
[04:18:23] <peloverde> just add the offset to the bae pointer
[04:19:41] <peloverde> *base pointer
[04:19:52] <saintdev> erm, wtf was i thinking, LOL
[04:28:48] <saintdev> peloverde: http://pastebin.org/404082
[04:29:14] <saintdev> think i need to smack my head on my desk a few times for that one :P
[06:15:26] <thresh> moroning
[06:19:15] <av500> +1
[06:19:33] * kshishkov thinks it's rather nice and lovely morning
[06:19:43] <mru> mornings
[06:19:52] <kshishkov> goda morgnar
[06:50:13] <av500> mru: http://wanderingcoder.net/2010/06/02/intro-neon/
[06:54:45] <mru> I disagree with his conclusion
[06:54:59] <mru> neon is much easier to use than sse or altivec
[06:55:25] <mru> lack of a SAD instruction isn't the end of the world
[06:56:29] <funman> lack of SAD should make people HAPPY
[07:02:54] <kshishkov> unless you're encoder guy, you don't care about it much
[07:03:50] <mru> video encoder
[07:04:01] <kshishkov> or audio encoder with MC
[07:04:13] <mru> it has VABA though
[07:04:19] <mru> absolute difference and accumulate
[07:04:48] <mru> a few adds at the end give you the SAD
[07:12:21] <av500> woot the vote!
[07:18:27] * kshishkov now truly hates C++
[07:50:26] <KotH> moin
[07:50:43] <mru> morning KotH
[07:53:05] <CIA-99> ffmpeg: diego * r24320 /trunk/doc/faq.texi:
[07:53:05] <CIA-99> ffmpeg: Remove duplicate RTP depacketization entry.
[07:53:05] <CIA-99> ffmpeg: Two questions below there is the same Q+A, slightly rephrased.
[08:11:20] <lu_zero> good morning
[08:11:25] <mru> morning
[08:13:26] * kshishkov feels that ffmpeg-devel returned to its hello-channel status
[08:17:00] <mru> it's monday morning, what do you expect?
[08:22:05] <j0sh> lu_zero: ping
[08:23:24] <benoit-> moin
[08:23:34] <av500> gm
[08:23:37] <benoit-> anyone interested to sell FFmpeg?
[08:23:40] <benoit-> "Please give necessary details about licence,price of ffmpeg tool."
[08:23:47] <av500> 4) profit
[08:24:00] <jenk> i'll sell it
[08:24:19] <jenk> tell them to hti me up
[08:25:19] <saintdev> jenk: does that mean you get to tell them it'll do things it really can't just to get the sale?
[08:25:51] <av500> "It's user friendly..."
[08:26:07] * kshishkov sues av500 for slander
[08:26:29] <av500> "It's *super* user friendly..."
[08:26:53] * kshishkov just multiplies compensation by ten
[08:26:54] <av500> wait, didn't we vote against users?
[08:27:24] <kshishkov> no need to do that
[08:27:53] <jenk> i'll be willing to provide them with a license enabling them full source code access
[08:27:57] <jenk> for a reasonable fee
[08:28:26] <kshishkov> may Stallman be with you then
[08:28:35] <jenk> oh he is
[08:28:48] <jenk> he is tiled on my desktop bg
[08:28:57] <saintdev> o.O how can we afford you to just give the source away
[08:28:59] <jenk> no hoarders
[08:29:07] <jenk> who said anything about giving it away???
[08:35:31] <CIA-99> ffmpeg: diego * r24321 /trunk/doc/faq.texi: Mark file references as such with texinfo markup.
[08:42:35] <CIA-99> ffmpeg: diego * r24322 /trunk/doc/faq.texi: Clarify bug reporting policy with regard to releases.
[08:57:46] <CIA-99> ffmpeg: diego * r24323 /trunk/doc/faq.texi: Mark URL as such with texinfo markup.
[09:01:11] <Dark_Shikari> _troll_: ping
[09:01:16] <_troll_> pong
[09:01:29] <Dark_Shikari> On a Cortex, what's the current speed status of ffh264 vs CoreAVC?
[09:01:46] <_troll_> I'd have to run a test
[09:01:49] <_troll_> suggest a sample
[09:01:57] <Dark_Shikari> ok, I'll get you a few samples
[09:02:08] <_troll_> something realistic please
[09:02:13] <av500> meh
[09:02:16] <Dark_Shikari> I'll get something relatively worst-case
[09:02:19] <_troll_> nothing 1080 or so
[09:02:26] <Dark_Shikari> since what matters is it being able to keep up in hard situations
[09:02:30] <Dark_Shikari> not how fast it goes in zero motio
[09:05:36] <Dark_Shikari> so this will be the first test we've done on a purely-hard test clip.
[09:07:22] <Dark_Shikari> ok, uploading.  it's 4 clips, each of which is 250 frames long.  they're .h264, so you can easily cat them to make them longer
[09:07:26] <Dark_Shikari> test1.h264: normal high profile
[09:07:31] <Dark_Shikari> test2.h264: minus cabac
[09:07:35] <Dark_Shikari> test3.h264: minux cabac and loopfilter
[09:07:51] <Dark_Shikari> test4.h264: minus cabac, loopfilter, subpel, all modes except i16x16 and p16x16
[09:07:58] <Dark_Shikari> i.e. "like h261"
[09:08:52] <_troll_> how does that compress compared to mpeg2?
[09:09:21] <Dark_Shikari> dunno.
[09:09:33] <Dark_Shikari> probably worse, I'm just curious
[09:09:39] <Dark_Shikari> wrt decoding speed
[09:10:04] <kshishkov> Dark_Shikari: and what's the outcome of your codec testing (the one with parkrun sample, SVQ1 and Bink)?
[09:10:11] <Dark_Shikari> kshishkov: parkjoy
[09:10:14] <Dark_Shikari> and meh, never finished it
[09:10:16] <Dark_Shikari> :effort:
[09:10:18] <Dark_Shikari> to make it totally fair
[09:10:26] <Dark_Shikari> it did satisfy my curiosity though
[09:10:33] <Dark_Shikari> _troll_: http://x264.nl/developers/Dark_Shikari/bench_clips.tar
[09:10:52] <av500> 404
[09:14:29] <Dark_Shikari> fixed.
[09:14:47] <CIA-99> ffmpeg: diego * r24324 /trunk/doc/faq.texi: Remove outdated entries about bt8x8 capture on Linux 2.4 kernels.
[09:26:08] <Dark_Shikari> btw, our problem on the ipad was _always_ the worst case
[09:26:10] <_troll_> Dark_Shikari: decode times with ffh264: 16.5 13.6 10.3 8.1
[09:26:12] <_troll_> at 600MHz
[09:26:18] <Dark_Shikari> we could easily get 5-8ms on low motion
[09:26:22] <Dark_Shikari> on high motion it could spike to 30-40ms
[09:26:37] <Dark_Shikari> oh wow, no subpel really is a lot faster.
[09:26:54] <Dark_Shikari> interesting, deblocking takes more time than cabac.  barely.  sounds like you need to write that deblock strength function ;)
[09:27:06] <_troll_> yeah, should do that
[09:27:25] <Dark_Shikari> you can write it for x264 first if you want, since it has a clear C version and checkasm
[09:27:33] <Dark_Shikari> once that's done it's probably a trivial port.
[09:27:35] <Dark_Shikari> so... now coreavc.
[09:28:04] <_troll_> what resolution are those clips?
[09:28:04] <Dark_Shikari> Also, I just got an email from Fluendo about licensing x264.
[09:28:09] <_troll_> :-)
[09:28:10] * Dark_Shikari wonders what to do.
[09:28:17] <Dark_Shikari> they're evil, but... hey
[09:28:18] <_troll_> make 'em pay
[09:28:19] <Dark_Shikari> lol
[09:28:56] <_troll_> coreavc: 12.1 9.8 7.1 5.7
[09:29:13] <twice11> Just curious: why is Fluendo evil?
[09:29:18] <_troll_> lol
[09:29:30] <_troll_> why is satan evil?
[09:29:41] <Dark_Shikari> Because their entire business model consists of attempting to convince people to purchase proprietary alternatives to open source software?
[09:29:49] <Dark_Shikari> I mean, it's not like microsoft
[09:29:56] <Dark_Shikari> Microsoft doesn't say "we're a linux alternative, buy us"
[09:30:04] <_troll_> selling proprietary sw on its own merits is fine by me
[09:30:09] <Dark_Shikari> agreed
[09:30:27] <Dark_Shikari> _troll_: a8 or a9?
[09:30:31] <_troll_> beagle
[09:30:34] <Dark_Shikari> ok, so a8
[09:30:38] <_troll_> I don't have an a9 with neon
[09:30:58] * KotH would use a4, a8 is way too small
[09:31:02] <KotH> ;-)
[09:31:09] <_troll_> actually, I do have access to one
[09:31:29] * Dark_Shikari sends numbers to boss
[09:31:35] <av500> _troll_: could you be mru again?
[09:31:42] <mru> better?
[09:31:44] <av500> yes
[09:31:59] <kshishkov> but it was appropriate for those benchmarks
[09:32:06] <Dark_Shikari> lol
[09:34:17] <Dark_Shikari> mru: that's pretty bloody impressive.
[09:34:40] <twice11> Doesn't Microsoft's "get the facts" campaign claim that "Windows can do everything Linux can do, but more reliable and with a lower TCO"?
[09:35:02] <twice11> err, "Windows server can do everything Linux servers can do" to be more exact.
[09:35:08] <Dark_Shikari> ok, true, they do that for servers.
[09:35:13] <Dark_Shikari> so yeah, they're pretty evil there.
[09:35:19] <Dark_Shikari> though even then, their methods aren't the same
[09:35:31] <Dark_Shikari> Fluendo says "use us because OMG OPEN SOURCE IS ILLEGAL"
[09:35:35] <Dark_Shikari> Microsoft gave up on that a few years ago
[09:35:55] <twice11> And now we have VFAT long name patent lawsuits...
[09:36:32] <mru> yet we don't see debian dropping vfat support
[09:37:13] <twice11> The kernel already crippled VFAT long/short name dualism as response to the patent claims, AFAIK.
[09:38:11] <twice11> And Debian's policy is mostly to not care about patents anyway.
[09:38:18] <mru> except for ffmpeg
[09:38:51] <KotH> mru: s/ffmpeg/mplayer/$
[09:38:57] <mru> same thing
[09:39:08] <Dark_Shikari> ubuntu actually honestly doesn't care about patents
[09:39:09] <KotH> mru: ffmpeg has been in debian for ages until they allowed mplayer in
[09:39:14] <Dark_Shikari> debian doesn't care about patents except when it suits them politically to do so
[09:39:31] <mru> KotH: didn't they --disable-everything?
[09:39:32] <Dark_Shikari> Then they care a lot.
[09:39:33] <KotH> mru: interstingly, they always critizied lavcodecs as the main source of probable lawsuits
[09:39:37] <av500> Dark_Shikari: how many frames is that test clip?
[09:39:41] <KotH> mru: no, that was suse
[09:39:41] <Dark_Shikari> av500: 250
[09:39:44] <av500> right
[09:41:14] <av500> so, I get: 5, 6, 3.5 and 2.75
[09:41:24] <mru> ittiam?
[09:41:34] <av500> yes
[09:41:35] <mru> and what hw?
[09:41:43] <av500> 3440
[09:41:43] <mru> MHz?
[09:42:00] <av500> 600
[09:42:04] <mru> impressive
[09:42:05] <Dark_Shikari> what's a 3440
[09:42:11] <mru> Dark_Shikari: same as 3530
[09:42:11] <av500> but this is the split one, arm and dsp
[09:42:15] <mru> of course
[09:42:23] <Dark_Shikari> explain?  is this a dsp decoder?
[09:42:32] <Dark_Shikari> wait.  5, 6???
[09:42:33] <mru> it splits the work between arm and dsp
[09:42:35] <Dark_Shikari> CABAC IS FASTER THAN CAVLC?
[09:42:42] <Dark_Shikari> This thing has a dedicated cabac unit, right?
[09:42:45] <kshishkov> Dark_Shikari: TI OMAP 3xxx I think
[09:43:02] <mru> Dark_Shikari: the ittiam decoder does the first stages on arm and transfers to dsp
[09:43:06] <av500> at 800mhz, the last clip is 9ms/frame
[09:43:11] <mru> so cabac/cavlc will be don on arm
[09:43:13] <mru> done
[09:43:17] <Dark_Shikari> Why would CABAC be faster than CAVLC?
[09:43:24] <av500> Dark_Shikari: dunno, but its like that
[09:43:26] <Dark_Shikari> that makes no sense if there's no dedicated CABAC unit
[09:43:32] <mru> Dark_Shikari: it's probably not the bottleneck anyway
[09:44:14] <Dark_Shikari> interesting that deblocking takes up so much time
[09:45:03] <mru> maybe it can be done faster
[09:46:02] <Dark_Shikari> av500: thanks for the info, forwarded
[09:46:06] <av500> hmm, I think my measurements are off
[09:46:08] <av500> Dark_Shikari: hold that
[09:46:15] <Dark_Shikari> oh.  already sent.  I can send a new one of course
[09:46:19] <Dark_Shikari> er, correction email
[09:46:22] <av500> ok
[09:46:25] <Dark_Shikari> since nobody I'm sending the email to is awake anyways
[09:46:28] <av500> but might take some time
[09:46:37] <Dark_Shikari> btw, you can run the test multiple times
[09:46:38] <Dark_Shikari> e.g. using cat
[09:46:41] <Dark_Shikari> to get more accurate results
[09:46:46] <Dark_Shikari> cat it 10 times, divide by 10
[09:46:51] <av500> rly? :)
[09:47:01] <av500> all my setup is only for ms/frame
[09:47:11] <av500> I never care for total runtime
[09:47:15] <mru> 54
[09:47:32] <av500> mru: its a 26/26 split between arm and dsp
[09:47:49] <Dark_Shikari> av500: well yes, ms per frame matters
[09:47:54] <Dark_Shikari> but we need to be comparable with mru's results
[09:48:08] <Dark_Shikari> and of course, average time per frame * numframes...
[09:48:24] <mru> another decoder: 12.7 10.5 6.7 5.3
[09:49:56] <kshishkov> that's better
[09:56:39] <av500> mru: Dark_Shikari: ah, I see why, I do not render faster than 60fps
[09:56:58] <Dark_Shikari> ah
[09:56:59] <av500> coz the LCD is 60fps or s
[09:57:08] <Dark_Shikari> can you remove that lock?
[09:57:11] <av500> I need to write mode that only decodes without renderinf
[11:25:49] <pross-au> Evenin'
[11:44:24] <CIA-99> ffmpeg: mstorsjo * r24325 /trunk/libavformat/rtpdec_asf.c: rtpdec_asf: Include lavu headers using quotes instead of angle brackets
[11:50:59] <CIA-99> ffmpeg: pross * r24326 /trunk/ (5 files in 2 dirs): Add doxygen @file comment block
[12:17:21] <Dark_Shikari> fuck.  I hate the fact that pixfmts are enums, not defines
[12:17:28] <Dark_Shikari> this means we can't do logic based on whether a pixfmt exists or not
[12:17:42] <Dark_Shikari> (in an swscale-using app)
[12:17:56] <mru> all of them always exist
[12:18:04] <Dark_Shikari> I mean wrt old versoins.
[12:18:08] <mru> check the version
[12:18:12] <mru> you can #if on that
[12:18:19] <Dark_Shikari> then you have to track the version for every single pixfmt
[12:18:21] <Dark_Shikari> which is really stupid
[12:18:22] <mru> or just use latest
[12:18:36] <Dark_Shikari> x264 has a function which converts swscale pixfmts to the closest internally supported one
[12:18:38] <mru> or do a configure-type test
[12:18:39] <Dark_Shikari> for its filter chain
[12:18:45] <Dark_Shikari> e.g. RGB565 -> RGB24
[12:18:56] <Dark_Shikari> it has a switch statement off pix fmts
[12:19:00] <mru> x264 does pixfmt conversion now?
[12:19:12] <Dark_Shikari> when you can do decoding, you have to be able to do pixfmt conversion
[12:19:24] <mru> true
[12:19:49] <mru> but why not use libswscale names directly
[12:19:56] <Dark_Shikari> because we don't want to require swscale
[12:19:59] <Dark_Shikari> for two reasons
[12:20:11] <Dark_Shikari> 1) x264 should be able to build without swscale, to begin with
[12:20:27] <Dark_Shikari> 2) avisynth can do colorspace conversions and resizes, so not having swscale is not doom for the filtering system
[12:20:52] <Dark_Shikari> the only way to fix 1) is to keep our own copy of pixdesc.h
[12:20:53] <Dark_Shikari> which is stupid
[12:21:14] <mru> ok, point taken
[12:21:50] <Dark_Shikari> oh, and we don't want to support every colorspace in the world in the filter system
[12:21:54] <Dark_Shikari> that's very stupid
[12:21:54] <Dark_Shikari> and too much work
[12:22:59] * kshishkov thought pixfmt are not in sws anymore
[12:23:56] <Dark_Shikari> they're in avutil.
[12:23:58] <Dark_Shikari> same problem.
[12:27:13] <av500> they should go to libavcore
[12:28:17] <Dark_Shikari> we still shouldn't require it.
[12:28:34] <Dark_Shikari> placing a required dependency between x264 and ffmpeg is a gigantic dick move.
[12:28:41] <Dark_Shikari> and should only be done if absolutely necessary.
[12:28:45] <Dark_Shikari> Which it isn't.
[12:29:04] <mru> but do you need the pixel format defs when not using ffmpeg?
[12:29:05] <KotH> how about merging x264 into ffmpeg? ;-)
[12:29:25] <elenril> KotH: right after -mt i think
[12:29:39] <KotH> is that before or after hurd 1.0?
[12:29:49] <av500> at the same time as DNF
[12:29:56] <elenril> before, after hurd 1.0 we won't need mt
[12:29:56] <kshishkov> Dark_Shikari: or introduce a function to swscaler to get needed colourspace ID from required parameters
[12:30:22] <Dark_Shikari> mru: we would, if we didn't do what we did now
[13:05:20] <Honoome> elenril: after hurd 1.0 we won't need computers
[13:05:49] <Honoome> actually, hurd 1.0 codename is going to be "Matrix"... so we would want to stay _away_ from computers then :P
[13:06:28] * elenril thought is was skynet
[13:08:35] * kshishkov though "Hurd" was just a codename for Emacs 256.0 or so
[13:23:55] <pross-au> Ah, the Duke Nukem Forever of operating systems...
[13:24:46] <av500> no, DNF, the hurd1.0 of video games
[13:25:23] <pross-au> But most people have heard of DNF
[13:25:49] <KotH> DNF is taking away the glory from hurd 1.0!
[13:27:27] <elenril> evil proprietary software!
[13:27:55] <KotH> elenril: is that a trope?
[13:28:41] <pross-au> goes back to GNU/FFmpeg
[13:30:23] <elenril> KotH: there's a trope for everything
[13:30:31] <elenril> it's like rule 34
[13:31:20] * mru applies rule 34 to tropes
[13:31:57] * elenril throws http://tvtropes.org/pmwiki/pmwiki.php/Main/Trope-tan at mru 
[13:34:01] * KotH wonders how rule 34 on ffmpeg would look like
[13:34:07] <BBB> \o/
[13:34:13] <BBB> my mbedge loopfilter worked at once
[13:34:37] <KotH> then you have not seen the obvious bug ;-)
[13:34:41] <BBB> and then I used the mru approach to break it intentionally to make sure it's actually used, and it broke indeed \o/
[13:34:41] <kshishkov> KotH: whenever you feed one ffmpeg output to another
[13:34:45] * BBB cheers
[13:37:42] <elenril> KotH: http://tvtropes.org/pmwiki/pmwiki.php/Main/BeCarefulWhatYouWishFor
[14:11:41] <KotH> elenril: i've seen rule 34 invoced on shopping carts... so nothing is going to shock me anymore
[14:12:37] <kshishkov> KotH: isn't it demonstrated in every supermarket?
[14:14:50] <Honoome> kshishkov: only in .ua I guess :P
[14:15:09] <av500> you are not supposed to demostrate in supermarket!
[14:18:29] * Honoome has been trained by xkcd to reply with "that's what SHE said" but will avoid doing so this time
[14:21:17] <kshishkov> Honoome: may I remind you that Italia does not differ from Ukraine much
[14:21:50] <Honoome> kshishkov: our supermarkets are still not applying rule34 daily
[14:23:26] <KotH> Honoome: do you have nightmares about being sourunded by thousands of mouse sized dromaeosaurids?
[14:23:28] <kshishkov> Honoome: we still don't have enough supermarkets so I cannot say what happens in them
[14:23:29] <mru> KotH: would you be shocked by rule 34 applied to high-voltage power lines?
[14:23:51] <KotH> mru: hmm...
[14:24:01] <mru> or rule 34 applied to various fractions of spork
[14:24:06] <kshishkov> mru: everybody will be shocked when applied to high-voltage lines
[14:24:10] <KotH> mru: only if they are under power and have more than 1GV applied ;)
[14:24:26] <Honoome> KotH: not yet no, but I have strange hobbies lately
[14:25:08] <kshishkov> mru: replacing conditions with loops and switches
[14:25:18] <Honoome> well, never stranger than elenril's linking of tvtropes at any chance ;)
[14:25:32] <mru> Honoome: tried #331?
[14:26:01] <Honoome> not yet, I have too many friends who work in the graphics area :/
[14:26:31] <mru> Honoome: #559?
[14:27:09] <Honoome> that one yes
[14:29:19] <mru> #79 is fun
[14:30:12] <Honoome> saste just did #139
[14:30:15] <Honoome> err #138
[14:35:47] <kshishkov> #253
[14:59:29] <CIA-99> ffmpeg: aurel * r24327 /trunk/libavformat/avformat.h:
[14:59:30] <CIA-99> ffmpeg: fix av_seek_frame_binary() documentation
[14:59:30] <CIA-99> ffmpeg: read_timestamp() is part of AVInputFormat, not AVCodec
[15:23:48] <Honoome> I _definitely_ got to try #590... I know _so_ many of them
[15:24:49] <mru> it is a dreadful font
[15:25:14] <Honoome> where is it found?
[15:25:41] <mru> papyrus.ttf says fc-match
[15:26:02] <mru> which is in a bag of fonts I snagged from a windows system years ago
[15:26:13] <kshishkov> standard MacOSX Comic Sans replacement? eww
[15:26:14] <Honoome> windows, gotcha! :)
[15:27:11] <mru> nice fonts, but expensive: http://typography.com/
[15:27:38] <kshishkov> mru: still, Comic Sans is #0 in dreadfulness
[15:32:11] <jhuntwork> Hi!
[15:32:29] <mru> lo
[15:33:18] <jhuntwork> I was wondering if there had been any updates on getting speex encoding to work with ffmpeg
[15:33:40] <jhuntwork> saw there had been a few patches floating around, but none of them seem to have been accepted from what I can tell
[15:34:11] <mru> 1. find them
[15:34:13] <mru> 2. fix them
[15:34:17] <mru> 3. submit them
[15:34:21] <mru> 4. ???
[15:34:23] <mru> 5. profit
[15:34:37] <jhuntwork> heh, ok
[15:34:58] <mru> sorry, I didn't follow those patches
[15:36:48] <jhuntwork> the last one I saw was here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-October/077595.html
[15:43:30] * Kovensky would like to know why is the SNR -1.5dB on his modem's statistics page
[15:45:07] <kshishkov> read the manual
[15:45:28] * kshishkov had lots of different SNRs on his modem statistics
[15:45:51] <mru> what's the snr of the snr reading?
[15:48:51] <Kovensky> it's -2.0 now =p
[15:48:55] <Kovensky> kshishkov: no manual
[15:49:06] <Kovensky> the help just says "View status and statistical information for the Digital Subscriber Line (DSL)when the physical WAN-side connection to the service provider is achievedthrough a DSL line. Statistical information is accumulated over periodicintervals and may be displayed for up to a 24 hour period"
[15:50:09] <mru> well, as long as it's not -inf you have some signal...
[16:09:16] <Honoome> Kovensky: SNR of -1.5dB? and you're still connected? MiracleModem?
[16:11:12] <Kovensky> is there even negative SNR anyway
[16:11:48] <mru> of course
[16:11:56] <mru> when the signal is weaker than the noise
[16:12:07] <mru> signal/noise < 1
[16:12:28] <av500> take #beagle for example
[16:12:41] <mru> nah, it has snr of 54db
[16:12:58] <av500> right 26^2
[16:12:58] <mru> signal and noise are both 26
[16:13:35] <Kovensky> <@mru> when the signal is weaker than the noise <-- how can you even find the signal when it's below the noise
[16:13:48] <mru> Kovensky: you look harder
[16:14:11] * mru points at shannon
[16:14:51] <av500> Kovensky: you might know something about the signal
[16:15:35] <mru> av500: you always know something about the signal: it's not noise
[16:16:16] <av500> yes
[16:30:54] <kshishkov> Kovensky: look at matched filtering, for example
[16:31:23] * Kovensky is only now starting at DSP ._.
[16:31:35] <av500> look at how GPS works
[16:31:37] <Kovensky> actually, I paused the DSP reading stuff to read on calculus and other math stuff
[16:31:54] * Kovensky needs to learn math properly
[16:31:56] <kshishkov> Kovensky: unlike you DSP has never met with me
[16:32:01] <mru> calculus exists so we can do dsp
[16:32:24] <mru> gauss and his friends had amazing foresight
[17:18:31] <CIA-99> ffmpeg: mru * r24328 /trunk/Makefile: fate: echo fate-run command with V=1
[17:18:32] <CIA-99> ffmpeg: mru * r24329 /trunk/ (Makefile configure): Generate list of lavfi tests in configure
[17:18:41] <CIA-99> ffmpeg: mru * r24330 /trunk/ (4 files in 3 dirs): (log message trimmed)
[17:18:41] <CIA-99> ffmpeg: Fix lavfi pixdesc test
[17:18:41] <CIA-99> ffmpeg: This test verifies the pixdesc code by comparing the output with and
[17:18:41] <CIA-99> ffmpeg: without a filter which should have no effect on the image. Since the
[17:18:42] <CIA-99> ffmpeg: available pixel formats depend on the byte order of the machine, a
[17:18:42] <CIA-99> ffmpeg: simple reference checksum is not possible.
[17:18:43] <CIA-99> ffmpeg: The test originally tried to solve this by generating a reference file
[17:21:29] <pJok> what to do with the power of perl on my android phonne?
[17:22:23] <saintdev> Try and take over the world!
[17:22:38] <mru> ffperl?
[17:41:01] <_av500_> pJok: use it to run ffmpeg
[18:13:09] <pJok> _av500_, that would require root ;(
[18:13:11] <pJok> ;)*
[18:13:28] <mru> make it suid root then
[18:14:33] <pJok> mru, rooting it requires some bashing on the bootloader
[18:14:45] <pJok> and i can't be bothered doing that till android 2.2 officially is out from htc
[18:14:47] <mru> doesn't it have bash installed?
[18:14:55] <pJok> nop
[18:14:59] <mru> ah..
[18:15:00] <pJok> i think it has busybox
[18:15:10] <mru> try boxing the bootloader then
[18:15:22] <pJok> again, can't be bothered doing it till 2.2 is out
[18:15:27] <mru> then you can make an unboxing vid after
[18:15:38] <pJok> since i will have to do it all over again anyways
[18:17:38] <pJok> annoyingly you have to create a rom and flash it if you want to change the OS
[18:18:02] <pJok> otherwise i'd have fixed 2.2 when i got it
[18:20:45] <CIA-99> ffmpeg: alexc * r24331 /trunk/libavcodec/aacenc.c:
[18:20:45] <CIA-99> ffmpeg: aacenc: Refactor apply_window_and_mdct() so it no longer takes an offset channel.
[18:20:45] <CIA-99> ffmpeg: Patch by Nathan Caldwell <saintdev at gmail.com>
[18:23:34] <CIA-99> ffmpeg: alexc * r24332 /trunk/libavcodec/aacenc.c:
[18:23:34] <CIA-99> ffmpeg: aacenc: Adjust array offsets for the current channel before calling ff_psy_suggest_window().
[18:23:34] <CIA-99> ffmpeg: Patch by Nathan Caldwell <saintdev at gmail.com>
[18:38:37] <CIA-99> ffmpeg: alexc * r24333 /trunk/libavcodec/aaccoder.c: Cosmetics: Whitespace
[18:44:11] <CIA-99> ffmpeg: mstorsjo * r24334 /trunk/libavformat/rtpdec_xiph.c:
[18:44:12] <CIA-99> ffmpeg: rtpdec_xiph: Avoid extra memcpy in Xiph RTP depacketizer
[18:44:12] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[18:45:56] <saintdev> peloverde: does the initial window type have to be anything specific?
[18:46:13] <peloverde> no
[19:07:05] <saintdev> peloverde: is there any sort of frame analysis software that you know of?
[19:07:31] <peloverde> nothing useful
[19:08:21] <BBB> how do I force a video decoder with ffmpeg?
[19:08:22] <peloverde> Some video software claims to handle AAC but it's never more than pulling a few flags out of an ADTS header
[19:08:32] <Dark_Shikari> BBB: -vcodec blah -i input
[19:08:34] <peloverde> -vcodec before -i
[19:08:39] <BBB> ah ok, thanks
[19:35:49] <peloverde> saintdev: I did start writing my own analysis tools in python but they still are pretty rough
[19:52:21] <CIA-99> ffmpeg: siretart * r24335 /branches/ (0.6 0.6/libavformat/aviobuf.c):
[19:52:22] <CIA-99> ffmpeg: aviobuf: Do short seeks forward by reading and skipping data instead of a proper seek
[19:52:22] <CIA-99> ffmpeg: This improves performance on e.g. seekable http.
[19:52:22] <CIA-99> ffmpeg: backport r24280 by mstorsjo
[19:55:54] <BBB> Dark_Shikari: peloverde: does ffplay have a -vcodec option of some sort also?
[19:56:22] <Dark_Shikari> yes afaik
[19:56:51] <BBB> Unrecognized option 'vcodec'
[19:56:57] <BBB> what is the name of the option? :-p
[19:57:21] <_av500_> dont they all use the same option parser?
[19:57:55] <BBB> apparently not
[19:59:14] <_av500_> right ffplay.c has its own set of options
[19:59:54] <_av500_> the only codec you can force is "none"
[19:59:59] <_av500_> aka .vn
[20:00:03] <_av500_> -vn
[20:05:40] <mru> I'm hooking the normal regtests into the fate test runner...
[20:07:27] <peloverde> BBB You could always pipe FFmpeg output to FFplay
[20:07:34] <BBB> not needed
[20:07:36] <BBB> pretty awesome
[20:07:41] <BBB> we surpasses libvpx already
[20:07:58] <BBB> \o/
[20:08:38] <spaam> with how much?
[20:08:48] <mru> shhh
[20:09:36] <BBB> 1:50 for decoding a movie our version, C takes almost 4 minutes, libvpx takes 2:05
[20:09:45] <BBB> 110 vs 125 seconds
[20:09:47] <Dark_Shikari> BBB: on your cpu.  if you can commit
[20:09:49] <Dark_Shikari> I'll test on a core 2 later
[20:09:51] <Dark_Shikari> er, core i7
[20:09:56] <BBB> so 12%
[20:10:49] <Dark_Shikari> BBB: I think libvpx has h and v swapped for deblock function names
[20:11:16] <BBB> you mean we have v and h swapped
[20:11:40] <BBB> same thing I guess
[20:11:44] <BBB> I still think 14.3% is too much
[20:11:53] <BBB> I need to at least be able to explain that
[20:11:54] <Dark_Shikari> Your CPU sucks
[20:12:06] <Dark_Shikari> I'll comment more later when I get to work
[20:12:08] <BBB> even if it doesn't suck, it'd still be the topmost function
[20:12:08] <Dark_Shikari> and you commit your stuff
[20:12:15] <BBB> can I commit it all?
[20:12:54] <BBB> and yeah we need some profiling data from other cpus also
[20:12:56] <Dark_Shikari> the sseslow change... you really should call it something else imo
[20:13:05] <Dark_Shikari> we have if(SSE2 && 3DNOW to detect some amd slow stuff
[20:13:05] <BBB> I'm open for suggestions
[20:13:10] <Dark_Shikari> there are effectively 4 categories of SSE
[20:13:14] <Dark_Shikari> VERYSLOW (worthless, conroe)
[20:13:19] <Dark_Shikari> SLOW (sometimes worthless, amd64)
[20:13:22] <Dark_Shikari> er, athlon 64
[20:13:23] <Dark_Shikari> NORMAL
[20:13:28] <Dark_Shikari> and FAST (Core 2, Phenom, i7)(
[20:13:44] <Dark_Shikari> with the extra category FAST_AND_DOES_FAST_SHUFFLES (penryn, phenom, i7)
[20:14:09] <BBB> I don't mind a good bikeshed about this
[20:14:20] <Dark_Shikari> this isn't critical to the rest of your patch
[20:14:24] <Dark_Shikari> commit the inner loopfilter if it isn't committed already
[20:14:27] <Dark_Shikari> er, chroma bits and all that
[20:14:28] <saintdev> let's take a vote!
[20:14:31] <Dark_Shikari> and I'll review mbedge when I get to wokr.
[20:14:31] <Dark_Shikari> brb.
[20:14:35] <BBB> ok, thanks
[20:16:12] <Yuvi> for us, v == filtering in the vertical direction (no transpose)
[20:16:12] <Yuvi> for libvpx: v == filtering a vertical edge (in the horizontal direction)
[20:18:24] <BBB> Yuvi: any recommendations on how to further speed up our vp8 decoder, or what to waste time on instead?
[20:18:47] <BBB> if nothing else matters, I'll probably move on and start learning neon or so
[20:19:00] <_av500_> mru: watch out
[20:19:05] <BBB> heh :)
[20:19:06] <_av500_> BBB: you have a BB?
[20:19:10] <BBB> no
[20:19:22] <mru> a B?
[20:19:23] <BBB> I have an iphone
[20:22:09] <Yuvi> BBB: http://pastie.org/1050972 is probably the biggest possible speedup left, I needed to check wheter gcc combined the branches or if not, how much a macro that did would benefit
[20:22:26] <Yuvi> and something I forgot
[20:22:55] <Yuvi> I'm busy for the next couple of days unfortunately
[20:24:38] <BBB> I'm not in a hurry ;)
[20:24:51] <Yuvi> http://pastie.org/1050981 is a WIP for edge emulation, it doesn't work
[20:28:12] <peloverde> Do people have thoughts on attack detection and window decision?
[20:29:04] <_av500_> DHS might care about attack detection
[20:30:59] <BBB> peloverde: what is attack detection?
[20:31:11] <saintdev> peloverde: i've got lame's almost ported over ;)
[20:31:53] <BBB> Yuvi: that first one looks pretty complicated, I don't fully get it... if it works, why don't you commit it? if it's faster...
[20:32:43] <peloverde> BBB: Attack detection is looking for a changes in signal properties to decide when to use a short window sequence
[20:32:45] <BBB> Yuvi: the second one I can look at also, I was already considering doing some work on both lack of emu_edge for intra, as well as implementing non-edge-emu inter MV handling and maybe (if possible ??) implement optimized edge emulation routines
[20:32:59] <saintdev> although it decides on pretty much entirely short blocks for castinets
[20:33:19] <saintdev> so i'm not 100% sure everything is correct
[20:33:23] <peloverde> Too many false positives burns bitrate
[20:33:33] <saintdev> also i'm not sure how to do group decision
[20:34:03] <peloverde> There is a table in 26.403 that covers group decision
[20:34:36] <peloverde> http://www.3gpp.org/ftp/Specs/archive/26_series/26.403/26403-900.zip
[20:34:52] <_av500_> we tried to have a group decision on where to eat at fosdem, it was hard
[20:35:12] <mru> in the end we had chinese
[20:35:26] <mru> can we encode audio in chinese?
[20:35:50] <_av500_> and chinese is always short packets err waiters...
[20:36:11] <mru> short change...
[20:36:44] <pJok> nearly time to run ffmpeg on android it seems
[20:37:05] <_av500_> pJok: use one of the 15+ chinese players :)
[20:37:46] <pJok> i just hope i got my contacts back
[20:37:54] <BBB> Yuvi: also, since you're maintainer, ist he change of prototype for vp8's filter8 inner/mbedge functions ok with you, and do you want me to change the names to something else (filtery/filter16y, filteruv/filter8uv) in the process? or is filter16/8 ok?
[20:37:57] <pJok> otherwise i have to "sync" them manually again
[20:37:59] <_av500_> did you root it?
[20:38:05] <pJok> not only that
[20:38:15] <_av500_> riot it?
[20:38:17] <pJok> i found myself a nice 2.2 android rom
[20:38:32] <pJok> it works
[20:38:56] <pJok> but i just recovered my settings to see if it actually is going to keep my contacts or not
[20:38:58] <_av500_> then u dont need ffmpeg any more, you have flash(tm) now
[20:39:37] <saintdev> peloverde: but have those been investigated, or are they just blind suggestions?
[20:39:54] <Dark_Shikari> BBB: ok, let me look over it
[20:40:06] <Dark_Shikari> you never changed movpx....
[20:40:09] <Dark_Shikari> It looks like "mov vpx"
[20:40:11] <pJok> i had that before
[20:40:12] <Dark_Shikari> which seems a bit blegh
[20:40:16] <BBB> I knew you'd bring that up ;)
[20:40:19] <BBB> I'm doing that right now
[20:40:22] <pJok> 10.1 was out for 2.1 for some reason
[20:40:28] <peloverde> saintdev: They are just blind suggestions but intuitively they look like a good starting point
[20:40:29] <BBB> I forgot yesterday, was finishing mbedge filter first
[20:40:38] <Dark_Shikari> ok
[20:41:18] <Dark_Shikari> why are there ifdef m12 blocks inside ifidn mmx?
[20:41:19] <Dark_Shikari> (line 432)
[20:41:26] <Dark_Shikari> don't have ifs that never trigger
[20:41:40] <BBB> really?
[20:41:46] <BBB> aiee
[20:42:05] <Dark_Shikari> try putting pw_63 in a register, please
[20:42:12] <Dark_Shikari> (even if only on x86_64)
[20:42:15] <saintdev> peloverde: ok
[20:42:19] <Dark_Shikari> remember: you can _overwrite_ constants you no longer need
[20:42:21] <Dark_Shikari> and in sse, there's no loop
[20:42:25] <Dark_Shikari> so you really do no longer need them.
[20:42:28] <BBB> ugh, you're right
[20:42:38] <Dark_Shikari> Also, in general, I think you might be able to use that fact to get away with fewer total regs required
[20:42:48] <BBB> probably, yes
[20:43:01] <BBB> I haven't gone to the extreme yet, in particular for the sse one
[20:43:04] <Dark_Shikari> ok
[20:43:18] <BBB> I might eventually rip out sse into its own function and further optimize it
[20:43:29] <BBB> because the loop-noloop makes a huge difference
[20:43:56] <Dark_Shikari> yeah, might be a good idea
[20:44:08] <pJok> deadshot
[20:44:14] <pJok> good thing i took a backup
[20:45:19] <Dark_Shikari> BBB: can you try macroing out the movd crap?
[20:45:22] <Dark_Shikari> at the end
[20:45:26] <BBB> yes
[20:45:40] <BBB> I said in my email I'd do it if someone would ask me to, so I will now ;)
[20:46:37] <BBB> and pextrw directly to mem is useful there, but needs testing (I don't have sse4)
[20:46:45] <Dark_Shikari> and that ssse3 multiply trick
[20:47:03] <BBB> for the +63>>7?
[20:47:06] <Dark_Shikari> yes
[20:47:07] <Dark_Shikari> the pmaddubsw
[20:47:10] <BBB> yeah
[20:53:53] <saintdev> peloverde: http://pastebin.org/406253
[20:54:52] <CIA-99> ffmpeg: alexc * r24336 /trunk/libavcodec/aaccoder.c: aacenc: Convert if () abort() to assert().
[20:55:17] <BBB> Dark_Shikari: what was the conclusion on filter8/16 naming?
[20:55:28] <BBB> some people complained but nobody gave a preference for a better name
[20:55:40] <BBB> filter16y/filter8uv ok?
[20:56:51] <Dark_Shikari> ok
[20:57:18] <peloverde> anyone know if pylab has an fdatool clone?
[21:06:52] <peloverde> That so called highpass filter looks like a bandpass to me
[21:07:34] <Dark_Shikari> well your so-called aac encoder looks like a spectral hole creator
[21:08:04] <saintdev> peloverde: in lame it only operates on 576 samples if that matters.
[21:08:10] <saintdev> Dark_Shikari: lol
[21:11:11] <peloverde> Dark_Shikari:  shut up we are actually trying to be constructive here
[21:11:21] <Dark_Shikari> lol
[21:12:07] <saintdev> peloverde: also the center coefficient i'm guessing is 0.5
[21:12:30] <peloverde> ahh, I missed the center coef
[21:12:52] <saintdev> it's not in the table, but sum1 is set equal to the center sample
[21:12:59] <peloverde> yes, I see that now
[21:13:01] <saintdev> so i assume that is 0.5 * 2
[21:13:51] <saintdev> although that doesn't make sense if it's the center it shouldn't be doubled
[21:15:51] <saintdev> although about all i know about fir is the coefficient table the wfir prints out in scilab
[21:18:58] <CIA-99> ffmpeg: rbultje * r24337 /trunk/libavcodec/ (vp8dsp.c x86/vp8dsp.asm vp8dsp.h x86/vp8dsp-init.c vp8.c):
[21:18:59] <CIA-99> ffmpeg: Change function prototypes for width=8 inner and mbedge loopfilter functions
[21:18:59] <CIA-99> ffmpeg: so that it does both U and V planes at the same time. This will have speed
[21:18:59] <CIA-99> ffmpeg: advantages when using SSE2 (or higher) optimizations, since we can do both
[21:18:59] <CIA-99> ffmpeg: the U and V rows together in a single xmm register.
[21:18:59] <CIA-99> ffmpeg: This also renames filter16 to filter16y and filter8 to filter8uv so that it's
[21:19:00] <CIA-99> ffmpeg: more obvious what each function is used for.
[21:20:01] <peloverde> saintdev: http://imgur.com/MCZy9l&hY2zn
[21:20:31] <peloverde> First image is 3GPP second image is GPSYCHO
[21:27:00] <peloverde> saintdev: presumably la should be advanced ten samples, no?
[21:28:25] <saintdev> i don't think so
[21:29:46] <peloverde> don't we want the center value to slide through the whole window rather than center sliding through win+10 to next_win+9?
[21:31:20] <saintdev> well lame does a weird offset to it's equivalent before the code you see there.
[21:31:51] <saintdev> it uses firbuf = input[576 - 350 - FIRLEN + 192]
[21:32:12] <saintdev> the 576 and 192 i can guess where they came from, but what is with the 350
[21:39:24] <peloverde> I don't know MP3 windowing well enough to know where it came from
[21:39:36] <peloverde> Do you know an overview of MP3 window sequences
[21:45:57] <saintdev> neither do i :P
[21:46:25] <saintdev> but from reading the lame source they're almost identical, except long/short are 576/3x192
[21:46:30] <CIA-99> ffmpeg: rbultje * r24338 /trunk/libavcodec/x86/vp8dsp.asm:
[21:46:30] <CIA-99> ffmpeg: Be more efficient with registers or stack memory. Saves 8/16 bytes stack
[21:46:30] <CIA-99> ffmpeg: for x86-32, or 2 MM registers on x86-64.
[21:47:00] <saintdev> or at least from window type/length
[21:53:17] <peloverde> Does MP3 have start/stop windows?
[21:53:45] <saintdev> yes
[21:54:21] <CIA-99> ffmpeg: rbultje * r24339 /trunk/libavcodec/x86/ (vp8dsp.asm vp8dsp-init.c): Implement chroma (width=8) inner loopfilter MMX/MMX2/SSE2 functions.
[21:54:29] <Dark_Shikari> \o/
[21:54:47] <Dark_Shikari> mru, peloverde, other people who know slightly more than zero about the lgpl, ping
[21:55:03] <mru> pong
[21:55:07] <peloverde> pong, also BBB
[21:55:25] <Dark_Shikari> ok, so my company obviously wants to abide by the LGPL.
[21:55:34] <Dark_Shikari> However, they have some practical issues which mean they can't do it exactly the same way that most companies do
[21:55:39] <Dark_Shikari> normally, you have a software download link on your site
[21:55:43] <Dark_Shikari> and you either include source + LGPL
[21:55:51] <Dark_Shikari> or you put a link next to it for source, and say "we use ffmpeg blah blah blah"
[21:55:58] <Dark_Shikari> (also, ffmpeg is not the only LGPL lib here, fyi)
[21:56:03] <Dark_Shikari> However, our downloadable is... an applet
[21:56:06] <Dark_Shikari> There's no link.  There's no install.
[21:56:09] <Dark_Shikari> It starts automatically.
[21:56:21] <Dark_Shikari> Putting lgpl or source in the .jar is stupid -- nobody will ever see it or even know that it's there.
[21:56:34] <Dark_Shikari> What should be done to be LGPL compliant in this case?
[21:56:36] <mru> java!!?!?
[21:56:55] <Dark_Shikari> Java is just used for the network stack and as a payload.
[21:56:58] <BBB> provide a link to the source in an about dialog or so
[21:57:07] <Dark_Shikari> e.g. it's a way to get lavc onto a user's machine without an install
[21:57:15] <BBB> I'm working on committing the other stuff btw, but splitting takes a little
[21:57:16] <Dark_Shikari> All the stuff that matters is native code.
[21:57:49] <mru> put a note on the page containing the "installer" that it uses lgpl and link to a page with source
[21:57:53] <Dark_Shikari> er.....
[21:57:55] <Dark_Shikari> there is no such page
[21:58:01] <Dark_Shikari> there is no installer
[21:58:11] <mru> but surely people get it _somewhere_
[21:58:15] <peloverde> the page where the applet is embedded then
[21:58:20] <Dark_Shikari> Our plugin is inserted on the pages of of websites using one line of javascript
[21:58:25] <mru> it's not a worm that installs itself on computers without asking, is it?
[21:58:26] <Dark_Shikari> We are not going to require our customers to modify their websites
[21:58:30] <Dark_Shikari> in order to insert our client
[21:58:36] <Dark_Shikari> (beyond that one line)
[21:58:39] <peloverde> can you put it in the applet gui then?
[21:58:40] <Dark_Shikari> i.e. no forcing them to include extra content
[21:58:45] <Dark_Shikari> We don't want to clutter the GUI pointlessly
[21:58:49] <Dark_Shikari> right now it has a grand total of two things
[21:58:53] <Dark_Shikari> 1) The game window.
[21:58:58] <Dark_Shikari> 2) A tiny bar at the top, with our logo.
[21:59:05] <peloverde> do you have a screenshot?
[21:59:10] <Dark_Shikari> sure
[21:59:19] <Dark_Shikari> my suggestion was "click the logo, get the about box"
[21:59:21] <mru> is there some kind of <object> or <embed> tag?
[21:59:50] <saintdev> Dark_Shikari: that was my immediate thought also :P
[22:00:12] <mru> that one line that goes into the page, what does it end up doing?
[22:00:19] <mru> insert some html?
[22:00:25] <mru> with an object tag?
[22:00:43] <Dark_Shikari> I guess.  one moment
[22:00:48] <mru> can't it also insert a line of text with link to lgpl info page
[22:00:54] <Dark_Shikari> we don't want to add random text to the interface
[22:00:57] <Dark_Shikari> imo an about box makes more sense
[22:01:04] <mru> like google ads insert "ads by google"
[22:02:00] <Dark_Shikari> http://i25.tinypic.com/6r6cep.jpg
[22:02:29] <votz> Dark_Shikari: what does the applet do? install necessary bins and libs in the host OS for the gaikai client?
[22:02:30] <mru> I see plenty of space in that title bar
[22:02:34] <Dark_Shikari> votz: no installation
[22:02:48] <Dark_Shikari> mru: "click on gaikai, get about box?"
[22:02:51] <Dark_Shikari> or "add about link"?
[22:02:54] <peloverde> turn the logo into a menu or having it launch a dialog seems reasonable
[22:03:02] <mru> Dark_Shikari: either would be fine with me
[22:03:33] <Dark_Shikari> now, would it be reasonable to only provide source for the latest applet?
[22:03:41] <Dark_Shikari> since the applet is provided directly from our website
[22:03:44] <Dark_Shikari> and not intended to be "installed"
[22:03:50] <mru> I guess
[22:03:53] <merbanan> Dark_Shikari: as long as you "offer" the source you should be ok
[22:04:04] <Dark_Shikari> merbanan: yeah, but we shouldn't be required to give source for 2 year old applets
[22:04:09] <Dark_Shikari> since we don't even distribute anything but the latest
[22:04:37] <Dark_Shikari> in some sense "if you want the source for the current version, get it when you get the current version"
[22:05:00] <votz> ah, an 'invisible' installation? ffmpeg/libs etc have to get installed somehow right?
[22:05:17] <Dark_Shikari> No
[22:05:20] <Dark_Shikari> They're just linked into the app.
[22:05:23] <Dark_Shikari> Inside the .jar.
[22:05:40] <Dark_Shikari> It's just an applet.  It ends up in a tempdir and gets cleared with your browser cache.
[22:06:07] <votz> Dark_Shikari: perhaps add a down arrow to the right of the 'Gaikai' logo to let users know there's a menu available if they click on the logo
[22:06:37] <votz> quick example that comes to mind are chrome's default dropdown boxes next to the page and wrench icons
[22:06:52] <merbanan> Dark_Shikari: I think that is a lawyer question, so maybe both yes and no is the correct answer
[22:07:04] <Dark_Shikari> k.
[22:07:30] <mru> personally I'm not too fussed over that 3-year thing
[22:07:50] <merbanan> but very unlikely that someone ever will go to court over that
[22:08:28] <merbanan> I would go with only supplying the latest version
[22:08:39] <Dark_Shikari> k
[22:08:41] <Dark_Shikari> makes sense.
[22:09:57] <peloverde> saintdev: Also, new code should be in the style of "if (x)" not "if( x )"
[22:11:07] <saintdev> ok
[22:24:33] <Dark_Shikari> ok, talked with them about it
[22:24:40] <Dark_Shikari> the menu is hard because we don't do compositing on the client currently
[22:24:50] <Dark_Shikari> and we would rather avoid that if we don't have to
[22:24:59] <Dark_Shikari> ( mru, peloverde, BBB )
[22:25:10] <Dark_Shikari> the decision they made is to take advantage of the fact that our client is in a frame
[22:25:23] <Dark_Shikari> and make the "powered by gaikai" link at the bottom go to a special page on our site
[22:25:29] <Dark_Shikari> which has information about the client, version info, and source downloads.
[22:25:54] <Dark_Shikari> seems to work.
[22:26:08] <peloverde> saintdev: Anyway until we can figure out where that 350 comes from, I think la-sizeof(aac_psy_fir_coeffs) makes sense as where to start
[22:26:18] <peloverde> saintdev: Did you look at the commit log for clues?
[22:28:59] <michaedw> Dark_Shikari: IANAL and IDNSFME, but I would be less concerned about the mechanics of delivering the source code and more concerned about meeting the conditions for allowing the recipient to use his own build of the LGPL library
[22:29:42] <Dark_Shikari> They could extract the JAR and insert their own lavc
[22:29:44] <Dark_Shikari> no problem with that
[22:29:51] <peloverde> saintdev: This could be done with "for (j = -((FIRLEN - 1) / 2); j < 0; j += 2)"
[22:30:57] <michaedw> ok, so as long as you provide adequate instructions for how to do that, I'd think you'd be fine
[22:32:03] <Kovensky> IDNSFME?
[22:33:00] <michaedw> including instructions for how to fetch the LGPL source from a "designated place" side-by-side with your distribution of your jar
[22:33:17] <michaedw> I Do Not Speak For My Employer
[22:34:29] <BBB> Dark_Shikari: I think a link to source should be fine
[22:34:56] <michaedw> you don't have to distribute code from every location that you distribute the binary; that's what the "written offer" clause is for
[22:35:15] <BBB> true, but that can be a lot of work if someone slashdots you
[22:36:39] <michaedw> BBB: I doubt anyone could get a judge to issue an injunction on the basis that you got Slashdotted and didn't have the bandwidth to serve everyone who wanted just your source without having actually received the binary first
[22:36:57] <BBB> that's what the gpl says though
[22:37:08] <BBB> you want to take that to court and throw a dice?
[22:37:14] <Dark_Shikari> we have a lot of bandwidth.
[22:37:27] <michaedw> "equivalent access" doesn't have to mean "unlimited access" if you are making a good faith effort to serve the source on terms equivalent to the binary
[22:37:51] <Honoome> michaedw: fsf won't stop at "good faith effort"
[22:38:27] <michaedw> judges, historically, do; see Progress vs. MySQL
[22:38:29] <Dark_Shikari> we aren't the fsf
[22:39:20] <CIA-99> ffmpeg: rbultje * r24340 /trunk/libavcodec/ (avcodec.h x86/cpuid.c x86/vp8dsp-init.c x86/dsputilenc_mmx.c): (log message trimmed)
[22:39:20] <CIA-99> ffmpeg: Remove FF_MM_SSE2/3 flags for CPUs where this is generally not faster than
[22:39:20] <CIA-99> ffmpeg: regular MMX code. Examples of this are the Core1 CPU. Instead, set a new flag,
[22:39:20] <CIA-99> ffmpeg: FF_MM_SSE2/3SLOW, which can be checked for particular SSE2/3 functions that
[22:39:21] <CIA-99> ffmpeg: have been checked specifically on such CPUs and are actually faster than
[22:39:21] <CIA-99> ffmpeg: their MMX counterparts.
[22:39:22] <CIA-99> ffmpeg: In addition, use this flag to enable particular VP8 and LPC SSE2 functions
[22:39:31] <michaedw> fsf and other guardians of the faith also have a history of pursuing good faith compliance as long as they don't feel they've compromised their "future enforcement ability" in the process
[22:39:36] <Honoome> Dark_Shikari: don't worry, they'll try to put something under your wheels anyway
[22:40:06] <michaedw> you're thinking of gpl-violations.org
[22:40:44] <peloverde> I would argue the iPhone people were making a good faith effort
[22:41:03] <michaedw> not familiar with the situation.  what were people unhappy about?
[22:42:02] <Honoome> michaedw: no different bunch those
[22:42:15] <Honoome> peloverde: argue for or against they were making it?
[22:42:45] <michaedw> Honoome: yes and no; the FSF and the netfilter folks are coming from different places
[22:42:58] <Honoome> michaedw: gpl-violations is far from being just netfilter
[22:44:39] <michaedw> true; I'm just mentioning a couple of significant participants in gpl-violations, who come from different places :-)
[22:44:45] <peloverde> http://arstechnica.com/apple/news/2010/05/fsf-apples-itunes-store-terms-of-service-at-odds-with-gpl.ars
[22:45:03] <Dark_Shikari> "good thing we don't use the gplv3"
[22:47:14] <peloverde> Dark_Shikari: "The primary problem is that Apple imposes numerous legal restrictions on use and distribution of GNU Go through the iTunes Store Terms of Service, which is forbidden by section 6 of GPL*v2*."
[22:47:22] <peloverde> (emphasis mine)
[22:47:39] <Dark_Shikari> of course, they think that the gpl means whatever they want it to mean
[22:47:46] <michaedw> the FSF sometimes confuses itself with a government.
[22:48:23] <BBB> Dark_Shikari: ok, I'm at the patch now ;)
[22:48:28] <BBB> what did I have to change again?
[22:48:49] <BBB> pw_63 in a reg, something about using %ifdef m12 in mmx code
[22:48:52] <BBB> was there more?
[22:49:33] <Honoome> mru: ping
[22:49:52] <Honoome> michaedw: no, a religion
[22:50:11] <michaedw> Honoome: there's a difference?  :-)
[22:50:47] <Honoome> michaedw: yes, a government is unlikely to take itself very seriously
[22:51:15] <Dark_Shikari> BBB: using fewer regs for constants by reusing them after the constant is done being used
[22:51:20] <michaedw> I know some religions that take themselves less seriously than (at least some departments in) most governments
[22:51:32] <Honoome> not fsf's case
[22:51:37] <saintdev> peloverde: i'll give that a try. and no i haven't checked the commit logs
[22:52:05] <peloverde> saintdev: I'm not sure how good lame commit messages are, but commit logs are usually a goof place to find context
[22:52:23] <BBB> Dark_Shikari: ah yes
[22:52:24] <BBB> ok
[22:52:25] <michaedw> I have my own opinions about the FSF, some of which are unprintable; but none of them seem to be relevant to Dark_Shikari's ask, which is pretty straightforward AFAICT
[22:52:29] <saintdev> peloverde: just glancing at them, not that great
[22:52:37] <BBB> fixed the other two
[22:53:31] <peloverde> Also I'm going to go ahead and switch to pluggable psymodels right away
[22:55:10] <saintdev> want me to resend that patch?
[22:55:26] <Dark_Shikari> BBB: so basically, you split up the big part of constant loading at the top
[22:55:30] <Dark_Shikari> and just put some parts in other places in the code
[22:55:42] <Dark_Shikari> e.g. "now we're done with register X, so we can load a new constant in it and %define a new name for it"
[22:56:56] <BBB> Dark_Shikari: but only for >=sse2 right?
[22:57:05] <michaedw> for what it's worth, good judges are familiar with prevailing practices in the industries they deal with, and try not to invalidate those practices without good reason
[22:57:16] <Dark_Shikari> BBB: well your current code is only ifdeffed under that too
[22:57:18] <Dark_Shikari> and yeah, of course
[22:57:23] <Dark_Shikari> well, only where it makes sense
[22:57:27] <BBB> yeah
[22:57:32] <Dark_Shikari> you won't be able to do it except on x86_64 anyways
[22:57:34] <Dark_Shikari> probably
[22:58:04] <michaedw> and providing notice in the About box, and a source download link, is very much the prevailing practice for web-delivered programs with LGPL bits inside
[22:58:56] <BBB> ugh
[22:58:59] <BBB> I broke x86_64 again
[22:59:10] <Dark_Shikari> lol gj
[22:59:17] <Dark_Shikari> why are you not testing first??
[22:59:27] <Dark_Shikari> you have a gajillion people who can give you ssh access to x86_64 boxes
[22:59:58] <BBB> I test most of my changes ;)
[23:00:02] <Honoome> sigh one time I needed mru around he's not here?!
[23:01:36] <spaam> mru is always here
[23:02:27] <Honoome> I also need him sober
[23:22:26] <BBB> ugh, can't figure out what's wrong :(
[23:45:34] <BBB> dammit
[23:45:42] <BBB> should I revert, or can I leave this for tonight?
[23:45:45] <BBB> I need to go home ;)
[23:46:05] <Dark_Shikari> spend a bit more time if you need to
[23:46:23] <Dark_Shikari> try disabling all your x64-specific stuff
[23:46:29] <Dark_Shikari> and just running the x64 with x86-style stuff
[23:46:31] <Dark_Shikari> i.e. no using extra regs
[23:46:34] <Dark_Shikari> then add it on bit by bit until it breaks
[23:46:47] <BBB> I probably need a ssh account first for that
[23:46:54] <BBB> can anyone get me one?
[23:46:55] <iive> BBB: you committed bad code?
[23:46:57] <BBB> preferrably on 24/7
[23:47:06] <BBB> iive: yes I should be shot
[23:47:23] <Dark_Shikari> er wait
[23:47:25] <Dark_Shikari> you said you were testing it
[23:47:26] <Dark_Shikari> .....
[23:47:35] <Dark_Shikari> how the hell were you testing it if you didn't have an x86_64 machine?
[23:47:36] <iive> does it break compilation or just gives funny pictures?
[23:47:37] <Dark_Shikari> ...
[23:47:45] <BBB> you tested it earlier
[23:47:49] <BBB> I never modified it since then
[23:47:57] <BBB> lu_zero tested this particular patch
[23:48:12] <Honoome> oh god, BBB is relying on lu_zero's tests? :P
[23:48:13] <BBB> it worked for him (yesterday?)
[23:48:15] <Dark_Shikari> er, I didn't test it
[23:48:26] <Dark_Shikari> not on x86_64 at least
[23:48:36] <BBB> no, lu_zero tested this one
[23:48:42] <Dark_Shikari> "I tested it" means "I tested it"
[23:48:46] <Dark_Shikari> it doesn't mean "some other guy tested it"
[23:49:00] <Dark_Shikari> no more commits from you, for anything, until you can test on x86_64.
[23:49:05] <Dark_Shikari> there are a billion people who can give you ssh
[23:49:07] <Dark_Shikari> stop being lazy
[23:49:28] <Honoome> and stop leaving lu_zero to test something ¬_¬ lovely guy, just not the one to test :P
[23:49:30] <BBB> mru: ping
[23:49:31] <iive> Dark_Shikari: he feels bad enough already.
[23:49:57] <BBB> anyone with x86-64 server with ssh access: ping
[23:50:03] <Dark_Shikari> BBB: ask checkers
[23:50:11] <Dark_Shikari> if you can't get one otherwise
[23:50:25] <BBB> there must be someone in here with x86-64...
[23:50:31] <iive> BBB: if you want to go home, revert and finish it tomorrow.
[23:50:34] <BBB> checkers is in #x264dev?
[23:50:48] <BBB> iive: it doesn't break compilation, just gives (probably) funny pictures
[23:51:34] <Dark_Shikari> tes
[23:51:36] <Dark_Shikari> *yes
[23:51:39] <Dark_Shikari> checkers provides my shell
[23:51:53] <iive> so no runtime segfault either... How did you found the problem?
[23:52:02] <BBB> fate
[23:52:15] <Dark_Shikari> oh nevermind
[23:52:16] <Dark_Shikari> it's x86_32
[23:52:17] <Dark_Shikari> :/
[23:52:36] <BBB> let's wait for mru to wake up
[23:52:37] <Dark_Shikari> don't ping checkers.
[23:52:43] <Dark_Shikari> revert the patch for the meantime.
[23:54:10] <iive> some of the fate test run in qemu, don't they?
[23:55:27] <j0sh> BBB: i'm getting a x86_64 image running on my linode right now, you can have an account on there
[23:55:55] <BBB> that'd be great
[23:56:06] <BBB> can you send me login credentials to my email when it's up?
[23:56:13] <BBB> and is it on 24/7?
[23:57:59] <j0sh> yeah
[23:58:02] <j0sh> it will be
[23:58:50] <BBB> ok
[23:58:59] <BBB> I'll logon once you've got it going then, I guess ;)
[23:59:06] <BBB> let me know, I'll check email tonight
[23:59:14] <j0sh> geting thigns set up now, will be a few mins
[23:59:21] <j0sh> ill send you an email once its up
[23:59:24] <BBB> thanks