[FFmpeg-devel-irc] IRC log for 2011-02-23

[irc at mansr.com]

[01:34:09] <saintdev> awww, he just left http://danbooru.donmai.us/post/show/859807
[01:37:41] <saintdev> gah, keep doing that
[05:17:52] <saintdev> peloverde: ping
[05:31:27] <saintdev> actually, also ruggles: ping
[06:52:07] <saintdev> lol "(float)1.0f"
[06:52:41] <superdump> where's that?
[06:52:51] <saintdev> 3gpp source
[06:53:17] <saintdev> superdump: check your blog
[06:53:39] <superdump> already responded
[06:53:55] <saintdev> i guess emails are off :/
[06:54:09] <superdump> i'll check
[06:55:05] <saintdev> superdump: dmcrypt is a gentoo init script included with the cryptsetup packages to handle automic setup/open/close of encrypted volumes
[06:55:19] <saintdev> check out /etc/conf.d/dmcrypt
[06:56:00] <saintdev> *automatic even
[06:59:21] <superdump> saintdev: interesting...
[06:59:25] <saintdev> superdump: i use it for encrypted swap
[06:59:29] <superdump> is that only in openrc or in older stuff?
[06:59:53] <superdump> i just had a look through and it seems like it could do what i want quite simply
[07:00:27] <superdump> although... it's in /etc
[07:00:34] <saintdev> afaik openrc, but the scripts belong to sys-fs/cryptsetup
[07:00:48] <superdump> so i need to unlock root before i can access this
[07:01:02] <saintdev> yeah, that's why i don't know if it can handle encrypted root
[07:01:19] <saintdev> probably not, but you can use it for the other partitions/swap
[07:01:52] <superdump> i don't think i really had to do anything for the other partitions as they're all lvm volumes inside the crypt partition
[07:02:08] <superdump> once the crypt partition is unlocked, lvm does the rest
[07:02:19] <saintdev> oh, you're doing lvm on top of the encrypted partition
[07:02:20] <superdump> (though it doesn't seem to be unmounting them properly at the end)
[07:02:23] <superdump> yes
[07:02:53] <superdump> not really necessary as it's a laptop and i just have root, home and swap in there, but hey
[07:03:45] <superdump> it means i only have to remember and type one passphrase
[07:05:59] <superdump> hmm
[07:06:01] <saintdev> also theoretically ctr mode can be faster than cbc mode. not sure if the actual implementation is or not
[07:06:29] <superdump> i don't see any options anywhere to make wordpress send email to users who commented on a post
[07:06:36] <superdump> only to me
[07:07:37] <saintdev> lol, and i have almost nothing in my control panel :/
[07:09:06] <superdump> hrm
[07:09:09] <superdump> sorry about that
[07:09:39] <saintdev> i can see your askimet stats, though!
[07:09:40] <saintdev> lol'
[07:10:03] <superdump> you can?
[07:10:12] <superdump> brooooooken
[07:10:18] <superdump> how?
[07:10:31] <saintdev> clicking on Dashboard from my control panel
[07:51:37] <cartman> moin
[08:24:57] <saintdev> we lost that netsplit, big time
[08:26:29] <wbs> indeed
[08:32:41] <pJok> kshishkov, not if using a cattleprod
[08:33:54] <KotH> does saintdev have kids? if so, using a catleprod would be a moderate psychological pressure ;)
[08:34:21] <kshishkov> KotH: no, he seems to be a good developer
[08:34:26] <saintdev> what were you guys talking about, i ended up on the loosing side of the netsplit
[08:34:47] <saintdev> getting me to fix aacenc?
[08:34:52] <kshishkov> saintdev: how to make you into making ffaacenc being faster and better than faac
[08:35:03] <kshishkov> saintdev: before 0.7 release preferably
[08:35:07] <saintdev> o.O
[08:35:39] <KotH> kshishkov: so no gf either? damn!
[08:35:57] <saintdev> pe = inf, desired = 613.749878
[08:35:57] <saintdev> en = 4149235.750000, thr = 25190834.000000, nz = 3.105415, act = 3.105415, ah = 2
[08:35:57] <saintdev> en = 3235864.000000, thr = 402199.812500, nz = 12.661351, act = 12.661351, ah = 2
[08:35:58] <saintdev> ;)
[08:36:29] <kshishkov> looks like debug dump from ffaacpsycho
[08:38:04] <saintdev> that's what i'm currently looking at in my console ;)
[08:39:19] <superdump> what do each of the values mean?
[08:39:32] <kshishkov> they are meaningless
[08:39:41] <kshishkov> though somehow realted to signal energy
[08:40:11] <saintdev> pe = perceptual entropy, desired = target pe
[08:41:21] <saintdev> en = scalefactor energy, thr = scalefactor threshold, nz = number of non-zero spectral lines, act = number of active spectral lines, ah = hole avoidance flag
[08:43:51] <kshishkov> saintdev: have you tried rewriting psymodel from scratch after 3GPP spec?
[08:44:22] <saintdev> kshishkov: no need. what's there is correct, just incomplete
[08:44:40] <peloverde> saintdev: I'm sure at some point people will mention some details about CELT preserving energy in all bands, I recommend you ignore them until you have something 3GPPish working first
[08:44:42] <saintdev> also the spec is incomplete
[08:46:12] <saintdev> peloverde: are you against adding feedback between the coder and the psymodel to FFPsyContext?
[08:46:49] <peloverde> I'm against being more ambitious than 3GPP until we have something working
[08:46:55] <saintdev> the coder needs the frame-wide PE, and the psymodel needs the state of the bitreservoir
[08:47:42] <peloverde> there is nothing wrong with the psymodel having access to the bit reservoir
[08:48:26] <saintdev> i just want to make sure putting it in FFPsyContext is ok.
[08:49:03] <peloverde> yeah
[08:49:38] <kshishkov> s/having access/making encoder report/
[08:52:24] <saintdev> yay, pe is no longer ∞
[08:57:22] <ubitux> http://undeadly.org/cgi?action=article&sid=20110223045047
[08:59:18] <kshishkov> saintdev: it's infinity when some NAN occures somewhere (and with my sloppy coding and poor understanding of standards...)
[09:01:34] <Tjoppen> hm
[09:01:51] <Tjoppen> does ffmpeg indeed only do straight filter graphs?
[09:02:14] <saintdev> kshishkov: it was my fault. stupid bug.
[09:02:16] <Tjoppen> reading over the it seems that way
[09:03:54] <kshishkov> saintdev: but in most cases you can blame it all on me
[09:04:33] <saintdev> oh wow, even in functions that i wrote completely myself! thanks!
[09:12:31] <saintdev> well, that's...decidedly worse
[09:43:24] <Kovensky> http://i.imgur.com/ZyeCO.jpg
[09:45:19] <kshishkov> meh
[09:54:14] <Kovensky> mru: what the... britland is changing timezones?
[09:54:43] <kshishkov> Kovensky: they are obviously following Russian example
[09:55:37] <kshishkov> Kovensky: see http://en.wikipedia.org/wiki/Decree_time too
[09:56:57] <Kovensky> время is time?
[09:57:00] * KotH doesnt mention that .fr should actually move it's time zone back one hour
[09:57:04] * Kovensky will probably promptly forget it in 10 minutes
[09:57:17] <kshishkov> Kovensky: yep
[09:57:41] <Kovensky> why so many ya/yo/ye sounds, they're annoying to pronounce :D
[09:57:47] <kshishkov> KotH: sounds wrong. French people should adjust timezone by 79 minutes
[09:58:11] <kshishkov> Kovensky: try French with its é,è and ê
[09:58:40] <Kovensky> well, I know é and è because the diacritics happen to do exactly the opposite of what they do in portuguese
[09:58:43] <Kovensky> no idea about ê though
[09:59:21] <kshishkov> it's long e IIRC
[09:59:33] <Kovensky> actually... not very sure about é either, since there's no ` diacritic in portuguese, and when it existed, it only applied to a, and it didn't change its sound
[09:59:55] <ubitux> 'ê' sounds a bit like the "heh?" in japanese
[10:00:13] <ubitux> or like a sheep, as you prefer
[10:00:21] <Kovensky> baa
[10:01:33] <kshishkov> wikipedia says it's a tombstone for dead consonants
[10:01:43] <kshishkov> http://en.wikipedia.org/wiki/Circumflex#Deletion
[10:09:11] * siretart likes http://andrewvos.com/2011/02/21/amount-of-profanity-in-git-commit-messages-per-programming-language/
[10:11:15] <kshishkov> time to switch to Ruby?
[10:11:43] <jannau> or C++
[10:12:09] <kshishkov> that would generate much profanity by itself
[10:26:46] <pross-au> They didnt cover common lisp
[10:28:08] <kshishkov> it's hard to swear with parentheses
[10:28:23] <pross-au> (Asshole)
[10:30:13] <kshishkov> nay, that's too lame
[10:30:30] <kshishkov> at least Russians seldom swear
[11:43:37] <mru> the total amount of profanity is constant
[11:43:53] <mru> those languages with little of it in comments simply have it in the code
[11:45:19] <kshishkov> mru: there's Russian where people can completely speak in profanities
[11:46:01] <kshishkov> computer code analogy would be probably corporate code
[11:47:24] <BBB> siretart: that mostly sounds what my lawyers came to conclude also - but so you think the license allows it to be redistributed?
[11:48:02] <BBB> siretart: not that I care a lot of course, all I care about is that lavcodec+faac is not allowed to be linked together
[11:48:35] <kshishkov> BBB: your lawyers? You're very evil man then
[11:50:59] <BBB> SFLC :)
[11:51:03] <BBB> they're "good" lawyers
[11:51:21] <siretart> BBB: TBH, I don't care that much either, but this is the conclusion of the ubuntu technical board
[11:52:28] <siretart> I'm currently thinking about an answer to that
[11:53:06] <BBB> from my point of view, you can tell them I'm happy to see they concluded libavcodec cannot legally link to libfaac :)
[11:53:22] <siretart> nobody really proposed that anyway
[11:53:36] <BBB> DonDiego: please look at https://roundup.ffmpeg.org/issue455
[11:54:09] <siretart> BBB: would you still veto a libfaacbin wrapper that loads faac bin at runtime, similar to other wrappers we already have?
[11:54:17] <BBB> yes
[11:54:34] <BBB> the libfaac glue code can stay
[11:54:36] <kshishkov> maybe other binary loaders as well
[11:54:37] <BBB> the code is not illegal
[11:54:44] <BBB> neither is building it yourself
[11:54:49] <BBB> but you cannot redistribute the combination
[11:55:11] <siretart> that's not what's happening
[11:55:34] <siretart> they are still distributed seperately
[11:55:38] <BBB> you're trying to create a libfaacbin so people can compile/install libfaac themselves and ffmpeg will pick it up
[11:55:48] <BBB> I don't think that is the right message to send to people
[11:55:58] <BBB> the right message is: please help us make ffaacenc better
[11:56:12] <BBB> but if others think it's a good idea I can be overruled of course
[11:56:30] <BBB> I don't like the libfaacbin idea, but I hate vetos more :)
[11:56:33] <siretart> we trying to send that message out for years. in reality, people rather fetch (broken) packages that illegally dynamically link against libfaac
[11:56:42] * kshishkov doesn't like any binary lib loader
[11:56:44] <siretart> I'd like that to stop. fast.
[11:57:05] <kshishkov> siretart: I can tell you how to get to Nero
[11:57:24] <siretart> kshishkov: I doubt they would help to improve ffaac
[11:57:34] <mru> kshishkov: shall I tell them about the backdoor I left? :)
[11:58:18] <kshishkov> mru: next time they invite you to work
[12:01:06] <kshishkov> siretart: well, Ivan Dimkovic said that Polish guy virtually rewrote faac making it much better that original Menno's
[12:01:39] <mru> doesn't matter, as long as that file with the bad licence is there
[12:02:12] <kshishkov> mru: well, faac AUTHORS file contains your name too!
[12:04:21] <mru> what?
[12:04:21] <siretart> kshishkov: how does this help getting ffaac improved?
[12:05:17] <kshishkov> mru: yep, in contributors section
[12:05:41] <mru> I must have sent a patch some time
[12:06:46] <kshishkov> siretart: in no way
[12:06:56] <kshishkov> siretart: but maybe you can work on improving it?
[12:07:23] <kshishkov> siretart: I suspect it's on reference decoder level, i.e. any change would only improve it
[12:08:17] <wbs> BBB: would you mind pushing the win/errno patch you queued yesterday, so we could close the roundup ticket?
[12:08:32] <siretart> kshishkov: I put it on my list
[12:08:46] <siretart> kshishkov: but don't expect me to get to that in the next 2 years ;-)
[12:10:34] <kshishkov> BTW, what's the status with Bink-b audio patches?
[12:22:01] <BBB> wbs: done
[12:22:20] <CIA-15> ffmpeg: Martin Storsjö <martin at martin.st> master * r28c4741a66 ffmpeg/ (8 files in 2 dirs): (log message trimmed)
[12:22:20] <CIA-15> ffmpeg: libavformat: Remove FF_NETERRNO()
[12:22:20] <CIA-15> ffmpeg: Map EAGAIN and EINTR from ff_neterrno to the normal AVERROR()
[12:22:20] <CIA-15> ffmpeg: error codes. Provide fallback definitions of other errno.h network
[12:22:20] <CIA-15> ffmpeg: errors, mapping them to the corresponding winsock errors.
[12:22:21] <CIA-15> ffmpeg: This eases catching these error codes in common code, without having
[12:22:22] <CIA-15> ffmpeg: to distinguish between FF_NETERRNO(EAGAIN) and AVERROR(EAGAIN).
[12:22:22] <BBB> wbs: sorry I hadn't done it before, I had it patch -p1'ed instead of git am'ed, so it didn't show up as a queued patch, my fault
[12:22:39] <mru> why would you do that?
[12:22:40] <wbs> BBB: np, and thanks for pushing
[12:22:48] <BBB> mru: accident
[12:22:58] <mru> strange accident
[12:23:06] <BBB> not sure why I did that
[12:23:31] <BBB> kshishkov: if they're OK'ed, I can apply
[12:26:19] <kshishkov> BBB: let's see...
[12:26:36] <BBB> I first have to apply elenril's patches though
[12:26:42] <BBB> I still don't like put_tag()
[12:27:35] <kshishkov> you prefer pull_tag()?
[12:28:50] <BBB> I feel that with proper work, avio_wl32() could write 4 bytes at once, and most put_tag() uses could then use avio_wl32() with a MKTAG fourcc, possibly as a macro so it's easier to write
[12:29:25] <BBB> for the few remaining cases, we could use avio_put_str() (which should be avio_write_str()), with an extra argument indicating if we want to write the terminating zero
[12:29:59] * elenril doesn't really like adding one more argument
[12:30:07] <elenril> but we can decide that later
[12:31:55] <BBB> we can keep that version internal
[12:32:12] <BBB> just like put_tag
[12:35:39] <mru> has anyone looked into that vp8 clang bug?
[12:36:33] <kshishkov> we have cartman for clang
[12:38:37] <mru> yeah, but has he looked at it?
[12:41:11] <mru> elenril: http://abstrusegoose.com/342
[12:43:22] <kshishkov> mru: rather silly question. He should have started with physical meaning of acceleration - it's meters divided by SQUARE SECONDS!!!
[12:44:12] <mru> there's more than one time dimension, you know
[12:44:26] <mru> a square second is one second in each of two time dimensions
[12:44:34] <kshishkov> explain that to a man who rejects math
[12:45:21] * Kovensky prefers round seconds
[12:45:51] * mru multiplies Kovensky's seconds by pi
[12:45:59] <mru> Kovensky: better?
[12:46:13] * Kovensky confuzzled
[12:47:32] <mru> Kovensky: when's your birthday?  I was thinking of getting you a square pie plate
[12:47:47] <Kovensky> lol
[12:58:23] <BBB> cartman: ping
[12:58:28] <BBB> mru: I've told him how to debug it
[12:58:31] <BBB> mru: he didn't do it
[12:59:05] <BBB> michael kostylev gave me shell on a system having that bug
[12:59:09] <BBB> maybe I should look at it
[12:59:42] <BBB> mru: also, are you sure vc1 idct can be done in words/17bit? because if counting from 12bit input (see specs), range can go up to 23-24 bits, if I count correctly
[13:01:44] <kshishkov> BBB: he's implemented NEON VC-1 transform, I think, so he should know
[13:01:58] <mru> I could have made a mistake
[13:02:27] <mru> such as believeing ivan when he said 17 bits was enough
[13:02:32] <mru> -e
[13:02:55] <mru> kshishkov: look at your mmx/sse code
[13:03:01] <mru> iirc it uses 16 bits all the way
[13:03:08] <mru> and hopes for the best
[13:04:15] <kshishkov> mru: it wasn't mine, I did altivec only
[13:04:28] <mru> kshishkov: yours as in your employer's
[13:04:59] <cartman> BBB: I am busy with real $job atm, clang thing is not easy to debug (at least for me)
[13:06:01] <kshishkov> mru: yes, that one seems to be pure 16-bit
[13:07:47] <kshishkov> probably because everybody ignores that BS about overlap transform extending range to 10 bits
[13:07:57] <kshishkov> s/transform//
[13:08:29] <mru> the spec says input to the transform is 12-bit signed
[13:08:40] <mru> output of first stage is 13-bit signed
[13:08:52] <mru> says spec
[13:09:15] <kshishkov> indeed
[13:09:23] <mru> and output is 10-bit signed
[13:09:45] <BBB> I don't see the output being 13-bit
[13:09:54] <mru> the spec says it must be
[13:09:56] <BBB> if you take the first line, 16+15+9+4*some input
[13:10:04] <BBB> then that's 12-bit*(16+15+4+9)
[13:10:09] <BBB> =12+6 bits
[13:10:11] <BBB> =18 bits
[13:10:16] <kshishkov> BBB: intermediate matrices are in -4096..4095 range - i.e. 13 bits
[13:10:29] <BBB> first part similar
[13:10:33] <BBB> so input before >>3 is 19 bits
[13:10:37] <BBB> so after >>3 16 bits
[13:10:39] <BBB> how did it become 12?
[13:10:47] <kshishkov> clipping
[13:11:05] <BBB> hm...
[13:11:11] <BBB> so is it all done in words
[13:11:20] <BBB> or is it done in dwords and then intermediate clipping to words?
[13:11:30] <BBB> as in, how much can I clip?
[13:11:37] <mru> anyhow, in the second stage the coeffs sum to 90
[13:11:57] <kshishkov> and 96 in the first stage
[13:11:58] <BBB> 90 *13bits > 16 bits
[13:12:02] <BBB> so I don't see it fitting
[13:12:07] <mru> you're right, it doesn't
[13:12:09] <BBB> 90 = 7 bits
[13:12:10] <BBB> so it's 20
[13:12:17] <BBB> ok, I'll do it in dwords then
[13:12:45] <BBB> altivec code is in ints btw
[13:12:46] <mru> I had some doubts, but ivan said it was fine...
[13:12:54] <BBB> ivan just told me it wasn't fine
[13:13:02] <mru> different ivan
[13:13:04] <BBB> oh
[13:13:04] <BBB> ok
[13:13:19] <mru> one of the ivans in kshishkov's office
[13:14:39] <BBB> as in, there's ten of them, and this is #7?
[13:15:07] <mru> not quite that many
[13:15:29] <kshishkov> aac one and smoking one
[13:24:13] <lu_zero> o_O
[13:24:18] * lu_zero is still on break
[13:25:56] * iive wonders what is the family name of the smoking one
[13:26:15] <BBB> "cigarette man"
[13:26:37] <kshishkov> BBB: nope, he prefers cigars
[13:26:55] <kshishkov> iive: not Bulgarian
[13:35:59] <elenril> mru: spin is a certain feature of our mathematical models of reality
[13:36:05] <elenril> it doesn't get much better than that
[13:36:07] <mru> elenril: iKnow
[13:36:30] <kshishkov> elenril: I always remeber Feynman's quote about electron
[13:36:35] <kshishkov> *remember
[13:37:17] <cartman> kshishkov: feel free to share Feynman quotes
[13:38:04] <kshishkov> cartman: "when I think about an electron I imagine a bunch of graphics and formulae"
[13:38:27] <cartman> lol :>
[13:38:50] <kshishkov> that's the only way to imagine it properly
[13:39:27] <cartman> true :)
[13:48:06] <lu_zero> ^^;
[13:49:18] <elenril> nah, electron is a rotating yellow point
[13:49:47] <kshishkov> * NielsBohr stabs elenril
[13:49:50] <mru> actually, it's white now
[13:51:09] <mru> sorry, old kth joke
[13:52:07] * kshishkov remembers SL joke on KTH
[13:52:14] <elenril> kth?
[13:52:24] <mru> kth.se
[13:53:12] <elenril> meh, engineers
[13:53:39] <pJok> elenril, spin is what politicians do...
[13:53:56] <deppan> engineers are cool
[13:53:58] <deppan> especially kth ones
[13:54:23] <elenril> theoretical physicists are way cooler
[13:54:29] <deppan> no
[13:54:33] <mru> bullshit
[13:54:39] <mru> engineers actually do shit
[13:54:46] * kshishkov is also an engineer from KTH but different one
[13:54:52] <deppan> theoretical physicists just whines and claims stuff wont work
[13:55:01] * deppan has watched lots of stargate
[13:55:01] * cartman is distinguished slacker
[13:55:13] <mru> engineers get stuff done, whether possible or not
[13:55:21] <deppan> många kth'are här eller?
[13:55:33] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BeyondTheImpossible
[13:55:39] <kshishkov> deppan: those are experimenters, theoreticians don't care about real world at all
[13:55:41] <mru> deppan: minst två iaf
[13:56:00] <deppan> tre då+ :)
[13:56:04] <mru> tre?
[13:56:30] <deppan> kshishkov också?
[13:57:05] <mru> kshishkov är från kharkov
[13:57:06] <kshishkov> deppan: for me it was Kharkivska Tekniska (inte-so-)Högskolan
[13:57:22] <mru> deppan: elektro?
[13:57:25] <deppan> oh.
[13:57:27] <deppan> mru: nä data
[13:57:30] <mru> meh
[13:57:47] <deppan> håller på med exjobbet atm
[13:58:55] <spaam> kth..   tacka vet ja bth ;P
[13:59:12] <spaam> </ironi>
[13:59:28] <elenril> so when are the engineers who actually do stuff going to commit my patches
[13:59:43] <elenril> oh wait, BBB isn't an engineer
[13:59:47] <elenril> makes sense now
[13:59:50] <spaam> hohohoh
[14:17:53] <Dark_Shikari> http://news.ycombinator.com/item?id=2253945
[14:20:12] <mru> solution: be that "perfect candidate" instead
[14:20:57] <Dark_Shikari> That's the best bet, indeed~
[14:21:22] <mru> and the best jobs are never advertised at all
[14:21:30] <Dark_Shikari> Except because of #3.
[14:21:37] <mru> those are not the best jobs
[14:21:49] <mru> simply because the best jobs are not in companies with such policies
[14:21:58] <Dark_Shikari> true.
[14:22:23] <lu_zero> or the best job is for hr-type and the job is reorganize that part
[14:22:50] <mru> self-obsoleting jobs...
[14:23:08] <mru> do your job too well, and you won't have one
[14:24:16] <lu_zero> you do your job well and move to something else
[14:24:27] <lu_zero> then if the need arise they'll call you back =P
[14:32:21] <kshishkov> lol at MN's mail: ".. but if you think[,] you are smarter than the previous people who worked on it."
[14:37:24] <mru> he has a point
[14:37:42] <mru> and jpeg2k is dead anyway
[14:38:00] <mru> or is it still used by dcinema?
[14:38:45] <Dark_Shikari> used by "professional" shit
[14:38:53] <Dark_Shikari> i.e. still matters despite being awful
[14:38:56] <kshishkov> but it's _wavelets_!
[14:39:30] <mru> like any codec, with a low enough quantiser it gives decent picture
[14:39:46] <mru> except maybe theora
[14:40:02] <mru> theora has some really ugly artifacts
[14:40:28] <kshishkov> mru: it's called design
[14:40:52] <Dark_Shikari> theora should work fine as well
[14:40:57] <Dark_Shikari> unless you're using like some version using the old VP3 encoder
[14:41:02] <Dark_Shikari> which had insane fdct/idct mismatch
[14:41:04] <Dark_Shikari> due to being written by on2
[14:41:50] <mru> sure, but haven't you noticed the peculiar artifacts you get with theora?
[14:41:58] <mru> they're not like anything I've seen elsewhere
[14:42:02] <Dark_Shikari> eh?  nothing that looks atypical for an 8x8dct format
[14:42:24] <Dark_Shikari> Pre-1.2 it had some really obnoxious artifacts at low rates in motion due to overzealous ungated skip decision
[14:42:43] <kshishkov> mru: scalable JPEG?
[14:43:05] <mru> Dark_Shikari: it uses a slightly different dct than the mpeg family
[14:43:10] <mru> maybe that's the reason
[14:43:12] <mru> I don't know
[14:43:12] <Dark_Shikari> it's still an 8x8dct
[14:43:23] <mru> or maybe it's the mismatch you mentioned
[14:43:24] <Dark_Shikari> sure it's not exactly the same but neither is h264's or vc-1's
[14:43:29] <Dark_Shikari> mismatch was fixed years ago
[14:43:38] <mru> h264 isn't even a dct strictly speaking
[14:43:49] <Dark_Shikari> It's close.  Vaguely.
[14:43:56] <mru> it has similar properties
[14:44:03] <mru> which makes it a good choice for video coding
[14:44:06] <mru> but it's not a dct
[14:44:40] <Dark_Shikari> how close to a dct does it have to be for you to call it a dct?
[14:44:51] <mru> dct has a precise mathematical definition
[14:44:57] <mru> either something is one or it isn't
[14:44:59] <Dark_Shikari> so simpledct isn't a dct?
[14:45:11] <Dark_Shikari> it's not quite exactly equivalent.
[14:45:30] <mru> it uses approximate values for the coeffs
[14:46:01] <skal> at least it's orthogonal
[14:46:05] <skal> could be worse
[14:46:18] <mru> the h264 transform is all shifts and adds
[14:46:22] <mru> no multiplications
[14:46:27] <mru> with is wonderful to implement of course
[14:46:33] <mru> but it's not a dct by a far cry
[14:46:41] <Dark_Shikari> <insert snarky comment about how multiplications are just shifts and adds>
[14:46:50] <mru> right
[14:47:00] <mru> shifts by _one_
[14:47:27] <mru> coeffs of 1, 2, and 3 don't make a dct
[14:47:42] <Dark_Shikari> the h264 dct has more complex coeffs than that
[14:47:49] <Dark_Shikari> they're just factored into quant/dequant instead
[14:48:43] <kshishkov> look at VC-1
[14:49:29] <mru> a dct decomposes a signal into a sum of cosines
[14:49:37] <mru> a transform that doesn't do that isn't a dct
[14:49:59] <Dark_Shikari> You can factor multiplication factors from a DCT into quant/dequant too
[14:50:00] <Dark_Shikari> i.e. a real DCT
[14:50:03] <Dark_Shikari> Not all of them, but many of them
[14:50:09] <mru> first stage yes
[14:50:12] <Dark_Shikari> And last stage
[14:50:15] <Dark_Shikari> iirc
[14:50:26] <Dark_Shikari> Oh, depends what you're calling first and last of course.
[14:50:45] <mru> first stage for inverse, last stage for forward
[14:50:56] <mru> or decode/encode if you will
[14:50:56] <Dark_Shikari> yeah
[14:52:59] <mru> I don't see any cosine-like coeffs in any stage of the h264 transform
[14:53:33] <Dark_Shikari> http://cerezo.name/blog/2011/02/16/automatic-exploit-generation/
[14:53:57] <mru> only shifts by one or two and add/sub
[14:53:59] <Dark_Shikari> a program that, given an input, finds vulnerabilities in said input program, and automatically generates exploits.
[14:54:37] <mru> btw, is libjpeg or omx more likely to have a weird idea of dct?
[14:56:04] <mru> plugging an omx idct into libjpeg needs a dc bias
[14:59:09] <skal> jpeg's DC value is 0-centered
[14:59:51] <mru> and mpeg is 128
[14:59:54] <mru> apparently
[15:01:54] <skal> well, that's not counting with the various predictors
[15:02:13] <skal> but yes
[15:02:32] <Dark_Shikari> He's referring to the first block.
[15:05:09] <BBB> elenril: why prevent deprecating symbols?
[15:05:16] <BBB> elenril: I oppose that patch a little
[15:05:51] <BBB> elenril: can't you just replace all put_tag by a pretty printed macro doing a avio_wl32(pb, MKTAG(str[0],str[1],str[2],str[3]))?
[15:05:58] <BBB> elenril: otherwise I have to do it and I AM LAZY :-p
[15:06:07] <BBB> elenril: plus all the stuff you just said
[15:07:30] * Kovensky deprecates elenril
[15:09:05] <elenril> BBB: ?
[15:09:57] <BBB> elenril: instead of renaming put_tag and being silly, I'd like to get rid of it
[15:10:02] <BBB> I think it's a silly function
[15:10:19] <elenril> :effort:
[15:10:26] <elenril> ok, i'll try
[15:10:49] <BBB> how about for each non-four-letter one, we introduce an internal function called ffio_write_str(AVIOContext *pb, const char *str, int include_terminating_zero)
[15:10:58] <elenril> btw
[15:10:59] <BBB> then have avio_put_str() use that internally
[15:11:06] <elenril> what to do about avio_put/get_strfoo
[15:11:27] <BBB> and for each four-letter one have an internal macro ffio_write_fourcc() that calls avio_wl32()
[15:11:38] <BBB> elenril: leave them for now
[15:11:45] <BBB> naming is sub-ideal but it's ok, not a big deal
[15:12:45] <BBB> we can change it if you feel like it, but then let's figure out if we want avio_write_str(AVIOContext *, const char *str) or avio_write_str(AVIOContext *, const char *str, int include_terminating_zero)
[15:12:56] <BBB> important distinction
[15:13:39] <elenril> meh, let's keep them
[15:14:06] <BBB> :)
[15:14:31] <elenril> yeah, i'm lazy
[15:14:45] * BBB high-fives elenril
[15:14:46] <elenril> can you commit url_fopen/fclose?
[15:14:54] <BBB> I'll have a look
[15:17:22] <BBB> they look good
[15:17:24] <BBB> let me queue 'em
[15:19:17] <BBB> queued
[15:20:44] <elenril> avio_wl32(pb, MKTAG(str[0],str[1],str[2],str[3])) << will that work properly on all the weird archs?
[15:22:05] <BBB> (str)[n]
[15:22:07] <BBB> not str[n]
[15:22:10] <BBB> (said mru)
[15:22:18] <BBB> and yes it'll work on all weird archs
[15:22:23] <BBB> MKTAG() automatically writes a LE tag
[15:22:37] <cartman> where is av500 ? http://feedproxy.google.com/~r/Techcrunch/~3/e2gCRFfuUDs/
[15:31:16] <BBB> cartman: please find clang 2.9 bug thanks! :-p
[15:32:04] <elenril> char tag[5]; put_tag(&tag[0]) << wtf
[15:32:17] <cartman> BBB: I would if I could just fix this damn Android bug
[15:35:58] <BBB> elenril: where?
[15:36:08] <elenril> BBB: avienc
[15:37:40] <ruggles> saintdev: you pinged?
[15:38:10] <BBB> avi_stream2fourcc looks buggy with >10 streams
[15:38:54] <mru> ruggles: isn't the past tense of "ping" "pang"?
[15:39:00] <mru> compare "ring"
[15:39:53] <ruggles> :)
[15:41:19] <ruggles> google says it's "pinged"
[15:41:33] <ruggles> first definition: hit with a pinging noise; "The bugs pinged the lamp shade"
[15:41:57] * elenril pours some hate on mov
[15:42:04] <mru> ruggles: different ping
[15:42:25] <kshishkov> pingeth?
[15:43:22] <kshishkov> mru: also http://www.learnersdictionary.com/search/ping
[15:44:00] <mru> that's an archaic form
[15:45:11] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r22a3212e32 ffmpeg/ (14 files in 2 dirs):
[15:45:11] <CIA-15> ffmpeg: avio: rename url_fopen/fclose -> avio_open/close.
[15:45:11] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[15:45:19] <CIA-15> ffmpeg: longstone <zhibing.min at hotmail.com> master * r4acc94e97a ffmpeg/libavformat/ (avi.h avienc.c):
[15:45:19] <CIA-15> ffmpeg: avienc: fix AVI stream index for files with >10 streams
[15:45:19] <CIA-15> ffmpeg: Fixes issue 2563.
[15:45:19] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[15:46:51] <pJok> thou shalt not pingeth?
[15:47:16] <kshishkov> "du ska inte pingar" even
[15:47:35] <elenril> BBB: all the remaining uses of put_tag use constant strings
[15:47:45] <elenril> so we can just put_buffer(sizeof())
[15:47:59] <elenril> no need to modify put_str
[15:48:11] <BBB> elenril: really?
[15:48:21] <BBB> elenril: if others are OK with that, then I am too
[15:49:24] * elenril compiles
[15:49:29] <BBB> and thanks for pointing out that avienc code to me
[15:49:35] <BBB> I had a pending patch on roundup for that
[15:49:41] <mru> elenril: sizeof("string") includes the null terminator
[15:49:49] <elenril> iKnow
[15:50:04] <mru> just checking, wasn't sure which you wanted
[15:59:14] <elenril> BBB: patch sent
[16:00:37] <BBB> awesome
[16:02:00] <ruggles> kshishkov: is there any easy way to get the number of samples in a wavpack frame before the decoder starts writing the output?
[16:02:14] <ruggles> the source is driving me crazy
[16:02:22] <BBB> x?"AIFF":"AIFC" <- I wonder if the compiler does silly shit like MKTAG(x?'A':'A', etc.)
[16:02:29] <ruggles> kshishkov: or even maximum number of samples
[16:16:51] <BBB> elenril: commented
[16:17:15] * BBB tihnks elenril will top our commit stats over 2011
[16:17:36] <spaam> cool guy
[16:17:48] <spaam> BBB: who won last year?
[16:17:56] <BBB> dunno
[16:18:16] <BBB> mans, it seems
[16:18:35] <BBB> (lines of code changed)
[16:22:40] * mru goes to find some more tables
[16:22:59] <mru> in fact, I have a patch messing with the twinvq tables somewhere
[16:25:15] <merbzt> gotta love those
[16:25:32] <merbzt> boom, ffmpeg got 500kb larger
[16:25:42] <lu_zero> uhm?
[16:25:50] <mru> my patch should make them a little smaller (compiled)
[16:25:56] <mru> more efficient packing
[16:26:08] <mru> perhaps I should dig it out again
[16:27:40] <BBB> holy shit 500kb tables?
[16:28:03] <BBB> does it load those tables if you don't actually use 'em?
[16:28:21] <mru> depends on the OS
[16:30:08] * mru tries to build ffmpeg with pcc, finds loads of bugs
[16:30:11] <mru> in pcc
[16:33:07] <lu_zero> pcc?
[16:33:43] <mru> http://pcc.ludd.ltu.se/
[16:33:48] <lu_zero> http://pcc.ludd.ltu.se/news/
[16:33:52] <lu_zero> ok =)
[16:35:42] <lu_zero> I wasn't aware it was still developed actively
[16:36:02] <Flameeyes> decisions are made or taken? :| I never remember
[16:36:18] <mru> made
[16:36:30] <mru> actions are taken
[16:36:32] <mru> and hostages
[16:36:42] * elenril takes a cookie
[16:36:43] <Flameeyes> thanks
[16:36:59] <mru> cookies can also be made
[16:37:51] * elenril prefers taking them
[16:38:40] <Flameeyes> I think I'll go make some tea
[16:48:05] <elenril> BBB: i'll send a separate patch for &tag[0]
[17:01:35] <BBB> elenril: fine, I'll apply this then, looks good from my angle
[17:05:16] * BBB stabs elenril for almost breaking fate
[17:05:39] <elenril> what did i do again
[17:06:02] <BBB> put_tag("FLV") != ffio_wfourcc()
[17:06:14] <elenril> oops
[17:06:17] <elenril> this is evil
[17:06:22] <elenril> i thought i caught them all
[17:34:29] <merbzt> http://www.h-online.com/open/news/item/Unicode-6-adds-astonished-face-1195872.html
[17:35:46] * mru would use one but doesn't have the font
[17:38:11] <merbzt> ☃
[17:40:52] <kshishkov> ruggles: yes, it's in frame header
[17:42:01] <ruggles> kshishkov: is the samples_left stuff just for multichannel?
[17:43:02] <kshishkov> nope
[17:43:19] <siretart> merbzt: for me that looks more like a turd than a snowman…
[17:43:51] <kshishkov> ruggles: lossy wavpack files also tend to have more samples in a block than can fit default av buffer
[17:45:00] <ruggles> ok, is the only thing samples_left is for?
[17:45:50] <kshishkov> it's for signalling there are still some samples left undecoded in this block
[17:46:04] <ruggles> and they're only left undecoded because of the output buffer size?
[17:46:12] <kshishkov> yep
[17:46:35] <ruggles> wow, that can go away completely with get/release_buffer()
[17:46:56] <kshishkov> indeed
[17:47:37] <ruggles> it looks like mkv mode and multichannel are the only cases where wavpack_decode_block() is called more than once for a frame.
[17:47:50] <ruggles> and mkv mode has samples in the frame header
[17:48:09] <kshishkov> all of them have\
[17:48:27] <kshishkov> mkv just stores them in first block, lavf demuxer - in all blocks
[17:49:49] <kshishkov> and mono/stereo is just trivial case of multichannel :)
[17:51:06] <ruggles> right, but it only has 1 block correct? the decoder sets frame_size = buf_size in the first loop iteration.
[17:52:10] <kshishkov> yep
[17:52:21] <ruggles> but multichannel has multiple blocks for multiple sets of 1 or 2 channels?
[17:52:45] <kshishkov> yes
[17:53:17] <ruggles> ok. so sample count is the same in each block, it just sets a different channel offset in the output buffer correct?
[17:53:43] <kshishkov> yes
[17:54:14] <ruggles> ok good. that samples_left part was throwing me for a loop... thanks for clarifying it.
[17:55:18] <ruggles> nice solution for getting around the buffer size limit though :)
[17:55:29] <kshishkov> it was rather obvious
[17:55:44] <kshishkov> luckily it doesn't need that much of context to save
[18:06:31] <therealgalen> irock: what's the status of your 10-bit ffmpeg code? is it usable for playing back h.264?
[18:35:39] <saintd3v> ruggles: do you plan on using the psymodel at all (psymodel.{ch})?
[18:37:44] <kshishkov> I fear it's not usable right now for AC3
[18:38:51] <saintd3v> kshishkov: well of course not
[18:39:38] <ruggles> saintd3v: possibly if it improves it could be useful
[18:40:12] <saintd3v> ruggles: i just mean the wrapper, not the stuff in aacpsy
[18:41:59] <ruggles> saintd3v: oh, maybe. it depends on how complex a secondary psy model for ac3 would need to be. that just has critical band structure and function prototypes correct?
[18:43:06] <ruggles> saintd3v: oh, the wrapper needs to support float samples though. now it just takes int16_t.
[18:44:39] <saintd3v> ruggles: hmm, good point.
[18:45:15] <kierank> hehe that mpeg-ts demuxer for flash remuxes the file into an flv in-memory
[18:45:25] <kierank> I thought it was a bit dubious
[18:45:48] <saintd3v> ruggles: if you're planning on using it, i was going to run some api changes by you (once i get back home). if not, i'll just do my own thing.
[18:48:11] <ruggles> saintd3v: it would be good to see what you have in mind
[18:51:12] <saintd3v> ruggles: ok, nothing big. just feedback from quantization for the state of the bitresevior (ac3 is pure cbr, isn't it?) and a way to pass frame-wide PE to quantization.
[18:52:08] <mru> there's nothing to stop you changing bit rate between frames in ac3
[18:52:15] <ruggles> the ac3 encoder is currently pure cbr, and that's pretty much all that is used in practice.
[18:52:16] <mru> don't know if that's allowed by the spec though
[18:52:18] <ruggles> but it can be vbr
[18:52:23] <ruggles> spec doesn't address it
[18:52:29] <ruggles> aften does vbr ac3
[18:52:31] <mru> then it's allowed
[18:52:49] <ruggles> i haven't gotten enough feedback to know what device support is like though
[18:53:18] <ruggles> which probably means nobody is using it or that it doesn't break anything
[18:53:52] <mru> I can imagine it breaking various spdif receivers
[18:54:29] <saintd3v> mru: that was my first thought, lol
[18:55:20] <mru> the receiver has to derive its clock from the signal, and I don't know how it would do that with vbr
[18:55:35] <ruggles> what does it do when the program changes?
[18:55:59] <ruggles> it would just be a program change every frame. :)
[18:55:59] <mru> resyncs to the new rate I guess
[18:56:12] <mru> but a frame is too short to sync properly
[18:56:17] <ruggles> yeah, probably so
[19:00:56] <kierank> mru: the spdif muxer can pad the frames out
[19:01:12] <mru> but then it's cbr
[19:01:28] <mru> and you'd be better off using those bits for actual audio instead
[19:05:19] <ruggles> saintd3v: it looks like the psymodel api can only report bit allocation per band, correct?
[19:14:29] <irock> therealgalen: yes, it works with 8-10 bits depth.
[19:15:21] <irock> what's left to do is basically clean up and some refactoring
[19:16:12] <irock> but it's usable as is right now
[19:20:45] <saintd3v> ruggles: currently yes.
[19:21:16] <saintd3v> which seems rather useless, imo.
[19:21:41] <ruggles> yeah. ac3 does bit allocation per bin based on the energy estimate for that bin and the masking threshold for the corresponding band.
[19:22:26] <ruggles> and the snr offset "quality" setting, which is adjusted to fit the cbr frame
[19:22:43] <therealgalen> irock: good, i'm trying to package it up into a useful player, but i'm sure i'm doing something stupid at the moment
[19:54:20] <irock> well, ask any question you like if it doesn't work for you
[19:54:31] <irock> therealgalen: ^
[19:55:07] <therealgalen> irock: i think ffplay is not building for stupid local reasons, missing a library or something
[19:55:27] <therealgalen> irock: i'm going to sort it out further but i have a few other things distracting me right now
[19:55:40] <irock> ok, :)
[20:08:26] <elenril> hmm, make fate fails on ./tests/data/vsynth1/flashsv.flv for me
[20:09:39] <Kovensky> it's fate
[20:09:56] <spaam> hohoh Kovensky was funny
[20:10:19] * Kovensky spams spaam away
[20:10:39] <spaam> instantrimshot.com
[21:08:19] * elenril pokes BBB 
[21:11:05] * mru hands elenril a pointy stick
[21:11:44] <elenril> mru: why does fate hate me?
[21:12:40] * elenril wonders if he should blame clang
[21:17:38] <mru> elenril: how does it hate you?
[21:21:16] <elenril> http://pastebin.com/RViQ5jyY
[21:22:15] <mru> it died during decoding
[21:22:23] <mru> look for a .err file with more details
[21:22:48] <mru> tests/data/vsynth1/flashsv.err or something
[21:25:20] <elenril> http://pastebin.com/jLUXtFYk weird
[21:26:28] <mru> the encoding step worked fine
[21:26:49] <mru> since the checksum there didn't change
[21:28:42] <mru> seems like something failing miserably reading the header
[21:28:56] <elenril> well that happens on master
[21:29:04] <mru> blame clang
[21:30:50] * mru updates his copy of clang
[21:30:54] * elenril tries gcc
[21:35:37] <elenril> still fails with gcc
[21:35:48] * mru blames elenril 
[21:36:52] * elenril wonders
[21:39:44] * elenril sleeps
[21:51:50] <ruggles> BBB: does wmavoice support stereo?
[22:55:56] <BBB> shit
[22:56:21] <BBB> clang-2.9 is definitely compiler bug, it's reproducible at -O2/3, not -O0/1
[22:56:25] <BBB> I wonder how to debug that
[22:56:49] <mru> a new one?
[22:57:12] <Yuvi> http://llvm.org/docs/HowToSubmitABug.html#miscompilations
[22:59:19] <BBB> Yuvi: that's a massive document
[22:59:31] <BBB> btw, Yuvi, weren't you buried in work at apple? is the iphone/ipad finished? :-p
[22:59:42] * BBB checks pre-order to see if it shipped
[23:00:28] <BBB> I wonder if they accept a bug if I tell them "ffmpeg version git-#@%&!$#(^&!#(%&!@% fails at make fate-vp8, but succeeds if compiling this one file at -O1, and this happens since this patch was applied"
[23:00:58] <mru> BBB: same old bug?
[23:01:28] <BBB> the clang-2.9 one failing vp8-fate since dark_shikari's patch
[23:02:05] <mru> that's the one I meant
[23:03:09] <BBB> yes that one
[23:03:20] <BBB> is there an existing bug report for it?
[23:03:42] <mru> are we sure it's not a bug in our code?
[23:05:20] <Kovensky> well, he did say it only happens on -O2 and -O3
[23:05:27] <Kovensky> -O1 / -O0 don't trigger it
[23:06:37] <mru> doesn't mean it's not our bug
[23:07:04] <iive> aliasing?
[23:08:00] <mru> or just about anything else
[23:08:49] <kierank> [22:59] BBB: btw, Yuvi, weren't you buried in work at apple? is the iphone/ipad finished? :-p --> should I ask a friend of mine who told me about it early last time?
[23:09:18] <mru> who cares about rotten fruit anyway?
[23:09:23] <mru> nothing personal, Yuvi
[23:09:24] <BBB> I love apple :)
[23:09:30] <kierank> mru: women
[23:12:55] <Yuvi> BBB: no comment on potential future hardware ;)
[23:13:03] <BBB> well d'uh
[23:13:08] <BBB> but good to have you back anyway :)
[23:17:07] <Yuvi> actually, is it clang only or does it happen with llvm-gcc too?
[23:17:50] <mru> llvm-gcc seems fine
[23:19:20] <superdump> lu_zero: ping?
[23:20:06] <Yuvi> it looks like the llvm-gcc configs on fate are r123173 and the clang 2.9 configs are r 125085 or newer
[23:20:32] <mru> updating
[23:20:40] <BBB> mru: thanks
[23:20:48] <BBB> I could compile with llvm-gcc on kostylev's machine also
[23:20:59] <BBB> locally I only have clang 1.5/2.8 and that works fine
[23:21:08] <mru> those are ancient
[23:21:24] <BBB> 2.9 isn't released yet
[23:21:30] <mru> they could have added an optimisation that exposes a bug in our code since then
[23:21:39] <BBB> probably
[23:21:48] <mru> released or not, there have been a lot of changes since 2.8
[23:22:03] <BBB> or they could have added a bug that specifically creeps up when compiling ffmpeg
[23:22:07] <BBB> wouldn't be the first time :-p
[23:22:31] <BBB> brb
[23:29:44] <mru> now I remember why llvm-gcc is stuck at an old version
[23:30:00] <mru> linker crashes building it
[23:56:31] <mru> anyone know a good gcc/binutils combination for building llvm-gcc?
[23:56:45] <mru> everything I've tried fails