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

[irc at mansr.com]

[00:28:13] <peloverde> Dark_Shikari, your new patch has line ending issues
[00:28:13] <Dark_Shikari> oh, I'll fix that.
[00:28:13] <Dark_Shikari> in h264_intrapred.asm only right?
[00:28:25] <peloverde> yes only in that file
[00:28:34] <peloverde> Also "Added: svn:executable"
[01:16:46] * Terminating due to: TERM
[01:16:58] * /join #ffmpeg-devel ...
[01:17:00] *** 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.
[01:17:00] *** TOPICINFO: peloverde!~alex at cpe-173-88-148-20.neo.res.rr.com, 1276886498
[01:19:53] <CIA-99> ffmpeg: bcoudurier * r23764 /trunk/libavformat/mov.c: Improve mov atom parsing debug message, print parent atom and size in decimal
[01:23:00] <mru> anyway, the silly float_to_int_interleave converts each channel linearly into a temp buffer, then scatters it into the output buffer
[01:25:44] <bcoudurier> kierank, nice progress on dolby-e
[01:26:14] <mru> wouldn't it be more efficient to scatter-store the samples directly?
[01:26:15] <pengvado> yes, for the odd case that I didn't bother to optimize
[01:26:52] <mru> pengvado: so you make a fucking vla with unbounded size instead?
[01:27:07] <pengvado> yes
[01:27:10] <mru> WHY????
[01:27:20] <mru> do you have a deathwish?
[01:27:47] <Dark_Shikari> because ffmpeg doesn't have h->scratch_buffer ?
[01:27:49] <kierank> bcoudurier: there are still many mysteries to figure out.
[01:28:06] <kierank> like syntax elements that seem to do nothing
[01:28:22] <bcoudurier> can you hear sound yet ?
[01:28:41] <kierank> the mdct is not implemented yet, so no
[01:28:47] <bcoudurier> ok
[01:28:54] <bcoudurier> what's your sample again ? mxf or ts ?
[01:29:01] <mru> Dark_Shikari: and why not store directly to the final destination?
[01:29:15] <kierank> and the binary decoder i haven't been able to get sound out of (i have no idea why but i'm sure it's a 10l somewhere)
[01:29:16] <pengvado> because even though I didn't spend any effort optimizing that case, I thought that "sub esp, foo"was faster than malloc.
[01:29:31] <kierank> bcoudurier: a sample i made with the encoder
[01:29:32] <mru> you don't need a temp buffer AT ALL
[01:30:05] <Dark_Shikari> "didn't spend any effort"
[01:30:10] <pengvado> do I then special-case the last sample, or accept writing beyond the end?
[01:30:20] <mru> Dark_Shikari: that's negative effort
[01:30:30] <mru> it's actively stupid
[01:30:41] <mru> pengvado: ???
[01:31:13] <Dark_Shikari> "laziness is a cardinal virtue"
[01:31:15] <pengvado> there is no 16bit store from mmx. (well there's pextrw, but that's slow)
[01:31:21] <mru> gaaaaaaaaaaaaaaaaah
[01:31:31] <Dark_Shikari> Oh yeah, and what pengvado said.
[01:31:35] <mru> see why x86 is annoying?
[01:31:40] <Dark_Shikari> mru: compare altivecd
[01:31:44] <Dark_Shikari> it has no 32-bit or 64-bit store
[01:31:49] <mru> compare neon
[01:31:55] <Dark_Shikari> Not everything is like neon
[01:31:57] <lu_zero> compare spu
[01:31:59] <Dark_Shikari> in fact, most things are not like neon
[01:32:01] <pengvado> altivec has a 32bit store, but it requites 16byte alignment...
[01:32:02] <mru> has 8, 16, 32, 64, 128, 256
[01:32:15] <mru> to/from _any_ position
[01:32:16] <kierank> bcoudurier: mxf and ts will need some fixes. Probably in conjunction with latm, some sort of way of searching the packet for 337m headers or latm headers.
[01:32:35] <lu_zero> Dark_Shikari: altivec should be compared to mmx
[01:33:13] <Dark_Shikari> mmx had 32-bit stores too
[01:33:19] <Dark_Shikari> mmx had no alignment restrictions
[01:33:23] <lu_zero> so?
[01:33:30] <mru> to be fair, the guy designing neon had mmx and altivec to avoid mistakes from
[01:33:34] <Dark_Shikari> and what mru said.
[01:33:53] <lu_zero> alignment restrictions complaint are similar about compare&swap complaints...
[01:33:54] <mru> thankfully he had the insight to do so
[01:34:15] <mru> compare&swap is silly
[01:34:18] <bcoudurier> ts should use s302m no ?
[01:34:19] <pengvado> anyway, I could have not used mmx at all for the cases I didn't cother to specialize. or I could have used malloc. whatever, I don't see anything to apologize for.
[01:34:36] <mru> load-locked/store-exclusive is much easier to implement and more flexible to use
[01:34:50] <Dark_Shikari> mru: btw, the only weakness I can spot in NEON is the lack of pmovmskb and its inverse (mmx doesn't have the inverse either)
[01:34:54] <lu_zero> yet I got people complaining to me about that
[01:34:58] <mru> pengvado: you have a frikkin vla to apologise for
[01:34:59] <Dark_Shikari> or, in general, byte -> bit and vice versa.
[01:35:06] <lu_zero> since ppc was so limited because of that
[01:35:13] <kierank> bcoudurier: yes you're right, ts will have another step but you might just be able to handle that in the ts demuxer because afaik you can't have 302m in mxf or anything else
[01:35:20] <lu_zero> then we looked at behaviour and latency...
[01:36:38] <mru> anyway, enough blaming
[01:36:44] <mru> how do we fix it?
[01:37:29] <Dark_Shikari> btw, mru, how are you detecting vlas?
[01:37:32] <Dark_Shikari> or just looking at the code?
[01:37:34] <mru> -Werror=vla
[01:37:38] <Dark_Shikari> i.e. did you explicitly go looking at the asm to find it?
[01:37:46] <Dark_Shikari> er... but that won't catch yasm will it?
[01:37:49] <Honoome> mru: uh... nice one that.. /me checks on feng
[01:38:09] <mru> Dark_Shikari: no, but I have to stop somewhere
[01:38:18] <Dark_Shikari> but how did you find float interleave ?
[01:38:30] <mru> the vla is in c
[01:39:02] <bcoudurier> mxf uses either sdti-cp S385M or aes3/wav
[01:39:02] <Dark_Shikari> ahhh k
[01:39:03] <mru> I'd hope there are no bad vlas in the yasm code
[01:39:05] <bcoudurier> should
[01:39:17] <Honoome> guuuh autoconf fails to identify a c99 compiler if you use -Werror=vla ....
[01:39:25] <mru> wtf
[01:39:34] <Dark_Shikari> mru: just grep for regex "sub[ ]*esp,"
[01:39:36] <Dark_Shikari> ;)
[01:39:47] <mru> Dark_Shikari: a vla would have to use ___chkstk on windows
[01:40:01] <bcoudurier> in any case it shouldn't be difficult to handkle
[01:40:33] <Dark_Shikari> mru: true
[01:40:37] <Dark_Shikari> yeah, i doubt any yasm uses it
[01:40:40] <Dark_Shikari> definitely none in x264
[01:40:41] <Dark_Shikari> in C or yasm
[01:41:11] <kierank> bcoudurier: it will need a round of bikeshedding on ffmpeg-devel.
[01:42:04] <mru> if something is allocating a small variable amount in yasm I don't care
[01:42:14] <pengvado> pixel_ads does
[01:42:25] <bcoudurier> why, you don't want to handle it in the decoder ? :)
[01:42:44] <Dark_Shikari> pengvado: oh, you're right
[01:42:54] <mru> what does it do?
[01:43:04] <Dark_Shikari> that would make it the only one
[01:43:57] <Dark_Shikari> mru: successive elimination for exhaustive motion search.  the stack space appears to be a place to output candidates before iterating over them in scalar
[01:44:08] <bcoudurier> personnally I start to think that we should have a format field in AVCodecContext
[01:44:22] <bcoudurier> set to the format variant
[01:44:34] <bcoudurier> or we could just use a different codec_id
[01:44:42] <pengvado> if they're processed in the right order, we could use the output space as tmp too
[01:45:16] <kierank> bcoudurier: how will the container know whether it's plain wav or dolby e. (equally for aac whether it's plain aac or latm). The way ffmpeg's designed right now means the container sets the number of streams
[01:45:32] <Dark_Shikari> pengvado: are they?
[01:45:44] <kierank> 302m makes this more complicated because you have to parse that too
[01:47:01] <kierank> also it doesn't help that 302m allows non-byte-aligned 20-bit audio which would have to be made 24-bit or 32-bit aligned
[01:48:59] <bcoudurier> kierank, the ts knows if it's latm
[01:49:08] <bcoudurier> the ts knows if it's s302m too
[01:49:23] <kierank> we still have the problem then for mxf and plain wav
[01:49:25] <bcoudurier> mxf is supposed to use another codec ul
[01:49:34] <bcoudurier> but all files do not use it
[01:49:42] <bcoudurier> so in that case, you need a codec probe
[01:50:01] <kierank> you'd need a "container probe"
[01:50:27] <kierank> also afaik some of the japanese streams still flag the audio as aac
[01:50:35] <kierank> even though it's latm
[01:50:46] <bcoudurier> are you sure about that ?
[01:51:02] <bcoudurier> what stream type is it using ?
[01:52:17] <pengvado> Dark_Shikari: yes
[01:53:00] <Dark_Shikari> pengvado: patches welcome then
[01:53:10] <Dark_Shikari> preferably after you send me the comments for the patches you said you would send comments on
[01:53:26] <Dark_Shikari> hmm.  would there be any objections to me just committing tons of non-bikeshed vp8 optimizations?
[01:53:30] <Dark_Shikari> i.e. C optimizations
[01:53:33] <Dark_Shikari> not asm or anything outside of vp8.c
[01:55:08] <kierank> bcoudurier: looks like mpeg-2 aac.
[01:55:21] <kierank> whatever the id is for that; i forget
[01:58:46] <kierank> there will also be a flurry of brits complaining about lack of latm support soon to so it's something that should be dealt with if one could sort out dolby e and latm in the same swoop
[01:59:52] <Honoome> oh my latm again?
[02:05:00] <janneg> bcoudurier: there should be a sample in roundup which switches from adts to latm in stream
[02:05:32] <bcoudurier> without a new pmt ?
[02:06:23] <kierank> maybe there's a descriptor or something. however there are no good ts analyzing apps so it's difficult to tell
[02:06:43] <janneg> I don't remember
[02:07:53] <janneg> kierank: I'm currently writing latm demuxer and the idea is to integrate it then as subdemuxer into the mpeg ts demuxer
[02:08:18] <kierank> can latm go in anything other than ts?
[02:09:48] <kierank> mp4 possiblty
[02:09:49] <mru> it can go insane
[02:11:32] <kierank> latm doesn't have a good reason to do such weird things. dolby e arguably does
[02:11:58] <janneg> bcoudurier: http://roundup.ffmpeg.org/issue1999
[02:12:32] <kierank> freeview hd will be doing latm with 2 programs inside I think
[02:13:40] <janneg> so we need a demuxer or at least something which can produce more than one stream
[02:14:34] <bcoudurier> janneg, why in the ts demuxer ?
[02:14:53] <kierank> a chained demuxer would be best but it would need some bikeshedding to get it agreed upon
[02:20:33] <janneg> bcoudurier: I have easier than chained demuxers
[02:20:47] <janneg> s/I have //
[02:23:11] * Honoome wonders if the people who would like to see FatELF have an idea what LSB is/was
[02:25:09] <bcoudurier> janneg, ok
[02:25:09] <Honoome> lu_zero, j0sh_, wbs: if you care, feng just merged in the netembryo 0.2.0 branch into master ;)
[02:25:20] <bcoudurier> something that works will be ok with me :>
[02:34:02] <Honoome> stupid C++ optimisations, I can't get it to emit a constructor for me
[02:34:52] <bcoudurier> yes this ts sample looks broken
[02:35:41] <kierank> worth saying coreaac handles it fine
[02:35:49] <kierank> and mplayer if you seek into the latm part
[02:41:18] <Compn> Dark_Shikari : google should hire you to work on libvp8
[02:41:22] <Compn> :P
[02:41:40] <Dark_Shikari> Well they're going to enjoy my "fuck you"
[02:41:42] <Dark_Shikari> all this code is LGPL
[02:42:10] <Dark_Shikari> aka not BSD.
[02:42:29] * Compn wonders how many times google is using ffmpeg
[02:42:55] <Compn> 1. youtube, 2. on2 mencoder flux encoder, 3. chrome h264 decoder, 4. webm/vp8, 5. android?
[02:43:15] <Dark_Shikari> though this is really more of a "fuck you" to firefox.
[02:43:26] <Dark_Shikari> Chrome is in fact totally awesome.
[02:43:31] <Compn> i guess google video is a seperate project from youtube, so we'll make that #6
[02:43:42] <kierank> chrome aac probably
[02:44:14] <Compn> firefox could add a ffmpeg vp8 plugin instead of using libvp8
[02:44:14] <Dark_Shikari> hmm.  if I really wanted to be a dick, I could make my code gpl.
[02:44:20] <Dark_Shikari> Compn: over blizzard's dead body
[02:44:27] <Compn> so it wouldnt be a fuck you so much as a bit more work for firefox...
[02:44:50] <Compn> i mean, firefox could compile a vp8/vorbis-only ffmpeg plugin
[02:44:52] <Dark_Shikari> firefox is rather... anti-ffmpeg
[02:44:54] <Dark_Shikari> period
[02:45:01] <Dark_Shikari> not "anti-stuff-they-don't-like-in-ffmpeg"
[02:45:05] <Compn> it seems so
[02:45:44] * Compn waits for chrome to have some advanced preferences before he uses it
[02:46:14] <Compn> also less google privacy invasions
[02:46:22] <kierank> chromium still crashes on long pages :/
[02:46:45] <Dark_Shikari> as opposed to firefox, which just crashes
[02:50:10] <Compn> Dark_Shikari : btw some benchmarks on your sssee3 patches might be of some help
[02:50:30] <Dark_Shikari> why
[02:52:22] <Compn> dunno, sounded like a good idea at the time
[02:53:46] <Dark_Shikari> I didn't bench any of it.
[02:53:47] <Dark_Shikari> Ever.
[02:54:06] <Dark_Shikari> ok, except for the idct sse4, that one was tricky
[02:54:14] <Dark_Shikari> the rest I didn't bench.
[02:54:22] <Dark_Shikari> I wonder if that will piss off michael =p
[02:54:49] <bcoudurier> gpl is fine :)
[02:54:51] <kierank> what's up with videolan and shoutcast?
[02:55:17] <Dark_Shikari> aol
[02:55:24] <bcoudurier> aol license requiring toolbar shipping along
[02:55:27] <bcoudurier> crap like that
[02:55:51] <kierank> lol
[02:56:00] <kierank> the vlc website should just troll aol
[02:56:21] <bcoudurier> kierank, yes any implementation is free to handle broken files, ffmpeg handles many of them :)
[02:56:53] <kierank> "YOU WERE AN INTERNET TITAN, AND NOW YOU'LL SETTLE FOR A TOOLBAR" AOL c2010
[02:59:01] <Compn> http://www.videolan.org/press/2010-1.html
[02:59:04] <Compn> that kinda explains things
[02:59:41] <kierank> send them some CDs
[02:59:46] <kierank> that'll shut them up
[02:59:49] <verb3k> "<Dark_Shikari> Chrome is in fact totally awesome." -->> That means the chromium development team/model isn't bad, and libvpx development might be similar.
[03:00:29] <Compn> but i guess j-b can explain further :)
[03:00:58] <Dark_Shikari> verb3k: libvpx uses the mozilla development model
[03:01:09] <Compn> chromium devel model good? ahahaha
[03:01:14] <Dark_Shikari> and no, chromium model isn't good
[03:01:31] <verb3k> but the software rocks.
[03:01:38] <Dark_Shikari> Sure, until you try to do things like fullscreen a video
[03:01:44] <Dark_Shikari> "better than firefox" doesn't mean your model is any good
[03:01:46] <Dark_Shikari> it just means it's less shit
[03:02:00] <verb3k> lol
[03:02:17] <Dark_Shikari> competing with firefox is like competing with the fat retard in class
[03:02:18] <Compn> firefox was following microsoft's lead, become slower over time and require more ram/cpu
[03:02:35] <Kovensky> @Dark_Shikari | as opposed to firefox, which just crashes <-- I tried midori today, it crashed before even the ui showed up
[03:03:02] <Kovensky> kierank | send them some CDs <-- oh you
[03:03:43] <Compn> oh now i got that finally
[03:03:45] <Compn> aol cds
[03:03:53] * Compn is slow
[03:03:59] <Compn> over 9000 hours free
[03:04:55] <kierank> 1000 free hours every month
[03:06:45] <saintdev> wasn't there a project a while ago to gather as many aol cds as possible and mail them back to aol?
[03:07:26] <Compn> yep
[03:08:53] <Kovensky> there's an ISP here, uol, that used to use the aol method
[03:13:21] <kierank> aol also did floppies
[04:24:34] <CIA-99> ffmpeg: darkshikari * r23765 /trunk/libavcodec/vp8.c: fix typo in vp8 decoder error message
[04:29:51] <CIA-99> ffmpeg: jai_menon * r23766 /trunk/libavformat/avienc.c:
[04:29:51] <CIA-99> ffmpeg: avienc : Avoid creating invalid AVI files when muxing subtitle streams
[04:29:52] <CIA-99> ffmpeg: other than XSUB.
[04:30:12] <jai> error: Unable to append to .git/logs/refs/remotes/git-svn: Permission denied
[04:30:15] <jai> mru: ^
[04:37:07] <CIA-99> ffmpeg: jai_menon * r23767 /trunk/libavutil/log.c:
[04:37:07] <CIA-99> ffmpeg: Print a space after the AVClass prefix.
[04:37:07] <CIA-99> ffmpeg: This improves readability a bit.
[06:54:51] <KotH> hoi zäme
[07:03:25] <j-b> Compn: trolling AOL is fun :D
[07:19:20] <kshishkov> j-b: trolling AOL is pointless
[07:20:09] <kshishkov> j-b: and next thing you'll attempt to troll local bureaucracy
[07:42:36] <wbs> Honoome: that's good :-)
[07:57:39] <CIA-99> ffmpeg: mstorsjo * r23768 /trunk/libavformat/ (rtsp.c internal.h):
[07:57:39] <CIA-99> ffmpeg: RTSP: Remove skip_spaces in favor of strspn
[07:57:39] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[07:59:35] <CIA-99> ffmpeg: mstorsjo * r23769 /trunk/libavformat/ (rtsp.c Makefile rtpdec_mpeg4.c rtpdec.c rtpdec_mpeg4.h):
[07:59:35] <CIA-99> ffmpeg: RTSP: Decouple MPEG-4 and AAC specific parts from rtsp.c
[07:59:35] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[08:00:57] <CIA-99> ffmpeg: mstorsjo * r23770 /trunk/libavformat/ (rtsp.c rtpdec_mpeg4.c):
[08:00:57] <CIA-99> ffmpeg: RTSP: Move more SDP/FMTP stuff from rtsp.c to rtpdec_mpeg4.c
[08:00:57] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[08:02:10] <CIA-99> ffmpeg: mstorsjo * r23771 /trunk/libavformat/ (rtpdec_mpeg4.c rtpdec.c):
[08:02:10] <CIA-99> ffmpeg: rtpdec: Move AAC depacketization code in rtpdec to a proper payload handler
[08:02:10] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[08:03:41] <CIA-99> ffmpeg: mstorsjo * r23772 /trunk/libavformat/ (rtpdec.h rtsp.c rtpdec_mpeg4.c rtsp.h rtpdec.c):
[08:03:41] <CIA-99> ffmpeg: RTSP, rtpdec: Move RTPPayloadData into rtpdec_mpeg4 and remove all references to rtp_payload_data in rtpdec and rtsp
[08:03:41] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[08:04:43] <CIA-99> ffmpeg: mstorsjo * r23773 /trunk/libavformat/rtpdec_mpeg4.c:
[08:04:44] <CIA-99> ffmpeg: rtpdec_mpeg4: Rename PayloadContext to be consistently 'data'
[08:04:44] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail
[08:13:08] <lu_zero> Honoome: good =)
[08:15:54] <mru> mornings
[08:17:29] <kshishkov> goda morgnar, mru
[08:20:12] <CIA-99> ffmpeg: mru * r23774 /trunk/libavcodec/ (rv34vlc.h rv34.c): rv34: kill VLAs
[08:20:26] <Tjoppen> midsommar \o/
[08:21:20] <mru> is that when swedes get pissed, then raped?
[08:23:14] <mru> Dark_Shikari: why don't you start committing some vp8 simd?
[08:24:19] <Dark_Shikari> I'm waiting for bbb to fix his shit
[08:24:38] <mru> can none of it be committed before that?
[08:24:44] <Dark_Shikari> Some could, I guess.
[08:25:02] <astrange> llvm svn claims to not miscompile anymore
[08:28:31] <mru> hmm, vp8 tests are failing with armcc
[08:28:33] <mru> wonder why
[08:29:53] <astrange> of course, llvm assembler doesn't assemble us yet, and that comes first anyway
[08:30:08] <mru> ?
[08:30:25] <Dark_Shikari> mru: it outputted nothing
[08:30:30] <Dark_Shikari> looks like it crashed/failed?
[08:30:34] <mru> obviously
[08:31:14] <mru> I'll run it manually and check
[08:32:23] <mru> sigsegv
[08:34:06] <mru> calling some pred function with null dest
[08:41:53] <mru> libavcodec/vp8.c:1210: warning: 'curframe' may be used uninitialized in this function
[08:42:27] <mru> which is blatantly obvious looking at the code
[08:43:15] <Dark_Shikari> how did it work in the first place?
[08:43:19] <mru> or is there some very clever magic preventing that from happening?
[08:43:27] <mru> look at vp8_decode_frame
[08:44:18] <mru> I guess it makes sense for that for loop to always find something
[08:44:26] <roxfan> it's a shroedingbug!
[08:44:39] <mru> no, just somewhat fragile code
[08:44:42] <roxfan> it worked until you found it
[08:45:15] <mru> it works if I noinline intra_predict
[08:45:22] <mru> so it's a compiler bug for sure
[08:46:33] <Dark_Shikari> it could still be a bug in the code that's hidden by undefined behavior, but yeah, most likely a compiler issue
[08:46:51] <mru> it looks like a typical armcc bug
[08:48:03] <Dark_Shikari> "typical"?
[08:48:14] <mru> the kind of bug they usually have
[08:48:23] <mru> different compilers have different kinds of bugs
[08:49:26] <Dark_Shikari> I mean from them
[08:49:28] <Dark_Shikari> what makes it typical of their bugs
[08:53:31] <mru> it just feels familiar
[08:54:18] <Dark_Shikari> what kind of similar things have you seen?
[08:54:38] <mru> I don't know exactly what the problem is here yet
[08:55:43] <mru> but in most of them there's been a loop involved
[09:01:38] <mru> btw is vp8 intended to support emu_edge?
[09:03:02] <mru> it currently rejects it in init but checks the flag in various places
[09:03:16] <mru> that's fine if the plan is to support it eventually
[09:03:24] <mru> otherwise the checks should be removed
[09:03:42] <Dark_Shikari> it _should_ support it eventually
[09:03:54] <Dark_Shikari> right now it has the worst of both worlds
[09:04:03] <Dark_Shikari> it does emulated_edge_mc (worse than just extending the edges)
[09:04:21] <Dark_Shikari> _and_ it is inefficient due to requiring edge padding
[09:05:26] <mru> edge padding can't be all that bad
[09:05:32] <mru> it's like 16 pixels or whatever
[09:05:44] <mru> don't tell me the spec requires more
[09:05:54] <Dark_Shikari> Well you see, there was actually an issue in that regard ;)
[09:05:58] <Dark_Shikari> You need 32 anyways though
[09:06:00] <Dark_Shikari> due to 6-tap filter + alignment
[09:06:08] <Dark_Shikari> (same as in h264)
[09:06:10] <mru> 16 on either side, sure
[09:06:13] <Dark_Shikari> no
[09:06:15] <Dark_Shikari> 32 on either side
[09:06:17] <Dark_Shikari> same as in h264
[09:06:29] <Dark_Shikari> You can have a 16-wide mb fully off the frame
[09:06:34] <mru> yes
[09:06:35] <Dark_Shikari> plus 3 pixels more for the 6-tap filter
[09:06:38] <Dark_Shikari> 19 pixels
[09:06:42] <mru> ok
[09:06:43] <mru> I see
[09:06:54] <Dark_Shikari> It's a tad worse in vp8 due to the rather hilarious mv clamping bug.
[09:06:58] <Dark_Shikari> But still fits in 32.
[09:07:08] <mru> what is that bug?
[09:07:23] <mru> mvs more than just off the edge?
[09:07:43] <Dark_Shikari> So, VP8 had three mistakes.  Each of them individually would have probably been minor, or in some cases, hardly an issue at all.
[09:07:46] <Dark_Shikari> But..
[09:08:01] <Dark_Shikari> "mistake" 1: MVs cannot go more than 16 pixels off the frame.  no pointlessly long MVs.
[09:08:07] <Dark_Shikari> Not really a mistake, but this leads us to 2....
[09:08:34] <Dark_Shikari> mistake 2: MVs are clamped in the MV prediction loop.  therefore, encoder and decoder clamping must match or else mv pred will give wrong results sometimes.
[09:08:43] <Dark_Shikari> mistake 3: lol let's totally fuck our encoder-side clamping
[09:09:19] <mru> why would you ever want an mv more than just off the edge?
[09:09:33] <Dark_Shikari> Suppose you have an MV that goes 16 pixels off the edge, i.e. the max that makes sense.
[09:09:44] <Dark_Shikari> suppose your frame is 10 macroblocks wide, and this is at macroblock 8.
[09:09:51] <Dark_Shikari> Macroblock 9 will have its MV predicted to be 32 pixels off the frame.
[09:09:54] <mru> why does being 16 pixels off the edge make sense?
[09:10:01] <mru> or did you mean it ends 16 off?
[09:10:05] <Dark_Shikari> it ends 16 off.
[09:10:10] <mru> ok
[09:10:12] <mru> makes sense
[09:10:15] <Dark_Shikari> so anyways, block 9 will have 32 off.
[09:10:24] <Dark_Shikari> if no mv delta is coded
[09:10:25] <Dark_Shikari> thus:
[09:10:36] <Dark_Shikari> 1) you allow arbitrarily far off the frame -- mv clamping is done during MC (h264)
[09:10:50] <Dark_Shikari> 2) you require a delta MV to make it valid again (still requires mv clamping if only to stop crashes)
[09:10:59] <Dark_Shikari> 3) you clamp MVs in the prediction loop
[09:11:20] <mru> MVs are predicted same as left MB + delta?
[09:11:28] <Dark_Shikari> no
[09:11:33] <Dark_Shikari> I was just giving a simple example
[09:11:35] <Dark_Shikari> of how, say, in MPEG-2
[09:11:44] <Dark_Shikari> you could have an MV that was not insane, become insane, merely through prediction to the next MB.
[09:11:52] <Dark_Shikari> i.e. by coding nothing, you get an insane MV.
[09:12:03] <mru> sure, it's just prediction
[09:12:15] <Dark_Shikari> Yes, but the point is, accordingly, you have to do one of 1), 2), or 3).
[09:12:59] <mru> 2 seems stupid
[09:13:19] <mru> 1 should encode most efficiently
[09:13:27] <Dark_Shikari> yes.
[09:13:34] <Dark_Shikari> well, actually, 3) might be better.
[09:13:41] <Dark_Shikari> it requires shorter deltas
[09:13:46] <Dark_Shikari> since it doesn't predict you into stupidly long mvs
[09:13:52] <Dark_Shikari> but, 3) is more costly
[09:14:02] <Dark_Shikari> and more importantly -- it means encoder-side clamping and decoder-side MUST MATCH.
[09:14:07] <Dark_Shikari> And they fucked that up.
[09:14:16] <Dark_Shikari> They had multiple mistakes:
[09:14:20] <Dark_Shikari> 1) splitmv mode did clamping wrong
[09:14:31] <Dark_Shikari> 2) at one point, clamping was done to the wrong pel level (i.e. fullpel instead of qpel or similar)
[09:14:37] <Dark_Shikari> 3) chroma used luma clamps
[09:14:41] <mru> lol
[09:14:43] <Dark_Shikari> and other really stupid shit
[09:14:55] <Dark_Shikari> fortunately there was only _one_ horrible mangling of the spec (splitmv) necessary to fix it
[09:15:08] <Dark_Shikari> and it only affects backwards compatibility with old streams
[09:15:21] <Dark_Shikari> but it's still _retarded_.
[09:15:41] <mru> that's why you should have two teams doing enc and dec independently off the same spec
[09:16:00] <Dark_Shikari> spec?  what spec?
[09:16:08] <Dark_Shikari> they dont have a spec
[09:16:15] <mru> I know
[09:16:16] <Dark_Shikari> they changed "spec" to be the "bitstream guide"
[09:16:19] <Dark_Shikari> since that's what it is
[09:16:23] <mru> lol
[09:16:23] <Dark_Shikari> not joking
[09:16:25] <Dark_Shikari> they renamed it
[09:16:38] <mru> that's hilarious
[09:17:18] <av500> https://review.webmproject.org/gitweb?p=bitstream-guide.git;a=summary
[09:18:28] <mru> ugh, unwrapped lines
[09:18:43] <av500> it cites 3 references: ITU BT.601, Shannon and KR!
[09:19:29] <mru> when a "spec" describes a format using C struct syntax, you know something is amiss
[09:19:38] <mru> since struct layout in C is unspecified
[09:19:42] <Dark_Shikari> lol
[10:12:10] <lu_zero> ^^;
[10:17:56] <mru> ah, latest version has fixed the bug
[10:18:01] <mru> need to get a licence for that
[10:20:07] <kshishkov> license to kill bugs?
[10:22:29] <Honoome> at the end icculus himself commented on my latest blogpost.. at leaset he concedes most of the points I made
[10:26:04] <kshishkov> FatXXX always reminds me of Windows PE files that actually contain DOS program as well.
[10:26:37] <lu_zero> oh
[10:26:56] <Honoome> kshishkov: there are a few things that PE is better at than ELF thoug
[10:27:05] <Honoome> like the use of import tables...
[10:27:18] <Honoome> [sure it's a mess, but it works better at runtime]
[10:27:33] <mru> you call that better?
[10:27:36] <Honoome> otoh it stops you from being able to do proper runtime loading, and interposing...
[10:27:42] <mru> it's the most retarded feature ever
[10:28:01] <Honoome> mru: no chances of collisions, no need to hash 400-characters long symbol names...
[10:28:24] <mru> but binding by table index is insane
[10:28:30] <mru> change the dll and all hell breaks loose
[10:28:52] <kshishkov> it does by default
[10:28:55] <av500> dll hell?
[10:29:07] <Honoome> av500: (soname hell)**2
[10:29:39] <mru> elf will rarely just blow up in your face without an explanation
[10:29:46] <Honoome> mru: I guess neither approach is flawless.. sometimes I wish we didn't have the current flat namespace though
[10:29:56] <mru> there are cases, as we've seen, where it can fail to resolve things in annoying ways
[10:30:14] <Honoome> *cough* xine's aac bug from 2006
[10:30:24] <Honoome> siretart might remember that :P
[10:30:45] <mru> but I'd rather have a few obscure link errors than random runtime failures
[10:30:56] <Honoome> it was a runtime failure in xine's case
[10:31:08] <Honoome> runtime crash to be precise
[10:31:14] <mru> I'm not familiar with that bug
[10:31:16] <mru> what was it?
[10:31:28] * av500 guesses a smybol clash
[10:31:28] <Honoome> playing aac files, xine (and any app linked to libxine) crashed
[10:31:39] <mru> yeah, but what was the cause?
[10:31:45] <mru> symbol clash?
[10:31:48] <Honoome> I circled around it until Michael Meeks provided -Bdirect patches that solved it..
[10:31:49] <kshishkov> faad?
[10:32:01] <Honoome> turned out that xine-lib was bundling libfaad 2.5, while ffmpeg linked to libfaad 2
[10:32:14] <Honoome> (or the other way around, details are fuzzy in my mind right now)
[10:32:38] <Honoome> so the symbol from the faad plugin were being resolved by the libfaad brought in by libavcodec
[10:32:57] <Honoome> yes -Bdirect would have solved that
[10:33:21] <Honoome> [at the end I solved it using elf visibility, only exporting the single symbol the plugins used to load]
[10:33:33] <mru> that's what you deserve when bundling libs
[10:33:41] <Honoome> I know
[10:34:03] <Honoome> that's actually my original reason to write ruby-elf and the collision checker script
[10:35:15] <av500> err, -Bdirect does what?
[10:35:43] <Honoome> av500: nowadays nothing, it was a test by SuSE of binding symbols between libraries at build-time
[10:36:15] <Honoome> think of it as a -Bsymbolic between shared objects as well
[10:36:30] <av500> man gcc says something like: -Bprefix ...specifies where to find the executables, libraries, include files, and data files of the compiler itself
[10:36:41] <Honoome> or prelink on steroids
[10:36:46] <av500> ic
[10:36:47] <Honoome> av500: -Bdirect from the linker.. is long dead now
[10:36:53] <av500> ah
[10:36:54] <av500> ok
[10:38:15] <av500> Honoome: these AAPL "bundles", do they resolve deps between each other? or are they all standalone, except for "system" stuff?
[10:38:50] <Honoome> av500: afaict, it's the latter, they copy in the libraries they link to
[10:41:09] <av500> mru, after vla please remove all sleep(1) calls: http://bugs.python.org/issue9075
[10:42:22] <Honoome> ahaha... but it's a bit scary, is python the only one doing that stuff?
[10:45:20] <mru> lol
[10:46:11] <lu_zero> av500: ?
[10:46:26] <lu_zero> av500: you have bundles and frameworks...
[10:46:29] <lu_zero> and installers
[10:46:41] <lu_zero> the world isn't as simple as people like to picture it
[10:47:08] <lu_zero> so you might have a bundle (wesnoth) that uses some frameworks (sdl)
[10:47:23] <lu_zero> so you have to install the framework and then you can use the bundle
[10:47:47] <av500> ok
[10:48:21] <lu_zero> and ryan could consider just letting distributors do their stuff and be happy...
[10:48:26] <av500> and who resolves that sdl might have changed between wesnoth and wesnoth_2_return_of_the_wesnoth?
[10:48:54] <Honoome> hrm, did ffmpeg lose the ability to rotate videos, I'm deluded it ever did, or am I missing something?
[10:49:38] <lu_zero> avfilter...
[10:49:43] * lu_zero meanwhile disables it
[10:57:47] <lu_zero> I couldn't track where that damn var gets overwritten =_=
[10:58:22] <Honoome> lu_zero: use gdb watchpoints
[10:59:18] <lu_zero> uhmm
[11:19:25] <lu_zero> wbs: a patch got lost am I wrong?
[11:29:51] <lu_zero> siretart: ping
[11:30:15] <siretart> lu_zero: what's up?
[11:30:29] <lu_zero> I need your ubuntu knowledge ^^;
[11:30:49] <lu_zero> I have to setup 10 laptops with the very same system
[11:31:07] <lu_zero> which is the quickest route given I have one already prepared?
[11:31:24] <iive> lu_zero: same model and harddisk size?
[11:31:56] <av500> lu_zero: fatelf of course!
[11:32:14] <lu_zero> identical
[11:32:32] <av500> fatelt_lite then :)
[11:32:32] <lu_zero> av500: pff
[11:32:41] <Honoome> lu_zero: iscsi?
[11:32:49] <lu_zero> Honoome: uh?
[11:33:24] <Honoome> run sysresccd, add iscsitarget, make it export the harddisk of the first one, then use all the others to fetch it via iscsi :D
[11:33:28] <av500> lu_zero: but imagine you had an x86, an ARM, a MIPS, an 68k, a PPC laptop and a PDP11....
[11:33:39] <lu_zero> sure
[11:33:51] <Honoome> av500: and pretend to run the same code on all of them...
[11:33:56] <av500> of course
[11:34:10] <lu_zero> and pretend that the code doesn't need even libc
[11:34:24] <siretart> lu_zero: so you want to do a 'mass deployment'?
[11:34:30] <lu_zero> yup
[11:34:37] <av500> then you need a WMD...
[11:34:46] <lu_zero> and since it's ubuntu I have no clue but I want to learn
[11:34:52] <siretart> let's take that to /query, I think that's a bit offtopic here..
[11:34:55] <Honoome> actually, I think the main issue that we should tackle somehow, fatelf or not, is api consistency among arches _in the same OS_ at least
[11:35:23] <lu_zero> Honoome: the iscsi trick sounds like a good solution I just need to bake a sysres
[11:36:09] <Honoome> lu_zero: alternatively put N nc commands listening in multicast, and then multicast the image to them :P but you'll probably need something more reliable than UDP
[13:44:47] <CIA-99> ffmpeg: mru * r23775 /trunk/libavcodec/twinvq.c: twinvq: remove VLAs
[13:46:08] <janneg> do we care about libvpx with disabled encoder or decoder? configure --enable-libvpx fails currently if not both are enabled
[13:47:58] <mru> iirc we decided not to care
[13:48:43] <mru> soon eneough we'll be using it for encoding only
[13:48:46] <janneg> the libvpx encoder needs -lm. I assume it's ok to just commit it
[13:49:09] <janneg> adding it to the require2 check
[13:49:23] <mru> uh?
[13:49:30] <mru> -lm should have been added already
[13:50:17] <janneg> yes, but it's before -lvpx which doesn't lay nice with --as-needed
[13:50:24] <janneg> play
[13:50:52] <mru> let's fix that then
[13:51:28] <janneg> ok, the lame and libopencore have also redundant -lm
[13:52:45] <mru> so let's fix those too
[13:53:13] <janneg> mru: http://pastie.org/1018763
[13:53:23] <mru> wrong
[13:53:25] <mru> 5min
[13:54:24] <janneg> yes, missed all the check_mathfunc
[13:54:35] <mru> no
[13:58:42] <janneg> wll, let's say another error of changing things without thinking
[13:59:02] <mru> I'm fixing it properly
[13:59:05] <mru> give me a moment
[13:59:33] <janneg> no problem
[14:02:15] <Honoome> so to _de_mangle a C++ symbol you have to use a recursive, stack-based, backreferencing parser... not bad
[14:02:31] <Honoome> and the process is not perfect: two symbols may demangle to the same string
[14:04:05] <mru> what about the reverse?
[14:04:35] <mru> demangling is never required for correct operation
[14:05:17] <lu_zero> beside debugging
[14:05:32] * lu_zero meanwhile is having his share of fun with gdb
[14:10:17] <Honoome> mru: the reverse is much easier
[14:11:34] <mru> reverse demangling...
[14:12:33] <Honoome> mangling the symbols is a perfect process, mostly...
[14:12:50] <Honoome> and requires _relatively_ less complexity
[14:14:40] <kierank> iirc google wrote a demangler
[14:19:12] <Honoome> what I'm really surprised is that the GCC3 style avoids using special characters for the symbol names; technically I don't htink that anything stops them from using some special characters for interleaving...
[14:20:25] <mru> it's best not to use special characters
[14:20:45] <mru> although allowed by elf, many assemblers have restrictions on what they accept
[14:21:32] <Honoome> that's a good point I guess
[14:22:48] <lu_zero> still having more than 50 chars to define a symbol is interesting...
[14:23:24] <Honoome> gnash is the exception, most of other symbols are generally shorter...
[14:23:24] <mru> at least the spec doesn't call for randomly inserting "Factory" in the mangled name
[14:23:43] <lu_zero> what's that?
[14:23:49] <mru> java
[14:24:23] <lu_zero> I wonder if having long/overlylong symbols has an effective impact on performance
[14:24:48] <Honoome> lu_zero: sure
[14:25:01] <mru> only startup time
[14:25:02] <Honoome> you know .gnuhash right? know why it was introduced?
[14:25:04] <mru> not runtime
[14:25:21] <Honoome> mru: startup definitely, runtime if you use lazy bindings
[14:25:57] <mru> only first time the symbol is hit
[14:26:14] <Honoome> true
[14:26:17] <Honoome> tux saves the plt
[14:27:27] <KotH> Honoome: wth is .gnuhash?
[14:27:57] <Honoome> actually I forgot a dot, it's .gnu.hash
[14:28:21] <Honoome> KotH: binutils and glibc since about 2006 or 2007 implement a replacement for the sysv .hash section of ELF files
[14:28:33] <Honoome> uses a different algorithm because the original one caused too many collisions with C++ symbols
[14:29:49] <j-b> __gb__ ?
[14:30:03] <Honoome> hm?
[14:32:38] <mru> Honoome: int (*(*foo)[4])(int (*)(int *))[2](int);
[14:32:43] <mru> something for you to mangle
[14:33:01] <Honoome> I said relatively easier ;)
[14:35:57] * KotH doenst even get whether that code is valid or not, much less what it should do
[14:36:19] <mru> sorry, that has a mistake in it
[14:41:44] <Honoome> it would seem to be a bidimensional array of function pointers taking as parameter a further function, but yeah doesn't look entirely valid ;)
[14:42:07] <mru> there, got it  int (*(*(*(*foo)[4])(int (*)(int *)))[2])(int);
[14:42:55] <mru> it's a pointer to array 4 of pointer to function (pointer to function (pointer to int) returning int) returning pointer to array 2 of pointer to function (int) returning int
[14:43:19] <mru> don't _ever_ try to use anything like that
[14:43:25] <Honoome> mru: now write some (C++) code that works with that :P
[14:43:45] <mru> functions returning function pointers have weird syntax
[14:44:53] <Honoome> JJ Abrams and flares, damn them :P
[14:45:32] <lu_zero> ok
[14:45:40] <lu_zero> 4 systems more or less configured
[14:45:48] <lu_zero> 20 min left before I must go...
[14:46:01] <mru> ok, demangle this: _Z3barPA4_PFPA2_PFiiEPFiPiEE
[14:46:39] <Honoome> gha I didn't reach A which I guess is array.. :P
[14:49:01] <Honoome> ghaaaa it's a double-function pointer again :P
[14:49:09] <mru> same as before
[14:49:14] <mru> but as argument to a function
[14:49:21] <mru> so one more level of function
[14:49:38] <Honoome> it's almost more readable this way
[14:49:52] <mru> nm -C says bar(int (* (*(* (*) [4])(int (*)(int*))) [2])(int))
[14:55:55] <BBB> mmx didn't need alignment right?
[14:56:01] <BBB> what alignment do sse2/ssse3 need?
[14:56:15] <mru> size of access I presume
[14:56:24] <mru> nothing else would make sense
[14:56:26] <BBB> ssse2: 16, ssse3: 32?
[14:56:45] <mru> probably not more than 16 bytes
[14:56:49] <mru> that's unheard of
[14:56:52] <BBB> ok, 16 then
[14:56:52] <BBB> thanks
[14:56:59] <mru> is there an instruction to load 32 bytes?
[14:57:01] <BBB> mmx needs none right?
[14:57:06] <mru> mmx is faster with aligned
[14:57:11] <BBB> ah
[14:57:12] <mru> aligned is always faster
[14:57:13] <BBB> ok, 8 then
[15:18:32] <lu_zero> BBB: you _want_ to have aligned vars
[15:18:56] <lu_zero> altivec is quite educative on that since you have to do the align work explicitly there
[15:19:14] <mru> unaligned altivec loads are "interesting"
[15:19:21] <lu_zero> useful
[15:19:27] <mru> kind of like armv4 unaligned loads
[15:19:37] <Honoome> sparc64 unaligned loads?
[15:19:41] <mru> they're only useful because true unaligned is missing
[15:19:51] <Honoome> has anybody ever seen a niagara box running? o_o
[15:19:59] <mru> there's one on fate
[15:20:12] <Honoome> fun, I thought they dropped out of the face of the earth
[15:20:19] <lu_zero> if you know which part you want to process you can just avoid aligning
[15:21:22] <mru> if theh operands are differently aligned you have to mess with one to align the registers
[15:21:36] <mru> like in your average MC
[15:38:04] <j-b> who works for fluendo here?
[15:38:24] * mru grabs shotgun.... nobody
[15:38:29] <mru> not anymore
[15:39:25] <lu_zero> not me
[15:40:50] <j-b> http://www.moovida.com/download/ because I fail to see the sources
[15:41:43] <kierank> that looks exactly like spotify
[15:43:05] <Honoome> j-b: I think you won't find them
[15:43:11] <Honoome> j-b: http://www.moovida.com/faq/#will-the-diesel-engine-become-open-source
[15:43:20] <j-b> https://code.launchpad.net/moovida is vastly outdated
[15:43:53] <j-b> Honoome: hmm, interesting how they include libdvdnav, libdvdread and libdvdcss that are GPL
[15:44:16] <Honoome> buh that was the only source reference I could find prodding around
[15:44:47] <Honoome> j-b: but don't worry, me and you are still part of the enemies of free software for supporting h264...
[15:44:58] <j-b> oh? I am?
[15:45:11] <j-b> :)
[15:45:13] <Honoome> well you're in #ffmpeg-devel aren't you? :P
[15:45:20] <j-b> Honoome: I am not :D
[15:45:28] <mru> and you're not being flamed
[15:45:37] <j-b> you don't see me, just my very sophisticated bot :)
[15:45:41] <CIA-99> ffmpeg: mru * r23776 /trunk/configure: configure: remove unused function check_foo_config
[15:45:42] <CIA-99> ffmpeg: mru * r23777 /trunk/configure: configure: simplify check_lib function
[15:45:43] <CIA-99> ffmpeg: mru * r23778 /trunk/configure: configure: simplify append function
[15:45:43] <CIA-99> ffmpeg: mru * r23779 /trunk/configure: configure: remove unused flag save/restore functions
[15:45:44] <CIA-99> ffmpeg: mru * r23780 /trunk/configure:
[15:45:44] <CIA-99> ffmpeg: configure: reverse order of -l flags
[15:45:44] <CIA-99> ffmpeg: Adding new libs to the front of the list allows them to resolve
[15:45:44] <CIA-99> ffmpeg: symbols against previously added ones.
[15:45:45] <CIA-99> ffmpeg: mru * r23781 /trunk/configure: configure: remove superflous -lm flags
[15:45:58] <j-b> Honoome: still, I don't understand how they are not violating the GPL
[15:46:16] <Honoome> j-b: don't ask me, I refused the offer a long time ago
[15:47:13] <j-b> and of course, no LGPL, or GPL license but a stupid Eular
[15:47:59] <Honoome> shush, gstreamer is backed by nokia, they can't be evil...
[15:48:29] * Honoome is sarcastic, if you couldn't tell
[15:48:32] <j-b> :)
[15:48:46] <j-b> but, wtf stil
[15:52:52] <j-b> an incompatible GPL and LGPL license, and all dlls from open source projects
[15:53:21] <kierank> go to fluendo irc
[16:08:30] <KotH> Honoome: if nokia back gstreamer, they have to be evil!
[16:11:59] <j-b> that has nothing to do with gstreamer, but with fluendo here.
[16:12:01] <BBB> mru: current patch better? I removed the huge VLAs
[16:12:18] <BBB> if this is OK, I'll work on adding jason's patches into it
[16:12:25] <kierank> hmm...where's ruggles and merzbt when you need them
[16:15:03] <lu_zero> uhm?
[16:15:16] <lu_zero> bilboed is collabora's
[16:15:19] <lu_zero> still gst devel
[16:15:46] <BBB> why are we talking gst in this channel
[16:15:50] <BBB> superdump is also collabora
[16:17:18] <lu_zero> uhmm
[16:17:26] <lu_zero> looks like an evolved elisa
[16:17:30] <BBB> btw
[16:17:37] <BBB> lu_zero: didn't fluendo fund you long time ago?
[16:17:43] * BBB holds tar and feathers
[16:17:55] <lu_zero> BBB: didn't do for you as well? =)
[16:18:03] <BBB> I repented
[16:18:12] <lu_zero> thehe
[16:18:21] <lu_zero> well it was even worse
[16:18:32] <BBB> I went into exile and then I went back to the right path
[16:18:40] <lu_zero> I got founds to write the vorbis in rtp rfc
[16:19:19] <lu_zero> so it was fluendo paying me to work with xiph people
[16:20:03] * BBB boils tar
[16:21:27] <lu_zero> ...
[16:22:01] <BBB> btw josh is doing great, how much longer is soc gonna last?
[16:22:14] <BBB> with a little luck he can finish both x-qt and svq3/qdm2 integration
[16:23:06] <lu_zero> other two months more or less
[16:23:21] <lu_zero> bbl
[16:38:16] <mru> BBB: no vlas, nice
[16:42:45] <j0sh_> BBB: yeah, soc isn't even 1/3 over yet :)
[16:48:41] <BBB> mru: can you reply on-list so I can pretend that I had some approval?
[16:48:54] <mru> I can't comment on the asm
[16:48:56] <BBB> if dark_shikari and michael are ok also, I'll commit
[16:49:03] <BBB> but you're a neon asm god
[16:49:18] <mru> this is mmx
[16:49:20] <peloverde> j0sh_, so do you think you will be sticking around after soc? :)
[16:49:37] <mru> peloverde: is that his choice?
[16:49:44] <mru> if we want him, we keep him
[16:49:51] <j0sh_> oh, yeah, i'd like to
[16:50:01] <mru> resistance is futile, you will be assimilated
[16:50:07] <j0sh_> heh
[16:50:13] <BBB> I think we need to make j0sh_ RE some codec next
[16:50:59] <mru> oh yeah
[16:51:00] <j0sh_> BBB: yeah, i've been watching you and Dark_Shikari work on vp8 together, that looks like fun :)
[16:51:34] <BBB> don't forget david (yuvi), he wrote much of the C code
[16:52:01] <j0sh_> cool, he maintains the xiph stuff doesn't he?
[16:52:21] <BBB> yeah
[16:53:18] <BBB> also, mru will write all of the neon asm
[16:53:22] <BBB> he just doesn't know it yet
[16:53:36] <j0sh_> heh
[16:53:57] <j0sh_> actually i have a beagleboard, i've been meaning to get some use out of it
[16:54:02] <j0sh_> i'd be willing to learn
[16:54:16] <mru> BBB: of course I know I have neon code to write
[16:54:30] <mru> unless yuvi beats me to it
[16:54:38] <j0sh_> i can do asm, but i've never done neon, and i'm not that familiar with the theory behind codecs (mc, etc)
[16:54:52] <BBB> does iphone 3G (non-S) support neon?
[16:55:01] <mru> you need only a basic understanding of the codec to write the asm
[16:55:10] <mru> 3gs has neon, not the earlier ones
[16:55:21] <BBB> hm, ok, will buy a 4g then
[16:55:30] <BBB> good excuse to learn neon
[16:55:30] <j0sh_> do some android phones have neon?
[16:55:31] <mru> the phone without a phone
[16:55:33] * j0sh_ has a droid
[16:55:39] <mru> droid should have neon
[16:55:42] <mru> is it snapdragon?
[16:55:49] <j0sh_> no, the other one
[16:55:58] <mru> do you know what cpu it has?
[16:56:08] <j0sh_> lemme look it up, its def a TI
[16:56:18] <mru> omap3?
[16:56:21] <jai> whatever happened to the resident demoscener?
[16:56:27] <mru> basty/
[16:56:31] <j0sh_> coretx a8
[16:56:37] <BBB> he's a little awol, I've complained about that a couple of times
[16:56:39] <mru> j0sh_: has neon
[16:56:43] <mru> same as beagle
[16:56:51] <BBB> I'm not very happy with basty's soc performance so far
[16:57:21] <mru> his biggest skill is boasting about his skills
[16:57:36] <janneg> droid is an omap3430
[16:57:57] <mru> same as beagle
[16:58:30] * j0sh_ can never keep track of all the TI model numbers
[16:58:48] <mru> most of them are the same thing
[16:59:07] <mru> omap3[45]xx are all the same silicon
[16:59:36] <mru> for xx < 30 some units are disabled with fuses
[16:59:59] <j0sh_> ah
[17:00:01] <mru> so 3505 has just the cortex-a8
[17:00:18] <mru> 3515 and 3525 have one each of dsp and sgx
[17:00:31] <mru> 34xx and 35xx are the same
[17:00:52] <j0sh_> mru: you are to TI codenames what DS is to intel codenames :)
[17:01:15] <j0sh_> is there any benefit of writing for the dsp, rather than arm/neon?
[17:01:28] <mru> it's 10x harder
[17:02:11] <mru> the benefit of using the dsp is that it doesn't keep the arm busy
[17:02:22] <mru> for best performance you use both
[17:02:43] <j0sh_> i imagine that phones offload some work to the dsp?
[17:02:46] <janneg> 36xx are the 45nm shrinks
[17:02:59] <mru> 36xx are more than shrinks
[17:03:21] <mru> the sgx is much faster per clock
[17:03:29] <mru> the a8 is upgraded to r3p2
[17:03:41] <mru> various peripherals are upgraded
[17:03:44] <j0sh_> is neon/mmx/etc executed in the same instruction pipeline as regular asm? or can it be done in parallel?
[17:04:05] <mru> neon is in the same instruction stream but runs in its own pipeline
[17:04:16] <mru> so there is fine-grained parallelism there
[17:04:32] <j0sh_> cool
[17:04:35] <KotH> mru: isnt it also possible to get more decoding power per W on the dsp?
[17:04:48] <KotH> mru: or is that just dsp vendor FUD?
[17:04:50] <mru> KotH: depends on what you're doing
[17:05:08] <KotH> mru: 0815 dct based codecs
[17:05:16] <mru> if your algorithm maps nicely onto the dsp instruction set, it's probably more power-efficient
[17:05:35] <mru> it's a much simpler processor
[17:05:45] <KotH> ok, 0815 dct based codecs on a 0815 dsp core
[17:05:56] <KotH> well.. not so simple
[17:06:08] <KotH> current dsps are nothing else but VILW machines
[17:06:27] <KotH> VLIW*
[17:06:43] <mru> yes, and a vliw cpu is much simpler to build than an out of order, superscalar regular cpu
[17:06:50] <mru> but much harder to write code for
[17:07:06] <mru> the C64x pipeline isn't even interlocked
[17:07:37] <KotH> hmm...
[17:07:48] <mru> so be careful with your nops
[17:07:49] <KotH> i never looked at the implementation complexity of an vliw machine...
[17:08:30] <KotH> though the itanium was a fucking huge dump of a vliw machine
[17:08:33] <mru> each very long instruction contains one instruction for each execution unit
[17:08:48] <KotH> i know the idea of vliw
[17:08:58] <KotH> but i havent had a in depth look at it
[17:09:34] <mru> the advantage is that you have complete control over instruction scheduling
[17:09:48] <mru> the disadvantage is that you must control the scheduling completely
[17:10:28] <KotH> i know
[17:10:41] <KotH> btw: what made the itanic so fucking complex?
[17:10:45] <mru> intel
[17:10:59] * KotH remembers how the first versions were fucking huge 250W heaters
[17:11:14] <KotH> when all other CPUs were around 50-70W
[17:11:46] <Honoome> mru: I thought it was HP, the fault
[17:11:54] <mru> well, both
[17:12:07] <sp_> hey guys, can you read this message?  this is a test
[17:12:12] <mru> take two large companies, each with their own agenda and stack of patents
[17:12:32] <peloverde_> Is the itanium .bss issue an itanium flaw or is it just the gnu toolchain being reatrted?
[17:12:40] <mru> bit of both
[17:12:50] <mru> 22 bits is rather small
[17:12:57] <peloverde_> sp_, yes
[17:13:09] <mru> peloverde_: I was hoping nobody would answer :-)
[17:13:29] <KotH> er.. no, peloverde_: you should not have answered! ;)
[17:13:40] <KotH> peloverde_: or at least answer with a "no"
[17:13:48] <mru> or a /kick
[17:14:01] <sp_> fuck, /kick would've let me know you could see it too
[17:14:14] <mru> /fuck ?
[17:14:23] <KotH> mru: dont use that on spaam
[17:14:34] <KotH> mru: unless you want to take microchips place
[17:14:39] <mru> no thanks
[17:50:47] <BBB> Dark_Shikari: wake up! :-p
[17:51:11] <Dark_Shikari> what
[17:52:09] <KotH> Dark_Shikari: go back to sleep! :-p
[17:53:06] <mru> /kill -STOP Dark_Shikari
[17:53:40] <BBB> Dark_Shikari: can you ok my mmx patch on the mailinglist? I'm halfway adding your sse2 to it locally
[17:54:07] <Dark_Shikari> and drop the property change obviously btw
[17:54:15] <BBB> the ssse3 functions look lovely by the way
[17:54:17] <Dark_Shikari> that's cygwin sucking
[17:54:23] * BBB wishes he had a ssse3 cpu
[17:54:26] <Dark_Shikari> Don't you love how the ssse3 functions are like
[17:54:29] <Dark_Shikari> five billion times shorter?
[17:54:32] <BBB> I know
[17:54:33] <BBB> so unfair
[17:55:01] <Dark_Shikari> You still need to merge my changes to the dsputil function
[17:55:05] <Dark_Shikari> i.e. where I made your functions moree generic
[17:55:09] <Dark_Shikari> _ ## INSTR instead of _mmxext
[17:55:28] <BBB> that doesn't work anymore
[17:55:32] <Dark_Shikari> why?
[17:55:35] <BBB> because I changed the actual asm prototypes
[17:55:41] <Dark_Shikari> .... and?
[17:55:50] <Dark_Shikari> You still need the #defines to be generic
[17:55:55] <Dark_Shikari> they all now have mmx hardcoded
[17:55:56] <Dark_Shikari> this is stupid
[17:56:02] <BBB> the function pointers in VP8DSPContext are different from the asm function pointers
[17:56:09] <BBB> so you can't make a 16 call 8 twice
[17:56:12] <Dark_Shikari> Why?
[17:56:16] <BBB> look at the code
[17:56:20] <Dark_Shikari> That's stupid
[17:56:23] <BBB> yeah, I know
[17:56:26] <Dark_Shikari> Um, fix that
[17:56:29] <Dark_Shikari> that's a bug.
[17:56:33] <BBB> I can't figure out how
[17:56:36] <Dark_Shikari> Huh?
[17:56:36] <Dark_Shikari> wtf
[17:56:41] <Dark_Shikari> I have no idea what you're on
[17:56:44] <Dark_Shikari> "you can't figure out how"???
[17:56:50] <BBB> I might need some coffee
[17:56:53] <Dark_Shikari> How do you make prototypes the same
[17:56:55] <Dark_Shikari> BY CHANGING THE ARGUMENTS
[17:56:56] <Dark_Shikari> hurrrrrr
[17:57:03] <BBB> hush darling
[17:57:05] <Dark_Shikari> seriously, I have no idea what you're talking about
[17:57:09] <Dark_Shikari> Also, your hv width 8 is completely wrong
[17:57:18] <Dark_Shikari> +    DECLARE_ALIGNED(8, uint8_t, tmp)[8 * (8 + TAPNUMY - 1)]; \
[17:57:21] <Dark_Shikari> 8 can be height 16.
[17:57:49] <BBB> with the same change, it can't anymore
[17:57:52] <Dark_Shikari> Yes it can
[17:58:02] <BBB> the static functions never call each other anymore with my changes
[17:58:07] <Dark_Shikari> That isn't what I said.
[17:58:15] <Dark_Shikari> First of all, the static functions should call each other
[17:58:20] <Dark_Shikari> but unreleatedly, VP8 supports 8x16 partitions
[17:58:25] <Dark_Shikari> that's a width-8 partition of height 16.
[18:00:08] <BBB> width 16, height 8
[18:00:11] <BBB> the other doesn't exist
[18:00:12] <BBB> just checked it
[18:00:26] <BBB> but you're right that a width 4 height 16 exists :-p
[18:00:30] <BBB> so I'll change it
[18:00:50] <BBB> oh wait I'm misreading
[18:00:51] <BBB> darnit
[18:00:52] <BBB> you're right
[18:01:17] <BBB> there's 16x8, 8x16, 8x8 and 4x4 splits
[18:01:41] <BBB> and yes I have to change that if I ever fix the C code to do the correct thing there
[18:01:46] <Dark_Shikari> width 4 height 16 does not exist
[18:01:46] <BBB> consider it done
[18:01:48] <BBB> anything more?
[18:01:53] <BBB> yeah I know I'm smoking bad stuff
[18:01:54] <Dark_Shikari> Anyways, since you refuse to fix your bloody dsp functions
[18:02:02] <Dark_Shikari> I'm going to unilaterally break your local tree ok?
[18:02:04] <Dark_Shikari> I'm fixing the C code.
[18:02:33] <BBB> I'm doing the same thing as h264, what's wrong with that?
[18:02:36] <BBB> the dsp functions are fine
[18:03:02] <Dark_Shikari> What's wrong is src and dst stride are assumed to be the same!!!
[18:03:07] <Dark_Shikari> didn't we tell you this already
[18:03:17] <BBB> only in the dsp function pointer prototypes
[18:03:29] <BBB> and when called from vp8.c, that's indeed true
[18:03:39] <BBB> h264dsp_mmx.c does this too
[18:03:46] <Dark_Shikari> h264 is different
[18:03:51] <Dark_Shikari> it doesn't round between staged filter steps
[18:04:19] <mru> if someone tells you something is wrong, don't try to defend it by saying that something else is _also_ wrong
[18:04:41] <BBB> mru: maybe it means it's not that wrong (?)
[18:04:51] <mru> hardly
[18:04:51] <KotH> what's currently the status of vp8 playback with ffmpeg?
[18:05:02] <mru> KotH: bickering
[18:05:14] <BBB> the problem with adding another function argument is that it becomes a 7-register function, thus needs to be under HAVE_7_REGS, which I think is unnecessary
[18:05:23] <KotH> mru: and that means?
[18:05:27] <BBB> because we never use all 7
[18:05:50] <mru> isn't it pure asm?
[18:05:58] <pengvado> if it's in yasm it doesn't need HAVE_7_REGS
[18:06:15] <pengvado> because yasm doesn't allow gcc's register allocator to get in the way
[18:07:01] <Dark_Shikari> we want to avoid unnecessary wrapper functions
[18:07:05] <Dark_Shikari> esp. with x86_32 calling conventions
[18:07:15] <Dark_Shikari> if we can call asm directly instead of going through a wrapper, so much the better
[18:07:57] <Dark_Shikari> BBB: where is ff_put_vp8_pixels c?
[18:08:03] <BBB> Dark_Shikari: in dsputil
[18:08:27] <Dark_Shikari> why is it there
[18:08:35] <BBB> that's where put_pixels is
[18:09:19] <BBB> (put_pixels{4,8,16}_c)
[18:09:40] <BBB> oh these also merely take one stride argument, so we'll need to fix them too if you want me to change it
[18:10:03] <Dark_Shikari> already done
[18:10:30] <BBB> I would learn a lot more from this if you wouldn't do it for me but would leave me a little time to do it myself
[18:11:04] <Dark_Shikari> You're the one who hasn't done crap for a week
[18:11:08] <Dark_Shikari> and is bikeshedding over fixing your own code
[18:12:08] <Dark_Shikari> I want this done relatively fast, so I don't want bikeshedding getting in the wa
[18:12:12] <Dark_Shikari> *way
[18:12:22] <Dark_Shikari> so I'm using the anti-bikeshed method: just push things through
[18:12:43] <Dark_Shikari> I don't intend to be stealing your thunder -- I just want it done
[18:12:51] <BBB> ??
[18:13:06] <mru> at this rate it's more of a hum than a thunder
[18:13:12] <BBB> you can't call a 1-line argument a bikeshed, but anyway I'm about to start one
[18:13:21] <Dark_Shikari> 1-line arguments are the biggest bikesheds
[18:14:15] <BBB> bla... well whatever let's just get it done otherwise we'll still be flaming tomorrow
[18:14:19] <Dark_Shikari> Committed.
[18:14:34] <mru> \o/
[18:14:42] <Dark_Shikari> the commit message will explain it.
[18:14:56] <Dark_Shikari> yes, I said it -- "commit message" and "explain" in the same sentence.
[18:15:03] <CIA-99> ffmpeg: darkshikari * r23782 /trunk/libavcodec/ (dsputil.c vp8dsp.c vp8dsp.h vp8.c):
[18:15:03] <CIA-99> ffmpeg: Make VP8 DSP functions take two strides
[18:15:03] <CIA-99> ffmpeg: This isn't useful for the C functions, but will allow re-using H and V functions
[18:15:03] <CIA-99> ffmpeg: for HV functions without adding separate H and V wrappers.
[18:15:39] <mru> wtf were those functions doing in dsputil.c?
[18:15:48] <BBB> so if I redo this and set height=16 for all h/v8 functions it's fine and I can commit?
[18:16:05] * mru needs to find a gcc flag to stop people adding random weird stuff to dsputil.c
[18:16:11] <BBB> Dark_Shikari: you can probably move them to vp8dsp now, put_pixels() being static was the only reason why they were there iirc
[18:16:16] <Dark_Shikari> I already did.
[18:16:20] <BBB> oh
[18:16:21] <BBB> fine
[18:16:24] * BBB goes work on asm
[18:16:35] <Dark_Shikari> BBB: you should take my patch and modify it, not vice versa
[18:16:35] <mru> actually, that might be possible
[18:16:40] <Dark_Shikari> i.e. your patch shoudl have the sse2 and ssse3 stuff too
[18:16:44] <Dark_Shikari> and the templated vp8dsp loaders
[18:16:59] <Dark_Shikari> If you can't test the ssse3 -- that's _fine_, just send me the patch when you _think_ you've fixed it
[18:17:02] <Dark_Shikari> and I'll test it for you.
[18:17:13] <Dark_Shikari> in short:
[18:17:17] <Dark_Shikari> 1) save local changes
[18:17:21] <Dark_Shikari> 2) revert local changes
[18:17:23] <Dark_Shikari> 3) apply my patch
[18:17:27] <Dark_Shikari> 4) apply your changes
[18:17:34] <Dark_Shikari> 5) try to make it work for all the functions
[18:17:44] <Dark_Shikari> 6) when you think you've done it, and it passes for everything you can test, I'll test the rest.
[18:18:21] <Dark_Shikari> also, fyi, your C code is actually pretty good.  like, seriously, I did an microoptimization pass over it and found nothing obvious
[18:18:24] * BBB is about to start another bikeshed
[18:18:33] <Dark_Shikari> What now?
[18:18:37] <Dark_Shikari> Just say it, and we'll resolve it instantly
[18:18:39] <Dark_Shikari> by force if necessary.
[18:19:03] <BBB> you templated h4/6 for no good reason, that's useless
[18:19:15] <Dark_Shikari> what do you mean?
[18:19:18] <BBB> and if I just apply your changes, I don't learn anything, so what's the point then?
[18:19:26] <Dark_Shikari> Sure you learn something
[18:19:29] <Dark_Shikari> a) you wrote the mmx
[18:19:33] <Dark_Shikari> b) you learned how to modify someone else's asm
[18:19:48] <Dark_Shikari> which is often much harder than writing it on your own
[18:20:18] <Dark_Shikari> If you're going to commit it with all my changes removed, I will fix it myself and you will commit nothing.
[18:22:42] <Dark_Shikari> anyways I'll  go commit the non-vp8-specific parts
[18:26:00] <Dark_Shikari> intra pred: committed
[18:26:43] <CIA-99> ffmpeg: darkshikari * r23783 /trunk/libavcodec/ (7 files in 2 dirs): 16x16 and 8x8c x86 SIMD intra pred functions for VP8 and H.264
[18:33:19] <CIA-99> ffmpeg: mru * r23784 /trunk/libavcodec/huffyuv.c: huffyuv: make VLAs fixed size
[18:34:38] <Dark_Shikari> BBB: any other issues?  we now have everything committed except those core dsp functions (mc, idct)
[18:34:54] <CIA-99> ffmpeg: cehoyos * r23785 /trunk/libavcodec/x86/h264dsp_mmx.c: Cosmetics: Fix indentation.
[18:36:25] <Honoome> Dark_Shikari: how sensible is the improvement for h264? :P
[18:36:57] <Dark_Shikari> dunno, 0.1-3%
[18:37:01] <Dark_Shikari> didn't measure, so guessing
[18:37:04] <Dark_Shikari> and giving a stupidly large range
[18:37:11] <Dark_Shikari> depends on how many intra blocks.
[18:37:48] <Honoome> the improvement is for? SSSE3?
[18:37:51] <Dark_Shikari> everything
[18:38:01] <Honoome> that's nice then
[18:47:40] <Dark_Shikari> oh hurr, I broke compilation
[18:47:59] <Dark_Shikari> on gcc 2.9.5
[18:48:07] <mru> fix it!
[18:48:20] <Dark_Shikari> I am
[18:48:21] <mru> j-b: we need your bot here :-)
[18:49:36] <CIA-99> ffmpeg: darkshikari * r23786 /trunk/libavcodec/vp8dsp.c: Fix c99ism in r23782
[18:49:53] <Dark_Shikari> oh hurr, I fail wrt makefile hackery
[18:51:04] <Dark_Shikari> feel free to fix my mistake, I don't trust myself with makefiles
[18:51:32] <mru> what have you done?
[18:52:16] <CIA-99> ffmpeg: mru * r23787 /trunk/libavcodec/elbg.c: elbg: remove VLAs
[18:52:40] <Dark_Shikari> I broke compilation with yasm and without gpl
[18:52:48] <Dark_Shikari> because I put a non-gpl-asm file in CONFIG_GPL in the makefile
[18:52:53] <Dark_Shikari> and I don't know how to fix it properly
[18:52:57] <Dark_Shikari> because I suck at makefiles
[18:53:02] <mru> so learn
[18:53:08] <Dark_Shikari> I don't want to break it again
[18:53:14] <mru> I'm looking at it
[18:53:24] <Dark_Shikari> I don't know what CONFIG it should be under
[18:53:26] <Dark_Shikari> is there a CONFIG H264?
[18:53:49] <Dark_Shikari> should it be under MMX-OBJS-$(HAVE_YASM) ?
[18:53:54] <Dark_Shikari> should it be under YASM-OBJS-$(CONFIG_FFT) ?
[18:53:56] <mru> it's used by vp8 as well, right?
[18:53:58] <Dark_Shikari> I have no fucking clue
[18:53:58] <Dark_Shikari> yes
[18:54:15] <mru> then vp8 should _select h264dsp in configure
[18:54:42] <mru> and the relevant files should be under CONFIG_H264DSP
[18:55:10] <Dark_Shikari> I have no idea what the right thing is to do, and I have to go to work
[18:55:13] <Dark_Shikari> so please, somebody fix this.
[18:55:19] <mru> I'm on i
[18:55:20] <mru> t
[18:55:24] <Dark_Shikari> ok
[18:55:25] <Dark_Shikari> thanks
[18:57:41] <mru> deblock and idct are gpl?
[18:59:06] <Dark_Shikari> yes
[18:59:13] <mru> why?
[18:59:13] <Dark_Shikari> they're copypastad from x264
[18:59:29] <mru> who's refusing lgpl?
[18:59:31] <Dark_Shikari> the company I work for is paying to get deblock lgpl'd
[18:59:31] <Dark_Shikari> loren
[18:59:47] <mru> I'm making a mint selling lgpl code btw
[19:00:30] <mru> did you test this code at all?
[19:00:32] <mru> it doesn't build here
[19:00:40] <Dark_Shikari> I tested it with enable-gpl
[19:00:44] <Dark_Shikari> all fate tests are with enable-gpl
[19:00:58] <mru> libavcodec/vp8dsp.c:261: error: 'y' redeclared as different kind of symbol
[19:01:42] <mru> removing the int y line fixes
[19:02:28] <Dark_Shikari> oh I'm a fucking moron
[19:02:43] <mru> I don't see why that's an error though
[19:03:07] <Dark_Shikari> committed
[19:03:13] <Dark_Shikari> it's because y is an argument to the function
[19:03:15] <Dark_Shikari> and we just shadowed a variable
[19:03:20] <Dark_Shikari> fuck it I cannot think this morning
[19:03:27] <Dark_Shikari> I should not be coding, pull my hands off the keyboard =p
[19:03:28] <mru> but that shouldn't be an error normally
[19:03:37] <Dark_Shikari> Redeclaring a variable is an error.
[19:03:48] <mru> not in an inner scope
[19:03:55] <CIA-99> ffmpeg: darkshikari * r23788 /trunk/libavcodec/vp8dsp.c: Really fix r23782
[19:03:56] <Dark_Shikari> it isn't in an inner scope
[19:04:09] <Dark_Shikari> the scope of the function args is the same as the highest level scope in the function
[19:04:25] <mru> no
[19:04:31] <Honoome> mru: gcc 4.5?
[19:04:38] <Dark_Shikari> function( int x ) { int x; } is invalid
[19:04:38] <mru> when did that change?
[19:04:46] <mru> that used to be totally valid
[19:04:59] <Honoome> mru: gcc45 refuses it
[19:05:10] <Honoome> as to whether it changed in the standard, no clue
[19:06:25] <mru> or maybe it is invalid
[19:06:30] <mru> whatever
[19:06:32] <mru> it's fixed
[19:07:07] <Dark_Shikari> cehoyos fixed my makefile
[19:07:11] <Dark_Shikari> I guess he's not here, but either way thanks
[19:07:16] <CIA-99> ffmpeg: cehoyos * r23789 /trunk/libavcodec/x86/Makefile: Fix compilation without --enable-gpl.
[19:07:48] <mru> and he did it wrong
[19:07:51] <mru> damn
[19:07:57] <mru> I'm the makefile maintainer here
[19:08:43] <Dark_Shikari> lol
[19:08:45] * Honoome hands mru a hacksaw
[19:08:52] <Dark_Shikari> BIKESHED BIKESHED
[19:10:21] <mru> I was 10s from committing it properly
[19:10:25] <Dark_Shikari> lol
[19:10:26] <Dark_Shikari> then fix it
[19:10:31] <mru> alredy done
[19:10:58] <CIA-99> ffmpeg: mru * r23790 /trunk/ (libavcodec/x86/Makefile configure): Make vp8 select h264dsp and use this to pull in mmx intrapred
[19:28:58] <CIA-99> ffmpeg: mru * r23791 /trunk/libavcodec/huffyuv.c: huffyuv: remove unnecessary size argument from generate_len_table()
[20:18:46] <Honoome> mru: what was the reason why you discouraged using precalculated tables? (with the exception of storage space for embedded, that i know)
[20:19:02] <mru> huh?
[20:19:35] <Honoome> mru: you said something against using hardcoded constant tables the other day when I was talking about the huge .bss in ffmpeg
[20:20:04] <mru> hardcoded makes the lib bigger
[20:20:29] <mru> generated can't share the tables at runtime
[20:20:34] <mru> tradeoffs
[20:20:41] <mru> there's a reason we support both
[20:21:05] <Honoome> so it's okay if I write and submit some more generators?
[20:22:07] <mru> of course
[20:22:45] <Honoome> k will think first if I can get that done automatically even dure cross-compile ^^
[20:23:18] <mru> our tablegen framework already supports that
[20:23:50] <Honoome> oh? I missed the introduction of that then
[20:24:18] <mru> last year some time
[20:24:25] <Honoome> yeah that explains it
[20:30:03] <spaam> KotH: <3
[20:30:23] <KotH> mru: could you kick spaam for me? thanks
[20:30:58] <spaam> KotH: :(
[21:08:46] <Dark_Shikari> BBB: got your email
[21:09:00] <lu_zero> who implemented tablegen?
[21:09:16] <Dark_Shikari> BBB: wasn't there that "broken on x86_64 problem" you needed to fix?
[21:17:14] <BBB> lu_zero: reimar, I think
[21:17:15] <Honoome> mru: uh... can I assume that a host with cross-compiling has ffmpeg installed, at all? /me needs libavutil >_<
[21:17:24] <mru> no
[21:17:43] <Honoome> afraid so
[21:17:45] <Dark_Shikari> BBB: ?
[21:17:54] <mru> Honoome: what are you doing?
[21:18:12] <Honoome> wanted to start with an "easy" one (the VLCs are a biit messed up), so I picked up mlp at random
[21:18:18] <Honoome> it has three CRC tables
[21:18:55] <BBB> Dark_Shikari: looking into x264 on how to do that again ;)
[21:19:10] <Dark_Shikari> BBB: I don't actually _know_ why it crashes
[21:19:17] <Dark_Shikari> it should work
[21:19:22] <Dark_Shikari> but either way, the correct method is something like this:
[21:19:32] <Dark_Shikari> %ifdef ARCH_X86_64
[21:19:47] <Dark_Shikari> or actually, crap, win64 is different too
[21:19:53] <Dark_Shikari> Just be lazy and do 7,7
[21:19:54] <Dark_Shikari> instead of 6,6
[21:19:56] <Dark_Shikari> problem solved
[21:20:04] <Dark_Shikari> better solution imo
[21:20:12] <BBB> k
[21:20:14] <Dark_Shikari> BBB: in short, remove "mov r5, r6m"
[21:20:17] <Dark_Shikari> replace r5 with r6 in those functions
[21:20:21] <BBB> right
[21:20:23] <Dark_Shikari> etc
[21:20:32] <Dark_Shikari> Also, it passes on my machine
[21:20:35] <Dark_Shikari> your diff
[21:20:38] <Dark_Shikari> Make sure to test each level of asm, btw
[21:20:41] <Dark_Shikari> I tested ssse3 and sse4
[21:20:45] <Dark_Shikari> I assumed you tested mmx, mmxext, sse2
[21:20:50] <Dark_Shikari> to test each, comment out the loads for sse2
[21:20:53] <Dark_Shikari> then comment out for mmxext
[21:20:53] <Dark_Shikari> etc
[21:21:47] <BBB> I tested all of them
[21:22:06] <BBB> I had to do that to test for performance improvements anyway ;)
[21:22:07] <Dark_Shikari> ok, great
[21:22:19] <Dark_Shikari> in that case, fix the mov r6m issue and you are DONE and we can commit :)
[21:22:29] <Dark_Shikari> if you want, give me the patch one more time so I can check the ssse3 ones again
[21:22:33] <Dark_Shikari> (when you're ready)
[21:23:52] <BBB> still have to fix PIC
[21:23:57] <Dark_Shikari> Oh yeah, that.
[21:24:13] <Dark_Shikari> cabac-a.asm has the LOAD_GLOBAL macro, which you can borrow.
[21:24:19] <Dark_Shikari> oh, but that's not quite the same.
[21:24:35] <Dark_Shikari> ok, well, feel free to write up an example solution and I'll check it out for you
[21:26:17] <Honoome> mru: do you think it's possible to have a generic hardcoded version of INIT_VLC_STATIC? seems to be the cause of most of the .bss
[21:29:03] <mru> tricky
[21:29:49] <Honoome> I estimate at least 2 of the 4MB of .bss in libavcodec are caused by that
[21:30:05] <mru> rv34 and ivi*?
[21:30:14] <mru> dv is pretty awful too iirc
[21:30:24] <Honoome> ivi and msmpeg4
[21:30:30] <mru> but what's so bad about bss anyway?
[21:30:48] <Honoome> as you said, it cannot be shared :)
[21:31:05] <mru> do you run hundreds of ffmpeg processes decoding indeo at the same time?
[21:31:40] <Honoome> indeo, no... but testing feng it's not so rare to run over 200 ffmpeg instances...
[21:31:59] <mru> if you don't use indeo, that table will not use any space at all
[21:47:06] <BBB> I don't think I get it... so which part takes care of PIC?
[21:47:17] <BBB> is it just the indirect lea ?
[21:49:31] <Dark_Shikari> PIC means you cannot do [global_constant + REG]
[21:49:42] <Dark_Shikari> for example, this is one way to avoid this:
[21:49:48] <Dark_Shikari> %ifdef PIC
[21:49:56] <Dark_Shikari> lea r5, [const]
[21:50:04] <Dark_Shikari> lea r5, [r5+r2*4+8]
[21:50:07] <Dark_Shikari> %else
[21:50:14] <Dark_Shikari> lea r5, [const+r2*4+8]
[21:50:15] <Dark_Shikari> %endif
[21:50:38] <BBB> oh that's all?
[21:50:43] <Dark_Shikari> That's it.
[21:50:52] <Dark_Shikari> Oh, and on x86_64, where PIC matters, iirc r11 is free for a temp.
[21:50:57] <Dark_Shikari> i.e. you can do whatever you want with it.
[21:51:10] <Dark_Shikari> If you need it.  You rarely do.
[21:51:19] <BBB> I can just use r5/r6 in each function
[21:52:10] <Dark_Shikari> to test, all you need is an x86_64 machine.
[21:52:18] <Dark_Shikari> which I strongly suggest you get ssh access to
[21:52:24] <Dark_Shikari> no matter how shitty it is
[21:52:42] <BBB> can I do lea r5, [const + r5]?
[21:54:04] <Dark_Shikari> no.
[21:54:11] <Dark_Shikari> but you can do lea r11, [const]
[21:54:13] <Dark_Shikari> add r5, r11
[21:54:36] <BBB> is pic ever defined for non-64-bit machines in yasm?
[21:54:50] <BBB> (because for 32-bit machines, r11 doesn't exist, right?)
[21:55:31] <Honoome> ebx...
[21:56:06] <Dark_Shikari> BBB: we only support x86_64 pic
[21:56:25] <Dark_Shikari> much to the chagrin of hardened gentoo users
[21:56:38] <mru> and the selinux trolls
[21:56:44] <peloverde> and google
[21:57:20] <mru> I've still not seen a single explanation of why textrels would be a security problem
[21:57:34] <Honoome> I thought it was also part of the debian policy to not allow textrel?
[21:57:40] <Honoome> mru: it's not that htey are a security problem themselves
[21:57:53] <Honoome> but to enable textrel, you enable write access to the executable memory areas
[21:57:55] <mru> debian are fading
[21:57:59] <Dark_Shikari> Honoome: no you don't
[21:58:06] <Honoome> thus you cannot lock them up with nx
[21:58:11] <mru> Honoome: and how did you think the code got there in the first place?
[21:58:16] <Honoome> Dark_Shikari: that's what the current implementation does..
[21:58:16] <mru> the kernel puts it there!
[21:58:23] <mru> by WRITING it
[21:58:26] <Dark_Shikari> what mru said
[21:58:33] <Honoome> mru: erm yes, but the relocations are done in userspace by ld.so
[21:58:41] <mru> so?
[21:58:45] <Dark_Shikari> Honoome: and ld.so couldn't, like, set the nx bit back when it's done?
[21:58:54] <mru> remove the write bit, then set the exec bit
[21:59:00] <Honoome> Dark_Shikari: seems like it doesn't..
[21:59:00] <Dark_Shikari> And what mru said.
[21:59:03] <Dark_Shikari> Then that's a bug
[21:59:09] <Dark_Shikari> allowing write-execution is a bug.
[21:59:13] <Honoome> don't tell that to me..
[21:59:21] <mru> Dark_Shikari: x86 is a bug then...
[21:59:30] <Honoome> it's like gcc trampulines that require execstack
[21:59:36] <Dark_Shikari> mru: it's not the job of the arch to stop the kernel from doing stupid things
[22:00:07] <Honoome> the other problem is that you then end up treating .text like .data and causing CoW
[22:00:23] <mru> x86 didn't have an exec bit at all until the late P4s
[22:00:34] <mru> Honoome: so?
[22:00:40] <mru> is that a _security_ problem?
[22:00:44] <Honoome> no
[22:01:02] <BBB> should pw_64 also be accessed using that thing?
[22:01:10] <Honoome> that's a "I would like not to waste 100MB of FFmpeg instances" :P
[22:01:32] <Honoome> otoh my solution to all this is "x86-64"
[22:01:53] <Honoome> to the chagrin of those who insist that 32-bit code is faster
[22:02:39] <mru> when the selinux trolls see something can be forbidden, they have an instinctive knee-jerk reaction to enable that
[22:02:47] <mru> because that has to be more secure, right?
[22:03:29] <Honoome> mru: I'm not really a selinux kind of guy myself
[22:03:41] <mru> good
[22:03:53] <mru> they tend to run fedora
[22:04:00] <mru> or sometimes centos
[22:04:04] <Honoome> yeah well gentoo's selinux support is shitty, so ..
[22:04:09] <mru> if they're hardcore
[22:04:15] <Honoome> I'm actually more interested in things like ssp myself
[22:04:25] <Honoome> it's like PIE and ASLR...
[22:05:03] <mru> I think more effort should be spent on writing correct code to begin with
[22:05:22] <mru> and less on papering over the effects of bad code after it's exploded
[22:05:26] <Honoome> sure you randomize the address space... fine for binary distros.. but how can you tell what are the addresses on _my_ gentoo system?
[22:05:50] <Honoome> and if you can find them by probing at apache, aslr is not going to help me the slightest until I restart it...
[22:06:16] <Honoome> mru: I think ssp itself is a nice way to identify the broken code, but that's about it
[22:06:43] <mru> tools for finding bugs are good
[22:06:54] <mru> they should be used during development
[22:07:21] * peloverde found the logic flaw in aacenc window selection :)
[22:07:50] <Honoome> I'm still uncertain about fortify-source
[22:07:58] <Honoome> it changes too much the logic around
[22:08:14] <spaam> mru: do you use that kind of tool on ffmpeg? :)
[22:08:56] <mru> we run the full test suite under valgrind
[22:10:48] <spaam> using cppcheck or something like that also? :)
[22:13:16] <mru> cppcheck?
[22:13:56] <j-b> astrange: ping
[22:14:01] <Honoome> looks like a static analysis tool
[22:14:20] <mru> probably not very useful then
[22:14:44] <peloverde> We run CSA regularly http://tranquillity.ath.cx/clang/, it found a few bugs the first few times, now it's more or less useless
[22:14:46] <spaam> mru: static code analysis for c/c++
[22:14:52] <spaam> ;D
[22:14:56] <peloverde> However like mru it hate VLAs :)
[22:15:06] <mru> good ;-)
[22:15:07] <spaam> peloverde: ok :)
[22:15:08] <Honoome> just the auto-variable tests but that's very much rare
[22:16:11] <mru> only a few more vlas left now
[22:17:33] <Honoome> mru: interestingly enough checking for vlas on feng brought up a stupid function that was passed a parameter, used for vla... that was a constant =_=
[22:19:37] <mru> I found several of those in ffmpeg
[22:19:51] <mru> or where the only possible values were 1 and 2
[22:20:58] <Honoome> now my only huge problem is that the way I'm running the parser over rtsp requests it's a bunch of memmove :(
[22:21:18] <_av500_> mru: but then you can make the param a bool :)
[22:21:28] <_av500_> boo + 1
[22:21:31] <_av500_> +l
[22:21:40] <mru> boo and far?
[22:21:44] <Honoome> because I can't be sure I got the whole request at once ... unless I use sctp with my patched kernel, and FIONREAD
[22:21:59] <_av500_> my coworkers love to typdef bool
[22:22:12] <_av500_> and then to always assing it 0 or 1 and pass to int params...
[22:22:25] <_av500_> but, its a bool...
[22:22:32] <mru> tell them about stdbool.h
[22:22:45] <_av500_> no, they are on java now, they have good bool
[22:22:55] <_av500_> and = 1 is verboten
[22:24:01] <mru> it's fun to set a "boolean" variable to, say, 17 and wait for it to hit some code doing if (foo == true)
[22:24:19] <_av500_> yep
[22:24:29] <_av500_> or how they used to use char for a fn param
[22:24:38] <_av500_> because the value is just so small...
[22:24:50] * Honoome would wish that glib3 required C99, and finally dropped guint8 and company... but knows he'd be delussional
[22:25:16] <_av500_> glib3 can only need GC99
[22:25:17] <mru> but that would be removing the very _soul_ of the library
[22:25:32] <_av500_> genau!
[22:26:09] <mru> the quality of a programmer is inversly proportional to the number of standard types he typedefs
[22:27:09] <pross-au> lol
[22:27:52] <mru> typedefs are ok for function pointers
[22:28:22] <mru> otherwise you end up with int (*(*(*(*foo)[4])(int (*)(int *)))[2])(int)
[22:28:35] <Honoome> mru: did you yank that to a file to paste it back at will? :P
[22:28:48] <_av500_> its on F3
[22:28:54] * Honoome would take all the packages that check for the _size_ of integers and similar in autoconf, and KILL THE UPSTREAMS
[22:29:26] <mru> I think that's one of the worst C declarations I've ever seen
[22:29:27] <Honoome> use the bloody standard types, and if one system (anybody said openbsd?) doesn't have those, simply typedefs out of _those_
[22:29:40] <mru> openbsd has them
[22:29:44] <Honoome> mru: since when?
[22:29:55] <mru> ffmpeg builds there at least
[22:29:57] <Honoome> ah sorry maybe openbsd only had them in the wrong headers until little ago...
[22:30:03] <Honoome> inttypes.h vs stdint.h
[22:30:12] <Honoome> I remember that openbsd was one of the few that lacked stdint.h _entirely_
[22:30:23] <mru> pre-c99 there was some confusion over those headers
[22:30:30] <Honoome> but I admit I haven't tried installing openbsd in a while, even in vm.. especially since qemu kills netbsd as well
[22:30:47] <Honoome> mru: confusion okay.. but why guint8 :|
[22:31:04] <j0sh_> http://www.youtube.com/watch?v=KrfpnbGXL70
[22:31:04] <Honoome> it's not even a #define, it's a damn typedef, which means the compiler warns when you mix those in
[22:32:37] <Honoome> j-b: do you happen to wish to comment about building software as universal binaries, btw? :P
[22:32:50] <mru> Honoome: NIH
[22:33:58] <j-b> Honoome: on Mac?
[22:34:19] <Honoome> j-b: well, yeah.. unless you actually want to use fatelf already :P
[22:35:00] <j-b> Honoome: on Mac, I would like to say ***£Dsdqs¤¤¤q#{#{é"|\^**@@@ and FUCK
[22:35:28] <Honoome> j-b: you can join the fatelf idea bashing then ;)
[22:35:42] <mru> Honoome: fatelf is dead
[22:35:47] <mru> nobody talks about it
[22:35:48] <_av500_> j0sh_: lol at the pron scene
[22:36:06] <j-b> Honoome: how do you call a binary with intel32 and intel64 wrapped up? UB? But then how do explain to moronic users that this UB isn't a ppc UB ?
[22:36:08] <Honoome> mru: I want to make sure no idea like that comes up in the next months
[22:36:13] <mru> btw, for those who don't speak norwegian, the subtitles are accurate
[22:36:54] <mru> j-b: I can haz vlc for m68k?
[22:37:14] <j-b> yes, sure. Here is a compiler
[22:37:51] <j0sh_> _av500_: hilarious,isn't it? :)
[22:37:52] <_av500_> j-b: next vlc has to be a fatelf, you need to bundle an aol cd!
[22:37:53] <mru> for macos8
[22:38:14] <j-b> _av500_: :)
[22:38:32] <Honoome> mru: can we start designing ffexe?
[22:38:37] <j0sh_> j-b: did you ever get ffmpeg networking working?
[22:38:47] <_av500_> ffnet?
[22:38:54] <j-b> j0sh_: I never activated it on Windows builds, IIRC
[22:39:10] <mru> j0sh_: it's only about 10 years late
[22:39:19] <j0sh_> heh
[22:39:27] <Honoome> j-b: while we're all here harassing you, have you fixed live on debian/ubuntu? :P
[22:39:39] <mru> java became the modern-day cobol some 8 years ago
[22:39:42] <j-b> live, as in live55555555555 ???
[22:39:47] <Honoome> that crap yes
[22:39:51] <mru> dead666
[22:40:09] <j-b> Honoome: Sebastien has a patch for the latest live555 crappy change
[22:40:13] <j0sh_> Honoome: he doesn't have to, now that i wrote a patch integrating ffmpeg rtsp in vlc
[22:40:17] <mru> Honoome: we had the idea to write an elf demuxer for lavf
[22:40:28] <Honoome> j-b: what other crappy change?
[22:40:51] <Honoome> j0sh_: good, so soon I can drop the workarounds I added for vlc in feng :P
[22:41:15] <Honoome> mru: okay the demuxer.. but I'm actually tempted to design a new executable format _from scratch_ to workaround elf limitations...
[22:41:59] <roxfan> what limitations?
[22:42:00] <_av500_> will it be fat?
[22:42:12] <Honoome> _av500_: definitely not :P
[22:42:39] <Honoome> roxfan: no encoding of abi, uncountable workarounds and vendor-extensions to provide any basic detail.. standardised versioning...
[22:42:52] <BBB> Dark_Shikari: does that compile?
[22:43:16] <roxfan> there's a movement now for using eabi-derived attributes to encode abi specifics
[22:43:41] <Honoome> where's that movement?
[22:44:08] <roxfan> well, maybe i chose a wrong word
[22:44:57] <roxfan> thisa stuff: http://sourceware.org/binutils/docs/as/GNU-Object-Attributes.html
[22:45:25] <roxfan> it's quite extensible
[22:45:39] <j-b> Honoome: well, I doubt live555 runs on the iPad anyway, so an alternative is welcome
[22:45:58] <Honoome> I meant library ABI, as in the parameters to functions...
[22:46:13] <Honoome> j-b: ipad? O_o
[22:46:18] <j-b> Honoome: why not?
[22:46:30] <roxfan> i'm not sure how a _file format_ going to help there
[22:46:46] <j-b> Honoome: it could be a nice device for VoD rtsp:// client, no?
[22:47:01] <Honoome> j-b: why is there something that seriously still use rtsp?
[22:47:11] <Honoome> I thought we were doing that just for our own enjoyment?
[22:47:32] <j0sh_> lol
[22:47:34] <j-b> Honoome: well, all French ISP are streaming their TVs with rtsp://
[22:47:38] <mru> each architecture has its own properties that might need to be encoded in the file
[22:47:40] <roxfan> you want to implement automatic conversion of function parameters at call time or something?
[22:47:45] <j0sh_> Honoome: i think some network cameras might use rtsp too
[22:47:48] <Honoome> j-b: ah that I didn't know...
[22:47:49] <mru> it makes sense to leave defining those attributes to the vendors
[22:47:54] <_av500_> j-b: freebox ftw
[22:48:01] <j-b> for example :)
[22:48:21] <_av500_> add the fact that it messes up wifi pm
[22:48:31] <Honoome> j-b: next conference in paris I'll try to be there.. by train :P
[22:48:43] <_av500_> train is ok
[22:48:49] <_av500_> at least from FRA
[22:48:56] <j-b> Honoome: could I get then an autograph from you?
[22:48:57] <mru> Honoome: any reason you don't like planes?
[22:49:02] <Honoome> _av500_: from ita :P
[22:49:12] <Honoome> mru: I'm acrophobic.. extends to planes mostly..
[22:49:21] <Honoome> I can accept them if I'm not alone, but alone they still scare the shit out of me :/
[22:49:37] <_av500_> you are seldom alone on a plane
[22:49:43] <Honoome> j-b: sure, bring your gpg fp :P
[22:49:51] <_av500_> unless there are snakes
[22:50:10] <mru> if I found myself alone on a plane I'd be scared
[22:50:20] <Honoome> well "alone" :P
[22:50:31] <j-b> Honoome: nice.
[22:51:36] <janneg> mru: even if it's not flying?
[22:51:52] <mru> janneg: I'd expect at least a pilot
[22:51:53] <BBB> Honoome: radio streams also use rtsp sometimes
[22:52:17] <Honoome> the train from venice is not too bad, by price and time-table... leave at 23, arrives by 12 next day.. single room is acceptable
[22:52:37] <mru> or you could just fly...
[22:53:31] <Honoome> I'm not icarus :P
[22:53:42] <j-b> astrange: do you plan to have hwaccel working with ffmpeg-mt?
[22:53:48] <mru> good, _he_ couldn't fly so well
[22:54:03] <mru> j-b: pointless
[22:54:14] <mru> what is there to mt?
[22:55:02] <j-b> mru: not having 2 different versions of ffmpeg installed?
[22:55:30] <mru> I mean having hwaccel work with -mt should be simply a matter of not doing any mt when using hwaccel
[22:55:34] <janneg> hwaccel doesn't work in -mt?
[22:55:55] <j-b> so far ffmpeg-mt with t=1 doesn't seem to make hwaccell to work
[22:57:08] <janneg> I would consider that a bug
[22:59:16] <j-b> one might
[22:59:35] <j-b> also, maybe our lavc module is borken
[23:10:52] <Honoome> mru: aes.c... the [1] vs [4] .. shouldn't that rather change a multiplier rather than declaring a 2-dimensional array? it's _always_ used linearly afaics
[23:11:15] <mru> try telling that to michael
[23:11:45] <Honoome> ouch..
[23:12:54] <lu_zero> uhm =)
[23:13:54] <BBB> Dark_Shikari: did it compile?
[23:14:24] <lu_zero> 00:46 < Honoome> j-b: next conference in paris I'll try to be there.. by train :P
[23:14:31] <lu_zero> you can reach Torino by train
[23:14:43] <BBB> ohwell, weekend time I guess
[23:14:44] <douglas_carmicha> I'm having problems compiling 0.6 on FreeBSD... can anyone take a look at my pastebin output?
[23:14:44] <BBB> later
[23:14:46] <mru> http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/61898
[23:14:48] <lu_zero> then you get tied and brought to the airplane in a cage
[23:14:56] <mru> ^^ there he claims it's a bug in gcc
[23:15:00] <mru> which is patently false
[23:15:01] <Honoome> lu_zero: I can also take a day to look out of the train writing on the laptop
[23:15:07] <lu_zero> douglas_carmicha: sure
[23:15:13] <lu_zero> Honoome: I did
[23:15:21] <mru> douglas_carmicha: -> #ffmpeg
[23:15:25] <lu_zero> you DO not want it
[23:17:22] <douglas_carmicha> http://ffmpeg.pastebin.com/tAt5M6Cm
[23:17:31] <douglas_carmicha> The main error messages are ones like these, when linking ffprobe_g:
[23:17:37] <douglas_carmicha> '/usr/ports/multimedia/ffmpeg/work/ffmpeg-0.6/libavcodec/libavcodec.so: undefined reference to `ff_dnxhd_init_mmx''
[23:18:25] <lu_zero> fun...
[23:19:08] <lu_zero> try master/svn
[23:20:02] <douglas_carmicha> Basically, build svn head without the port?
[23:20:14] <lu_zero> please try that
[23:20:26] <mru> busted shell or make
[23:20:44] <lu_zero> mru: hopefully
[23:20:54] <mru> probably make
[23:21:03] <mru> it's not building any of the x86 files
[23:25:03] <douglas_carmicha> I got a lot of these assembler messages when I tried a basic build with -D__BSD_VISIBLE in the extra-cflags option:
[23:25:08] <douglas_carmicha> '/var/tmp//cciNA3Jg.s:55: Error: `-1(%ebx)' is not a valid 64 bit base/index expression
[23:25:16] <douglas_carmicha> "/var/tmp//cciNA3Jg.s:55: Error: `-1(%ebx)' is not a valid 64 bit base/index expression
[23:25:39] <spaam> douglas_carmicha: what fbsd version do you use? :)
[23:25:44] <douglas_carmicha> 8.0-RELEASE-p3
[23:25:53] <douglas_carmicha> And the port is only ffmpeg 0.5.2.
[23:25:54] <douglas_carmicha> not 0.6.
[23:26:00] <mru> douglas_carmicha: you're in the wrong channel, go away
[23:26:33] <mru> either ask for help in #ffmpeg or file a proper bug report
[23:26:58] <mru> if you're using the ports, you should go to the port maintainr first
[23:33:56] <peloverde> kshishkov, ping?
[23:36:14] <Honoome> so I _could_ have just converted aes to the gentables framework...
[23:51:38] <mru> does anything test the aes code?
[23:53:33] <Honoome> that's a good question
[23:53:51] <mru> it has a littel test snippet at the bottom
[23:54:30] <mru> oh well, let's try a small patch