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

[irc at mansr.com]

[00:00:19] <Compn> i heard people get dumber after being hired at google
[00:00:25] <Compn> its probably the good food and atmosphere
[00:01:31] <skal> ahm
[00:02:07] <iive> BBB: are you going to move to another city?
[00:02:10] <Dark_Shikari> everything about on2 staff can be summed up by "after nearly a year, plus 5-10 years of prior development, it's still 50% slower than ffvp8, which has less than a man-month invested in it."
[00:02:35] <Compn> skal probably knows :D
[00:02:57] <gnafu> Dark_Shikari: I'd say you play that up too much, but I can't.  You have every right to be proud about that and gloat :-D.
[00:03:01] <Compn> Dark_Shikari : thats not fair, the code ffvp8 uses has many man months invested in it
[00:03:17] <Compn> e.g. all the h264 and idct whatnot code
[00:03:17] <Dark_Shikari> you mean like... the h264 pred code copied from the spec?
[00:03:22] <Dark_Shikari> idct is new to ffvp8
[00:03:27] <Dark_Shikari> the h264 pred is trivial and takes 1 hour to write
[00:03:31] <Dark_Shikari> and half of it needed to be changed
[00:03:36] <Dark_Shikari> and for emulated edge, like most was rewritten
[00:03:49] <Compn> thats the only h264 shared code ?
[00:03:58] <Dark_Shikari> yes
[00:04:46] <Dark_Shikari> there's a bit of code imported from vp5/6, but that was mostly rewritten
[00:04:51] <Dark_Shikari> for speed optimizations
[00:05:08] <Compn> ah i thought it reused a lot more code
[00:05:24] <Compn> since the commit was < thousand lines
[00:05:30] <Compn> er < few thousand
[00:05:46] <Dark_Shikari> the asm was another few thousand
[00:05:56] <Dark_Shikari> but yes, it's a pretty small decoder.
[00:08:32] <Sean_McG> hey folks
[00:09:05] <gnafu> Sean_McG: Howdy!
[00:09:11] <Sean_McG> :)
[00:10:42] <BBB> Compn: vp8 isn't as elaborate as h264, you could compare it to h264 baseline in complexity. that's nice because it's much easier to write a full vp8 decoder, whereas our h264 decoder is massive and still doesn't implement everything
[00:11:15] <mru> vp8 could be a bit less bizarre in place though
[00:11:17] <BBB> it shares a little here and there, things like edge emulation, it will share edge extension when I implement it, h264 prediction, a few other minor things, but by and large it's new code
[00:11:19] <mru> *places
[00:11:29] <BBB> oh absolutely, some things are a little funky
[00:11:52] <mru> saturating in strange places, unusual rounding, etc
[00:12:07] <BBB> the edge default values for prediction are a little weird
[00:12:39] <BBB> "slices" (what was that called again?) is implemented in a funny way that isn't as easy to implement as h264 or vc1 slices
[00:12:46] <BBB> partitions, I believe
[00:13:26] <BBB> because partitions can depend on each other and aren't contiguous, but rather interleaved on a line-by-line basis
[00:13:47] <mru> what's the point in that?
[00:13:55] <BBB> you could use it for threading
[00:14:05] <BBB> but because they depend on each other it'll be much more complex than h264 slice threading
[00:14:05] <mru> you said they depend on each other
[00:14:08] <BBB> right
[00:14:17] <BBB> so you need pthread_cond_() stuff
[00:14:24] <mru> that's not all
[00:14:38] <mru> slices are typically used for some error resilience as well
[00:14:47] <mru> a damaged block doesn't ruin the entire picture
[00:14:56] <BBB> good point
[00:14:59] <BBB> I hadn't thought of that
[00:15:14] <mru> that's why they were invented in the first place
[00:49:34] * lu_zero wonders how intepolation/enhancement layers could work
[00:51:07] <lu_zero> (as in pick just the even pixels instead of doing slices)
[01:36:15] <mru> fate is compiling on haiku
[01:39:47] <saintdev> mru: would have been better if you had made a haiku out of it
[01:47:53] <mru> testing
[02:03:09] <saintdev> whoa! gentoo bugzilla has a new color theme
[02:18:26] <lu_zero> saintdev: bugzie4
[02:18:38] * lu_zero is __really__ thinking about it
[02:18:54] * lu_zero recently update 3.6 on lscube and it went _really_ smooth =P
[02:19:59] <saintdev> it looks, gasp, modern!
[02:54:06] <siretart> moroning
[03:46:39] <Sean_McG> o_O;
[04:31:59] <xxthink> I have ever downloaded a ffmpeg version: ffmpeg-r22950
[04:32:14] * Sean_McG claps
[04:32:17] <xxthink> How can I find the corresponding git version now?
[04:36:20] <pengvado> git log --grep='Originally committed as revision 22950'
[04:39:20] <xxthink> pengvado, Great!!!
[08:44:58] <Tjoppen> morrn
[08:45:05] <kshishkov> god morgon
[08:45:46] <thresh> moroning, fellow ffmpeg developers
[08:46:16] <kshishkov> moronings are for VLC, här har vi bara goda morgnar
[08:46:34] <thresh> har har something something reminds me of Jar Jar Binks
[08:47:03] * kshishkov has a special codec for that
[09:18:12] <pross-au> Bink Bink
[09:21:43] <kshishkov> indeed
[09:33:13] * KotH blinks
[09:33:36] <kshishkov> KotH KotH Blinks is our new hero?
[09:33:59] <pross-au> thats a cool name for a codec
[09:34:16] <pross-au> But we dont have five CCs, only four
[09:34:45] <kshishkov> BLNK then
[09:35:25] <saintdev> why do we need the 'L', just abbreviate it BINK....oh, erm wait..
[09:38:07] <kshishkov> saintdev: finish ffaacenc soon, ffbinkaudioenc awaits!
[09:38:48] <saintdev> not touching that with a 39.5' pole
[09:39:00] <kshishkov> which one?
[09:39:46] <saintd3v> the latter
[09:39:57] <kshishkov> there are two of them
[09:40:04] <kshishkov> RDFT and FFT-based
[09:41:35] <saintd3v> yeah, still not dealing with a bink audio encoder..
[09:42:25] <kshishkov> saintdev: AAC then?
[09:44:54] <pross-au> Urgh
[09:44:59] <saintd3v> guess it'll have to be..
[09:45:11] <pross-au> Waiting for 'Bink Mk II'
[09:45:11] <saintd3v> :p
[09:45:31] <kshishkov> pross-au: we had it supported long before Bink Mk I aka Bink-b
[09:46:44] <saintd3v> ghost might be interesting, once monty gets to work on it.
[09:46:55] <kshishkov> and aoyumi
[09:48:27] <saintd3v> you think he'll help out with ghost like he did vorbis?
[09:48:43] <kshishkov> I think otherwise it would be futile
[09:48:53] <Tjoppen> isn't celt close to being frozen?
[09:48:57] <KotH> kshishkov: aoyume?
[09:49:02] <Tjoppen> -> ffceltdec
[09:49:40] <pross-au> its frozen
[09:49:42] <saintd3v> KotH:  AoTuV Vorbis
[09:50:51] <KotH> ok, then it's aoyume :)
[09:52:17] <kshishkov> KotH: that should demonstrate again how far I am from psychoacoustics
[09:52:40] <KotH> kshishkov: it only demonstrates that you are far from japan :)
[09:52:58] <kshishkov> KotH: well, http://www.geocities.jp/aoyoume/aotuv/ says "(c)2003-2011 蒼弓／AOYUMI"
[09:54:26] <KotH> hmm.. ok...
[09:54:35] * KotH should read the whole page... not just the url
[10:37:49] <kierank> _av500_: http://news.ycombinator.com/item?id=2301439
[10:40:35] <av500> you troll my BFF
[10:40:40] <av500> outrageous!
[10:41:31] <kshishkov> av500: no, he didn't troll TI
[10:41:56] <av500> bah
[10:42:28] <kierank> av500: not a troll
[10:42:31] <kierank> a statement of fact
[10:44:00] <kierank> av500: wow your post of http://parliamentfights.wordpress.com/ is brilliant
[10:44:36] <av500> thats why so many ppl upvoted it
[10:58:16] <CIA-36> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rfb61a7c534 ffmpeg/libavformat/id3v2.c:
[10:58:16] <CIA-36> ffmpeg: id3v2: fix typo in error message
[10:58:16] <CIA-36> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:14:26] <mru> all hail kostylev, we have win64 on fate again
[12:14:48] <BBB> wbs: I thought you had push access?
[12:14:56] <BBB> mru: indeed, I noticed yesterday night, I'm so happy
[12:15:08] <BBB> finally I will know again when I break win64
[12:15:16] <BBB> I still miss ramiro though
[12:15:46] <mru> well, apparently he _likes_ being oppressed
[12:16:23] <spaam> Nice.. no red stuff :D
[12:17:32] <spaam> nice segfault on icc / ia64.
[12:17:49] <wbs> BBB: no, I don't
[12:38:11] <lu_zero> meanwhile I'm finishing prepping up minw32 cross autobuilds
[12:44:29] <spaam> lu_zero: Nice.. for ming64 also?
[12:45:55] <lu_zero> spaam: never tried mingw64
[12:46:48] <lu_zero> cross compiling for windows something that does not have autotools or proper build system is quite problematic
[12:47:52] <lu_zero> (ffmpeg is good, autotools are usually good, cmake does not, many homebrew not as well)
[12:48:23] <lu_zero> brb
[12:57:41] * mru curses haiku a little
[12:58:40] <kshishkov> too small OS?
[13:08:27] <mru> hah, cursing helped
[13:09:36] <kshishkov> because it's toy oS
[13:09:53] <kshishkov> people constantly curse in Russia but nothing improves there
[13:10:17] <mru> well, hopefully fate/haiku should be self-running now
[13:11:34] <kshishkov> any other OSes to consider?
[13:11:43] <kshishkov> like plan9
[13:12:14] <kshishkov> or RISC OS
[13:12:25] <mru> plan9 is too fucked up
[13:12:32] <mru> it can't talk to anything but plan9
[13:12:44] <spaam> but plan9 works
[13:12:48] <spaam> cool name..
[13:12:53] <mru> and it doesn't have a C compiler
[13:13:13] <kshishkov> depends on C value
[13:13:25] <mru> they removed the #if directive
[13:14:18] <av500> and #else?
[13:14:29] <mru> they have #ifdef, not #if
[13:14:52] <kshishkov> well, they say "greatly simplified preprocessor"
[13:14:54] <av500> #if considered harmful?
[13:15:17] <mru> and they have obsession with ugly guis
[13:15:21] <mru> +an
[13:15:27] <Zor> many people believe that the #if preprocessor directive is the root of all the evil pp forests
[13:15:31] <kshishkov> av500: too lazy to compute conditions in preprocessor I suspect
[13:15:42] <mru> no, they consider it unnecessary
[13:15:47] <mru> and therefore it must go
[13:15:48] <kshishkov> Zor: no, it's #define
[13:16:06] <Zor> kshishkov: #define is not bad if you can only #ifdef
[13:16:10] <Zor> in that mindset anyway
[13:16:12] <mru> it's not hard at all to write bad code without #if
[13:16:15] <mru> witness java
[13:17:24] <kshishkov> mru: it's easy to write bad code in any language
[13:17:34] <mru> exactly
[13:17:49] <mru> so removing features in an attempt to make it harder is misguided
[13:19:50] <kshishkov> BCPL?
[13:21:05] * av500 forces kshishkov to write bink encoder in CICS
[13:22:09] <kshishkov> av500: after xvp8
[13:34:12] <kierank> silly fruit company
[13:34:14] <kierank> not fixing its bugs
[13:38:35] <kshishkov> do they acknowledge them at all?
[13:39:09] <mru> kshishkov: they are infallible
[13:39:17] <mru> they are the very definition of perfection
[13:40:14] <kshishkov> indeed!
[13:40:31] <av500> you are just holding it wrong
[13:40:32] * kshishkov still doesn't go to buy their products
[13:46:08] <mru> mmu_man: is there an ntp client for haiku?
[13:49:42] <mmu_man> mru: don't think so
[13:50:01] <mru> what kind of a joke os is this?
[13:50:17] <kshishkov> mru: joke os
[13:50:47] <mmu_man> http://ports.haiku-files.org/wiki/net-misc/ntp
[13:51:05] <mmu_man> you can send a patch
[13:51:16] * kshishkov thinks Haiku is intended for pleasing all three of its developers by the fact it exists, nothing else
[13:53:30] * mmu_man thinks kshishkov should just send patches instead of complaining
[13:53:45] <mru> mmu_man: not complaining, mocking
[13:53:50] <mru> there's a difference
[13:54:00] <mru> diff -u haiku linux | sendmail mmu_man
[13:55:20] <kshishkov> mmu_man: why should I complain? I don't use it and not sure if I've ever touched it
[13:56:31] <mmu_man> mru: you'll be over quota
[13:57:08] <kshishkov> yes, send shell script for replacing Haiku with stage3 instead
[14:13:30] <mru> ruggles: ping
[15:21:44] <Ayad123> i need begin to configure the ffmpeg, i need have the best option or synthaxe to convert and optimize a best quality of my video avi to swf or flv
[15:22:46] <av500> -> #ffmpeg
[15:30:57] <lu_zero> could be interesting having haiku using pkgcore or portage
[15:31:34] <mru> shouldn't be too hard to put gentoo prefix on it
[15:31:41] <lu_zero> mru: sure
[15:31:54] <kshishkov> just replace it completely with Gentoo
[15:31:57] <lu_zero> but they could use pkgcore and leverage what we provide
[15:32:23] * lu_zero usually offer that to every os starting to think about package management
[15:32:32] <lu_zero> sad minix preferred pkgsrc
[15:32:42] <mru> they'd be better off porting the gui and filesystem to linux
[15:32:48] <lu_zero> and haiku decided to make a workalike
[15:32:58] <lu_zero> mru: I prefer having variety
[15:33:26] <lu_zero> linux can be wrong, freebsd can be wrong, having both wrong at the same time is less likely ^^;
[15:33:50] <mru> the only variety you get with these fringe OSes is different levels of non-support for mainstream modern hardware
[15:34:12] <mru> they lack the manpower to write drivers for every device that comes out
[15:34:37] <mru> better to put it on top of a kernel that does all that for you and focus on what makes it different
[15:35:52] <kshishkov> lu_zero: minix is sad indeed
[15:36:04] <mru> minix can't do that for obvious reaons
[15:36:17] <mru> having a different kernel being the entire point of their existence
[15:36:54] <kshishkov> well, that's the point
[15:37:02] <kshishkov> every OS should have some goal
[15:37:24] <kshishkov> for Minix it's to demonstrate The Holiest Microkernel Architecture
[15:37:24] <ubitux> i don't know if roundup maintainers have been noticed by it, but i was unable to register with a message telling maintainers will get noticed
[15:37:31] <ubitux> can anyone confirm it?
[15:37:45] <kshishkov> for Haiku - to provide more shiny and useless OS than MacOS X
[15:37:48] <mru> a minix-like architecture might be good for building highly reliable systems
[15:38:04] <mru> for 99% of cases performance is more imporant though
[15:38:44] <mru> engineering is all about making tradeoffs
[15:38:50] * av500 wishes he could reboot the linux usb subsystem only
[15:39:09] <mru> all these fringe systems tend to take at least one of these tradeoffs to the very extreme in one direction or other
[15:39:19] <mru> av500: modprobe -r usb?
[15:39:36] <mru> av500: don't do it with a usb keyboard
[15:40:17] <mru> in a modular linux kernel, many subsystems can be restarted like this
[15:40:47] <av500> modules in "strange" states often refuse to unload
[15:40:52] <mru> if any core data structures have been corrupted you're stuffed of course
[15:40:59] <mru> av500: modprobe -rf
[15:41:12] <mru> the -rf flag works with many commands...
[15:41:28] <av500> mru: I know all that
[15:41:38] <av500> still I had cases where it did nothing
[15:41:47] <mru> yes, I've had those too
[15:42:05] <mru> and sometimes the hardware itself gets into a nasty state and needs a power cycle to reset properly
[15:42:15] <av500> so it would be nice to be able to tell linux: forget that subsystem and make a new one :)
[15:43:18] <kshishkov> mru: I believe Minix would encourage Windows approach to drivers, i.e. "crash at your heart desire"
[15:43:56] <av500> kshishkov: sadly the other option fails as well
[15:44:04] <av500> "this driver is bugfree"
[15:44:06] <av500> lol
[15:44:25] <kshishkov> but it's more appealing to me
[16:15:49] <BBB> astrange: ping
[16:19:16] <spaam> http://who-t.blogspot.com/2011/03/how-to-dos-developer.html
[16:19:28] <mru> old
[16:19:55] <spaam> mru: good
[17:25:10] <ruggles> mru: pong
[17:26:25] <mru> ruggles: I'm optimising ac3 for arm
[17:26:33] <mru> and I'm seeing simd potential everywhere
[17:27:15] <ruggles> yes, there is a lot of potential.
[17:27:46] <ruggles> i would certainly be interested in where you see it though
[17:28:24] <mru> well, the float scale_coefficients() would be an obvious one
[17:28:37] <mru> neon has an instruction for that
[17:28:50] <ruggles> yeah, i have that written already
[17:28:54] <mru> cool
[17:29:06] <ruggles> just need to submit it. it's kinda ugly due to the float param, but it works
[17:29:14] <mru> float params?
[17:29:22] <ruggles> the scalar
[17:29:27] <mru> scalar?
[17:29:33] <mru> I see a 24
[17:30:02] <mru> that needs to be a constant for neon
[17:30:03] <ruggles> oh, i wanted to make it more generic.
[17:30:11] <ruggles> for use with format conversion as well
[17:30:18] <mru> the float to fixed takes only an immediate for the fractional bits
[17:31:33] <ruggles> maybe a generic float scale factor is not needed then.
[17:31:50] <mru> not if you want twice the speed
[17:33:09] <ruggles> i don't think x86 has that though. we would have to scale the float to the proper range first.
[17:33:31] <ruggles> but still the function could take an int
[17:33:33] <mru> if you don't have that instruction you obviously have to do it the hard way
[17:34:50] <mru> got any more unsent patches?
[17:35:09] <mru> and don't bother doing neon stuff, I'm paid to do that
[17:35:24] <ruggles> no other asm
[17:36:24] <mru> that loop we were talking about yesterday could be simded I think
[17:36:49] <ruggles> yeah, i tried once and it was slower, but i was thinking about trying again
[17:36:59] <mru> and apply_rematrixing()
[17:37:06] <ruggles> yeah, i tried that too
[17:37:23] <ruggles> 1) none of the bands are on a 16-byte boundary
[17:37:30] <BBB> mru: why don't you mentor a soc project?
[17:37:46] <mru> BBB: I get 10x more money doing it myself
[17:38:04] <ruggles> 2) the first 3 bands are only 12 coefficients wide
[17:38:05] <BBB> you get a person doing it for you, and you can earn money doing something else in the mean time
[17:38:27] <mru> I'll probably be mentoring for beagleboard again
[17:38:30] <ruggles> but doing the whole thing in asm might be better.
[17:38:50] <mru> apply_rematrixing should be easy to do in pure asm
[17:40:21] <ruggles> i'm trying to focus on getting my feature patches done right now, but i'm keeping a list of where i think asm optimization will help.
[17:52:04] * iive mark
[18:06:00] <jb_holidays> hello
[18:06:18] <jb_holidays> av500: kshishkov: at CeBIT, people have asked for Bink support :D
[18:06:57] <mru> jb_holidays: you didn't recognise av500 in his disguise?
[18:08:28] <jb_holidays> I didn't !
[18:09:34] <ruggles> mru: what other good optimization opportunities do you see for ac3enc?
[18:09:45] <mru> I see loops everywhere
[18:09:59] <mru> need to figure out which ones are taking time
[18:11:28] <mru> now in ac3_exponent_min(), what are the rules for nb_coefs?
[18:14:12] <ruggles> i'll double-check. it was multiple of 16, but then i changed something in the loop so it doesn't have to be. but i forget what the exact behavior is.
[18:14:40] <ruggles> unfortunately, that will have to change anyway for channel coupling
[18:14:57] <mru> what will have to change?
[18:15:48] <ruggles> my current patch always calls it with nb_coefs=256 for simplicity, but i might have to just special-case the coupling channel.
[18:16:12] <ruggles> because it doesn't start on 16-byte boundary
[18:16:32] <mru> non-aligned is easy enough to handle
[18:16:44] <mru> not multiple of 16 is worse
[18:18:38] <ruggles> well, it only operates on multiples of 8 or 16. and rounds up due to how it is implemented.
[18:18:48] <ruggles> that probably needs to be documented
[18:18:49] <jb_holidays> michaelni: ping
[18:20:44] <mru> ruggles: there's a bug somewhere
[18:20:53] <michaelni> pong
[18:20:55] <mru> it's not giving the same result as the C version
[18:21:07] <michaelni> jb_holidays, pong
[18:21:24] <ruggles> really? it passes regression testing.
[18:21:49] <mru> maybe that's just luck
[18:22:41] <ruggles> and the result would not decode if it didn't work properly.
[18:24:43] <mru> well, I'm seeing nb_coefs=223 here
[18:24:53] <ruggles> yes, that's correct
[18:25:01] <mru> that's not a multiple of 16
[18:26:14] <ruggles> right
[18:26:58] <mru> so the simd functions write more than they should
[18:27:01] <mru> and the output differs
[18:27:33] <ruggles> it's ok for it to write more than it should
[18:27:47] <mru> the encoded output differs
[18:28:12] <mru> so either md5 is wrong or you're wrong
[18:28:14] <ruggles> ah, that would be the exponent grouping.
[18:28:39] <ruggles> i can fix that. the extra exponents are not decoded, but they are encoded.
[18:29:41] <ruggles> exponents are encoded in groups of 3, 6, or 12 so sometimes more are encoded than are actually used
[18:32:56] <mru> so how do we fix it?
[18:33:13] <ruggles> several ways...
[18:33:53] <ruggles> 1) require multiple of 16 for nb_coefs
[18:34:31] <ruggles> 2) handle it in group_exponents()
[18:34:48] <ruggles> 3) handle it in encode_exponents_blk_ch()
[18:35:26] <mru> 4) require the simd functions to handle a non-multiple of 16
[18:42:52] <ruggles> 5) pass nb_coefs+3
[18:47:28] <spaam> ???
[18:47:35] <spaam> PPROFIT
[18:49:18] <ruggles> mru: i can't reproduce the differing md5 even with a big file... which x86 version of the function are you using?
[18:54:54] <ruggles> maybe it's just luck. it's probably a rare case.
[18:59:54] <ruggles> mru: could you check if passing nb_coefs+3 fixes your sample?
[19:05:39] <mru> ruggles: all the x86 functions give the same differing output here
[19:06:32] <ruggles> what about nb_coefs+3?
[19:07:44] <jermy> ugh. I'm not having as much fun as I'd hoped with the smoothstream decoder.
[19:08:23] <kshishkov> try RealMedia
[19:08:55] <BBB> astrange: ping
[19:09:18] <kshishkov> BBB: use ping-mt
[19:09:27] <BBB> might have race conditions
[19:09:39] <jermy> I've got a parser for the metadat files, but having a demuxer in the same style as applehttp is doomed since the chunks don't decode properly
[19:09:46] <lu_zero> jermy: smoothstream -> ms-segmented-asf?
[19:10:03] <lu_zero> jermy: use the protocol approach
[19:10:09] <jermy> nah. Segments of mp4
[19:10:09] <mru> ruggles: different again
[19:10:16] <lu_zero> of mp4?
[19:10:16] <mru> why would +3 fix anything?
[19:11:03] <lu_zero> segments of mp4....
[19:11:08] <jermy> and the audio  is seperate, so it probably needs a demuxer to sync, no?
[19:11:17] <lu_zero> so you must use the demuxer approach
[19:11:18] <ruggles> mru: because it would ensure that at least that many exponents are processed. and none after that will be used.
[19:11:43] <jermy> yeah. little packets with a moof header and a mdat
[19:12:06] <mru> well, the c and simd versions still differ
[19:12:47] <jermy> I'm just wondering at what point do I copy some bits of the mov demuxer and create my own codec context
[19:13:46] <ruggles> mru: the encoded output differs even with nb_coefs+3?
[19:13:51] <mru> yes
[19:14:33] <ruggles> ah. i just thought of another thing...
[19:14:40] <ruggles> an issue i came across during channel coupling
[19:15:08] <ruggles> exponent strategy decision does sum of all 256 exponents
[19:15:55] <ruggles> so rare cases it could be putting it above or below the threshold
[19:17:11] <mru> and I just had to choose a sample where it did
[19:18:03] <ruggles> part of my coupling patch changes the exponent strategy decision to work for any number of coefficients.
[19:18:34] <ruggles> but that should be fixed ASAP
[19:33:22] <vcs> where can i find documentation on the int64 timestamp used in *_read_seek functions? Is it some predefined format?
[19:34:45] * mru attempts to complete the census form
[19:35:03] <kierank> not meant to do it yet mru
[19:35:17] <mru> only opened it now
[19:35:31] <kierank> do it online
[19:35:37] <kierank> you're meant to do it on the 12th iirc
[19:35:42] <mru> 27th
[19:35:46] <mru> but most of it won't change
[19:35:58] <kshishkov> name - mru, nationality - troll, occupation - see above
[19:36:16] <mru> it's not like my age or place of birth will change before the end of the month
[19:39:50] <kierank> still should sent it electronically, way more efficient
[19:39:56] <mru> of course
[19:40:37] <mru> the website doesn't require all at once
[19:40:52] * kierank has been waiting on the oyster card helpline for 30 mins now
[19:41:52] <kshishkov> kierank: isn't British service known to be relaxed?
[19:42:07] <kierank> dunno
[19:43:12] <ruggles> kierank: how is dolby e decoding coming along?
[19:43:43] <kshishkov> it's for gsoc 2011
[19:48:02] <BBB> vcs: what do you mean?
[19:48:13] <BBB> vcs: it's a time units as set in AVStream->time_base
[19:48:47] <BBB> vcs: so if time_base is num=1,den=1000000, then it's in microseconds, if time_base is num=1,den=44100, then it's an audio sample counter, etc.
[19:49:20] <BBB> vcs: and so on for whatever is your favourite way to handle timestamps, it's supposed to maintain timestamp accuracy regardless of source timebase
[19:49:30] * mru sets timebase to 1 aeon
[19:49:36] <vcs> ahh so its dependant on that
[19:50:24] <kierank> lol BBB too many people editing the wiki
[19:53:37] * kierank wonders what happens if you send the census paperwork as well as filling it out online
[19:54:24] <mru> they compare them, and if different come and take you away
[19:55:33] * kierank won't mind being shipped to australia
[19:56:22] <kshishkov> shackled?
[19:56:35] <mru> kierank: http://www.youtube.com/watch?v=hnzHtm1jhL4
[20:02:22] <mru> ruggles: I'm getting 4% cycles in memcpy
[20:02:27] <mru> I find that disturbing
[20:03:48] <ruggles> mru: what about deinterleave_input_samples()?
[20:04:16] <mru> I think I need to turn off some inlining to get sensible numbers
[20:05:16] <ruggles> the others can probably be addressed with some restructuring, but that memcpy() is necessary
[20:06:02] <mru> I guess
[20:06:27] <mru> unless running on a dsp with modulo addressing
[20:06:31] <mru> neat stuff, that
[20:09:16] <ruggles> mru: one of the things on my list to try is having a reference block for exp and bap rather than copying them.
[20:15:29] <mru> ffs, I can't make this damn thing not inline everythign
[20:19:34] <mru> what is it with gcc and function names?  apply_window.clone.4.clone.14
[20:27:09] <mru> that one can be simded
[20:28:36] <BBB> kierank: not seeing it (?)
[20:28:54] <kierank> works now
[20:29:10] <kierank> for a while the database had an error
[21:13:16] <kierank> mru: http://users.softlab.ece.ntua.gr/~ttsiod/cpp.html
[21:13:19] <kierank> </troll>
[21:14:33] <mru> aaaauuuuggh, WHY do some people prefix all struct names with 'tag'?
[21:14:37] <mmu_man> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2011
[21:14:43] <mmu_man> "This Account Has Been Suspended"
[21:14:48] <mmu_man> !?
[21:15:02] <gnafu> kierank: "to say something in less words, means that you are wise about it"
[21:15:04] <mmu_man> mru: cause M$ said so
[21:15:07] <gnafu> That's a lesson I need to learn :-P.
[21:15:22] <BBB> mru: because it's short and awesome
[21:15:54] <mru> I've even seen it _mandated_ by corporate coding standards
[21:16:06] <superdump> perhaps that happened because mike started mirroring the samples archive
[21:16:12] <gnafu> mmu_man: Ooh, looks like someone's been hitting the samples mirror a bit too hard.
[21:16:18] <mru> here's the funny part, I ignore said coding standards and nobody noticed
[21:16:20] <superdump> and someone found it objectionable / it used too much bandwidth
[21:16:46] <gnafu> Does anyone know what hosting provider he uses?
[21:17:02] <mru> a crappy one
[21:17:06] <mru> by the looks of it
[21:17:53] <BBB> I emailed mike
[21:17:55] <BBB> he'll fix it
[21:18:55] <gnafu> BBB: Give it to Mike(y).  He'll [fix] anything!
[21:20:16] <mru> kierank: some ideas in c++ are good, templates perhaps being one of them if used in moderation
[21:20:27] <mru> but the syntax is disgustingly ugly
[21:20:52] <mru> and typical c++ coders tend to write more code than average c programmers to solve the same problem
[21:21:21] <mru> I guess I dislike how it is used at least as much as the language itself
[21:23:49] <Flameeyes> mru: I actually like C# better than C++ :|
[21:24:04] <mru> never used it so I can't say
[21:24:07] <Dark_Shikari> A<B>>
[21:24:55] <Flameeyes> mru: it has most of the concepts of C++, but reduced syntax complexity, and a saner standard library
[21:25:26] <elenril> and it's inherently evil by virtue of its creator =p
[21:25:42] <mru> microsoft have done a few good things
[21:26:25] <DonDiego> greetz from tel aviv
[21:26:34] <Flameeyes> hi DonDiego
[21:26:39] <Dark_Shikari> C# is actually rather less awful than java
[21:26:48] <DonDiego> and don't ask me about anything ffmpeg-related, my email is bust :)
[21:27:13] <elenril> less awful than java << that carries no information
[21:27:25] <Flameeyes> elenril: C++ is more awful than java
[21:27:37] <elenril> is it?
[21:27:38] <mru> depends
[21:27:42] <elenril> you can use it like C
[21:27:49] <elenril> then it's certainly less awful than java
[21:27:49] <mru> in c++ you're not forced to do all that crap
[21:27:53] <mru> people just do it anyway
[21:28:04] <Flameeyes> elenril: C++ used as stroustrup and company wants it to be done is much more awful than java
[21:28:11] <mru> oh, for sure
[21:29:28] <Dark_Shikari> BBB: ugh
[21:29:29] <Dark_Shikari> in vp8.c
[21:29:30] <Dark_Shikari> if (!nnz4) break;
[21:29:35] <Dark_Shikari> we're only breaking out of the inner loop.
[21:29:37] <Dark_Shikari> oooops.
[21:29:44] <Dark_Shikari> I want a break statement that breaks out of two loops.
[21:30:10] <elenril> goto!
[21:30:12] <Flameeyes> Dark_Shikari: that's called goto
[21:30:15] <Dark_Shikari> I know
[21:30:23] <Dark_Shikari> But then I have to start making labels
[21:30:24] <Dark_Shikari> end1
[21:30:26] <Dark_Shikari> end2
[21:30:27] <Dark_Shikari> end3
[21:30:31] <Dark_Shikari> because labels aren't scoped.
[21:30:50] <Flameeyes> after_$action
[21:30:55] <Flameeyes> or done_$action
[21:31:08] <Dark_Shikari> after_for
[21:31:10] <Dark_Shikari> after_for1
[21:31:12] <Dark_Shikari> after_for
[21:31:14] <Dark_Shikari> *after_for2
[21:31:20] <Flameeyes> the for is doing something isn't it?
[21:31:22] <Dark_Shikari> true
[21:31:54] <Flameeyes> done_parsing, done_checking, found_maximum ...
[21:40:12] <Dark_Shikari> another problem
[21:40:14] <Dark_Shikari> libavcodec/vp8.c:1293: error: label at end of compound statement
[21:40:19] <Dark_Shikari> you can't put a label at the end of a {} block
[21:41:43] <mru> put a ; after
[21:42:06] <Dark_Shikari> chroma_idct_end: ; makes me want to stab myself
[21:42:17] <mru> then stab yourself and write it
[21:43:32] <Flameeyes> I usually add it _after_ the {} block
[21:43:57] <Dark_Shikari> the structure is:
[21:43:58] <mru> that doesn't work if the block is a loop
[21:44:21] <Dark_Shikari> for0 { if1 { if2 { for3 { for4{ stuff } } } } }
[21:44:28] <Dark_Shikari> we need to break out of "stuff" and go to the next iteration of "for0"
[21:44:28] <mru> if you have triple-nested loops and want to break from the innermost and continue the outer, that's the sane way
[21:44:49] <Flameeyes> mru: right sorry I didn't consider that
[22:20:22] <kierank> http://www.cnx-software.com/2011/03/09/video-wall-with-beagleboards-and-ffmpeg/
[22:24:24] <roxfan> oh i saw that one at fosdem
[22:24:49] <Compn> i think mru owns one of those
[22:25:17] <mru> av500 owns the displays of the mark 1 aka "the beast"
[22:25:24] <kierank> mru is mentioned in the video
[22:28:05] <Shu> the age limit on GSoC is still bugging me ;-;
[22:28:28] <mru> paying minors is always a hassle
[22:28:40] <Shu> by the time i get paid it's okay
[22:28:41] <kierank> Shu: did you get your t-shirt
[22:28:42] <Shu> just not at the start
[22:28:46] <Shu> i did lol
[22:28:52] <kierank> got mine today in a massive box
[22:29:00] <mru> or should I say minors are such a hassle...
[22:29:13] <Shu> kierank: mine was XXL <_<
[22:29:19] <Shu> kierank: forgot to say what size
[22:29:19] <kierank> mine was too small
[22:29:31] <kierank> should have chosen medium
[22:29:39] <Shu> did you get small?
[22:29:46] <kierank> yup
[22:30:09] * kierank thought it was going to be american small
[22:30:12] <Shu> i shoulda gotten small
[22:30:40] <kierank> Shu: you could come up with an "arrangement" with someone for gsoc
[22:30:43] <mru> kierank: I made the same mistake with gsoc last year
[22:30:45] <kierank> if you catch my drift
[22:31:06] <Shu> i do have a job this summer
[22:35:08] <Shu> oh, one of the projects is optimzing h264.
[22:54:43] <kierank> I wonder if kshishkov will be interested in reverse engineering Harmonic RTP
[23:03:06] <Flameeyes> Harmonic RTP?
[23:03:33] <kierank> yes they seem to have made their own proprietary implementation
[23:04:02] <Flameeyes> used where?
[23:04:13] <kierank> in harmonic products
[23:05:04] <kierank> and also i need to write/find a way of making ffmpeg just open a udp port and accept udp/rtp data
[23:05:07] * Flameeyes doesn't know harmonic
[23:05:24] <kierank> big broadcast company
[23:05:43] <mru> from what little I've seen, they seem as annoying as any other such company
[23:07:23] <Flameeyes> kierank: uhm based off where? /me really never heard of it and wikipedia doesn't help
[23:07:32] <kierank> USA
[23:07:51] <Flameeyes> that explains it
[23:08:39] <kierank> there seems to be a dll with the protocol in it
[23:08:44] <kierank> and some documentation of the api
[23:21:12] * lu_zero is pondering to write a small subset of rtp/rtsp in javascript...
[23:21:19] * lu_zero should go back to sleep
[23:28:09] <Sean_McG> o_O;
[23:30:06] <lu_zero> Sean_McG: consider it an inside joke
[23:30:11] <Sean_McG> will do
[23:30:14] <Sean_McG> ;)
[23:30:30] <lu_zero> even if it's feasible and shouldn't be _that_ bad
[23:31:11] <lu_zero> (given you hardcode mkv headers)