[FFmpeg-devel-irc] IRC log for 2010-09-01

[irc at mansr.com]

[00:00:13] <astrange> compile it with -S and see if the "mov 0x4(%ecx),%esi" is still there in the function
[00:00:51] <peloverde> bcoudurier: yes it errors out on me, but mov is human readable so it should be trivial to make another
[00:01:23] <BBB> can't I just submit the asm dump I just pastebin'ed?
[00:01:54] <astrange> sure
[00:02:12] <astrange> it's slightly less work for them if you can minimize the source attached
[00:05:14] <astrange> see if you can get them to adopt gcc-compatible preferred stack alignment too
[00:05:36] <CIA-11> ffmpeg: bcoudurier * r25014 /trunk/libavformat/gxfenc.c: gxf muxer only accepts pal or ntsc resolutions currently, so fail if resolution is something else
[00:11:14] <bcoudurier> hummm it errors out on the malloc
[00:11:17] <bcoudurier> werdio
[00:11:29] <bcoudurier> are you sure it's the good file ?
[00:19:00] <BBB> astrange: heh :)
[00:19:12] <BBB> let's do one thing at a time
[00:20:04] <peloverde> http://llvm.org/bugs/show_bug.cgi?id=1649
[00:21:24] <BBB> http://llvm.org/bugs/show_bug.cgi?id=8044
[00:23:01] <astrange> that bug is for stack alignment on entry, we want stack alignment on exit
[00:23:14] <BBB> on call, rather
[00:23:22] <astrange> yes
[00:23:25] <BBB> bleh, it's late
[00:23:27] * BBB goes home
[00:23:34] <BBB> asm debugging is kinda fun
[00:23:35] <astrange> i guess it'd make the stack a bit bigger per-function, though
[00:23:35] <BBB> addictive
[00:23:43] <BBB> but problematic if you want to go home
[00:24:00] <astrange> attach the preprocessed source when you're at home
[00:24:12] <BBB> how?
[00:24:16] <BBB> I can do it now
[00:24:21] <astrange> take the compile command
[00:24:31] <astrange> instead of -o x.o -c use -o x.i -E
[00:24:33] <astrange> and attach the .i
[00:27:21] <BBB> only this function?
[00:27:25] <BBB> or the whole file?
[00:30:30] <BBB> ohwell, they'll have to look a little harder
[00:30:36] * BBB goes home now
[00:32:08] <astrange> whole file
[00:32:23] <astrange> -S -emit-llvm might work too
[00:33:09] <BBB> I already gave it to them
[00:42:11] * funman wonders if BBB knows about make -k
[00:42:47] * mru tried to tell him about it
[01:47:49] * BBB is proud of finding his first compiler bug
[01:47:55] <BBB> so now what do I do?
[01:47:59] <BBB> just wait?
[01:49:08] <bcoudurier> party !
[02:12:53] <CIA-11> ffmpeg: diego * r25015 /trunk/ (libavcodec/ansi.c libavcore/parseutils.h libavcore/avcore.h): Use quotes instead of angle brackets for local #includes.
[02:38:32] <xxthink> av500: are you here?
[02:39:11] <xxthink> I have tried the flv mux problem, it's ok
[02:39:13] <xxthink> :)
[03:27:45] <xxthink> but how many audio frames can be saved continously in flv?
[03:57:24] <peloverde> happy mailman day
[06:29:36] <Tjoppen> god morgon
[06:29:51] <kshishkov> god morgon
[07:29:13] <KotH> salut
[07:36:42] <av500> salve
[07:41:13] <cartman> ehlo
[07:41:35] <av500> freestyle?
[08:10:59] <twnqx> hi guys, this is a question related to mplayer / ffmpeg interaction. ffmpeg presents the ac3 core of a truehd file as a separate audio stream, right? and that's not how it is in the transport stream?
[08:11:40] <twnqx> because something must be different between the extracted core and a real ac3 stream... i can't get mplayer to send it to my amp
[08:22:21] <Tjoppen> grr.. assertion failure in asfenc.c
[08:22:45] <Tjoppen> padsize>=0 online 587 if anyone's interested. no idea why yet though
[08:31:14] <av500> janneg: ping
[08:31:18] <mru> morning
[08:31:21] <av500> gm
[08:32:25] <pJok> god morgon
[08:36:09] <mru> av500: watch out, I'm heading in your general direction soon
[08:37:05] * av500 hides
[08:37:10] <av500> stop for coffee?
[08:41:52] * mru curses firefox
[08:46:26] <av500> firefox shrugs
[08:47:21] <mru> the print button has decided to do nothing at all
[08:47:31] <mru> not even an infinite loop
[08:49:38] <av500> it prints to the cloud
[08:49:39] <siretart> cheap button
[08:49:54] * mru looks at sky
[08:50:08] <mru> no clouds.. that explains it
[08:50:22] <av500> yes, monsun season seems over here
[08:50:27] <mru> siretart: the printer was cheap
[08:51:13] <av500> it came attached to an ink cartridge?
[08:51:18] <mru> yes
[10:27:20] <CIA-11> ffmpeg: aurel * r25016 /trunk/libavcodec/avcodec.h:
[10:27:20] <CIA-11> ffmpeg: add FF_API_PALETTE_CONTROL define to drop usage of AVPaletteControl
[10:27:20] <CIA-11> ffmpeg: and delay this transition to v54 as it is currently not functional
[10:58:35] * Terminating due to: TERM
[11:00:44] * /join #ffmpeg-devel ...
[11:00:46] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged.
[11:00:46] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886342
[11:02:45] <janneg> av500: pong
[11:03:12] <av500> monday ok?
[11:03:21] <av500> leave tue morning with beast
[11:03:21] <janneg> sure
[11:03:32] <av500> got a spare bunk?
[11:04:01] <janneg> yes
[11:04:07] <av500> splendid
[12:40:33] <CIA-11> ffmpeg: vitor * r25017 /trunk/tests/ (ref/vsynth1/qtrle ref/vsynth2/qtrle codec-regression.sh): QTRLE regtest
[12:41:03] <Vitor1001> BBB: Hi
[12:41:15] <cartman> Vitor1001: you make me wanna run fate over and over :-P
[12:41:18] <BBB> Vitor1001: hi
[12:41:29] <Vitor1001> cartman: :)
[12:42:42] <Vitor1001> BBB: Do you remember one patch you send once about order-two transfer function?
[12:46:10] <BBB> yes
[12:46:12] <BBB> long time ago
[12:46:15] <BBB> I think it was wrong
[12:46:21] <BBB> I didn't understand the function ;)
[12:46:41] <BBB> the one in ffmpeg svn is a little more complex, alex (peloverde) helped me out to understand I think
[12:47:05] <mru> BBB: btw, those wmavoice failures with armcc are compiler bugs
[12:48:30] <Vitor1001> BBB: I think that the AMRWB patch could use the same tips
[12:48:56] <Vitor1001> BBB: The function I'm talking about is http://ffmpeg.pastebin.com/Pq82NCVX
[12:51:28] <BBB> mru: ok, thanks for checking
[12:51:36] <BBB> Vitor1001: I can try to help... it looks familiar
[12:51:47] <BBB> remind me tomorrow, I'm completely unavailable most of today :(
[12:51:49] <mru> I check all failures on my machines, sooner or later
[12:52:19] <Vitor1001> BBB: ok, thanks
[12:52:29] <mru> btw fate is a bit ugly right now due to a networking glitch
[12:52:31] <Vitor1001> I'll try to find your original patch in the mean time
[12:52:41] <mru> it'll sort itself out soon enough
[12:52:59] <mru> meaning nfs is working properly again
[13:03:10] <Vitor1001> BBB: found it: "[PATCH] allow different input/output buffers for DC filter"
[13:04:43] <Vitor1001> BBB: But I'll stop bugging you now ;)
[13:05:06] <Compn> BBB : did you need WMAPro-in-WMAVoice samples ? there is one in incoming/
[13:05:26] <Compn> incoming/SP-DAY4-5.wmv
[13:05:39] <Compn> let me know if i should move to samples or delete
[13:06:53] <BBB> Compn: I have one
[13:06:57] <BBB> you can keep it though
[13:27:15] <mmu_screen> HTML	doc/developer.html
[13:27:15] <mmu_screen> Option number is ambiguous (number-footnotes, number-sections)
[13:27:17] <mmu_screen> Utiliser « texi2html --help » pour plus d'informations.
[13:28:42] <mmu_screen> texi2html --version = 5.0
[13:29:09] <mmu_screen> eh https://trac.macports.org/ticket/25888
[13:29:33] <mmu_screen> https://trac.macports.org/ticket/25803
[13:29:42] <mmu_screen> Seems that this is because texi2html 5.0 does not support '-number' option any longer.
[13:30:20] <funman> you can tell it's recent because the string isn't translated
[13:31:14] <mmu_screen> yep, and I just upgraded stuff with macport
[13:31:26] <funman> i have 1.82 (ubuntu) and --help only show --number-sections (two -)
[13:33:33] <mmu_screen> stripping -number seems to work
[13:33:40] <mmu_screen> same here
[13:33:50] <mmu_screen> -number likely was an antique option
[13:33:58] <mmu_screen> posting to thelist
[13:35:36] <mmu_screen> hmm interesting, realaudio works on OSX but not on BeOS...
[13:35:50] <mmu_screen> must be some issue with the old SDL
[15:39:44] <BBB> Dark_Shikari: why is ff_h264_idct_dc_add8_mmx2() in h264dsp_mmx.c under #if HAVE_YASM?
[15:39:53] <BBB> is that a mistake?
[15:40:11] <Dark_Shikari> because it calls yasm code iirc
[15:40:18] <Dark_Shikari> or it's used in tandem with yasm code
[15:40:29] <Dark_Shikari> I wrote it
[15:40:44] <Dark_Shikari> all I remember is that it has a relation to the x264 8x4 IDCT code
[15:43:17] <BBB> ok
[15:43:21] <BBB> I see no jmp/call in it
[15:43:25] <BBB> but I'm not looking very carefully
[15:43:28] <Dark_Shikari> No, I meant it was used in tandem
[15:43:31] <Dark_Shikari> in the c
[15:43:38] <BBB> ok
[15:43:43] <BBB> that makes sense then
[15:43:46] <Dark_Shikari> I mean seriously just grep
[15:43:51] <Dark_Shikari> it took me a grand total of 2.5 seconds
[15:43:56] <Dark_Shikari> Look where it's called.
[15:44:00] <BBB> right, ff_h264_idct_add16intra_sse2
[15:44:05] <Dark_Shikari>         if(nnzc[ scan8[i+0] ]|nnzc[ scan8[i+1] ])
[15:44:05] <Dark_Shikari>             ff_x264_add8x4_idct_sse2 (dst + block_offset[i], block + i*16, stride);
[15:44:09] <Dark_Shikari>         else if(block[i*16]|block[i*16+16])
[15:44:11] <Dark_Shikari>             ff_h264_idct_dc_add8_mmx2(dst + block_offset[i], block + i*16, stride);
[15:44:49] <BBB> got it, sorry
[15:45:31] <funman> BBB: you know make -k ?
[15:46:35] <BBB> I do since yesterday
[15:46:37] <merbzt1> Dark_Shikari: what would an 1,6 atom be able to encode with x264 ?
[15:47:03] <merbzt1> er what would it handle in realtime
[15:47:12] <Dark_Shikari> Not much.
[15:47:16] <Dark_Shikari> I'd guess maybe 640x480?
[15:47:21] <Dark_Shikari> on superfast or ultrafast
[15:47:29] <BBB> Dark_Shikari: all left in h264dsp_mmx.c locally is loopfilter and idct, do you want to help move it to yasm so we can delete h264dsp_mmx.c?
[15:47:33] <merbzt1> what bitrate ?
[15:47:35] <Dark_Shikari> BBB: sure
[15:47:39] <BBB> \o/
[15:47:40] <Dark_Shikari> merbzt1: bitrate doesn't have much of an effect on encoding speed
[15:47:44] <merbzt1> ok
[15:47:52] <Dark_Shikari> anyways this is just guessing you'd have to test
[15:48:05] <BBB> if you quickly review my old patch (mmx2 biweight/weight), I'll commit
[15:48:11] <BBB> then you can choose and I'll do the other
[15:48:43] <Dark_Shikari> Why not template all the biweights (sse2 and mmx) out of one function?
[15:49:08] <Dark_Shikari> Oh.  You did?
[15:49:12] <BBB> no
[15:49:16] <BBB> sse2 was already yasm
[15:49:20] <BBB> I moved the mmx2 to yasm
[15:49:21] <Dark_Shikari> Yes... so why not merge them?
[15:49:29] <merbzt1> the plan is to transcode SD tv and stream it at a lower resolution/bitrate
[15:49:30] <Dark_Shikari> .... and?
[15:49:31] <BBB> I could, but then the patch is bigger, michael might complain
[15:49:42] <Dark_Shikari> BBB: I will preemptively approve such a thing.
[15:49:44] <merbzt1> just wanted an idea if it would be possible at all
[15:49:46] <Dark_Shikari> Furthermore, you deleted the SSE2 code.
[15:49:51] <Dark_Shikari> thus, patch rejected.
[15:49:53] <BBB> ?
[15:49:58] <BBB> where?
[15:50:02] <Dark_Shikari> 150 onwards?
[15:50:34] <BBB> no, I renamed h264_weight_sse2.asm to h264_weight.asm
[15:50:44] <Dark_Shikari> then why do I only see the code being deleted?
[15:51:02] <BBB> because my stupid quitl tree doesn't understand svn cp
[15:51:14] <Dark_Shikari> ok
[15:51:18] <Dark_Shikari> please merge the two
[15:51:22] <BBB> ok
[15:51:23] <Dark_Shikari> more specifically, please delete the mmx code entirely
[15:51:28] <Dark_Shikari> lol
[15:51:33] <Dark_Shikari> since the sse2 is yasm originally
[15:51:36] <Dark_Shikari> and thus more right
[15:51:48] <Dark_Shikari> (this would have made your life easier earlier if you told me earlier)
[15:53:45] <BBB> the sse2 code isn't necessarily right, it only does 8x8 and 16x16
[15:53:52] <BBB> the mmx2 code does all blocksizes
[15:53:56] <BBB> (4x2-16x16)
[15:53:57] <Dark_Shikari> width4 in mmx is width8 in sse
[15:54:01] <Dark_Shikari> with INIT_MMX set
[15:54:04] <BBB> yes
[15:54:16] <Dark_Shikari> so just adjust number of iterations, etc
[15:54:24] <BBB> I guess I need to first rewrite the sse2 code to take more blocksizes into account
[15:54:48] <BBB> this won't be too hard, will take me another day though
[15:55:27] <Dark_Shikari> er....
[15:55:30] <Dark_Shikari> that's just a single macro param
[15:55:32] <Dark_Shikari> to the loop
[15:55:38] <Dark_Shikari> maybe 5 minutes
[15:55:58] <Dark_Shikari> i.e. mov r3, %2 instead of 4
[16:00:23] <BBB> hm... sse2 has no weight funcs
[16:00:36] <Dark_Shikari> Then go read x264's and make them! =p
[16:00:37] * BBB writes it all then :-p
[16:00:55] <Dark_Shikari> They're pretty dead easy.
[16:00:57] <BBB> yeah
[16:01:05] <Dark_Shikari> Now, as a future optimization, it would help to make something like x264's addone/subone weight functions
[16:01:09] <Dark_Shikari> which are simplified for common special cases
[16:01:09] <BBB> I should claim to not look at x264
[16:01:21] <Dark_Shikari> You're allowed to look just fine, apparently
[16:17:30] <thresh> kshishkov: in soviet .ru, iphone buys you http://www.imghost.in/images/73misk4ssxd0fmbnf2f3.jpg
[16:28:44] <kshishkov> thresh: http://tema.livejournal.com/717661.html
[17:31:12] <bcoudurier> hi guys
[17:54:30] <BBB> hm... everything works, except my ssse3 biweight 8x4 and 16x8
[17:54:31] <BBB> that's odd
[17:56:41] <BBB> oh duh
[17:56:45] <BBB> wrong function pointer assigned
[17:56:46] <BBB> no wonder
[18:02:11] <elenril> bcoudurier: can i nag you about the vorbis metadata patch again?
[18:02:19] <BBB> Dark_Shikari: done
[18:02:46] * elenril wonders if BBB's work will fix clang on 32bit
[18:02:56] <BBB> elenril: it does
[18:03:09] <BBB> except for the compiler bug (llvm issue 8044 I think)
[18:03:40] <elenril> it's still red on fate
[18:03:44] <BBB> http://llvm.org/bugs/show_bug.cgi?id=8044
[18:03:53] <BBB> I didn't apply it yet
[18:04:02] <elenril> ah
[18:04:06] <elenril> that's awesome then
[18:04:14] <BBB> I just see reimar agreed, so now if pengvado (he wrote this) can review it, I'd be very happy
[18:04:23] <BBB> and it'll still be half-red because of the compiler bug ^^
[18:04:31] <elenril> :/
[18:07:04] <BBB> elenril: fi the compiler bug ;)
[18:07:10] <BBB> or, better, help me fix other fate issues
[18:07:16] <BBB> I'm getting the hang of it
[18:07:26] <elenril> haha very funny
[18:07:32] * elenril knows next to nothing about asm
[18:07:52] <BBB> I knew nothing until +/- 3 months ago
[18:08:02] <funman> write it in C, use gcc -S, pretend you wrote it :-)
[18:08:11] <elenril> lol
[18:08:27] * elenril also knows next to nothing about compilers and video coding
[18:09:16] <bcoudurier> elenril, yes
[18:10:03] <bcoudurier> sorry what's the name of the thread ?
[18:13:07] <elenril> bcoudurier: Add VorbisComment writing for Vorbis and Theora streams in Ogg
[18:26:19] <bcoudurier> thanks
[18:28:23] <BBB> Dark_Shikari: will you do idct or loopfilter? then I'll start working on the other one while I wait for your (weight/biweight) and pengvado's (h264dsp_mmx split and clang fixes in loopfilter code) review
[18:30:10] <BBB> actually, the split is 3 days old
[18:30:12] <BBB> I'll apply it
[18:32:36] <Dark_Shikari> no, school just started here, I'm busy
[18:32:43] <Dark_Shikari> loopfilter you can just copy x264's
[18:32:52] <Dark_Shikari> as in, you can port the rest of x264's loopfilter code, and delete ffmpeg's
[18:32:59] <Dark_Shikari> Because Loren LGPL'd it
[18:33:24] <Dark_Shikari> NB: you'll want to copy the loopfilter code from before we NV12'd it.
[18:33:28] <Dark_Shikari> You should probably ask him first though
[18:33:33] <Dark_Shikari> as he only LGPL'd the code that's actually in ffmpeg
[18:33:36] <Dark_Shikari> i.e. not the mmx stuff
[18:33:45] <Dark_Shikari> pengvado: ^
[18:34:03] <pengvado> ok
[18:34:18] <Dark_Shikari> ok, now x264's (old) asm will match up with ffmpeg's.
[18:34:24] <Dark_Shikari> Well, except for your stack alignment changes.
[18:34:28] <Dark_Shikari> Speaking of which, did pengvado ever review that?
[18:36:54] <pengvado> patch ok if you want to cause ffmpeg's copy of deblock to diverge more than it already does from x264's.
[18:37:08] <pengvado> I like being able to assume aligned stack in x264
[18:37:17] <Dark_Shikari> pengvado: of course, we're already diverging with nv12 vs yv12
[18:37:20] <Dark_Shikari> though that only applies to chroma
[18:37:25] <mru> I like to have a pony
[18:38:12] <pengvado> do you have a pony? cause I do currently have an aligned stack.
[18:43:00] <mru> if I close my eyes and imagine really hard, yes I have a pony
[18:43:22] * mru curses usb
[18:43:39] <bcoudurier> ahh ponies ...
[18:43:42] <mru> it just has to fuck up the minute after I close the door
[18:43:52] <mru> to be gone for a few weeks
[18:45:38] <_av500_> mru: coffee tomorrow then
[18:47:50] <mru> if anyone can think of a way to remotely reboot a linux system whose sshd has died, I'm all ears
[18:48:28] <mru> it's on nfsroot
[18:48:39] <mru> unfortunately not running cron
[18:50:34] <_av500_> gently nuke from orbit?
[18:51:03] <mru> sadly I don't see any OADS above it
[18:51:50] <_av500_> well, then ask the nerdy landlady to reboot it
[18:52:45] <mru> even if someone had a key, I'd be hesitant to ask them to touch that particular board
[18:54:32] <_av500_> which one?
[18:54:44] <mru> the sheeva
[18:55:02] <_av500_> you worry because your fringe cpu locked up?
[18:55:17] <mru> it hasn't locked up
[18:55:20] <_av500_> ill hook mine up for you :)
[18:55:24] <mru> for some reason sshd has died
[18:56:00] <BBB> hehe @ pony & aligned stack
[18:56:07] <BBB> that was kind of funny
[18:56:16] <BBB> I'll test with clang's -align-stack=16 to see if that helps
[18:56:19] <BBB> if it doesn't, I'll apply
[18:56:25] <BBB> else I need to learn configure magic
[19:06:39] <Dark_Shikari> BBB: looks good to me
[19:06:51] <Dark_Shikari> are we going to make configure fail by default if --disable-yasm isn't set and yasm isn't installed?
[19:06:54] <Dark_Shikari> or is that already done
[19:07:12] <mru> it's done
[19:07:14] <peloverde> I did that
[19:07:20] <peloverde> Or at least thought I did
[19:07:24] <BBB> you did
[19:07:27] <BBB> I remember that
[19:07:55] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blobdiff;f=configure;h=6311ef0a66de013e3709501695eae66a7ab5d73d;hp=d141089dfc41c130041f9bfd4c00213e362b03b9;hb=fbf9b2051a3f3f3722795ca017173c5d51f10182;hpb=770d0c22c9a2ed9151ac19651eba7839eab523c3
[19:08:08] <cartman> gitweb and its ugly URLs
[19:08:08] <peloverde> mru: prettied up the error message later
[19:08:48] <Dark_Shikari> sweet
[19:10:01] <BBB> Dark_Shikari: so you do loopfilter or you do idct?
[19:10:07] <BBB> let's kill h264dsp_mmx.c!
[19:10:18] <BBB> (except for the init code, but then we can rename it to h264dsp_init.c)
[19:10:37] <mru> KILL KILL
[19:11:33] <Dark_Shikari> as I said, I'm busy and lazy
[19:11:44] <Dark_Shikari> now if you mean "port the x264 loopfilter code..." hmm maybe
[19:11:58] <Dark_Shikari> but I have classes soon and meh
[19:12:12] <mru> and there's xvp8 to be written
[19:12:44] <Dark_Shikari> yup
[19:13:15] <Dark_Shikari> BBB: pengvado ok'd your stack patch
[19:37:29] <BBB> Dark_Shikari: yeah why don't you port the x264 loopfilter code
[19:37:32] <BBB> Dark_Shikari: assuming it's lgpl
[19:37:42] <BBB> Dark_Shikari: and then I'll fix the stack after that
[19:38:17] <Dark_Shikari> as I said I have classes, gotta leave in about 15 minutes or so
[19:38:29] <Dark_Shikari> I mean really it's just copy-pasting
[19:41:32] <BBB> ok, ok, go ;)
[19:41:34] <BBB> I'll do it
[19:41:48] <BBB> it brings me closer to my goal of killing all inline asm that could be yasm
[19:42:12] <Dark_Shikari> all inline asm that is not actually inline should be killed.
[19:42:19] <mru> ack
[19:42:19] <BBB> right
[19:42:29] <BBB> I'm working on it :-p
[19:43:29] <Dark_Shikari> if you want, a possible future task (after xvp8 and all that) would be to start fixing up ffmpeg's encoding asm and other such things
[19:43:34] <Dark_Shikari> e.g. porting in some x264 asm for SAD
[19:43:36] <Dark_Shikari> SATD
[19:43:36] <Dark_Shikari> etc
[19:43:45] <Dark_Shikari> since basically everything that isn't h264 or vp8 is stuck in the stone age
[19:44:47] <BBB> let's port x264 to ffmpeg
[19:45:12] <funman> but it's ill, it has a viral license
[19:50:29] <cartman> if you port it RMS will come and eat all the kittens
[19:54:37] <funman> do it in soviet russia then?
[19:56:12] <mru> kittens eat rms there?
[19:56:34] <funman> you'd need a lot of kittens but yeah
[19:56:59] <_av500_> from what i heard, rms might eat kittens
[19:57:18] <funman> free as in freedom to eat kittens!
[19:57:35] <_av500_> dont tell peta
[19:59:19] <cartman> I am not kidding :P
[20:49:55] <CIA-11> ffmpeg: rbultje * r25018 /trunk/libavcodec/x86/ (5 files):
[20:49:55] <CIA-11> ffmpeg: Split h264dsp_mmx.c (which was #included in dsputil_mmx.c) in h264_qpel_mmx.c,
[20:49:55] <CIA-11> ffmpeg: still #included in dsputil_mmx.c and is part of DSPContext, and h264dsp_mmx.c,
[20:49:55] <CIA-11> ffmpeg: which represents H264DSPContext and is now compiled on its own.
[20:52:18] <Compn> pretty soon we'll have libavcodec/h264/ :P
[20:52:55] <mru> libavh264
[20:53:42] <Dark_Shikari> I mean, if I had unlimited time
[20:53:45] <Dark_Shikari> I'd want to split all of lavc
[20:56:17] <mru> split how?
[20:56:24] <Dark_Shikari> libavcodec/h264/*
[20:56:33] <Dark_Shikari> libavcodec/vpx/*
[20:56:36] <Dark_Shikari> libavcodec/mpegvideo/*
[20:56:37] <BBB> I hope people don't flame me for the next commit
[20:56:47] <Dark_Shikari> of course, we'd get into bikesheds about exactly how to split everything
[20:56:47] <mru> BBB: what's it going to be?
[20:56:55] <BBB> I already committed it
[20:57:04] <mru> Dark_Shikari: well, a lot is shared code
[20:57:13] <mru> and a lot of codecs are only a single file
[20:57:21] <mru> putting those in a dir won't help anything
[20:57:45] <Dark_Shikari> mru: Yeah, the idea is that in a dir you could split them more reasonably
[20:58:09] <CIA-11> ffmpeg: rbultje * r25019 /trunk/libavcodec/x86/ (Makefile h264_weight_sse2.asm h264_weight.asm h264dsp_mmx.c):
[20:58:09] <mru> most of them are small enough that it's not a problem with a single file
[20:58:09] <CIA-11> ffmpeg: Rename h264_weight_sse2.asm to h264_weight.asm; add 16x8/8x16/8x4 non-square
[20:58:09] <CIA-11> ffmpeg: biweight code to sse2/ssse3; add sse2 weight code; and use that same code to
[20:58:09] <CIA-11> ffmpeg: create mmx2 functions also, so that the inline asm in h264dsp_mmx.c can be
[20:58:09] <CIA-11> ffmpeg: removed. OK'ed by Jason on IRC.
[20:58:30] <Dark_Shikari> BBB: sounds good
[21:03:30] <mru> BBB: you broke something
[21:03:53] <spaam> fate going to be yellow? :)
[21:03:58] <mru> red
[21:04:09] <spaam> oh no
[21:04:15] <mru> it ain't building
[21:04:41] <mru> at least not on x86
[21:05:21] <Dark_Shikari> oh god
[21:05:22] <Dark_Shikari>  jmp _ff_h264_weight_16x16_mmx2.nextrow
[21:05:24] <Dark_Shikari> bad BBB
[21:05:26] <Dark_Shikari> bad bad bad bad bad
[21:05:40] <mru> isn't there a macro for that?
[21:05:43] <Dark_Shikari> Yes
[21:05:59] <mru> please fix it then
[21:06:03] <Dark_Shikari> example from x264
[21:06:04] <Dark_Shikari> jmp mangle(x264_pixel_ssd_%1x%1_%3.startloop)
[21:06:20] <Dark_Shikari> BBB: ^^^^^^
[21:06:30] <BBB> mangle?
[21:06:31] <BBB> oh
[21:06:32] <BBB> oops
[21:06:38] <mru> fucking mac-using idiots
[21:06:38] <BBB> you reviewed it, why didn't you say something?
[21:07:19] <BBB> mangle(ff_..) or mangle(..)?
[21:07:23] <spaam> mru: what did they do this time? :)
[21:07:23] <mru> BBB: so you did get flamed
[21:07:41] <mru> spaam: BBB is one of them
[21:07:50] <spaam> aha :)
[21:07:54] <Dark_Shikari> mangle(ff_
[21:08:02] <Dark_Shikari> BBB: I assumed you tested it.
[21:08:07] <BBB> yes of course
[21:08:19] <mru> mac doesn't count as testing
[21:08:24] <Dark_Shikari> lol
[21:08:49] <mru> speaking of which, has anyone tested on iphone recently?
[21:09:20] <BBB> my contract is about to expire, then I'll get a iphone 4g or whatever is new then, and then I'll test
[21:09:34] <BBB> running make fate-h264 on 64/32 and then I'll fix it
[21:09:38] <cartman> ffmpeg on iphone? interesting
[21:10:10] <spaam> running fate on it \o/
[21:10:13] <mru> cartman: it's a supported platform
[21:10:25] <BBB> fixed
[21:10:27] <cartman> since its ARM thats expected :)
[21:10:27] <BBB> oops
[21:10:33] <mru> albeit with uch cursing
[21:10:45] <mru> cartman: they don't use standard abi
[21:10:59] <cartman> mru: but you guys can figured it out :)
[21:11:09] <mru> it's documented
[21:11:09] <CIA-11> ffmpeg: rbultje * r25019 /trunk/libavcodec/x86/ (Makefile h264_weight_sse2.asm h264_weight.asm h264dsp_mmx.c):
[21:11:10] <CIA-11> ffmpeg: Rename h264_weight_sse2.asm to h264_weight.asm; add 16x8/8x16/8x4 non-square
[21:11:10] <CIA-11> ffmpeg: biweight code to sse2/ssse3; add sse2 weight code; and use that same code to
[21:11:10] <CIA-11> ffmpeg: create mmx2 functions also, so that the inline asm in h264dsp_mmx.c can be
[21:11:10] <CIA-11> ffmpeg: removed. OK'ed by Jason on IRC.
[21:11:10] <CIA-11> ffmpeg: rbultje * r25020 /trunk/libavcodec/x86/h264_weight.asm: Unscrew breakage after my last commit because of symbol prefixes.
[21:11:13] <cartman> what kinda fucked up sentence was that, s/can//
[21:11:21] <cartman> mru: Apple documents stuff? thats new
[21:11:22] <mru> it's simply annoying to support it
[21:11:48] <mru> the dcumentation is pretty good
[21:11:51] <cartman> iPhone is worthless, iPad is a more interesting target
[21:11:56] <mru> it's what it documents that sucks
[21:12:04] <cartman> lol :)
[21:12:12] <BBB> is it green again?
[21:12:15] <cartman> sounds like MSDN
[21:12:30] <spaam> BBB: it builds now on my desktop :)
[21:12:49] <cartman> BBB: I'll late fate to decide :P
[21:12:52] <mru> BBB: wait ~3 minutes and we'll see
[21:12:53] <cartman> let*
[21:12:55] <cartman> bah
[21:15:29] <mru> yay, it's green
[21:15:42] <BBB> \o/
[21:16:57] <spaam> mru: did you add make checkheaders  as a test also ? :)
[21:17:09] <mru> no
[21:21:30] <BBB> Dark_Shikari: why are idct_add16/8_sse2 gpl?
[21:21:40] <BBB> and add16_intra
[21:22:40] <Dark_Shikari> because the x264 asm they call is
[21:22:51] <Dark_Shikari> and they're useless without it
[21:23:05] * BBB will start with loopfilter
[21:23:10] <BBB> lgpl code is always better than gpl code
[21:23:19] <BBB> pengvado was ok with lgpl'ing the non-nv12 parts right?
[21:23:29] <BBB> and it's already yasm \o/
[21:23:33] <Dark_Shikari> He was OK with LGPLing the entire asm as it was before the nv12 commit
[21:23:42] <Dark_Shikari> which includes the chroma asm
[21:23:42] <BBB> right
[21:24:05] * BBB goes look for a webgit
[21:24:12] <cartman> BBB: gitweb
[21:25:58] <BBB> http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/x86/deblock-a.asm;hb=97c7ecc5aae7739ad91e1d6d3cdd3d26aafefb06
[21:26:16] <BBB> http://git.videolan.org/gitweb.cgi?p=x264.git;a=blob;f=common/x86/deblock-a.asm;hb=6dc1217f510ece46166376dcca1d6b19d088a3b5
[21:26:19] <BBB> that one actually
[21:26:30] <BBB> (only difference is that jason added his (c), which probbaly should be there)
[21:36:01] <BBB> Dark_Shikari: last question of the day from me
[21:36:03] <BBB> #if ARCH_X86_32
[21:36:03] <BBB>             c->h264_v_loop_filter_luma_intra = ff_x264_deblock_v_luma_intra_mmxext;
[21:36:03] <BBB>             c->h264_h_loop_filter_luma_intra = ff_x264_deblock_h_luma_intra_mmxext;
[21:36:09] <BBB> why is that #if'ed?
[21:36:26] <BBB> (I know that it'll use the sse2 code later on, but we don't #if that elsewhere either)
[21:37:40] <Dark_Shikari> because the mmx code isn't compiled on x86_64
[21:37:42] <Dark_Shikari> sse2 is always faster
[21:38:22] <iive> even on amd64?
[21:39:05] <Dark_Shikari> yes, that's the whole point
[21:47:24] <BBB> Dark_Shikari: that reminds me that we (I :-p) should do that for ffvp8dec also
[21:47:39] <BBB> later... let's first integrate the loopfilter and remove more inline asm
[21:47:53] <BBB> will work on that tonight, need some food first
[23:01:54] <CIA-11> ffmpeg: bcoudurier * r25021 /trunk/libavformat/vorbiscomment.c: cosmetics: spaces between and after parentheses
[23:15:12] <efriedma> could someone please apply http://paste.pocoo.org/show/257375/ ?
[23:20:28] <CIA-11> ffmpeg: bcoudurier * r25021 /trunk/libavformat/vorbiscomment.c: cosmetics: spaces between and after parentheses
[23:20:29] <CIA-11> ffmpeg: darkshikari * r25022 /trunk/libavcodec/x86/h264_weight.asm:
[23:20:29] <CIA-11> ffmpeg: Fix typo in r25019.
[23:20:29] <CIA-11> ffmpeg: Patch by Eli Friedman <eli.friedman at gmail dot com>.