[FFmpeg-devel-irc] IRC log for 2010-06-24

[irc at mansr.com]

[00:44:54] <Dark_Shikari> someone was poking at me the other day that rgb48 didn't seem to work right
[00:45:04] <Dark_Shikari> I glanced at the code, and, uh.........
[00:45:05] <Dark_Shikari> #define PUTRGB48(dst,src,i)             \ Y = src[2*i];                       \ dst[12*i+ 0] = dst[12*i+ 1] = r[Y]; \
[00:45:10] <Dark_Shikari>     dst[12*i+ 2] = dst[12*i+ 3] = g[Y]; \
[00:45:11] <Dark_Shikari>     dst[12*i+ 4] = dst[12*i+ 5] = b[Y]; \
[00:45:15] <Dark_Shikari> I don't think that's quite what RGB48 means?
[00:45:42] <mru> lol
[00:45:55] <mru> who did that?
[00:45:59] <Dark_Shikari> I don't know.
[00:46:08] <mru> git knows
[00:46:10] <Dark_Shikari> But whatever it is, it's fucking funny
[00:46:33] <Dark_Shikari> Kostya.
[00:46:39] <Dark_Shikari> kshishkov: HAHAHAHAHA
[00:47:29] <mru> it's remarkable that software doesn't fail more often than it does
[00:48:04] <mru> everywhere you look, there's a buffer overflow or some other stupid bug
[00:49:37] <mru> looking at a buffer overread in svq1 now
[00:49:52] <mru> unterminated string
[00:50:00] <Kovensky> so he just doubled every byte on rgb24? lol
[00:50:02] <kierank> someone should invent a name for a bug that should completely destroy everything but somehow doesn't
[00:50:26] <mru> miracle?
[00:50:31] <kierank> miraclebug
[00:50:52] <mru> not as funny as heisenbug
[00:51:03] <Dark_Shikari> nobody used yuv -> rgb48
[00:51:04] <Dark_Shikari> so nobody ever saw it
[01:59:48] <kierank> lol michael
[02:00:35] <kierank> "The future is in perpetual motion, iam not capable to say anything
[02:00:35] <kierank> with certainity but i feel some remote danger.
[02:00:36] <kierank> "
[02:00:44] <kierank> etc
[02:03:14] <beandog> heh
[02:03:15] <beandog> just saw that
[02:03:16] <beandog> :)
[02:03:53] <roxfan> kierank: shroedingbug is somewhat close
[02:37:50] <Compn> oh wow
[02:37:52] <Compn> new mn quote
[02:38:24] <Compn> Re: [FFmpeg-devel] [PATCH 03/12] mdct: remove temporary array in ff_kbd_window_init()
[04:44:51] <kshishkov> DarKk_Shikari: I just committed it, not invented. Feel free to improve
[04:54:25] <Dark_Shikari> kshishkov: "improve"?
[04:54:27] <Dark_Shikari> it's completely wrong
[04:54:36] <Dark_Shikari> it doesn't even do what it says it does
[04:54:43] <Dark_Shikari> if you didn't write it, harass the person who did
[04:54:47] <Dark_Shikari> or at least tell mru so he can
[05:47:51] <CIA-99> ffmpeg: siretart * r23747 /branches/ (0.6 0.6/libavcodec/aacsbr.c):
[05:47:51] <CIA-99> ffmpeg: 10l: aacsbr: Fix f_master[2] calculation when k2diff == -1.
[05:47:51] <CIA-99> ffmpeg: backport r23660 by alexc
[05:53:41] <KotH> moin
[05:54:03] <av500> grüezi
[05:59:20] <thresh> woah, someone paid a lot of money to start a new wave of fighting-with-criminal-militia in Russia, http://russian-untouchables.com/eng/
[06:00:27] <thresh> this will surely end up with no results, but still..
[06:47:32] <wbs> superdump: does the latest patch in the libvorbis >2 channels thread look ok?
[06:51:15] <superdump> responded
[06:51:45] <superdump> and to answer your next question - if there is no maintainer in the maintainers file, it's michael
[06:52:04] <wbs> I think yuvi agreed to be maintainer for it
[06:52:19] <wbs> but he seems to be unavailable at the moment
[06:54:31] <CIA-99> ffmpeg: mstorsjo * r23748 /trunk/configure:
[06:54:31] <CIA-99> ffmpeg: Fix dependencies for the ra_144 encoder
[06:54:31] <CIA-99> ffmpeg: Patch by Francesco Lavra, francescolavra at interfree dot it
[06:56:45] <CIA-99> ffmpeg: mstorsjo * r23749 /trunk/libavformat/smacker.c:
[06:56:45] <CIA-99> ffmpeg: Correctly return EOF for smacker videos
[06:56:45] <CIA-99> ffmpeg: Patch by Alexei Svitkine, alexei dot svitkine at gmail
[07:36:02] <Tjoppen> ooh.. reordered_opaque. too bad it isn't used when encoding
[07:36:39] <astrange> coded_frame->pts or something
[07:36:53] <Tjoppen> yes, but that doesn't "survive"
[07:37:26] <Tjoppen> as in, that's not what comes out of coded_frame->pts when you get a packet (you get reordered synthetic PTSes)
[07:44:02] <Tjoppen> I'm also a bit unsure whether demuxed packets are supposed to be able to have dts == AV_NOPTS_VALUE
[07:45:14] <Tjoppen> oh, in AVPacket it says it can be that. nm
[07:45:37] <CIA-99> ffmpeg: vitor * r23750 /trunk/libavcodec/ (4 files in 2 dirs): SSE-optimized MP3 floating point windowing functions
[08:04:23] <mru> morning
[08:07:57] <Tjoppen> morrn
[08:08:05] <Tjoppen> fika \o/
[08:09:16] <av500> mru: os/2 is coming back: http://searchdatacenter.techtarget.com/news/article/0,289142,sid80_gci1508584,00.html
[08:12:36] <spaam> Tjoppen: o/
[08:12:54] <mru> gaaaah, they talk about corba
[08:12:57] <KotH> av500: rotfl
[08:13:05] <KotH> av500: ibm doesnt own os/2 anymore
[08:13:19] <KotH> av500: they sold everything a few years ago
[08:13:34] <mru> ecomstation
[08:13:40] <spaam> KotH: you bought it ?
[08:14:15] <KotH> spaam: see mru's acausal reply to your question
[08:14:41] <spaam> KotH: :)
[08:15:26] <kshishkov> wasn't OS/2 partially owned by M$ which prevented IBM doing some thing with it?
[08:16:19] <mru> no iirc
[08:16:34] * kshishkov is happy with the though though that if OS/2 rises from the dead there will be FFmpeg on it
[08:16:41] <kshishkov> *thought
[08:17:45] <mru> ms may have owned some bits for windows compat
[08:18:27] <kshishkov> they designed it in collaboration too
[08:18:36] <mru> and they had a bizarre deal that somehow prevented os/2 from being deployed widely before it was too late
[08:18:40] <kshishkov> though OS/2 turned out to be more stable
[08:19:02] <mru> os/2 isn't bad as such
[08:19:18] <mru> apart from a terrible user interface an absense of apps
[08:20:12] * kshishkov heard it performed quite well in ATMs
[08:21:10] <mru> yes, those problems don't matter there
[08:21:17] <mru> they put their on ui on it anyway
[08:21:22] <mru> and they only need one app
[08:22:28] <av500> mru: os/2 main problem was that it needed 8MB which at that time meant like $1000
[08:22:42] <av500> whereas win3.11 ran fine on 2-4
[08:22:56] <mru> and that it never quite seemed to be ready
[08:24:37] * kshishkov looks forward for FFmpeg 1.0
[08:25:10] <mru> I think that's comparable to the speed of light
[08:25:18] <mru> impossible to achieve
[08:26:48] <roxfan> you can get infinitely close to it but your mass will get inifinitely high :/
[08:27:30] <CIA-99> ffmpeg: mru * r23751 /trunk/libavcodec/alac.c: alac: change VLAs to fixed size
[08:28:51] * kshishkov waits for FFmpeg 0.9999999999999 then
[08:36:26] <Vitor1001> mru: why?
[08:36:55] <Vitor1001> It uses 5 regular registers and the mmx ones...
[08:37:10] <mru> they're in/out
[08:37:13] <mru> count as two
[08:37:18] <mru> look at fate
[08:38:22] <Vitor1001> hmm, I'm a noob in asm, so can I make them read-only?
[08:38:37] <Vitor1001> I modify the buffers but not the pointers
[08:38:40] <mru> let me have a look
[08:38:48] <Vitor1001> ok, thanks
[08:39:28] <mru> I didn't read the asm
[08:39:44] <mru> x86 asm gives me rashes
[08:40:09] <Vitor1001> This one shouldn't. There are no hacks to workaround missing instructions.
[08:40:09] <mru> anyway, I see what you mean
[08:40:28] <mru> change all the operands to "r"(foo)
[08:40:34] <mru> and add a :
[08:40:41] <mru> so :: "r"(win1a), ...
[08:40:52] <Vitor1001> ok. I don't know why, but gcc asm constraints looks black-magic to me :p
[08:41:00] <mru> they actually make sense
[08:41:07] <mru> when you know where they come from
[08:41:32] <mru> it's the same syntax used in the machine description files
[08:42:00] <Vitor1001> ugh, count is modified.
[08:42:01] <mru> the asm block is simply dropped into the rtl tree as a fancy instruction
[08:42:11] <Vitor1001> So I have to invert the registers numbers, no?
[08:42:20] <mru> yep
[08:42:33] <mru> this is why many of us prefer to write pure asm
[08:45:03] <Vitor1001> mru: This would work? http://ffmpeg.pastebin.org/356016
[08:45:42] <Vitor1001> I mean, in my box it works fine...
[08:45:46] <mru> it should be fine
[08:45:52] <Vitor1001> ok, will commit it.
[08:46:35] <mru> great
[08:46:42] <mru> should get some of fate back on track
[08:47:17] <Vitor1001> I hope so.
[08:47:30] <mru> but you still have errors on some systems
[08:47:40] <mru> Incorrect register `%r9' used with `l' suffix
[08:47:41] <CIA-99> ffmpeg: vitor * r23752 /trunk/libavcodec/x86/mpegaudiodec_mmx.c: Fix asm constraints in apply_window()
[08:48:25] <Vitor1001> :p
[08:48:37] <Vitor1001> And what is that supposed to mean?
[08:48:57] <mru> it means addl $16, %r9 isn't valid
[08:49:21] <Vitor1001> And how can it be it is valid in my box?
[08:49:29] <mru> 32-bit?
[08:49:34] <Vitor1001> Yes.
[08:49:35] <astrange> r9 isn't a 32-bit register
[08:49:48] <mru> replace addl with add
[08:50:02] <Vitor1001> Ok, will check.
[08:50:14] <astrange> (that is, it doesn't exist in 32-bit)
[08:50:49] <mru> the important thing here is that addl (note the l) only works with 32-bit registers
[08:51:03] <mru> %eax, not %rax etc
[08:51:12] <Vitor1001> ok, I see.
[08:51:27] <mru> that's why we have the x86_reg type
[08:51:47] <mru> it will use a register name that works with plain add
[08:51:47] <Vitor1001> Ok. "add" works with x86_reg...
[08:51:51] <mru> or something like that
[08:51:58] <Vitor1001> But isn't integers in x64 also 32-bits?
[08:52:13] <mru> %eax is 32-bit, %rax adds 32 high bits
[08:52:51] <mru> astrange: what are the 32-bit names for the high regs?
[08:53:08] <twice11> There is no name for just the top 32 bit of a 64 bit register.
[08:53:18] <mru> that's not what I meant
[08:53:25] <mru> I meant the low half of r8-r15
[08:54:13] <astrange> r9d
[08:54:23] <CIA-99> ffmpeg: vitor * r23753 /trunk/libavcodec/x86/mpegaudiodec_mmx.c: Fix compilation on x64.
[08:54:27] <mru> d? wtf is that supposed to mean?
[08:54:33] <twice11> double word
[08:54:52] <mru> they still believe a word is 32 bits?
[08:54:57] <twice11> no, 16 bits.
[08:55:00] <astrange> they think a word is 16 bits
[08:55:06] <mru> that's what I meant
[08:55:15] <astrange> r9l is taken for the low 8 bits
[08:55:21] <mru> gah
[08:55:28] <mru> and 16 bits?
[08:55:32] <twice11> r9w
[08:55:35] <twice11> http://www.x86-64.org/documentation/assembly.html
[08:55:40] <mru> not going there
[08:55:46] <mru> but thanks
[08:56:15] <mru> I don't see why parts of registers need names in the first place
[08:56:23] <mru> the size only matters for load/store
[08:56:43] <mru> or on x86, any memory operand
[08:56:44] <KotH> mru: old x86ism
[08:57:06] <mru> it made sense when you had %ah as well
[08:57:09] <KotH> mru: where ah+al were together ax which is in turn the lower half of eax
[08:57:10] <twice11> if you modify r9w, the top 48 bits are guaranteed to stay constant.
[08:57:21] <mru> but when only the low part is accessible separately it's totally pointless
[08:57:41] <mru> twice11: and that's mostly a nuisance
[08:57:44] <KotH> mru: there is an ah :)
[08:57:56] <mru> KotH: yes, but only a, b, c, d
[08:58:17] <mru> and there is no high 16-bit in 32-bit reg
[08:58:17] <KotH> mru: there were no more than 4 gp reg in x86 :)
[08:58:19] <kshishkov> mru: look at VFP/NEON registers - at least it's _sane_ lower part of register file you can access there
[08:58:37] <mru> eh?
[08:58:42] <mru> you can access everything there
[08:58:50] <kshishkov> KotH: si/di?
[08:59:15] <mru> KotH: but there is no sih
[08:59:25] <mru> only si and esi
[08:59:39] <mru> and rsi
[09:00:02] <KotH> kshishkov: these are no gp registers
[09:00:15] <mru> depends
[09:00:35] <mru> if you don't use them for their special purposes you can do whatever with them
[09:00:39] <mru> almost
[09:00:46] <mru> you probably can't multiply them
[09:00:48] <KotH> kshishkov: they are (were actually) index registers used for string operations
[09:00:57] <kshishkov> there are no gp-registers at x86 at all - try shl bl, al
[09:01:17] <KotH> mru: nope, they were not accessible in all operations until they got redefined to gp registers in 386
[09:01:46] <mru> but you could always use them to stash a value or so
[09:01:50] <KotH> juup
[09:01:59] <KotH> they were often used as cache for intermediate results
[09:02:01] <mru> and probably do some limited addition and such
[09:02:28] <mru> limited addition != saturating
[09:03:01] <twnqx> they are also perfect in "rep movsb" :P
[09:03:04] <KotH> saturation wasnt introduced until mmx
[09:03:17] <KotH> twnqx: that was their original purpose
[09:03:27] <mru> twnqx: but rep is mostly useless
[09:03:33] <CIA-99> ffmpeg: mru * r23754 /trunk/libavcodec/vp6.c: vp6: convert VLA to fixed size
[09:03:36] <KotH> twnqx: hence their name: source index, destination index
[09:03:42] <KotH> mru: useles? why?
[09:03:59] <twnqx> it's slower than manual looping in many cases
[09:04:10] <mru> it's ucoded in dirty ways
[09:04:18] <KotH> oh.. it became so slow?
[09:04:19] <mru> or rather as cheaply as possible
[09:04:24] <mru> because nobody uses it
[09:04:30] <mru> because it's slow
[09:04:41] * KotH still has an asm book or two who teaches how to use rep
[09:04:42] <mru> actually, it's compilers that have trouble using such instructions
[09:04:51] <KotH> realyl?
[09:04:52] <KotH> why?
[09:04:57] <KotH> what makes them difficult?
[09:04:58] <mru> they suck, didn't you know?
[09:05:48] <KotH> i dont know whether they suck, they taught me asm back in the days of old, when men were real men, women were real women and furry beings from alpha centauri were furry beings from alpha centauri
[09:06:08] <av500> wasnt it small furry beings?
[09:06:22] <KotH> dunno.. been some time since i read it
[09:06:53] <KotH> though, my asm definitly needs some refreshment..
[09:07:19] * KotH didnt learn much about protected mode, never had anything to do with mmx/sse/...
[09:07:26] <mru> good for you
[09:07:39] * mru never did _any_ x86 asm coding
[09:07:41] <KotH> you mean i shall learn arm asm instead? ;)
[09:07:46] <ohsix> repne scasb!
[09:07:47] <av500> yes
[09:07:50] <mru> KotH: that would be wise
[09:07:54] <spaam> haha
[09:08:14] <spaam> any asm that is not x86? :)
[09:08:26] <mru> ohsix: what's that? a klingon curse?
[09:08:34] <av500> for practical purposes that leaves you with arm asm...
[09:08:42] <ohsix> scan something, rep not equal
[09:08:59] <mru> mr worf, scan for life-signs
[09:09:19] <astrange> there's plenty of ppc asm to be written
[09:09:37] <mru> captain, long-range sensors are picking up an unusual rep prefix heading this way
[09:09:40] <ohsix> A common use of the REPNE SCASB instruction is to find the length of a NUL-terminated string.
[09:10:00] <mru> astrange: ppc has become irrelevant
[09:10:13] <ohsix> xbux?
[09:14:35] <kshishkov> ohsix: why y'all forget about "rep {mov,sto}sX" for memcpy/memset?
[09:15:04] <av500> astrange: pps for what?
[09:15:07] <av500> err, ppc
[09:15:19] <mru> kshishkov: memcpy is overrated
[09:15:37] <kshishkov> mru: so is everything else
[09:16:10] <av500> overrated is overrated
[09:16:16] <ohsix> kshishkov: truthfully i forgot everything, repne scasb has been something i've said out of context since the first time i saw it
[09:16:43] <mru> rating is overrated
[09:17:03] <mru> and it still sounds like a klingon curse to me
[09:17:33] <ohsix> it might be, except for the "asb" part
[09:17:50] <ohsix> not familiar with the language but thats a weird construct in any language :O
[09:19:20] <twice11> If I got recent optimization hints correctly, nearly everything is faster by hardcoded loops using XMM than using the string instructions.
[09:20:12] <twice11> And string instructions using a lower width than the maximum width supported by the processor are extremely slow.
[09:20:53] <ohsix> string instructions were a bad idea after the 286 iirc
[09:21:02] <mru> the 286 was a bad idea
[09:21:07] <astrange> strings are a bad idea
[09:21:28] <twice11> That's why memcpy typically has a core like "mov %ecx,%ebx; shr $2,%ecx; rep movsd; mov %ebx, %ecx; and $3,$ecx; rep mosvb"
[09:21:31] <ohsix> they were compact in representation and that was about it
[09:22:03] <ohsix> with rep it was almost like a function call
[09:22:16] <mru> I know that
[09:22:19] <mru> it's still useless
[09:22:25] <twice11> I think rep stosd/rep mosvd was the fastest way to store/copy on Pentium Pro/Pentium II with the right microcode loaded ("fast strings")
[09:22:31] <mru> optimising for something you shouldn't be doing is stupid
[09:22:55] <mru> they had alternative ucode variants?
[09:23:06] <ohsix> they got rid of SEX but added REP :>
[09:23:11] <DonDiego> mru, Dark_Shikari, say: was your mpeg4 simplification stuff helped by michael being trolled into refactoring it all some time ago by my humble trollness?
[09:23:29] <mru> he did?
[09:23:32] <twice11> Intel publishes microcode updates for all processors after the Pentium 1.
[09:23:36] <mru> oh, the h263 split
[09:23:55] <mru> twice11: I know they update the ucode from time to time
[09:24:08] <DonDiego> yes, that's what i was referring to
[09:24:12] <twice11> And I think fast strings were not in the original microcode.
[09:24:24] <mru> I hadn't heard of differently optimised alternatives
[09:24:26] <twice11> At least the BIOS somehow had to "enable" them.
[09:24:47] <mru> oh, it was something they added in some update
[09:24:52] <twice11> There are no alternatives, just "old" and "new" one, and the new one is faster.
[09:25:19] <twice11> The Pentium III added SSE which might beat string instructions again.
[09:25:48] <twice11> Optimizing for code size was important on the 8088 (which really was a bad idea, as it was starving on instruction supply)
[09:26:23] <twice11> Famous quote: "What use is a processor that can perform a 16 bit add in two clock cycles if it needs 14 cycles to fetch that instruction?"
[09:26:25] <mru> optimising memcpy is a largely futile exercise
[09:26:47] <twice11> Because the memcpy interface has no alignment requirements. Or are there further issues?
[09:27:27] <mru> because good code doesn't call memcpy
[09:27:41] <mru> or does it so infrequently that performance doesn't matter
[09:28:29] <twice11> I think any dictionary-based decompressor (Think LZ77) is just limited by memcpy speed for highly redundant data.
[09:29:36] <mru> you can't use memcpy in such code
[09:29:46] <mru> src and dst often overlap
[09:29:59] <mru> and memmove does the wrong thing
[09:30:04] <twice11> Err, right. But memmove is even slower usually.
[09:30:25] <twice11> Because that function has to test the direction of (possible) overlap on each invocation.
[09:30:34] <mru> I know that
[09:30:57] <mru> the point is standard lib functions do the wrong thing
[09:31:02] <mru> so their speed is unimportant
[09:43:23] <CIA-99> ffmpeg: mru * r23755 /trunk/libavcodec/ (fft.h mdct.c): Remove VLA in ff_kbd_window_init, limit window size to 1024
[09:45:41] <astrange> [A5
[09:46:15] <av500> [B 6
[09:47:05] <mru> escape codes!
[09:51:16] <astrange> irssi seems to like sending them instead of switching windows recently
[09:52:07] <mru> are on a laggy ssh?
[09:52:59] <astrange> yes
[09:53:48] <mru> I've seen that effect too
[09:54:57] <ohsix> it'll do it if you mash on pagedown if your buffer is way up, then you type some stuff in too
[09:55:13] <ohsix> ~[6~[6/sb end :>
[09:56:06] <mru> I guess it uses some heuristic to determine what's input and what's navigation
[09:56:51] <mru> if too much is bundled into a single read from the terminal, it gets confused
[09:56:57] <twice11> Navigation commands look like "ESC [ something"
[09:57:03] <ohsix> they do some buffering that detects pastes; recently improved a lot, but i suspect thats where the problem is
[09:57:31] <ohsix> new paste detection works if theres 3 chars in one read, instead of a handful of lines
[09:57:35] <twice11> if the delay between ESC and the rest is too big, ncurses decides that the ESC was stray and doesn't belong to a navigation key.
[10:56:21] <j-b> is there a ffmpeg-mt channel?
[10:56:48] <spaam> ask astrange :)
[10:57:03] <elenril> why should it exist?
[10:57:36] <peloverde> Are we any closer to merging -mt than we were 5 months ago?
[10:58:03] * mru thinks astrange should channel some effort into it
[10:58:13] * elenril thinks mru should help him
[10:58:51] <pJok> http://sphotos.ak.fbcdn.net/hphotos-ak-snc3/hs292.snc3/28268_408780123630_600348630_4272615_7646431_n.jpg that is what i do on a daily basis...
[10:58:59] <peloverde> no, mru needs to rewrite fate
[10:59:20] <pross-au> whats wrong with fate
[10:59:40] <DonDiego> it's not free software for starters
[10:59:49] <DonDiego> also, it sucks
[11:00:04] <pross-au> and your vapourware sucks less?!
[11:00:05] <mru> and mike is single point of failure
[11:00:22] <pross-au> fair enuff
[11:00:24] <DonDiego> i asked mike for the code, he refused to give it out
[11:00:31] <av500> I think fate should also only test free codecs
[11:00:37] <pross-au> Haha
[11:00:38] <mru> pross-au: saying you'd _like_ to do something doesn't make it vapourware
[11:00:56] <pross-au> yeah somebody said it sucks
[11:01:21] <DonDiego> it does
[11:01:33] <DonDiego> i've been asking mike for years to add 'make checkheaders'
[11:01:39] <DonDiego> for some reason this is too hard
[11:01:53] <DonDiego> and i'm being prevented from adding it myself
[11:01:55] <DonDiego> bbl
[11:02:17] <mru> devs should be able to add or change tests without going through $mike
[11:02:24] <av500> +1
[11:02:38] <av500> fata should be in svn/git
[11:02:42] <av500> a->e
[11:02:42] <spaam> fata!
[11:02:43] <mru> that's the plan
[11:02:48] <mru> fatwa
[11:02:51] <pross-au> haha
[11:03:06] <av500> mru: now, after fat elf a fat wa?
[11:04:14] <pross-au> so thats it? everything else non-sucks
[11:04:30] <mru> the basic idea is sound
[11:04:38] <mru> but it needs restructuring
[11:04:55] <mru> and it needs better ways to query the history
[11:05:12] <pross-au> do you use that?
[11:05:16] * mru might enlist lu_zero or Honoome for some web frontend work
[11:05:22] * mru doesn't do web
[11:05:48] * mru has far too much work queued up
[11:05:49] <pross-au> ffmpeg is Web
[11:05:58] <mru> eh no
[11:06:06] <mru> ffmpeg isn't written in php
[11:06:13] <mru> nor does it have a mysql demuxer
[11:06:15] <pross-au> i do all my web programming in c
[11:06:15] <pJok> fate should be part of ffmpeg
[11:06:28] <mru> pJok: it will if I have things my way
[11:06:55] <mru> actually, I'd like to make it a standalone project
[11:07:06] <pross-au> yet another test framework
[11:07:08] <mru> but the test specs go in ffmpeg of course
[11:07:27] <pJok> mru, it doesn't really matter where it is, as long as it works and is changeable
[11:07:55] <mru> pJok: if the framework, as it were, is separate it could be used by others too
[11:08:05] <mru> I know DonDiego wants a good test system
[11:08:58] <pross-au> so php?
[11:09:05] <pross-au> or python
[11:09:09] <pJok> mru, just wondering why mike wont set it free
[11:09:27] <mru> he says it's too embarassingly ugly
[11:09:35] <mru> and I can easily believe that
[11:09:56] <mru> writing maintainable code is not one of mike's stronger skills
[11:10:21] <mru> he's more of a just-in-time programmer
[11:10:25] <pross-au> Ouch
[11:10:47] <mru> he's great at RE though
[11:10:50] <pross-au> and this is our test system
[11:18:37] <mru> #define FRAME_TIME 1.04489795918367346939
[11:19:21] <kshishkov> add comment - "we are retarded, our seconds need to be longer"
[11:19:34] <mru> // FIXME: horribly broken, but directly from reference source
[11:20:01] <mru> what number is that anyway?
[11:21:08] <kshishkov> sqrt(sqrt(sqrt(sqrt(2)))) ?
[11:22:07] <mru> close, but not quite
[11:22:15] <mru> 1.04427378243
[11:22:30] <kshishkov> ln(2)*1.5
[11:22:55] <thresh> 1.04489795918367346939 * 490 = 512
[11:23:16] <thresh> well that, or 245 of course
[11:23:49] <kshishkov> and it's suspiciously close to 25/24
[11:25:55] <peloverde> 256/245
[11:26:21] <mru> 25/24 struck me as a possibility
[11:26:37] <mru> but that's not close enough
[11:26:59] <kierank> http://slashdot.jp/it/10/06/24/0452249.shtml
[11:29:33] <peloverde> the google translate version is almost readable
[11:32:16] <mru> that's readable without translation
[11:32:33] <mru> it says ffmpeg trunk has a vp8 decoder
[11:34:54] <Vitor1001> mru: Why not a "make fate2" for "unofficial" fate tests?
[11:35:15] <mru> Vitor1001: that's the plan
[11:35:30] <mru> and then we'll slip it in as default when nobody is watching
[11:35:39] <Vitor1001> Ah, ok.
[11:35:53] <Vitor1001> So it will still uses Mike's web-based framework?
[11:36:06] <mru> no
[11:36:40] <Vitor1001> What I meant (supposed to be very easy) is to add a new target that is the same thing as current "make fate"
[11:36:45] <Vitor1001> but with different test specs
[11:36:57] <mru> that would be easy
[11:37:00] <Vitor1001> All we need them is to convince mike to add a test spec to it to fate
[11:37:07] <mru> but the aggregation of results is important
[11:37:15] <Vitor1001> Yes, that's exactly the point. It's easy!
[11:37:35] <pross-au> mru: how about a standardised output for for 'make fate'
[11:37:44] <mru> what do you mean?
[11:37:45] <Vitor1001> And it is easy for Mike or whoever to split it one test number per test afterwards
[11:38:13] <pross-au> mru: so results can be extracted for presentation
[11:38:18] <pross-au> and recording into database
[11:39:01] <Vitor1001> The advantage is that in the meantime we can _vastly_ expand our test coverage.
[11:40:08] <mru> it would take me a few days full-time work to make a new system
[11:40:14] <mru> at least the foundations
[11:40:28] <mru> I hope to have that time soon
[11:40:34] <Vitor1001> And how much time to make a "make fate2"?
[11:40:40] <pross-au> mike started with a very basic system
[11:40:47] <pross-au> and evolved it
[11:40:52] <Vitor1001> You have to count at least two weeks for flames and bikesheds :p
[11:41:00] <mru> mike started with one bad requirement: python
[11:41:06] <kshishkov> it should be able to run ffmpeg -i fate-test-file -f framecrc2 mysql://user:pw@server/results
[11:41:17] <mru> mike's love of python is sometimes detrimental
[11:41:31] <mru> I wasn't planning on using mysql
[11:41:38] <pross-au> JSON
[11:41:50] <mru> how about plain old text for the comms?
[11:41:50] <kshishkov> pross-au: that's for x264 :P
[11:41:56] <pross-au> LOl
[11:42:18] * kshishkov still wants FTP support in FFmpeg
[11:42:27] <Vitor1001> mru: Does mike know that you are seriously thinking about redoing fate?
[11:42:45] <pross-au> Cya
[11:42:51] <mru> Vitor1001: don't know
[11:42:59] <elenril> kshishkov: send patches
[11:43:12] <Tjoppen> kshishkov: me too. is there a reason why not?
[11:43:13] <peloverde> what's wrong with python?
[11:43:19] <Vitor1001> Maybe this will change his mind about making the whole thing more collaborative...
[11:43:21] <thresh> everything
[11:43:36] <Tjoppen> I almost ended up writing one, but hacking around it using libcurl was easy enough
[11:44:45] <kshishkov> Tjoppen: exactly - nobody did it
[11:45:01] <Tjoppen> FTP is cool because it can actually tell you/block on partial files
[11:45:07] <benoit-> license violator winner of the day: posted a message on ffmpeg-user ML (without being registered) to advertise its software: http://www.pavtube.com/hd-video-converter/
[11:45:14] <Tjoppen> unlike POSIX files (BSD has fixed that though)
[11:45:24] <mru> benoit-: lol
[11:45:34] <mru> Tjoppen: tell you what?
[11:45:56] <Tjoppen> tell you that the file is partial
[11:46:03] <Tjoppen> in other words: being uploaded
[11:46:13] <Tjoppen> so you treat the connection as a pipe
[11:46:28] <mru> oh, you mean downloading a file from the same server it's being uploaded to
[11:46:34] <Tjoppen> yep
[11:46:50] <mru> I'd consider that a nothing more than a neat gimmick
[11:47:03] <peloverde> Registered in China, what a surprise
[11:47:13] <Tjoppen> libavformat handles that now. I sent in a couple of patches a while that makes reading from stdin work (except a few demuxers)
[11:47:16] <mru> it wouldn't know if the file is being written by some other means
[11:47:21] <Tjoppen> *a while bac
[11:47:47] <Tjoppen> I'm fairly sure FTP, like HTTP, doesn't allow you to change the content in the middle of a file
[11:49:14] <Tjoppen> doing stuff like   curl ftp://example.com/foo.avi | ffplay -  is pretty neat
[11:51:02] <kshishkov> even better - playing random file via SSH!
[11:51:21] * kshishkov waits for libavcrypt
[11:51:38] <Tjoppen> ah yes. like a lottery - every once in a while you get rick astley instead
[11:57:08] <lu_zero> good morning
[11:57:16] <lu_zero> kshishkov: write it =P
[11:58:25] <spaam> Tjoppen: like this http://spaam.se/secret/mru_and_koth_love.jpg ? :)
[11:58:46] <spaam> and yes you will get rickrolld..
[12:03:12] <mru> spaam: not if you check the headers first
[12:03:47] <mru> hehe youtube... Server: wiseguy/0.6.2
[12:06:53] <Tjoppen> luckily flash doesn't work on my machine
[12:08:52] <kshishkov> it's no luck, it's result of your own actions
[12:09:27] <kshishkov> like Firefox crashing when trying Flash on Gdium
[12:09:41] <Tjoppen> no, it actually does work occasionally
[12:10:02] <av500> kshishkov: those 3 things together are just asking for trouble...
[12:10:04] <spaam> mru: sure :) but not everyone do that :)
[12:10:13] <Tjoppen> I had a greasemonkey script that replaced the player with totem or mplayer, but it doesn't work any more
[12:10:40] <Tjoppen> youtube-dl does though, although a bit awkward
[12:10:46] <peloverde> running FFmpeg with arbitrary network input unsandboxed scares me
[12:11:25] <kshishkov> av500: even independently
[12:11:43] <av500> thats what I meant
[12:12:05] <kshishkov> spaam: being lazy is not an excuse to parse your HTTP responses in telnet window
[12:12:52] <lu_zero> kshishkov: you don't have a tcpdump as background?
[13:42:43] <BBB> peloverde: is there a webm irc channel?
[13:43:04] <av500> #webm
[13:43:51] <BBB> I guess I needed codec :)
[13:44:12] <av500> right
[13:44:26] <mru> #ffmpeg-devel ?
[13:44:51] <BBB> wbs: reviewing j0sh' patches now
[13:44:57] <BBB> mru: good point
[13:48:18] <Dark_Shikari> BBB: #vp8
[13:48:32] <Dark_Shikari> BBB: progress on asm?
[13:49:36] <BBB> it's working, sorry, can't spend full days on this on weekdays, have work to do, but it's progressing, it'll be done this weekend
[13:50:50] <Dark_Shikari> ah ok
[13:51:29] <av500> BBB: I just joined #vp3 - #vp7 as well :)
[13:51:59] <BBB> I've had a good read through your sse2/ssse3 asm, I get most of it, probably will document it a bit before I commit it though (just so I get it)
[13:52:14] <janneg> the official website of vp7 is vp7.de
[13:52:17] <janneg> ;)
[13:52:17] <Dark_Shikari> BBB: of course
[13:52:22] <Dark_Shikari> you've got to have some questions though =p
[13:52:29] <BBB> I will :-p
[13:52:33] <av500> janneg: yep
[13:53:33] <av500> Dark_Shikari: you are sure they still have vp7 source? the files on the smb chare have been now edited into vp8 src code...
[13:53:48] <Dark_Shikari> lol
[13:53:56] <Dark_Shikari> "version control, what's that?"
[13:54:47] <mru> alternatively you can use clearcase
[13:54:53] <mru> it actually stores all the old versions
[13:55:03] <mru> but in totally useless way
[13:59:11] <KotH> worse than vss?
[13:59:29] <mru> more expensive at least
[13:59:55] <mru> I've never encountered vss
[14:00:05] <wbs> vss is .. interesting
[14:00:10] <wbs> or at least was 8 years ago
[14:00:27] <mru> isn't that the one that corrupts the entire repo once a week?
[14:00:33] <wbs> one user locks a file, preventing all other team members from modifying the same file (within their own working copies)
[14:01:16] <KotH> well.. vss is to cvs what cvs is to git
[14:01:50] <kshishkov> mru: yes, especially if more than one guy uses it
[14:02:00] <mru> fundamentally, clearcase is cvs
[14:02:13] <mru> it works on files
[14:02:17] <av500> wbs: it's lol, but at some stage our CEO asked if that was possible, ppl editing files but not having the src code :)
[14:02:50] <wbs> it's major fun when one user has locked the file and gone home for the weekend ;P
[14:02:53] <mru> but they've added layers on top making it nearly impossible to do anything useful
[14:03:12] <kshishkov> sounds like user-friendly
[14:03:18] <mru> another "nice" one is pvcs
[14:03:19] <wbs> yeah, clearcase makes git seem dead simple (which it is, IMO, too ;P)
[14:03:32] <mru> it keeps _no_ track of where the local copy came from
[14:03:42] <mru> so if you do a checkout
[14:03:51] <mru> then someone else does a checkin
[14:03:52] <av500> it comes from the smb share, where else! :)
[14:03:56] <mru> and you check in
[14:04:02] <wbs> anyone used synergy/continuus?
[14:04:06] <mru> you effectively revert the previous checkin
[14:04:23] <kshishkov> wbs: those are too generic buzzwords
[14:04:24] <mru> av500: actually, that's how they ran it where I worked
[14:04:49] <av500> see, I know the enterprise business!
[14:05:16] <mru> then they mounted an smb share in the uk from the us
[14:05:29] <mru> a full checkout took an entire day
[14:12:34] <wbs> kshishkov: yeah, but they're also names of quite an ugly scm ;P
[14:21:33] <Honoome> wbs: you're not using SOCK_SEQPACKET for your code, are you?
[14:21:51] <wbs> Honoome: umm.. not that I know of at least :-)
[14:21:59] <Honoome> (sctp)
[14:22:04] <wbs> I don't use sctp at all
[14:22:15] <mru> that's lu_zero
[14:22:16] <Honoome> ah okay.. so was Josh doing so?
[14:22:28] <Honoome> mru: yes I know lu_zero is the sctp freak :P
[14:22:33] <wbs> no, I don't think he touches it either, yet at least
[14:22:45] * mru played with sctp a bit many years ago
[14:23:07] <Honoome> it's because lu suggested using seqpacket in feng that I'm making sure that nobody is going to use that in ffmpeg, as I've just been explained that it's not what we need :P
[14:23:27] <Honoome> on the other hand, I fixed FIONREAD/SIOCINQ and hopefully it'll be merged in a future kernel, yai.
[15:10:56] <CIA-99> ffmpeg: mru * r23756 /trunk/libavformat/asfdec.c: asfdec: ensure number of streams is within bounds; remove VLA in asf_read_pts()
[15:23:23] <CIA-99> ffmpeg: benoit * r23757 /trunk/libavcodec/ffv1.c:
[15:23:23] <CIA-99> ffmpeg: Set an opaque alpha value when decoding rgba ffv1.
[15:23:23] <CIA-99> ffmpeg: Patch by Thad Ward coderjoe69?yahoo?com
[15:58:19] <wbs> Vitor1001: btw, your mp3 decoding asm breaks compilation if you use --disable-everything --enable-decoder=mp3
[15:58:40] <wbs> Vitor1001: since it tries to call ff_mpegaudiodec_init_mmx within HAVE_MMX
[16:02:26] <mru> and...
[16:02:52] <mru> what does that function depend on to be built?
[16:03:30] <wbs> and the object file containing that function is only compiled if CONFIG_MP*FLOAT_DECODER is enabled (in lavc/x86/Makefile)
[16:27:18] <peloverde> "bash: ffaacdec: command not found" *headdesk*
[16:27:35] <mru> ?
[16:27:47] <peloverde> http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2010-June/025823.html
[16:27:54] <mru> oh, -user
[16:28:02] <mru> that's why we split it off
[16:28:43] <peloverde> The worst part is I can't tell if that guy is trolling or not
[16:29:16] <wbs> peloverde: probably not, don't underestimate users' cluelessness
[16:29:36] <twice11> famous quote: "Never attribute to malice what can be attributed to stupidity"
[16:54:01] <_av500_> peloverde: not all the ppl get the ff prefix thingy...
[16:54:35] <mru> they are not ffpeople
[16:55:09] <twice11> And have no ffclue :)
[16:55:38] <Dark_Shikari> fffuck them
[16:55:42] <BBB> peloverde: I thought that was awesome, you should not reply and wait for someone to figure it out ;)
[16:55:48] <BBB> that's called a "user community"
[16:55:48] <mru> Dark_Shikari: ffuck
[16:56:03] <mru> words already starting with f get only one extra
[16:56:24] <peloverde> The thread was about building ffmpeg with libfaad so presumably ffmpeg is still the correct binary
[16:57:03] <mru> the best part is most people were probably using ffaac all along
[16:57:20] <mru> it was always the default even if libfaad was enabled
[16:57:57] <twice11> The thread is about a two AAC decoding modules. One relies on libfaad and the other (internal) one is called ffaacdec
[17:02:09] <votz> peloverde: how much faster would you say ffaacdec is?
[17:02:20] <mru> votz: on what cpu?
[17:02:39] <peloverde> It's about twice as fast on my core2
[17:02:41] <votz> some modern desktop proc, like an i5 or an i7
[17:02:54] <peloverde> (except for main profile which is super slow) but that's because main profile sucks
[17:03:02] <votz> peloverde: wow, awesome
[17:03:18] <votz> peloverde: does ffaacdec practice black magic to attain such speed improvements?
[17:03:25] <votz> and/or voodoo
[17:03:48] <peloverde> well if you consider inlining get_bits primitives black magic then yes
[17:03:59] <peloverde> but mru gets the credit for that one
[17:04:09] <votz> mru: what does get_bits do exactly?
[17:04:26] <peloverde> The rest of the speed is mostly from av_fft and dsputil
[17:04:29] <votz> probably gets some bits of some kind, that I get ;)
[17:05:19] <mru> ffaac is ~3.6x faster than faad on my i7
[17:06:06] <twice11> get_bits reads a certain number of bits from a bit stream (which for obvious reason is a byte stream in computer memory)
[17:06:48] <votz> peloverde: mru: that's quite an impressive improvement
[17:07:40] <mru> faad isn't exactly brilliantly coded
[17:07:43] <Honoome> I wonder, can we make use of the mirror-climbing capabilities of fatelf supporters?
[17:08:01] <mru> there are more than one?
[17:08:22] * mru could use some shotgun target practice
[17:08:44] <Honoome> mru: sure, otherwise I wouldn't even waste the time
[17:09:14] <Honoome> if it was only icculus, it'd be all fine... he's insane, full stop
[17:09:39] <mru> who else?
[17:09:56] <mru> I'd like to see someone argue for fatelf in gentoo
[17:10:11] <mru> that would be the ultimate misachievement
[17:10:17] <Honoome> mru: http://mike.trausch.us/blog/2010/06/23/on-fatelf-or-because-140-characters-isnt-enough-for-a-discussion/
[17:10:24] <Honoome> but luckily nobody asked gentoo for it
[17:10:57] <Honoome> [and from the other side I posted another reasoning why fatelf makes no bloody sense... if somebody wants to spread it :P http://www.reddit.com/r/linux/duplicates/ciham/a_few_more_reason_why_fatelf_is_not/ ]
[17:10:58] <mru> (how does firefox manage to spin up the disk every time I touch it?)
[17:11:09] <Honoome> mru: sqlite
[17:11:31] <mru> is there a way to make it stop?
[17:11:43] <Honoome> emerge -C mozilla-firefox
[17:11:51] <mru> other than that?
[17:11:56] <Honoome> not that I know of
[17:12:09] <mru> I don't bloody care if it doesn't sync the db instantly
[17:12:20] <Honoome> but they do! :P
[17:12:23] <twice11> LD_PRELOAD something that kills fsync/fdatasync?
[17:12:41] <mru> or put ~/.mozilla in tmpfs
[17:12:50] <mru> and copy back when it exits
[17:12:52] <Honoome> that's an option
[17:12:54] <twice11> But be aware that the history and the like are stored in binary database files that can explode in your face if they get inconsistent.
[17:13:14] <mru> it's a laptop ffs
[17:13:17] <mru> it has builtin ups
[17:13:52] <mru> holy crap, .mozilla is 125M
[17:14:03] <twice11> It contains the disk cache.
[17:14:23] <twice11> that is on-disk cached file from the internet, not cached disk contents...
[17:15:01] <mru> hmm, there are files here not touched since 2005
[17:15:26] <Dark_Shikari> they were created on the init of .mozill
[17:15:27] <Dark_Shikari> *.mozilla
[17:15:50] <mru> and never deleted when they switch formats
[17:16:12] <Honoome> there are some that have older dates because are taken from firefox extensions
[17:16:26] * Honoome hates the fact that gentoo mozilla team insists on NOT creating ebuilds for extensions
[17:16:44] <Honoome> my home is not the place for stuff ! why should I keep the dictionaries there?
[17:23:20] <_av500_> Honoome: this guy is so misguided
[17:23:36] <_av500_> what is this small business argument?
[17:29:04] <mru> btw skype are still/again looking for people
[17:29:13] <mru> don't know if permanent or contract
[17:31:00] <Dark_Shikari> well if they want contract, I can help
[17:31:25] <mru> I don't know what skills they're looking for either
[17:31:36] <mru> only that it's arm related
[17:32:27] <mru> someone at arm mentioned it
[17:32:33] <_av500_> Dark_Shikari: they can give you vp7 src code :)
[17:32:55] <Dark_Shikari> mru: well they wanted h264-related stuff a month or two back
[17:33:05] <mru> yeah, I remember that
[17:33:18] <mru> but they didn't like the idea of contracts then
[17:33:24] <mru> maybe they've changed their minds
[17:33:57] <mru> I'll let you know if I hear anything further
[17:34:14] <Dark_Shikari> k
[17:34:14] <peloverde> Looking at their site it seems liek they have a bunch of openings
[17:34:30] <BBB> who on earth wants to work in talin?
[17:34:38] <Dark_Shikari> estonia?
[17:34:41] <BBB> yeah
[17:34:47] <Dark_Shikari> I recall that being a pretty awesome place actually
[17:34:47] <mru> when I spoke with them the jobs were in stockholm
[17:34:50] <_av500_> BBB: estonians?
[17:35:04] <Dark_Shikari> fast, cheap internet!
[17:35:08] <BBB> I recall new york being a pretty awesome place
[17:35:15] <Dark_Shikari> new york costs 15 times more to live in
[17:35:30] <BBB> that's probably because it has 15 times more to offer
[17:35:55] <mru> than?
[17:36:02] <BBB> than talin :)
[17:36:03] <_av500_> thats why you have a 15x larger apartment :)
[17:36:12] <Dark_Shikari> >large apartment
[17:36:13] <Dark_Shikari> >new york
[17:36:16] <Dark_Shikari> hahahaha
[17:36:36] <BBB> yeah, you'll get a shoebox here if you're lucky
[17:36:54] <BBB> although rental is quite cheap b/c of the crisis right now
[17:36:55] <_av500_> imagin talin now, you have to live in a teacup
[17:37:38] <BBB> mru: how close are you to london?
[17:37:55] <mru> 1.5 hours
[17:38:15] <BBB> that's not bad :)
[17:38:33] <mru> it's perfectly within range of a day trip
[17:38:38] <mru> last train back is at 1am
[17:38:57] <_av500_> or 6am i guess
[17:39:06] <mru> don't know when they start
[17:39:18] <mru> no later than 6 I guess
[17:40:03] <Dark_Shikari> _av500_: yeah but the tea is good
[17:40:33] <_av500_> in talin?
[17:40:43] <Dark_Shikari> 01:36 <+_av500_> imagin talin now, you have to live in a teacup
[17:40:47] <mru> changing topic, we have a threading related bug or two
[17:41:07] <mru> fate is showing spurious failurus on threaded encodes since I eneabled pthreads
[17:41:27] <janneg> german rail claims the first train is leaving at 05:30
[17:41:43] <mru> sounds about right
[17:44:41] <BBB> mru, Dark_Shikari: regarding src_stride and dest_stride issue
[17:44:49] <mru> fix it!
[17:44:51] <BBB> mru, Dark_Shikari: shouldn't h264 suffer from the same issue?
[17:45:00] <BBB> we're using a h264 function prototype
[17:45:17] <BBB> or is this because h264 doesn't use intermediate buffers when doing h+v subpel mc?
[17:45:54] <BBB> and if that's the case, should I just shut up and not do that either, rather than adding a function argument that I won't use when implemented correctly/optimally?
[17:46:06] <mru> my neon code uses an intermediate buffer in a couple of cases
[17:46:14] <mru> but the internal functions deal with different strides
[17:46:23] <BBB> oh, you have wrapper functions?
[17:46:30] <BBB> maybe I should do that too?
[17:46:30] <mru> no
[17:46:33] <mru> no wrappers
[17:46:49] <mru> well, tiny ones
[17:47:00] <BBB> that's what I mean :-p
[17:47:03] <mru> for calling h then v
[17:47:08] <mru> no wrappers around single functions
[17:47:14] <BBB> right
[17:48:17] <BBB> I'll look at the neon code for inspiration
[17:48:28] <BBB> on my way to fix it, but will be gone for a bit to watch the dutch play
[17:48:33] <BBB> go netherlands! \o/
[17:48:37] <lu_zero> uh?
[17:49:40] <mru> these crazy dutchmen...
[17:50:10] <lu_zero> mru: what's the impact of the whole vla -> max_sized arrays?
[17:50:20] <mru> impact?
[17:50:25] <mru> no vlas of course
[17:51:07] <lu_zero> in memory/on disk footprint should change a bit
[17:51:25] <mru> probably not
[17:52:11] <mru> I just want to stop people doing stupid things
[17:52:19] <mru> like allocing insane amounts of stack space
[17:52:35] <mru> megabytes in some cases
[17:53:57] <kierank> am I right in saying that to change the phase term in an mdct, only the postrotate needs to be modified?
[17:55:00] * lu_zero stares at ffmpeg.c
[17:56:08] <peloverde> kierank, that seems correct
[18:00:41] <mru> ffmpeg.c stares back
[18:00:59] <CIA-99> ffmpeg: lu_zero * r23758 /trunk/libavformat/options.c: Remove typo: s/ingore/ignore/
[18:18:02] <CIA-99> ffmpeg: mru * r23759 /trunk/libavcodec/tta.c: tta: replace potentially huge VLAs with malloc/free in context
[18:20:37] <Honoome> mru: out of curiosity do you happen to know if there is any tool that can tell you the size of the stack allocations of a given function statically?
[18:22:58] <mru> not if vlas are used :-)
[18:24:01] <Honoome> what if it gives you the amount or "amount + warning: vlas are used" ? :P
[18:24:55] * Honoome found some huge stacks in feng and would love to know if there are more
[18:25:10] <lu_zero> plumes?
[18:25:52] <Honoome> plumes?
[18:26:02] <mru> fumes
[18:26:05] <mru> flames
[18:26:54] <jai> can i apply a cosmetics patch like http://pastie.org/1017588
[18:27:26] <mru> I wouldn't touch that witihout asking michael
[18:27:36] <jai> ah, ok
[18:28:03] <Plumeseyes> lu_zero: this way?
[18:28:34] * lu_zero shivers at the idea of diego in a feathery costume
[18:28:48] <Plumeseyes> Monkey Island style?
[18:29:01] <lu_zero> exactly!
[18:36:57] <mru> Honoome: gcc -S for arm puts the frame size in a comment at the start of each function in the asm output
[18:37:29] <Honoome> hmm so it is feasible to expect that DWARF encodes that data as well?
[18:37:54] <mru> dwarf almost certainly does
[18:38:02] <mru> stack unwinding would be tricky without it
[18:38:14] * Honoome checks whether dwarves already has a tool to extract that information
[18:40:49] <Honoome> I'd rather not even start to think about parsing DWARF data myself...
[19:07:34] <Honoome> mru: please don't hate me.. you know if the C++ mangling scheme used by gcc3 is documented somewhere beside its source code?
[19:07:48] <Dark_Shikari> http://agner.org/optimize
[19:08:06] <mru> Honoome: it should be someplace more official
[19:08:32] <Honoome> Dark_Shikari: ah thanks :)
[19:08:50] <Honoome> mru: well, google's "gcc3 c++ mangling" didn't bring up any doc from the gcc website at all :|
[19:10:01] <lu_zero> Honoome: mangling?
[19:10:10] <Honoome> lu_zero: that's the name of the procedure
[19:14:47] <lu_zero> wikipedia doesn't give any better link
[19:15:00] <mru> well, it is gcc after all
[19:16:17] <Honoome> and C++! :P
[19:16:51] <lu_zero> well it states that they follow microsoft convention
[19:17:12] <lu_zero> http://www.codesourcery.com/public/cxx-abi/abi.html#mangling
[19:17:18] <lu_zero> du de dum...
[19:28:04] <lu_zero> that tells a lot about how messup c++ is...
[19:37:31] <wbs> lu_zero: did you check j0shs patches yet?
[19:40:02] <wbs> BBB: in case you want to reply to the -user mail you pointed out a few days ago (http://lists.mplayerhq.hu/pipermail/ffmpeg-user/2010-June/025790.html) (i'm not on that list)
[19:40:06] <lu_zero> read yes, tried not yet
[19:40:38] <wbs> BBB: it's a bug in the 0.6 branch, fixed in rev 23344 on trunk. and it's not related to http at all, some generic stuff in lavc that's mostly used when streaming to ffserver
[19:51:10] <j0sh_> wha should i work on next? quicktime depacketizer?
[19:51:45] <mru> feel free to review my patches :-)
[19:54:16] <wbs> j0sh_: as a follow-up on this, I'd say refactor out the common code for parsing sdp lines
[19:54:25] <wbs> j0sh_: I've added a note on the wiki list about that
[19:54:27] <j0sh_> ok
[19:54:30] <lu_zero> j0sh_: what you'd like to tackle next?
[19:54:42] <wbs> it shouldn't be big I think, then after that, more depacketizers and packetizers perhaps
[19:54:46] <lu_zero> btw please restart sending reports ^^
[19:54:54] <j0sh_> lu_zero: ah, yes, sorry
[19:55:04] <verb3k> Is libavfilter's fade patch usable atm?
[19:55:23] <j0sh_> patches at the end of the day aren't acceptable reports? :)
[19:55:28] <lu_zero> verb3k: you reminded me that I should dig ffmpeg.c
[19:56:37] <lu_zero> j0sh_: if it's a bourden we could quit that, still helps me a bit since in this week and the next I'll less reachable
[19:56:53] <j0sh_> lu_zero: what's the rfc for mpeg-4 video? 3016 or 3640?
[19:57:36] <wbs> lu_zero: I've tested the patches a bit, seems to work fine for me, valgrind clean too
[19:57:50] * j0sh_ also tested with valgrind for once
[19:57:54] <wbs> and yes, there's both string.h and strings.h, some odd functions are in the latter
[19:57:58] <wbs> j0sh_: good, good. :-)
[19:58:12] <wbs> j0sh_: isn't the tingling sensation that your code runs without a single remark nice? :-)
[19:58:16] <j0sh_> yeah, i got a warning for something using string.h that went away with strings.h
[19:58:28] <j0sh_> wbs: feels very good indeed
[19:59:12] <lu_zero> j0sh_: I was puzzled since the code you moved didn't have any of the strings functions
[19:59:30] <j0sh_> strcasecmp
[20:00:42] <lu_zero> the patch doesn't have strcasecmp references ^^
[20:01:34] <lu_zero> _maybe_ you should split the s/string/strings lines in a patch alone
[20:02:32] <j0sh_> patch 003 is where i introduced string.h with strcasecmp
[20:02:52] <lu_zero> uhm
[20:03:02] <wbs> j0sh_: the mpeg4 video is rfc 3016
[20:03:12] <j0sh_> i think i realized i needed strings.h after i made the commit
[20:03:16] <wbs> key quote from part of that rfc, "An MPEG-4 Visual bitstream is mapped directly onto RTP packets without the addition of extra header fields or any removal of Visual syntax elements.
[20:03:30] <j0sh_> but i changed nearby lines and didn't want to deal with merge conflicts
[20:03:35] <j0sh_> ...in other words,i was lazy :)
[20:03:50] <wbs> that is, you just chop up the packet into rtp packets, so no explicit parse routine is necessary for that one
[20:04:12] <j0sh_> wbs: that explains why there's no parse_packet needed
[20:04:23] <lu_zero> ^^;
[20:05:14] <j0sh_> lu_zero: will fix it tho. coming right up
[20:07:06] <lu_zero> ok =)
[20:10:22] <j0sh_> uh ohhh... accidentally squashed one of the patches... *mutters*
[20:13:03] <wbs> j0sh_: during a rebase -i?
[20:13:25] <wbs> you may be able to recreate the previous branch state before doing the rebase, by checking through the reflog
[20:18:57] <j0sh_> wbs: alright trying that
[20:20:10] <wbs> not sure if there's any pretty interface to the reflog, but you can at least check in .git/logs/refs/heads/<branchname>, there should be a list of the hashes that the branch head has pointed to
[20:20:36] <wbs> so if you try checkout one of the last hashes before the faulty rebase, you can reset the branch to that hash and redo the rebase properly instead
[20:23:56] <j0sh_> git reflog  works :)
[20:24:18] <j0sh_> and yeah, was able to checkout to a new branch based on the sha of the last good commit
[20:24:31] <j0sh_> man, git is AWESOME
[20:24:42] <wbs> :-)
[20:24:58] <lu_zero> =)
[20:25:11] <wbs> yeah, as long as you don't gc and purge the database right after doing something stupid, you very very seldom actually lose somthing
[20:25:15] <peloverde> indeed
[20:25:40] <peloverde> WTF http://java.dzone.com/dose/dzone-daily-dose-619 Why did they convert the FFmpeg logo to jpeg?
[20:25:56] <wbs> j0sh_: in case the reflog would have been turned off, you could also have done a git fsck and find all loose heads that aren't referenced by any branch head, and then look for the one you want :-)
[20:26:10] <j0sh_> i think i lost half of a day because of something like this a few weeks ago, when i was still geting the hang of git
[20:26:13] <mru> peloverde: becaue the domain starts with java
[20:26:20] <mru> peloverde: i.e. they're clueless
[20:26:34] <wbs> j0sh_: yeah, you may lose some time until you get the hang of it
[20:26:49] <wbs> j0sh_: actually understanding how it works on a lower level helps a lot of using it effectively though
[20:27:01] <j0sh_> i'm sure
[20:27:56] <wbs> and after using git for a while, you really realize how inferior svn is :-)
[20:28:12] <lu_zero> ;_;
[20:28:17] <j0sh_> i think i realized that after i learned how to wield rebase -i :)
[20:29:03] <wbs> :-)
[20:50:28] <CIA-99> ffmpeg: mru * r23760 /trunk/configure:
[20:50:28] <CIA-99> ffmpeg: configure: add 'warn' function
[20:50:28] <CIA-99> ffmpeg: The 'warn' function records a warning message for display after other
[20:50:28] <CIA-99> ffmpeg: informational messages.
[20:50:28] <CIA-99> ffmpeg: mru * r23761 /trunk/configure: configure: warn about missing yasm
[20:50:29] <CIA-99> ffmpeg: mru * r23762 /trunk/configure: configure: use warn function for unrecognised --cc and --arch settings
[21:07:46] <Dark_Shikari> mru: +100000
[21:08:09] <Dark_Shikari> actually, since we're going to rely on yasm optimizations entirely for vp8....
[21:08:16] <Dark_Shikari> why not we just require it unless the user does --disable-mmx?
[21:12:43] <BBB> warning is sufficient
[21:12:56] <Dark_Shikari> nobody pays attention to configure-time warnings
[21:12:58] <Dark_Shikari> we had them in x264 for years
[21:13:01] <Dark_Shikari> NOBODY NOTICED EVER
[21:13:05] <Dark_Shikari> they only noticed when it went 10x slower
[21:13:13] <BBB> haha :)
[21:13:18] <Dark_Shikari> seriously
[21:13:20] <Dark_Shikari> we must make it error out
[21:13:23] <Dark_Shikari> or nobody will ever notice
[21:13:28] <Dark_Shikari> they will just think ffmpeg is slow as fuck
[21:13:30] <BBB> I'm fine with an error as long as you can disable the error specifically (like --disable-yasm)
[21:13:45] <wbs> j0sh_: would you mind rerolling the whole series? some of the later parts don't apply on top of the modified versions you posted later
[21:14:29] <Dark_Shikari> BBB: ok, yes
[21:17:58] <mru> Dark_Shikari: suggest on the ML
[21:18:12] <mru> I can't make that change without some agreement
[21:20:22] <Dark_Shikari> done
[21:23:05] <mru> hmm, wonder how many fate machines that will bring down
[21:23:21] <mru> does openbsd have yasm?
[21:23:26] * mru smells a contradiction
[21:23:38] <j0sh_> wbs: ahh ok
[21:24:02] <mru> the fate one does
[21:24:04] <Honoome> hmm my demangler is taking form.. this stuff is damn crap though, if I may say so :P
[21:24:22] <mru> Honoome: can't you just steal one somewhere?
[21:24:31] <j0sh_> wbs: lemme test tomake sure they all compile cleanly, one after another
[21:24:43] <Honoome> mru: hard to do given I want to implement it in pure Ruby for consistency
[21:25:05] <Honoome> plus I'm very much curious to see how crazy C++ mangling is ;)
[21:25:12] <mru> dig your own grave if you want...
[21:25:17] <mru> I won't stop you
[21:28:37] <Dark_Shikari> mru: openbsd having yasm would be problematic for them
[21:28:43] <Dark_Shikari> that would be a way for people to compile ssse3 on bsd!
[21:28:45] <Dark_Shikari> and they can't have that.
[21:28:52] * Dark_Shikari grumbles about 7-year-old binutils
[21:29:26] <mru> it's a posix/elf system so it's rather hard to stop someone running yasm
[21:30:06] <iive> Dark_Shikari: do you mean linking would fail if there is ssse3 code in object file?
[21:30:09] <Dark_Shikari> no
[21:30:14] <Dark_Shikari> I mean their as can't handle it
[21:30:19] <Dark_Shikari> because it's 7 years old
[21:30:27] <Dark_Shikari> and they won't upgrade because something something lazy something something gplv3
[21:30:40] <iive> it would corrupt xmm registers on task-switch?
[21:30:44] <Dark_Shikari> no
[21:30:50] <Dark_Shikari> that would be if they weren't sse-aware at all
[21:31:18] <iive> i'm not familiar with ssse3, they may have doubled the registers :)
[21:31:25] <Dark_Shikari> it's just new instructions
[21:31:27] <Dark_Shikari> not modifying old instructions
[21:31:33] <Dark_Shikari> doubling the registers requires modifying instructions
[21:31:40] <mru> not old ones
[21:31:54] <mru> you could add more registers only accessible by new instructions
[21:31:59] <iive> or using prefix
[21:32:00] <Dark_Shikari> True
[21:32:06] <Dark_Shikari> oh god not more prefix notation
[21:33:47] <j0sh_> wbs: done
[21:34:35] <roxfan> isn't the new xsave buffer dynamically sized or something?
[21:34:48] <j0sh_> Honoome: a demangler?
[21:34:57] <Honoome> j0sh_: yup.. yes I'm crazy
[21:35:17] <j0sh_> what is a demangler?
[21:35:25] <mru> inverse of a mangler
[21:35:36] <j0sh_> ahhh, of course :)
[21:35:58] <Dark_Shikari> BBB: so let's stop being lazy and finish up that asm :)
[21:37:06] <j0sh_> i'm never sure if you guys are being sarcastic or not
[21:37:07] <Honoome> j0sh_: c++filt is a demangler :P
[21:37:23] <mru> j0sh_: assume we are
[21:37:33] <j0sh_> heh
[21:38:07] <Dark_Shikari> mru: I get the feeling that trying to write a yasm conversion script would be an equivalent task to writing yasm
[21:38:18] <Dark_Shikari> (i.e. to convert yasm to Something Weaker Than Yasm)
[21:38:28] <mru> write a gas backend for yasm
[21:38:36] <Dark_Shikari> Which is basically writing yasm.
[21:38:45] <mru> no, that's writing part of yasm
[21:38:46] <Dark_Shikari> Just as writing a java->c convert is basically like writing a java compiler.
[21:38:49] <Dark_Shikari> *converter
[21:38:50] <mru> the other part is already written
[21:38:52] <Dark_Shikari> ok, it's writing the frontend.
[21:38:57] <Dark_Shikari> But assemblers are easy
[21:39:12] <Dark_Shikari> I mean, converting instructions to asm is downright trivial
[21:39:22] <Dark_Shikari> parsing a complicated macro language is harder
[21:39:23] <mru> there's more than that to an assembler
[21:40:29] * j0sh_ wrote an assembly language for whitespace once...
[21:41:07] <j0sh_> (that was to test my whitespace interpreter, of course)
[21:41:09] <j0sh_> http://en.wikipedia.org/wiki/Whitespace_(programming_language)
[21:44:56] <wbs> lu_zero: ok with the latest version that j0sh_ posted?
[21:50:18] <twnqx> i'm a bit stumped at the code i just read (libavformat/mpeg.c)
[21:50:25] <twnqx>    if (!((startcode >= 0x1c0 && startcode <= 0x1df) ||
[21:50:26] <twnqx>           (startcode >= 0x1e0 && startcode <= 0x1ef) ||
[21:50:26] <twnqx>           (startcode == 0x1bd) || (startcode == 0x1fd)))
[21:50:36] <twnqx> couldn't  one aggregate the first two checks into one?
[21:53:15] <mru> I guess it's for clarity
[21:54:23] <twnqx> mh
[21:54:50] <mru> cx is audio and ex is video
[21:55:09] <twnqx> and dx?
[21:55:15] <mru> also audio
[21:55:18] <twnqx> ah
[21:55:19] <mru> same range
[21:57:36] <mru> anyone know where twinvq samples are?
[21:58:46] <mru> Vitor1001: ^^
[21:59:53] <Vitor1001> http://samples.mplayerhq.hu/vqf/
[22:00:23] <Vitor1001> I suggest http://samples.mplayerhq.hu/vqf/luckynight/
[22:01:02] <mru> suggest for what purpose?
[22:02:15] <Vitor1001> For any testing.
[22:02:41] <Vitor1001> The complete set of files tests all the possible modes of the decoder
[22:03:40] <Vitor1001> mru: Just out of curiosity, why are you interested in twinvq?
[22:04:30] <mru> vla killing
[22:06:42] <Honoome> and this is interesting..
[22:06:46] <BBB> Dark_Shikari: yes yes, I told you, this weekend it'll be done
[22:06:55] <BBB> Dark_Shikari: I'm a bit slow today b/c of the football match and work
[22:07:01] <Honoome> I write a function as "void function(const unsigned char *a) {}"
[22:07:12] <Honoome> c++filt reports it as "function(unsigned char const *a)"
[22:07:25] <Honoome> while my own demangler reports it as I expected it to..
[22:07:49] <mru> the position of const doesn't matter
[22:08:45] <Honoome> I know, but it's a bit silly mostly because the mangling rules mangle the const _before_ the type
[22:08:54] <Honoome> so I was expecting it to do the logical thing and emit it as prefix
[22:10:00] <mru> c++ is not logical
[22:11:10] <Dark_Shikari> BBB: ok, I'm writing intra pred now
[22:11:12] <Honoome> true
[22:14:01] <BBB> great
[22:14:07] <BBB> hey wait, that one is easy
[22:14:09] <BBB> leave some for me...
[22:14:15] <BBB> maybe I'm too slow
[22:14:21] <BBB> go do the loopfilter
[22:14:24] <BBB> that's much more difficult
[22:14:31] * BBB goes home
[22:14:43] <CIA-99> ffmpeg: mru * r23763 /trunk/tests/ (15 files in 2 dirs): fate: add vp8 tests
[22:15:03] <Dark_Shikari> BBB: I already did intra pred in x264
[22:15:06] <Dark_Shikari> so this'll be bonus easy
[22:16:01] <mru> Vitor1001: patch for your reviewing pleasure
[22:16:58] <mru> he ran away
[22:19:21] <spaam> go after him mru
[23:03:19] * Honoome founds the mangler backreferences and cries
[23:03:21] <Dark_Shikari> collateral damage of vp8 optimizations: h264 gets faster
[23:03:30] <mru> lol
[23:03:40] <Dark_Shikari> 16x16 intra pred == h264 intra pred
[23:03:42] <Dark_Shikari> so...
[23:03:57] * mru did those in neon ages ago
[23:04:00] <Dark_Shikari> yeah
[23:04:04] <Dark_Shikari> I've done them in x264
[23:04:11] <Dark_Shikari> I'm just doing them again here, where things are a tad different
[23:04:14] <Dark_Shikari> specifically, stride is variable.
[23:07:07] <Dark_Shikari> 10 16x16 intra pred functions done.  now I have to figure out what the fuck TM pred does
[23:08:19] * peloverde just got an ADIF feature request, strange
[23:08:33] <Dark_Shikari> It seems to do row(N+1) = row(N) + leftpixel(N+1) - leftpixel(-1)
[23:08:47] <mru> adif... haven't heard that mentioned in a long, long time
[23:09:01] <Dark_Shikari> oh, no, it does row(N) = row(-1) + leftpixel(N) - leftpixel(-1)
[23:09:06] <Dark_Shikari> Hmm.  That's actually pretty cool.
[23:09:31] <Dark_Shikari> so that's saturateub(row(-1) + SPLAT(leftpixel(N)-leftpixel(-1)))
[23:09:45] <Dark_Shikari> ah fuck.  byte saturation.
[23:09:51] <Dark_Shikari> we get to add 9-bit signed bytes to AGHHHHHHHHHHHHH
[23:10:14] <kierank> someone is going to write an mvc decoder for ffmpeg it seems
[23:10:23] <Dark_Shikari> "write an mvc decoder"?
[23:10:26] <Dark_Shikari> mvc is almost the same as avc
[23:10:32] <Dark_Shikari> the only thing that differs is ref frame handling basically
[23:10:39] <Dark_Shikari> I really hope they don't replicate all the code
[23:10:48] <kierank> ok then...adapt the current h.264 avc decoder to decode h.264 mvc streams
[23:10:59] <Dark_Shikari> No, I had a serious point there -- people love contributing new code
[23:11:01] <Dark_Shikari> even if it's total shit
[23:11:09] <Dark_Shikari> *cough* h264 encoder
[23:11:15] <kierank> I will tell the guy that then
[23:11:29] <Dark_Shikari> yes, make sure that he integrates it
[23:11:33] <Dark_Shikari> as opposed to contributing replicated code
[23:11:37] <mru> 9-bit data...  designed for pdp (tm)
[23:11:54] <Dark_Shikari> mru: well it's the same as idct_dc
[23:11:59] <Dark_Shikari> you have a 9-bit signed offset to apply to 8-bit pixel data
[23:12:04] <lu_zero> Dark_Shikari: the h264 encoder is an educational project iirc
[23:12:12] <kierank> making ffmpeg handle dependent substreams is more complicated though
[23:12:18] <Dark_Shikari> yeah
[23:14:15] <mru> 14 vla-killing patches pending...
[23:14:29] <mru> this never ends...
[23:14:57] <mru> the ones in dsputil_mmx.c scare me
[23:14:57] <Dark_Shikari> lol
[23:15:04] <Dark_Shikari> isn't it sad
[23:15:59] <mru> why do people even bother with a vla when the size is guaranteed to be 1 or 2?
[23:16:36] <mru> gaaaah, uint8_t edge_buf[(h+1)*stride];
[23:16:58] <Dark_Shikari> WELCOME TO STRIDEWORLD
[23:17:00] <Dark_Shikari> ENJOY YOUR STAY
[23:17:03] <mru> lol
[23:17:08] <Dark_Shikari> SPONSORED BY BBB
[23:17:17] <spaam> \o/
[23:17:29] <mru> hey, the next one is easy
[23:17:36] <mru> ac3
[23:17:42] <mru> how many channels can it have?
[23:18:00] <mru> surely no more than 9
[23:18:30] <mru> bet eeek that function is ugly
[23:18:36] <mru> ac3_downmix_sse
[23:18:48] <mru> if(in_ch == 5 && out_ch == 2 && !(matrix_cmp[0][1]|matrix_cmp[2][0]|matrix_cmp[3][1]|matrix_cmp[4][0]|(matrix_cmp[1][0]^matrix_cmp[1][1])|(matrix_cmp[0][0]^matrix_cmp[2][1])))
[23:18:53] <mru> parse that!
[23:18:54] <Dark_Shikari> ahahahahahhah
[23:20:03] <mru> #define AC3_MAX_CHANNELS 6
[23:20:06] <peloverde> Speaking of downmix, does anyone have any AAC samplus with Dolby Pulse Downmix info?
[23:20:11] <mru> is that still true for eac3?
[23:20:19] <mru> and that other extension someone sent a patch for
[23:20:39] <peloverde> eac3 can do 7.1 I think, I don't know if we support it
[23:21:01] <peloverde> eac3 can do 13.1 according to wikipedia
[23:21:35] <mru> we support eac3 allegedly
[23:23:40] <peloverde> That's what I've been told
[23:25:18] <kierank> [00:20] <@peloverde> Speaking of downmix, does anyone have any AAC samplus with Dolby Pulse Downmix info? --> afaik there are no deployments
[23:25:33] <kierank> Possibly freeview HD but there are no pc receivers yet
[23:26:13] <Compn> you guys want more eac3 samples, get mplayer to apply some bluray patches :P
[23:26:32] <Compn> or review/commit yourself...
[23:31:21] <mru> the downmix matrix has AC3_MAX_CHANNELS rows
[23:31:34] <mru> so it should never be used with the extended channels
[23:32:22] <kierank> [00:26] <@Compn> you guys want more eac3 samples, get mplayer to apply some bluray patches :P --> dd+ is rare on blu-ray
[23:32:26] <kierank> common on hd-dvd
[23:32:45] <mru> #undef AC3_MAX_CHANNELS
[23:32:45] <mru> #define AC3_MAX_CHANNELS 7
[23:32:56] <mru> /* override ac3.h to include coupling channel */
[23:32:59] <mru> wtf???
[23:33:13] <peloverde> DD+ on bluray only supports up to 8 channels
[23:33:32] <peloverde> Is that like a CCE?
[23:33:50] <mru> I can't answer that
[23:33:54] <mru> but that's not the point
[23:34:06] <mru> defining the same thing differently in two places is beyond evil
[23:34:45] <peloverde> weren't you aware, the ac-3 decoder is part of a nefarious C contest
[23:35:32] <Dark_Shikari> mru: whenever you try to eliminate one bit of ugliness, deep inside the bowels of ffmpeg
[23:35:37] <Dark_Shikari> it always uncovers far worse evil.
[23:36:01] <mru> the last couple of days I've been poking in some of the oldest parts
[23:36:08] <Honoome> Dark_Shikari: reminds me of feng..
[23:36:43] <mru> there was one codec written by mike for xine, ported to mplayer by arpi, and ported from there to lavc by nick kurshev
[23:36:57] <Dark_Shikari> damn, arpi, that's like before recorded history
[23:37:00] <mru> if that's not asking for trouble
[23:37:28] * Dark_Shikari sees "corrupted stack"... hmm, ok, my asm looks wrong.
[23:38:30] * peloverde misses the days when broken ogg continutaions caused stack corruption in the theora decoder
[23:39:01] <kierank> what happens if you're VLA has a length of -1?
[23:39:04] <kierank> your*
[23:39:23] <twice11> I expect that to be undefined behavour.
[23:39:26] <Dark_Shikari> probably.
[23:39:31] <twice11> Isn't the array size specified as size_t?
[23:39:49] <Dark_Shikari> you know, mru, to really get rid of libvpx
[23:39:51] <twice11> So its not -1, but 2^32-1 or even 2^64-1
[23:39:56] <Dark_Shikari> we'll need to have ffmpeg's vp8 decoder be fast on arm...
[23:40:17] <mru> kierank: you die
[23:40:45] <mru> signed or unsigned, dreadful things happen
[23:41:07] <twice11> The total array size is bigger than representable in a size_t for objects with sizeof() > 1 -> undefined behaviour
[23:41:15] <mru> Dark_Shikari: I or yuvi will for sure do the neon
[23:41:34] <twice11> And you exceed an implementation limit (maximum object size on the stack) for objects with sizeof() == 1 -> undefined behaviour.
[23:42:05] <twice11> And finally: undefined behaviour -> you die. Mans is right.
[23:42:20] <Dark_Shikari> mru: ok
[23:42:46] <mru> or demons fly from your nose
[23:43:23] <mru> what the fuuuuuuuuuuuck?
[23:43:38] <mru> mmx etc float_to_int16_interleave uses a temp buffer!!!
[23:43:43] <mru> on stack
[23:43:51] <mru> same size as output
[23:43:56] <Dark_Shikari> lol
[23:44:21] <mru> how is that even possible?
[23:44:37] * peloverde mumbles somethingsomething planar float ouput
[23:44:40] <Dark_Shikari> there's no security risk there
[23:45:13] <kierank> ffmpeg should have a proper "week of cleanup"
[23:45:24] <Dark_Shikari> month
[23:45:32] <kierank> gsoc
[23:45:33] <mru> kierank: I'm trying my best
[23:45:35] <Dark_Shikari> actually
[23:45:36] <kierank> google summer of cleanup
[23:45:37] <Dark_Shikari> here's an idea
[23:45:50] <Dark_Shikari> All developers are prohibited from committing new patches until they do X patches of cleanup
[23:45:54] <Dark_Shikari> Or, equally
[23:46:03] <Dark_Shikari> they must do X patches of cleanup for every Y patches that aren't
[23:46:04] <mru> my new approach is do a cleanup pass, then add -Werror=foo to stop it happening again
[23:46:15] <peloverde> Could we try to get some ghop students to do cleanup?
[23:46:26] <Dark_Shikari> I don't think making the interns do the cleanup is the best idea.
[23:46:31] <Dark_Shikari> developers should be made to clean up their own mess.
[23:46:40] <mru> the problem is that students can't do it properly
[23:46:56] <mru> it has to be done by someone who knows the ins and outs of ffmpeg
[23:47:06] <peloverde> A lot of the messes were left by the ancients
[23:47:41] <mru> yes, but they're gone
[23:48:05] <Dark_Shikari> the precursors
[23:48:52] <peloverde> Jak and Daxter I?
[23:49:09] <Dark_Shikari> No, the precusor would be 0, obviously.
[23:49:13] <Dark_Shikari> =p
[23:55:41] * j0sh_ has been cleaning up mpeg4/aac from rtsp...
[23:56:21] <Dark_Shikari> new patch for vp8 sent, with intra pred asm (for h264 as well)