[FFmpeg-devel-irc] IRC log for 2010-08-18

[irc at mansr.com]

[00:04:48] <peloverde> What about "movzx  ebp,[ecx+edi*2-0x4]" I see it in code generated by objdump but yasm is telling me "error: invalid size for operand 2"
[00:05:44] <BBB> ecx/edi are 32-bit
[00:05:52] <BBB> doesn't work on x86-64
[00:06:29] <peloverde> I'm doing 32-bit atm
[00:06:54] <BBB> oh, yuo're doing movzx on a lea trick
[00:06:56] <BBB> don't use movzx
[00:06:57] <BBB> use lea
[00:07:50] <peloverde> how so? doesn't lea just do the addressing part?
[00:08:39] <Dark_Shikari> oh
[00:08:42] <Dark_Shikari> what you have to do
[00:08:53] <Dark_Shikari> is specify the size of the instruction
[00:08:59] <Dark_Shikari> yasm does not know if you mean movzx byte or movzx word
[00:09:04] <Dark_Shikari> so it throws an error
[00:09:08] <Dark_Shikari> you need to disambiguate
[00:09:16] <Dark_Shikari> movzx ebp, byte [ecx+edi*2-0x4] (for example)
[00:09:20] <Dark_Shikari> but I don't know if you mean byte or word.
[00:09:54] <peloverde> thanks
[00:10:28] <Dark_Shikari> The error, yes, should be more specific.
[00:24:29] <peloverde> hmm, I'm running into linker errors which probably means I'm doing something stupid
[00:24:54] <Dark_Shikari> peloverde: yasm automatically adds the ff_ prefix
[00:25:02] <peloverde> bingo
[00:25:21] <BBB> why does gdb only remember 3 frames?
[00:25:26] <BBB> and how do I make it remember more?
[00:25:29] <Dark_Shikari> y is a crooked letter
[00:26:47] <peloverde> 3 stack frames ought to be enough for anybody --rms, 1981
[00:27:17] <ohsix> thats a lot more than you get on most PICs :D
[00:34:31] <BBB> \o/
[00:34:41] <BBB> my copy-pixels patch for h264 finally passes fate-h264
[00:34:43] <peloverde> Is there a way to make valgrind follow macros or print disassembly?
[02:47:07] <astrange> you can attach to it with gdb
[03:18:13] <peloverde> It works!
[03:26:15] <saintdev> peloverde: http://pastebin.org/570140
[03:27:03] <peloverde> Does it work?
[03:27:23] <saintdev> yes
[03:27:36] <peloverde> nice
[03:31:16] <saintdev> peloverde: just want any suggestions, or if you think i should send it to the ML?
[03:33:26] <peloverde> aac_ prefix on aac_psy_fir_coeffs is redundant
[03:36:59] <peloverde> otherwise it looks good
[03:38:07] <saintdev> ok
[03:57:26] <saintdev> peloverde: you've created a monster
[03:57:45] <saintdev> /usr/bin/python2.6 ./aacx.py        RES: 1057M
[03:59:37] <peloverde> It keeps all the mdct coefs and all the samples in memory atm
[04:00:08] <saintdev> yeah, so maybe loading an 8 minute file wasn't the brightest thing to do...still climbing
[04:01:46] <peloverde> The size of the .wav+logfile is the *lower*bound on memory usage
[04:02:03] <saintdev> \o/ finished loading
[04:12:20] <peloverde> Dark_Shikari: How do I declare a cglobal that uses the bonus 64-bit general purpose registers?
[04:12:46] <Dark_Shikari> Just stick it under an ifdef ARCH_X86_64 or whatever
[04:13:29] <Dark_Shikari> see deblock_h_luma_sse2 in common/x86/deblock-a.asm in x264 for an example
[04:14:48] <peloverde> I'm getting "undefined symbol `r7'"
[04:17:04] <Dark_Shikari> ok, so the rule is
[04:17:11] <Dark_Shikari> any time you're doing something outside of the bounds of the macro system
[04:17:19] <Dark_Shikari> you have to use the ACTUAL hardware names, not macro names
[04:17:26] <Dark_Shikari> r0 through r6 are actually
[04:17:31] <Dark_Shikari> rdi, rsi, rdx, rcx, r8, r9, rax
[04:17:46] <Dark_Shikari> So extra registers beyond that will be r10, r11, r12...
[04:18:04] <Dark_Shikari> and if you use REALLY a lot of extra regs, you may need to manually push them onto the stack
[04:18:16] <Dark_Shikari> We never wrote code to handle this because we never needed more than about 10.
[04:19:46] <peloverde> Ok, this particular function needs to be converted because it uses split __asm__s to deal with spillage on x86_32 (so yes it needs lots of registers)
[04:20:39] <Dark_Shikari> well you need an x86_32 version don't you?
[04:20:55] <peloverde> yes, I'm using a bunch of ugly ifdefs
[04:22:31] <Dark_Shikari> might as well just do  two separate versions with one ifdef
[04:23:01] <peloverde> I thought about that, we'll see what it looks like when it's done
[04:23:12] <Dark_Shikari> yup.  we don't use any register beyond r11 it seems in x264
[04:23:17] <Dark_Shikari> patches to improve the system welcome
[04:23:24] <peloverde> I already made all of Loren's inline ASM into macros in case I wanted to go that route
[04:23:28] <Dark_Shikari> (e.g. to allow more than 7 auto-saved registers)
[04:50:03] <peloverde> I can't believe I've spent the bunlk of my day on this :/
[04:50:08] <peloverde> *bulk
[05:08:27] <KotH> good morning girls
[05:14:52] <_av500_> <3
[05:16:28] <KotH> _av500_: stay away from me!
[05:16:29] <KotH> ;-)
[05:16:45] <thresh> moroning
[05:30:58] <saintdev> peloverde: do you want a separate patch that only renames the structs?
[06:12:48] <KotH> saintdev: probably yes
[06:12:49] <KotH> ;-)
[06:12:54] <saintdev> lol
[06:15:20] <Tjoppen> god morgon
[06:26:33] <KotH> günaydin cartman
[06:26:46] <cartman> morning KotH
[06:30:39] <Tjoppen> COM and DirectShow is a mess..
[06:31:56] <Tjoppen> had to write a small program that captures, displays and encodes a video from a webcam. the DS stuff was 2-3000 lines, while the libav* stuff was 120 :
[06:32:00] <Tjoppen> o
[06:32:30] <cartman> Tjoppen: I dropped DS and went directly to libvlc ;)
[06:32:57] * KotH might go the same path soon
[06:33:12] <KotH> we've a customer who wants to have a special camera app
[06:33:16] <Tjoppen> ah, good idea. haven't looked at it though
[06:33:30] <KotH> luckily, the requriements for the prototype are, that it runs on _linux_ :)
[06:34:10] <cartman> :D
[06:36:56] <Tjoppen> oh, and I found a patch for a ds device in lavd. IIRC it was rejected or not even proposed, due to it relying on C++
[06:37:23] <KotH> hmm?
[06:37:28] <KotH> why would that be rejected?
[06:37:40] <Tjoppen> but appearently there are C wrappers in xine for COM. which is.. interesting
[06:37:49] <KotH> yes, c-- is evil, but the ABI is that...
[06:37:57] <Tjoppen> KotH: because libav* is C, not C++
[06:38:15] <Tjoppen> although with COM, the ABI stuff shouldn't matter
[06:38:16] <KotH> Tjoppen: the only c++ files in mplayer are those that interface to dshow :)
[06:38:31] <Tjoppen> :)
[06:39:01] <Tjoppen> ooh, now I remember: COM + MinGW = probably not
[06:40:07] <Tjoppen> but I guess you could register it at runtime from your own code
[07:28:21] <mru> morning
[07:28:29] <kshishkov> god morgon
[07:28:38] <kshishkov> (nice Inlandsbanan Y1 train)
[07:28:50] <mru> kshishkov: can you identify the location too?
[07:30:01] <kshishkov> well, obviously it's Inlandsbanan part in Dalarna (i.e. southern part)
[07:30:11] <kshishkov> now only to find appropriate river...
[07:31:09] <superdump> kshishkov: you're on a train?
[07:31:30] <superdump> in sweden?
[07:31:35] <kshishkov> superdump: no, I'm residing in small German town
[07:31:55] <mru> superdump: he's talking about the photo I posted on my blog
[07:32:18] <superdump> aha
[07:32:47] <superdump> i just read kshishkov's blog about german cities
[07:34:43] <kshishkov> looks like some bridge over ämån
[07:35:17] <kshishkov> (not far from Tallhed station)
[07:35:41] <mru> correct river
[07:40:00] * kshishkov has made blåbär photo his new desktop background
[07:40:35] <superdump> :)
[07:41:47] <superdump> i went mushroom picking in the woods while i was 'down south west'
[07:42:37] <superdump> saw some blueberries there
[07:42:42] <_av500_> kshishkov: you have free time to gaze at desktop background?
[07:43:25] * kshishkov älskar norden bären - lingon, hjortron ock blåbär
[07:43:38] <superdump> saw lingon too
[07:43:45] <superdump> no hjortron though
[07:43:56] <mru> superdump: need to go north for those
[07:44:04] <kshishkov> _av500_: yes, right after I turn on my PC and before I launch something
[07:44:06] <Tjoppen> hjortron grow here
[07:44:11] <superdump> where's here?
[07:44:26] <_av500_> kshishkov: turn on pc, hmm...
[07:44:27] <kshishkov> Umeå
[07:44:31] <Tjoppen> umeå. well, they grow a bit more south (övik at least), so I assume here too
[07:44:35] <mru> actually they grow around stockholm
[07:44:38] <mru> in a few places
[07:44:47] <mru> sorry, don't know where
[07:44:47] <kshishkov> _av500_: not all of us develop software on Archos players, you know
[07:45:00] <superdump> we picked a shitload of kantareller though
[07:45:20] <superdump> and i have some photos of interesting funghi
[07:45:35] <mru> my sister has trained her dog to find those
[07:45:51] <superdump> hehe
[07:46:03] <kshishkov> pigs are better in finding truffles at least
[07:47:38] <kshishkov> maybe there's some use for llamas as well (not only blankets/ponchos/whatever)
[07:48:51] <spaam> :)
[07:53:25] <kshishkov> spaam, where're you from? Western Sweden has little coverage here
[07:54:36] <Tjoppen> kshishkov: same town as me
[07:54:39] <spaam> kshishkov: i first came from övik. then i went to BTH in ronneby :)
[07:55:13] <spaam> me and Tjoppen went to same school for 3 years ,D
[07:57:58] <spaam> BTH Blekinge Tekniska Högskola .
[08:02:06] * kshishkov should go to some of those river towns
[08:03:49] <spaam> which ones? :)
[08:04:57] <kshishkov> spaam: Ume_Ã¥, Lule_Ã¥, Skellefte_Ã¥ - see the pattern?
[08:05:39] <Tjoppen> also Piteå
[08:06:35] <spaam> ah those ;D
[08:07:00] <kshishkov> Tjoppen: precis
[08:07:07] <spaam> Umeå and Luleå is nice.  :)
[08:07:28] <KotH> if anyone ever gets near atmel hq, could you please go and hit the atmel engineers with somethin heavy and blunt? thanks
[08:07:56] <kshishkov> KotH: and some people pray on their ICs, you know
[08:09:59] <KotH> pray? i wont pray
[08:10:16] <kshishkov> you'd better pray it works
[08:10:21] <KotH> i'm currently at silicon bug number 4 in the usb core
[08:10:31] <KotH> actually, bug number 4 and 5
[08:10:43] <KotH> i happend to have the luck to trigger two bugs at the same time
[08:11:28] <KotH> and one of those killed my usb hardware debugger
[08:12:23] <kshishkov> that one is a serious bug indeed
[08:14:05] <KotH> yeah..
[08:14:32] <KotH> but what really pisses me of with atmel is that they are unable to talk about the bugs in their chips
[08:15:00] <mru> find an engineer
[08:15:11] <KotH> couldnt
[08:15:27] <kshishkov> is it that hard to RE chip, fix bugs and reassemble it back?
[08:15:47] <mru> KotH: what did you talk to?
[08:15:58] <KotH> mru: 2nd level support
[08:16:27] <KotH> kshishkov: if i'd have the time for that, i'd be designing my own chip
[08:17:16] <kshishkov> I heard there're other manufacturers, is it possible to replace that chip?
[08:21:17] <KotH> i would like to, but the cost would be very high as our whole code base has been build around that chip
[08:21:41] <KotH> we'd have to replace a few 100k loc of low level code
[09:40:13] <CIA-93> ffmpeg: cehoyos * r24820 /trunk/libavformat/flvenc.c:
[09:40:14] <CIA-93> ffmpeg: Add AVC EOS tag to H264-encoded FLV files.
[09:40:14] <CIA-93> ffmpeg: Patch by Thierry Foucu, tfoucu gmail
[10:11:36] <kurosu> do anyone know a bit the code for RV20 and mpeg4 part2/H.263 codec familly ?
[10:12:06] <kurosu> it seems RV20 is mostly H.263 which would then be part2's simple profile with short VOP header
[10:12:40] <kurosu> so basically, a lossless transform could be applied to RV20 bitstream to transform it in part2
[10:12:52] <kurosu> and thus having more h/w devices able to read it
[10:13:42] <kurosu> now, I was wondering if that could be done with streamcopy & forcing another codec id, or if bitstream filtering would be required
[10:13:54] <kurosu> *does anyone
[10:14:41] <Dark_Shikari> probably bitstream filtering
[10:14:50] <Dark_Shikari> iirc all the rvs have their own entropy coding
[10:14:53] <Dark_Shikari> or at least their own variations
[10:15:59] <kurosu> RV10 uses custom DC coding
[10:16:10] <kurosu> but I don't see much for RV20
[10:16:15] <kurosu> still investigating
[10:17:12] <Dark_Shikari> oh interesting.  there is really no rv20.c
[10:17:34] <kurosu> see for instance rv20enc.c, there's also the particular intra coding found in H.263+ afaik
[10:17:45] <kurosu> 'advanced' intra coding
[10:17:56] <kurosu> not sure if that's in mpeg4 part2 though
[10:23:12] <kurosu> I think they do use custom VLC codes
[10:23:19] <Dark_Shikari> then where is that code in ffmpeg?
[10:23:20] <Dark_Shikari> I don't see it
[10:23:57] <kurosu> but the really important part is whether the quantization is possible, and if the DC component precision is still ok
[10:24:10] <kurosu> rv10.c has such code
[10:24:23] <Dark_Shikari> yeah but this isn't rv01
[10:24:24] <Dark_Shikari> *rv10
[10:24:33] <kurosu> rv10_decode_{init,end,frame} is also used for rv20
[10:24:47] <kurosu> ok, gotta leave
[10:24:52] <Dark_Shikari> my quick perusal says no
[10:24:57] <Dark_Shikari> there's no special magic for rv20
[10:25:02] <Dark_Shikari> according to grep
[10:25:03] <kurosu> DC bits are 14 bits
[10:25:08] <Dark_Shikari> according to what
[10:25:14] <kurosu> I think they are 10 or 12 in mpeg4
[10:25:26] <Dark_Shikari> in flv (simple h263) they're 8
[10:25:35] <kurosu> AVCodec rv20_decoder at the end of rv10.c
[10:25:38] <kurosu> afk
[10:27:32] <kshishkov> it
[10:27:40] <kshishkov> is the same codebase anyway
[10:58:40] <CIA-93> ffmpeg: stefano * r24821 /trunk/configure:
[10:58:40] <CIA-93> ffmpeg: Fix configure .pc files generation and make install when
[10:58:40] <CIA-93> ffmpeg: --build-suffix is used.
[10:58:40] <CIA-93> ffmpeg: Patch by Anatoly Nenashev ${surname}_as at mail.ru.
[11:14:30] <CIA-93> ffmpeg: stefano * r24822 /trunk/Changelog:
[11:14:30] <CIA-93> ffmpeg: Remove "CODEC_CAP_EXPERIMENTAL added" entry from the Changelog.
[11:14:30] <CIA-93> ffmpeg: That's an API related change, no point to advertise it in the
[11:14:30] <CIA-93> ffmpeg: Changelog.
[12:04:33] <kurosu> I'm wondering if it's worth bothering the devel ml with my musing, as I'm not sure I would endeavour to take on the bitstream filter development
[12:06:32] <kshishkov> I suspect that even Chinese don't care about RV2
[12:08:09] <kurosu> ffmpeg cares about bikeshed colors, so...
[12:27:31] <twice11> OK, the bikeshed can be painted green. Granted. But are you sure you want to build a wooden bikeshed? Isn't a stainless steel bikeshed more durable, nicer looking and even better? Look, I built this steel bikeshed over there last month, you see, I *DO* know how to build bikesheds!!
[12:29:09] <mru> suddenly that spam for "steel buildings" makes a lot more sense
[12:55:48] <lu_zero> sigh...
[12:56:07] <lu_zero> mru: do you remember how to convert to something sane the gcc-ml patch style?
[12:57:12] <Compn> rv2 ?
[12:57:33] <Compn> there is still 'unknown bit set' in rv20 ... :P
[13:12:21] <kshishkov> I suspect it's for deinterlacing
[13:14:04] <Compn> its not in those rv9 specs? :
[13:14:07] <Compn> :\
[13:14:41] <kshishkov> of course not
[13:14:52] <kshishkov> not even in rv8 specs
[13:15:37] <Compn> i dont remember seeing interlacing in rv20
[13:16:36] <kshishkov> IIRC it usually occurs in files with fade-ins and fade-outs
[13:16:57] <Compn> yeah, like from static images to video
[13:18:44] <kshishkov> well, petition MN to remove that message - that bit doesn't seem to affect image in any way
[13:51:22] <CIA-93> ffmpeg: diego * r24823 /trunk/ (libavcodec/mips libavutil/tomi libavcodec/avr32): Ignore generated dependency files and header objects.
[14:03:40] <mru> lol @ dailywtf
[14:03:49] <mru> lu_zero: what patch?
[14:07:46] <kshishkov> mru: todays dailywtf post sounds like common Java practice. Some Java compilers or checkers will complain about using any non-zero constant in code
[14:08:52] <mru> any "lint" will do that
[14:09:28] * kshishkov looks into his pockets and sees some
[14:09:36] * twice11 suggests readimg the "writing unmaintenable code" guide.
[14:09:42] <lu_zero> uhm
[14:09:50] * lu_zero is reading gcc sourcecode
[14:10:00] <mru> twice11: lu_zero found it for you
[14:10:05] <BBB> how does h264 qpel work? is it 4tap? 6tap? 2tap?
[14:10:09] <lu_zero> mru: gcc has that strange context diff
[14:10:12] * kshishkov puts lu_zero into asylum to save time
[14:10:30] <lu_zero> kshishkov: eh eh
[14:10:33] <mru> BBB: it's a staged filter
[14:10:34] <BBB> it's 6tap right?
[14:10:47] <kshishkov> nope
[14:10:48] * KotH likes :39 -!- Topic for #eth: http://www.archive.org/download/ThePowerOfNightmaresDVD/ThePowerOfNightmaresDVD.iso
[14:10:51] <KotH> 20:39 -!- Topic set by attila [] [Sun Feb 25 12:14:05 2007]
[14:10:53] <KotH> hoops
[14:10:55] <kshishkov> qpel is hpel interpolated again
[14:10:59] <KotH> disregard that
[14:11:12] <BBB> the C code is a little messy
[14:11:17] <BBB> it takes hours to understand
[14:11:22] <BBB> and I'm not even at the asm yet
[14:11:29] <mru> BBB: look at some asm instead
[14:11:29] <kshishkov> KotH: we will but what about #etc members?
[14:11:38] <BBB> mru: omg the asm is better than the C?
[14:11:38] <mru> sometimes it's easier
[14:11:41] <BBB> someone please kill me
[14:12:05] * lu_zero kills BBB 
[14:12:07] <kshishkov> BBB: you can look into spec, it even has pictures
[14:12:08] <BBB> is there a doc that explains it?
[14:12:20] <mru> BBB: ITU-T H.264
[14:12:21] <BBB> spec might be better in this case
[14:12:28] <kshishkov> Iain Richardson should help
[14:12:41] <kshishkov> or what was that guy's name
[14:13:44] <lu_zero> mru: I had to fix gcc mismanagement of inline asm constraint for neon
[14:14:15] <lu_zero> and the only patch floating around was in that strange format
[14:14:23] <mru> lu_zero: avoid inline neon asm like the plague squared
[14:14:35] * twice11 was thinking about http://mindprod.com/jgloss/unmain.html
[14:14:49] <twice11> But maybe gcc source does provide good examples.
[14:15:04] <lu_zero> seems worst than using intrinsics...
[14:15:33] <mru> intrinsics are worse
[14:15:48] <mru> with inline asm you at least get the asm block the way you want it
[14:15:51] <lu_zero> so... pure asm is what's left...
[14:15:59] <kshishkov> you got it!
[14:16:13] <lu_zero> the altivec intrinsics weren't that bad
[14:16:28] <mru> I find that hard to believe
[14:16:28] <kshishkov> yes
[14:16:39] <mru> why would altivec intrinsics not suck when all others do?
[14:16:43] <lu_zero> mru: they were even properly optimized
[14:17:12] <kshishkov> mru: they almost didn't interact with memory or registers, that's why
[14:17:15] <mru> did some company with deep pockets pay to have it done properly?
[14:17:27] <lu_zero> apple+sony+ibm
[14:17:43] <mru> I guess their combined pockets are deep enough
[14:18:05] <lu_zero> last time I discussed some altivec codec
[14:18:51] <lu_zero> I suggested unrolling some part, no change in performance -> gcc did already spot and did the right thing
[14:19:30] <lu_zero> pity now altivec isn't that useful =P
[14:20:09] <lu_zero> kshishkov: well you had 4 ops to do stuff with memory and 2 to hint the cache
[14:20:37] <lu_zero> and a quite small number of instructions
[14:20:46] <lu_zero> there isn't much to get wrong
[14:21:08] <lu_zero> (beside the occasional typos like mergel -> mergeh)
[14:48:30] <jhuntwork> Hi - I have an mpeg2 stream that I need to cleanly slice into separate files at the top of every minute - what's the best way to determine the frame to slice at?
[14:49:33] <jhuntwork> I'm writing some small C code to do this - have the majority of the code so far, just uncertain how best to identify the right frame
[14:49:40] <KotH> step #1: ask in the right channel
[14:50:01] <jhuntwork> right, sorry, didn't read the topic
[14:50:48] <KotH> no problem. we'll only take your mortal soul and your first born if you ever do it again ;)
[14:52:23] * jhuntwork tempts fate by copying his question to the clipboard
[14:52:29] <jhuntwork> should I re-paste into the channel
[14:52:30] <jhuntwork> ?
[14:52:31] <jhuntwork> :)
[14:57:32] <KotH> there is no fate, but what we create ourselves
[14:57:46] <KotH> thus, mike and mans created our fate
[15:26:52] <BBB> this morning I had this amazing epiphany, that all MC code is exactly the same... ok, not exactly, but you have to admit that h264 chroma MC is almost identical to VP8 bilin, so why not share it?
[15:27:23] <BBB> I have an even more amazing epiphany now: I need coffee, and then I'll get back to xvp8, because dsputil is giving me headaches
[15:31:49] <pengvado> share what? they're both bilinears, but not the same function
[15:32:07] <cartman> xvp8 hmmmpf
[15:32:43] <BBB> they looked similar enough
[15:32:47] <BBB> didn't look closely though
[15:32:54] <BBB> hence my second epiphany with coffee
[15:39:52] <lu_zero> jhuntwork: are you trying to segment a file to please apple?
[15:40:04] <jhuntwork> no
[15:40:10] <jhuntwork> it's for personal use
[15:40:41] <jhuntwork> archiving video, but I need the files small-ish and manageable
[15:40:47] <lu_zero> ah
[15:40:48] <jhuntwork> and I need them to be concatenable
[15:40:56] <jhuntwork> and smooth
[15:40:56] <lu_zero> so mpegps
[15:41:00] <jhuntwork> yeah
[15:41:23] * lu_zero is tempted to do an ogg joke but could be killed the next time...
[15:42:15] <KotH> we do not kill people
[15:42:36] <mru> xiphs are not people
[15:42:54] <KotH> we just shot them, feed them to the troll, burn the leftovers and bury the remains under the raised floor
[15:44:05] * KotH would like to send the ffpeaceforce to liberate atmel, so they can finally have some democracy
[15:44:33] <jhuntwork> I'm so close... I'm like 95% there
[15:44:55] <KotH> you mean, you've done the easy 5% of the work?
[15:45:44] <jhuntwork> no... I mean I've got it all working except I think my slicing is just a tad off
[15:46:46] <mru> KotH: no, this is what we do to xiphs: http://imagebin.ca/view/m8GFEJ.html
[15:48:30] <kshishkov> KotH: but Atmel has no oil
[15:48:41] <mru> not even snake oil?
[15:50:45] <lu_zero> mru: the other 2 no?
[16:00:34] <KotH> mru: care to make a plush xpihzagged fish for next LT?
[16:01:21] <kshishkov> KotH: av500 drew it, make him sew one as well. He can also test it on his kids.
[16:01:36] <KotH> jhuntwork: "i just have it working" is always the last thing you hear from a programmer before they disapear for the next weeks coding "the last thing to get it working"
[16:05:03] <jhuntwork> yeah :/
[16:30:43] <CIA-93> ffmpeg: cehoyos * r24824 /trunk/libavformat/id3v2.c:
[16:30:43] <CIA-93> ffmpeg: Support unsynchronisation for id3v2 tags.
[16:30:43] <CIA-93> ffmpeg: Patch by Alexander Kojevnikov, alexander kojevnikov com
[16:40:44] <Rathann|work> what's "unsynchronisation"? ;)
[16:42:11] <mru> frame header emulation prevention
[16:52:18] <twice11> Rathann|work: The MP3 decoder synchronizes in to the beginning of the next frame by looking at the bit stream. A MPEG audio header begins with 12 bits of 1.
[16:52:59] <twice11> As ID3v2 headers are prepended to the file, you should make sure the decode skips the full tag and starts decoding on the data frames, even if it does not know about ID3v2.
[16:53:24] <twice11> And the process of removing the "synchronization" patterns from ID3v2 headers is called unsynchronization.
[16:54:55] <lu_zero> kshishkov, mru: a snagon+xiph-grill plush!
[16:55:27] <mru> lu_zero: what makes you think I can make such things?
[16:56:10] <Rathann|work> twice11: I see, thanks for the explanation
[16:57:00] <lu_zero> mru: I'd say troll leggends, still I could check and ask for a quote in that regard
[16:57:28] <lu_zero> (price for plush designs)
[17:25:39] <Compn> wasnt there an option for making near-black pixels totally black to save bitrate ?
[18:13:19] <DonDiego> bye
[19:01:10] <peloverde> It works on 64-bit too!
[19:02:52] <merbanan> the mdct code ?
[19:04:58] <mru> that would be most awesomest
[19:06:38] <peloverde> yes
[19:07:06] <peloverde> It remains untested on WIN64, but I think all the yasm macroage should take care of that or make it trivial
[19:07:51] <mru> fate will tell us, and it's already broken there
[19:07:57] <Dark_Shikari> watch out
[19:08:01] <Dark_Shikari> win64 has different register rules
[19:08:06] <Dark_Shikari> regarding callee-save, caller-save
[19:08:12] <mru> that's the reason we're doing this
[19:08:12] <Dark_Shikari> and which ones values are passed in
[19:08:22] <Dark_Shikari> it's a gigantic clusterfuck
[19:08:30] <peloverde> Ins't that what yasm macros are for?
[19:09:10] <Dark_Shikari> yes, they should handle it, but only if you're using them exclusively
[19:09:18] <Dark_Shikari> were you the one earlier trying to write code with all 15 GPRs?
[19:09:20] <Dark_Shikari> or was that someone else
[19:09:51] <peloverde> nah, I leave r15 open ;p
[19:09:59] <Dark_Shikari> lol
[19:10:04] <Dark_Shikari> my point is that the yasm macros don't handle all that
[19:10:15] <Dark_Shikari> since you had to do it outside the macro system
[19:10:16] <mru> peloverde: show Dark_Shikari a patch
[19:10:18] <peloverde> but I wind up pushing and popping r10-r14 manually
[19:10:56] <Dark_Shikari> and beyond that it's yasm-macro-based?
[19:11:06] <Dark_Shikari> Also, keep in mind not all of r10-r14 need to be pushed
[19:11:21] <Dark_Shikari> I think r11 doesn't, at least, as in x264 we use it as a generic free PIC register
[19:11:36] <peloverde> http://pastebin.ca/1919600
[19:12:42] <Dark_Shikari> looks good to me, but I can never spot these things anyways.
[19:13:09] <peloverde> the PREROTATER, PREROTATEW, and POSTROTATE correspond to pengvado's inline asm blocks
[19:13:40] <Dark_Shikari> probably should show it to pengvado ...
[19:20:39] <peloverde> hmm, new responses to my trolling of redhat and ubuntu in the chrome bug tracker
[19:20:49] <mru> link?
[19:21:27] <peloverde> http://crbug.com/21318
[19:30:48] <kierank> why does that guy keep using the phrase "proprietary code"
[19:31:47] <mru> obviously a freetard
[19:31:48] <spaam> who?
[19:31:53] <elenril> kierank: http://tvtropes.org/pmwiki/pmwiki.php/Main/VerbalTic
[19:32:24] <mru> and "distributions which will likely never be able to bundle ffmpeg" wtf?
[19:32:35] <Dark_Shikari> kierank: here's a simple solution to that problem
[19:32:38] <mru> refuse != unable
[19:32:39] <Dark_Shikari> every single time they refer to proprietary code
[19:32:51] <Dark_Shikari> say that no linux distribution bundles ffmpeg with libfaac
[19:33:02] <Dark_Shikari> repeat every single time.
[19:33:09] <Dark_Shikari> (and thus their point is invalid)
[19:33:25] <mru> libfaac isn't exactly proprietary
[19:33:30] <Dark_Shikari> mru: well, it contains proprietary code.
[19:33:32] <mru> it's just gpl-incompatible
[19:33:50] <Dark_Shikari> Well, if the reference counts as proprietary.
[19:33:53] <Dark_Shikari> I guess it really isn't.
[19:34:04] <mru> openly distributed source code isn't proprietary by definition
[19:34:08] <Dark_Shikari> well, yay for freetards who have no idea what words mean
[19:35:16] <mru> either that, or everything is proprietary
[19:35:32] <peloverde> I suggested they pay someone to untangle dsputil
[19:35:41] <Dark_Shikari> peloverde: can you please correct them every time they say proprietary?
[19:35:47] <Dark_Shikari> if you let them freely use it, they'll keep using it.
[19:36:18] <lu_zero> peloverde: untangle how?
[19:36:56] <peloverde> large portions of dsputil are built unconditionally and unused if you are only building FFmpeg for a few codecs
[19:38:59] <peloverde> Red Hat is concerned that the presence of that object code will somehow get them in trouble with the MPEG-LA
[19:39:25] <mru> but ubuntu is not?
[19:39:32] <Dark_Shikari> mru: ubuntu isn't patent-crazy
[19:39:34] <Dark_Shikari> they include all of ffmpeg.
[19:39:36] <mru> yes
[19:39:41] <mru> so why can't fedora et al
[19:39:55] <Dark_Shikari> because they are stupid.
[19:40:20] <peloverde> I hope the guy who doesn't want any patented code on his system doesn't use video drivers
[19:40:29] <mru> or computers
[19:40:29] <Dark_Shikari> lol
[19:40:42] <peloverde> or Java
[19:40:47] <kierank> maybe it's rms
[19:40:54] <Dark_Shikari> peloverde: nice patch
[19:42:01] <peloverde> thanks
[19:43:54] <Kovensky> <mru> so why can't fedora et al <-- probably because canonical is uk-based, redhat is us-based
[19:44:09] <mru> doesn't matter
[19:44:20] <mru> if you distribute in the US, their law applies there
[19:44:25] <Kovensky> or maybe it's rms
[20:08:23] <mru> peloverde: btw, you've been playing with clang, right?
[20:09:03] <peloverde> yes
[20:09:23] <mru> it seems it doesn't align stack "properly" on 32-bit x86
[20:10:23] <peloverde> I've only been using it on x86_64, register allocation bugs have plagued me on 32-bit
[20:11:08] <mru> apparently there's a magic flag that makes it build ffmpeg
[20:11:50] <peloverde> --disable-asm?
[20:12:06] <mru> http://fate.ffmpeg.org/x86_32-freebsd-clang/20100818170328
[20:12:39] <peloverde> Odd, I don't see the stack alignment warning
[20:13:00] <mru> that frame was probably aligned
[20:13:08] <mru> it doesn't even preserve alignment
[20:13:16] <peloverde> ahh
[20:13:53] <peloverde> The best I can recommend is to file a bug, but apple doesn't seem to care for preserving stack alignment
[20:14:37] <cartman> peloverde: how so?
[20:14:40] <cartman> they run on ARM
[20:15:00] <mru> cartman: apple doesn't follow official arm abi there
[20:15:06] <mru> and this was about x86
[20:15:37] <cartman> mru: I mean since they care about ARM they should care about stack alignment in general
[20:15:44] <mru> they don't
[20:15:46] <cartman> but since we are talking Apple here
[20:15:50] <cartman> I am not surprised
[20:15:51] <mru> they care about screwing devs
[20:15:54] <cartman> yup
[20:16:04] <mru> and what better way to do that
[20:16:11] <mru> than to subtly break the abi
[20:16:23] <cartman> or ship a sed that doesn't understand -i right ;)
[20:16:26] <mru> and then make the unaligned trap handler fill in garbage
[20:16:31] <mru> instead of dump core
[20:25:28] <Kovensky> <cartman> or ship a sed that doesn't understand -i right ;) <-- that's a GNU extension
[20:25:51] <cartman> Kovensky: stop defending Apple!!111!!!
[20:26:06] <cartman> at least perl -pi is portable :)
[20:26:08] <Kovensky> I'm not defending apple :P
[20:26:14] <Kovensky> and yes, I only use perl anyway
[20:26:17] <Kovensky> fuck GNU regexps
[20:26:36] <mru> those are not gnu
[20:26:43] <mru> they are posix BRE or ERE
[20:26:48] <mru> depending on options
[20:29:52] <jhuntwork> well, I got it
[20:33:28] <Kovensky> <mru> those are not gnu <mru> they are posix BRE or ERE <-- ic, I was traumatized by emacs
[20:33:35] <Kovensky> well, fuck POSIX regexps ;)
[20:33:45] <Kovensky> escaping p. much everything useful is NOT FUN
[20:33:56] <mru> emacs RE are yet another flavour
[20:34:04] <mru> Kovensky: those are BRE
[20:34:09] <mru> ERE are much more useful
[20:34:12] <mru> awk uses ERE by default
[20:34:22] <mru> sed and grep BRE
[20:34:27] <mru> grep -E uses ERE
[20:34:33] <Kovensky> <mru> emacs RE are yet another flavour <-- double escaping D:
[20:34:49] <mru> only in string literals in lisp code
[20:34:56] <mru> which is where you use them half the time
[20:35:07] <mru> _half_, making it doubly annoying
[20:35:36] <CIA-93> ffmpeg: aurel * r24825 /trunk/libavformat/ (8 files): rename LAVF_API_* defines to FF_API_* to clarify that it is not public API
[20:38:21] <CIA-93> ffmpeg: aurel * r24826 /trunk/libavformat/avformat.h: add a comment to clarify that FF_API_* defines are not part of public API
[21:04:11] <CIA-93> ffmpeg: stefano * r24827 /trunk/ (5 files in 2 dirs):
[21:04:11] <CIA-93> ffmpeg: Implement inline function av_fill_image_max_pixstep() and use it for
[21:04:11] <CIA-93> ffmpeg: factorizing code.
[21:08:13] <CIA-93> ffmpeg: stefano * r24827 /trunk/ (5 files in 2 dirs):
[21:08:13] <CIA-93> ffmpeg: Implement inline function av_fill_image_max_pixstep() and use it for
[21:08:13] <CIA-93> ffmpeg: factorizing code.
[21:08:13] <CIA-93> ffmpeg: stefano * r24828 /trunk/doc/APIchanges:
[21:08:13] <CIA-93> ffmpeg: Add APIchanges entry after the addition of av_fill_image_max_pixstep()
[21:08:13] <CIA-93> ffmpeg: of r24827.
[21:08:48] <CIA-93> ffmpeg: stefano * r24829 /trunk/libavfilter/vf_hflip.c: Fix braino: @flip -> @file.
[23:21:17] <CIA-93> libswscale: ramiro * r31976 /trunk/libswscale/swscale.c: validate input data and linesizes