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

[irc at mansr.com]

[00:34:08] <spaam> jaja :)
[04:18:53] <peloverde> saintdev: people are reporting breakage on the window decision patch
[04:19:00] <saintdev> eek
[04:19:03] <saintdev> like what?
[04:19:46] <astrange> cehoyos says "ffmpeg -i appletrailer.mov -ab 256k test.aac" sounds "heavily distorted"
[04:19:47] <peloverde> http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2010-August/032344.html
[04:21:31] * saintdev looks
[04:29:30] <saintdev> could it be because of non common windows?
[04:30:11] <saintdev> hmm, need a way to force common windowing
[04:31:27] <saintdev> it sounds 'echoy' but there's no way block switching (even if it's incorrect) could cause that. that i know of.
[04:33:40] * saintdev doesn't really want to be debugging stereo right now
[04:34:46] <saintdev> peloverde: do common short windows need to have the same grouping?
[04:35:54] <peloverde> I don't remember
[04:36:13] <peloverde> It wouldn't surprise me
[04:36:55] <saintdev> kshishkov: ^^
[04:38:08] <peloverde> Look at the spec or at how it gets decoded/encoded in the bitstream
[04:40:22] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/aacdec.c;h=62aab349e1d1dbd3c7c226927a282c7e87806b2a;hb=HEAD#l1427
[04:40:39] <saintdev> found the check later on
[04:40:46] <peloverde> decode_ics_info is only called once on common_window
[04:49:50] <saintdev> yep, seems to be a bug in non-common windowing
[04:50:22] <saintdev> if i force common widowing with lame attack detection it sounds just as bad as 3gpp
[04:50:38] <saintdev> if i give it free reign, it sounds worse
[04:54:26] <saintdev> the thing is after a certain length of time, 3gpp will bias heavily tword long windows
[04:54:26] <peloverde> huh? shouldn't forcing common_window=0 be essentially dual mono?
[04:54:34] <saintdev> peloverde: other way around
[04:54:49] <saintdev> i'm forcing common_window=1
[04:55:08] <saintdev> not just setting common_window=1, actually setting the window types so that it selects it
[04:55:56] <saintdev> so i'm guessing that 3gpp uses common windows on most everything (along with long blocks)
[04:56:20] <peloverde> common_window = 1 implies the signals are fairly similar
[04:56:50] <saintdev> well sure
[04:58:11] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/aacenc.c;h=0fa33e87b1b2b1e9cec5c0dbe938ebcd213e45ff;hb=HEAD#l569
[04:58:28] <saintdev> yeah i know
[04:58:43] <peloverde> groupings shouldn't be copied, they should be part of the test
[04:59:09] <saintdev> peloverde: http://pastebin.org/791748
[04:59:11] <saintdev> peloverde: ok
[04:59:28] <saintdev> oops forgot to remove the #if 0 there :P
[05:00:59] <peloverde> I'm missing somethign, taht doesn't make sense to me
[05:01:25] <saintdev> how so?
[05:01:51] <saintdev> i'm just copying channel 0's window decision to all subsequent channels
[05:01:57] <peloverde> yes... why?
[05:02:01] <saintdev> which forces common_window=1
[05:02:13] <peloverde> why do you want to force common_window=1?
[05:03:16] <saintdev> because it fixes the problem (not a solution, just a test to see if my hunch was right)
[05:05:31] <saintdev> peloverde: with common_window unset (free to choose) http://saintdevelopment.com/temp/test1.mp4
[05:05:56] <saintdev> peloverde: with the above hack to force common_window=1 http://saintdevelopment.com/temp/test2.mp4
[05:06:17] <peloverde> what do yo umean by free to choose?
[05:06:35] <saintdev> unmodified code
[05:07:12] <peloverde> How about you only set common_window=1 if the window is common to both channels?
[05:07:37] <saintdev> it does that unmodified
[05:08:11] <peloverde> No it doesn't, it ignores groupings
[05:08:54] <saintdev> if (wi[0].grouping[j] != wi[1].grouping[j]) { cpe->common_window = 0; break; }
[05:09:48] <peloverde> hmmm... then something else seems off
[05:10:51] <peloverde> Why is there distortion if the windows aren't identical and common_window=0? That's the dual_mono case
[05:11:15] <saintdev> maybe it uses M/S?
[05:11:39] <peloverde> It shouldn't
[05:11:47] <peloverde> M/S can only be used if common_window is 1
[05:11:51] <saintdev> ahh
[05:12:01] <peloverde> I can't look at this now, i'm in the wrong os
[05:13:15] <saintdev> see if i can do this proper-like. modifying all channels windows to match the current.
[05:14:07] <peloverde> none of this is making sense, i'm too tired, if you have ideas try some stuff out, otherwise I will look at it in the morning
[06:02:15] <saintdev> actually, erm what
[06:02:17] <saintdev> ugh
[06:03:09] <saintdev> i need to get to bed :/
[06:17:57] <saintdev> ok, more correct hack has the same results, whew
[06:23:19] <saintdev> peloverde: 'fixed' hack http://pastebin.org/791965
[06:27:12] <saintdev> although not proper, not seeing a way to do it cleanly at the moment, and i need to get to bed.
[06:29:16] <kshishkov> god morgon
[06:41:11] <kshishkov> hejsan
[06:59:30] <superdump> saintdev: you're working on aacenc i see, excellent! :)
[06:59:56] <superdump> i hope stereo gets fixed soon, as it's probably the more common use case than any other :)
[07:00:20] <superdump> peloverde: what do you think is broken in stereo mode?
[07:00:27] <superdump> hej kshishkov  ;p
[07:13:45] <kshishkov> superdump: any idea what conference is being held in Stockholm and when it ends?
[07:14:31] <superdump> kshishkov: there's this: http://www.digitaldays.se/
[07:14:36] <superdump> not foss, just stuff
[07:14:57] <superdump> http://communityhack2.eventbrite.com/
[07:15:01] <superdump> that's foss methinks
[07:15:08] <kshishkov> no, I mean some conference not related to us
[07:15:14] <superdump> when?
[07:15:25] <kshishkov> it's the reason why all hotels in Stockholm are full
[07:18:09] <superdump> no idea
[07:18:30] <superdump> there's some concert called popaganda on
[07:18:37] <superdump> but i can't imagine it being that big
[07:19:21] <kshishkov> ah, something on cardiology till 1st of September
[07:22:03] <kshishkov> well, I wanted to visit Sundsvall anyway
[07:29:39] <merbanan> kshishkov: are you in sundsvall now ?
[07:30:12] <kshishkov> merbanan: no :( Uppsala
[07:30:17] <merbanan> ah ok
[07:30:26] <kshishkov> but I'll go there today
[07:30:31] <merbanan> ok
[07:31:21] <merbanan> I'll be gone over the weekend
[07:31:34] <kshishkov> what a coincidence ;)
[07:31:37] <merbanan> but I'll be in stockholm during the weekdays
[07:32:01] <merbanan> then I'll be bizzy on the weekend again
[07:32:07] <kshishkov> eventually I'll be too
[07:32:32] <kshishkov> but I think I know how to lure you to meeting with me
[07:34:23] <merbanan> ;)
[07:35:22] * kshishkov tries to remember what was the capital of Sweden between Birka and Stockholm
[07:53:51] <kshishkov> time to explore vicinity
[08:12:11] <KotH> .o0(why did i read "explode"?)
[08:49:28] <cartman> mru: does fate test clang on OSX?
[08:49:37] <mru> doesn't look like it
[08:49:48] <mru> someone with an osx machine would have to do that
[08:49:53] <cartman> hmm it seems to be able compile it at least :D
[08:49:55] <cartman> nice warnings too
[08:51:43] <cartman> libavcodec/pcm-mpeg.c:294:36: warning: if statement has empty body [-Wempty-body]
[08:51:43] <cartman>                 retval, *data_size);
[08:51:47] <cartman> might be worth to look at
[08:52:36] <mru> if () { /* blank */ } or what?
[08:52:40] <cartman> doesn't seem to be able to compile mmx code
[08:53:06] <mru> it's just a dprintf
[08:53:10] <mru> nothing to worry about
[08:53:16] <cartman> yup
[08:53:28] <cartman> why would clang warn for that anyway
[08:53:34] <mru> because it's anal
[08:53:49] <cartman> libavcodec/x86/cavsdsp_mmx.c:428:1: error: unrecognized instruction
[08:53:50] <cartman> QPEL_CAVS(avg_, AVG_3DNOW_OP, 3dnow)
[08:53:52] <cartman> end of the road :D
[08:53:52] <Yuvi> haven't seen that warning as of late
[08:53:53] <Yuvi> if you're using svn it defaults to using its integrated assembler which can't assemble 3dnow
[08:54:02] <cartman> Yuvi: svn yup
[08:54:05] <Yuvi> so use --no-integrated-as
[08:54:14] <cartman> Yuvi: oh :)
[08:54:21] <mru> 3dnow is obsolete anyway :-)
[08:54:31] <cartman> 3dneverever
[08:54:35] <cartman> Yuvi: is there a bug for that?
[08:55:03] <Yuvi> http://llvm.org/bugs/show_bug.cgi?id=7352
[08:55:20] <cartman> Yuvi: thanks
[09:03:16] <cartman> make test passes
[09:04:09] <cartman> is there a fate howto somewhere?
[09:04:15] <cartman> how do I checkout & test
[09:06:40] <cartman> mru: any help there?
[09:06:46] <cartman> I am willing to burn my MBP :P
[09:41:50] <wbs> cartman: http://lists.mplayerhq.hu/pipermail/fate/2010-July/000260.html
[09:42:43] <cartman> thanks wbs
[11:47:04] <CIA-11> ffmpeg: vitor * r24954 /trunk/tests/ (5 files in 2 dirs): CCITT Fax Group compression fate tests
[12:17:19] * _av500_ is back from smaland
[12:21:08] <KotH> oh.. you were in lichtenstein? how much money did you "save" this time?
[12:25:30] <janneg> s/lichtenstein/sweden/
[12:25:42] * janneg gives _av500_ an 'Ã¥'
[13:50:46] <BBB> Dark_Shikari: if I have a define as in %define AVG(x, y) which is either nothing or pavgb x, y (called like AVG(m100, [addr])), can I make this define a multi-instruction statement somehow? e.g. AVG2(x,y,z) would expand to movd y, z; pavgb x, y; %define AVG2(x,y,z) movd y,z\<newline>pavgb x, y doesn't work
[14:08:06] <CIA-11> ffmpeg: aurel * r24955 /trunk/libavcodec/vp56dsp.c: cosmetic
[14:46:44] <CIA-11> ffmpeg: vitor * r24956 /trunk/tests/ (ref/fate/fax-g4 ref/fate/fax-g4s fate2.mak):
[14:46:44] <CIA-11> ffmpeg: Remove CCITT fax G4 tests (partial revert of r24954). This test is
[14:46:44] <CIA-11> ffmpeg: corrupting memory somehow and segfaulting in the BSDs.
[14:52:53] <CIA-11> ffmpeg: vitor * r24957 /trunk/tests/ (ref/fate/ws_snd fate2.mak): Add fate test for Westwood SND1 codec
[15:06:56] <Dark_Shikari> BBB: make it a macro
[15:07:06] <BBB> yeah I ended up doing that
[15:07:12] <BBB> so there's no way to do that using direct defines?
[15:07:39] <Dark_Shikari> what's wrong with a macro?
[15:07:42] <Dark_Shikari> a macro is just a multi-line define
[15:07:43] <BBB> nothing
[15:07:54] <BBB> it's a few more lines of code, it seems
[15:08:00] <BBB> but it's nothing important
[15:46:52] <BBB> if I specify that a function should use 8 registries on x86-64, I get this: "warning: (ASSERT:2) assert failed" (i.e. cglobal func, 6, 8)
[15:47:28] <BBB> Dark_Shikari: what should I do if I want to use 8 regular registries on x86-64? is func, 6, 7 enough?
[15:48:46] <Dark_Shikari> look at x264, deblock-a.asm
[15:48:48] <Dark_Shikari> and the x86_64 functions
[15:50:40] <BBB> cglobal deblock_h_luma_sse2, 5,7
[15:50:40] <BBB>     movsxd r10, r1d
[15:50:47] <BBB> so r10 is caller-save?
[15:51:04] <BBB> (or rather, callee-can-fuck-it-up-as-it-wishes)
[15:52:06] <Dark_Shikari> yes
[15:52:16] <Dark_Shikari> it's one of a few extra free registers
[15:52:23] <Dark_Shikari> we never created a unified system for handling functions with >=8 regs
[15:53:49] <BBB> got it
[15:53:56] <BBB> I only needed 1, r10 is perfect
[15:53:57] <BBB> thanks
[16:04:35] <kierank> anybody up for ffoktoberfest?
[16:04:51] <mru> where and when?
[16:05:20] <KotH> münchen, oktober?
[16:05:28] <kierank> yes
[16:05:34] <kierank> oktoberfest runs from Sep 18 – Oct 4
[16:05:35] <mru> oktober is a bit vague
[16:06:09] <KotH> kierank: wrong range of date for me
[16:06:20] <mru> I'll be in karlsruhe through september
[16:06:38] <mru> guess I could pop over to münchen for a weekend
[16:07:13] <mru> 18th or 25th would work
[16:10:08] * BBB has make fate passing with rv40/h264/vc1 mmx-mc converted into yasm
[16:10:09] <BBB> \o/
[16:10:17] <BBB> now to do the ssse3 parts
[16:10:28] <mru> nice work
[16:10:35] <BBB> it's a lot less code also
[16:10:44] <BBB> not code as in binary code
[16:10:49] <BBB> just code as in "crap around it"
[16:33:39] <Dark_Shikari> BBB: god damn this will be so much easier to maintain now
[16:33:43] <Dark_Shikari> you are awesome
[16:33:45] <BBB> I know
[16:33:53] <BBB> I already see tons of ways to optimize this now that I can read it
[16:34:15] <Dark_Shikari> but we need to do xvp8 eventually =p
[16:34:16] <BBB> you have no^devery idea how much more readable yasm is over inline asm
[16:34:23] <BBB> I know, I want to do that
[16:34:28] <BBB> but this needs to be done also
[16:34:37] <Dark_Shikari> at this rate we won't be done in time for xiphcon ;)
[16:34:51] <Dark_Shikari> but yes I agree.
[16:34:58] <BBB> some people have asked me about my ideas on vp8 encoding already
[16:35:06] <BBB> I might just push them a little so we get funding
[16:35:11] <BBB> much better than doing it for free ;)
[16:35:19] <BBB> everyone complains libvpx performance is horrible
[16:35:24] <Dark_Shikari> eheheheheh
[16:35:26] <BBB> these are the freetards btw :-p
[16:35:58] <Dark_Shikari> the evil x264 plan to take over the world
[16:37:53] <BBB> I always wonder how that will work... so will phones in 5 years from now use x264 for encoding plus a stripped ffmpeg for decoding when they do video-chat?
[16:38:06] <BBB> phones = android phones I guess, since that's currently the best seller in the US
[16:39:00] <BBB> please port yasm to support neon or so :-p
[16:39:52] <funman> what's wrong with gas?
[16:41:30] <Dark_Shikari> horrible preprocessor
[16:41:32] <Dark_Shikari> ugly syntax
[16:42:36] <roxfan> you can use c preprocessor o.o
[16:43:03] <pengvado> which is horrible
[16:43:05] <roxfan> and arm syntax is pretty much standard
[16:43:11] <Dark_Shikari> what pengvado said
[16:43:54] <Dark_Shikari> asm has no syntactical sugar like function calls and more-than-one-op-per-line like C
[16:43:58] <Dark_Shikari> so you need a very good preprocessor to compensate
[16:44:05] <roxfan> hmm
[16:47:21] <BBB> funman: yasm compared to any old-as is like comparing a ferrari to a ford from the 30s
[16:47:24] <BBB> they're both cars
[16:47:27] <BBB> that's where it ends
[16:55:17] <Dark_Shikari> oh btw, BBB, the new cavlc trellis will allow us to write a vp8 trellis in about 5 minutes
[16:55:21] <Dark_Shikari> "trellis"
[16:55:29] <Dark_Shikari> (we can write a real trellis later, since vp8 is relatively easy to trellis)
[16:55:55] * BBB accepts the poke :-p
[16:57:13] <BBB> shit I'm slow, should head out or I'll miss dinner
[16:57:17] * BBB forgot it was 1PM already
[16:57:32] <Dark_Shikari> 1 PM?  dinner?
[17:02:38] <mru> gas is fine
[17:02:47] <mru> it's not exactly the same as yasm
[17:02:52] <mru> and therefor Dark_Shikari can't stand it
[17:12:34] <Dark_Shikari> mru: er... no
[17:12:53] <Dark_Shikari> I'm fine with things that aren't yasm
[17:12:53] <pengvado> arm gas syntax isn't as horrible as x86 gas syntax
[17:12:58] <Dark_Shikari> and yeah, what pengvado said
[17:13:05] <Dark_Shikari> "GAS" is not one particular syntax
[17:13:08] <Dark_Shikari> "gas x86" is one particular syntax
[17:13:26] <mru> there are two x86 syntaxes in common use
[17:13:28] <Dark_Shikari> the preprocessor still sucks, but on ARM scheduling is so important than you can't macro things up that effectively anyways
[17:14:17] <mru> I don't think you've explored the full potential of gas macros
[17:15:16] <Dark_Shikari> what can you use besides the C preprocessor in inline asm?
[17:15:44] <mru> the gas builtin macro processor
[17:15:46] <Dark_Shikari> you certainly can't redefine register names
[17:15:52] <mru> can too
[17:15:56] <Dark_Shikari> can you override ops?
[17:16:00] <mru> sure
[17:16:09] <mru> why you'd want to I have no idea
[17:16:13] <Dark_Shikari> simple reason
[17:16:22] <funman> %define NOP RET
[17:16:22] <Dark_Shikari> on x86, "add REG, 128" is larger than "sub REG, -128"
[17:16:29] <Dark_Shikari> because of how the immediates are coded
[17:16:33] <Dark_Shikari> therefore, we do
[17:16:35] <Dark_Shikari> %macro add 2
[17:16:42] <Dark_Shikari> %ifnum %2
[17:16:42] <mru> that's a quirk of x86
[17:16:46] <mru> also not a problem on arm
[17:16:46] <Dark_Shikari> %if %2 == 128 ...
[17:16:53] <Dark_Shikari> Yes, but you didn't say ARM.
[17:16:54] <mru> but it could be done with gas
[17:17:04] <Dark_Shikari> Is there an "ifnum" in gas?
[17:17:17] <Dark_Shikari> i.e. an if that returns true if the operand is a number, false if not.
[17:17:30] <mru> don't remember
[17:17:43] <Dark_Shikari> anyways it's all besides the point since all this shitty x86 asm is inline in C, not separate gas files
[17:17:49] <Dark_Shikari> and is this a pile of bollocks
[17:17:54] <Dark_Shikari> *thus
[18:54:32] <peloverde> wow, winamp's aac decoder is really good
[18:55:01] <elenril> better than ffaac?
[18:55:38] <Dark_Shikari> as in fast?
[18:58:26] <peloverde> As in compliant
[18:58:48] <peloverde> It seems to play everythign except Main and LTP and I have a feeling in that case it's the demuxer rejecting them
[19:03:20] <peloverde> as opposed to FAAD which afaict doesn't actually support ANY whole profiles
[19:05:09] <spaam> kshishkov: Skål!
[19:06:55] <saintd3v> peloverde: don't think i've ever looked into who's decoder they licensed
[19:09:23] <peloverde> I think it was inhouse
[19:09:43] * saintd3v wonders what strings in_mp3.dll says
[19:09:55] <peloverde> "Fraunhofer IIS MP3 Decoder"
[19:10:00] <kshishkov> spaam: well, I got a bottle of Trocadero by Vasa Bryggeriet
[19:10:18] <spaam> kshishkov: nice :)  i got some carlsberg beer : )
[19:10:23] <kshishkov> spaam: but mysteriously it turned to be half-empty
[19:10:35] <spaam> haha :D
[19:10:48] <spaam> going to drink some more ..   c u later :D
[19:11:08] <kshishkov> hej daa
[19:11:39] <saintd3v> peloverde: guess that solves that mystery :P
[19:12:19] <kshishkov> depends on version
[19:12:44] <kshishkov> could it be actuall beta of MP3 licensed to EA?
[19:14:03] <saintd3v> or they could have done like Real, and changed a few things to make their 'own' format
[19:14:15] <kshishkov> why should one main a licensed codec - itÅ› all work and they were not going to compete on general market
[19:14:22] <kshishkov> *maim
[19:14:54] <saintd3v> vendor lock-in?
[19:15:33] <kshishkov> no need for that
[19:16:13] <kshishkov> could be for preventing unauthorised decoding (i.e. by user) though
[19:16:49] <peloverde> every elem_id=0 stream crashes winamp o.O
[19:18:16] <kshishkov> heh
[19:19:59] <Dark_Shikari> "better than faad" is not really that much to brag about
[19:20:57] <peloverde> everyone thought faad was "good enough" for years
[19:23:23] <kshishkov> thatÅ› because nobody tried to look closely at its source code
[20:26:18] <kierank> does oprofile work in a vm?
[20:26:37] <Dark_Shikari> yes, but you have to change the timing mode
[20:26:46] <Dark_Shikari> normally it uses CPU counters
[20:27:02] <Dark_Shikari> it'll tell you that only one counter is available, and that's the kernel timer
[20:34:42] <kierank> doesn't seem to do anything in virtualbox
[20:35:08] <Dark_Shikari> the kernel counter does not require CPU support
[20:35:12] <Dark_Shikari> it will work in virtualbox
[20:59:36] <saintd3v> peloverde: you looked at the issue in aacenc at all?
[21:04:04] <CIA-11> ffmpeg: lorenm * r24958 /trunk/libavcodec/x86/fft_mmx.asm: cosmetics in imdct_sse
[21:18:42] <CIA-11> ffmpeg: vitor * r24959 /trunk/libavcodec/ws-snd1.c: Hopefully fix the fate-ws_snd breakage on PPC
[22:59:23] <BBB> Dark_Shikari: more dark-gray yasm questions
[22:59:42] <mru> paint it black
[22:59:44] <BBB> Dark_Shikari: say I'm running a function that calls another one (idct), so I use jmp to call the second question
[22:59:54] <mru> tail call?
[23:00:00] <BBB> Dark_Shikari: however, on win64, I need to pop some registers before I do that
[23:00:04] <BBB> Dark_Shikari: how do I do that?
[23:00:18] <BBB> mru: jmp is like a tail call, no?
[23:00:24] <mru> jmp is jmp
[23:00:30] <mru> no more, no less
[23:00:31] <BBB> or can I just do call func instead of jmp func?
[23:00:59] <mru> you should optimise tail calls of course
[23:01:17] <Dark_Shikari> BBB: look in x264
[23:01:18] <lu_zero> BBB: those functions are big?
[23:01:19] <Dark_Shikari> there's stuff like
[23:01:22] <Dark_Shikari> %ifdef UNIX64
[23:01:23] <Dark_Shikari> jmp
[23:01:27] <Dark_Shikari> %else
[23:01:30] <Dark_Shikari> call, ret
[23:02:16] <BBB> ok, I don't need to pop regular regs, so I guess I'd do %if win64 call, ret %else jmp .. %endif?
[23:02:22] <BBB> or is that considered unsafe?
[23:02:55] <Dark_Shikari> you mean call, RET
[23:03:03] <Dark_Shikari> I think that's fine
[23:05:47] <BBB> right, call+RET
[23:05:52] <BBB> let's see if that fixes my last problem
[23:06:17] <BBB> yay!
[23:06:23] <BBB> ea-vp60 fate test passes on win64 now
[23:06:51] <BBB> also someone could write rv40 ssse3 mc functions if he wants to kill himself
[23:07:34] <Dark_Shikari> copy vp8's
[23:07:38] <Dark_Shikari> change coefficients
[23:08:54] <BBB> rv40 uses the h264 one
[23:09:01] <BBB> but yeah you could do that too
[23:09:13] <BBB> but if it all uses yasm that's already great progress
[23:17:49] <BBB> I think my patch fixes vc1 fate test on win64 also
[23:17:56] <BBB> goody
[23:18:28] <BBB> I wonder why h264 isn't breaking on win64, it has unmarked clobbering of xmm registers also
[23:21:15] <Dark_Shikari> BBB: luck?
[23:21:32] <Dark_Shikari> we actually have this issue with avisynth64
[23:21:35] <Dark_Shikari> avisynth64 + x264 breaks
[23:21:50] <Dark_Shikari> because avisynth64 clobbers an xmm register that contains a double
[23:21:59] <Dark_Shikari> this double changes to a value that causes a runtime failure
[23:22:28] <BBB> probably luck indeed then
[23:38:19] <BBB> Dark_Shikari: does yasm have access to config.h defines?
[23:38:25] <BBB> e.g. CONFIG_VC1_DECODER
[23:38:30] <Dark_Shikari> If it doesn't, it should.
[23:38:39] <Dark_Shikari> well... I guess it's a bit harder
[23:38:41] <Dark_Shikari> because you can't include it
[23:38:46] <BBB> I guess I meant "does it include config.h"?
[23:38:48] <Dark_Shikari> just use separate files
[23:39:18] <BBB> hm...
[23:39:28] <BBB> how hard is that to fix?
[23:39:36] <BBB> it'd be nice if it did have access to it
[23:41:19] <Dark_Shikari> why do you need it?
[23:43:52] <BBB> I'm wondering how hard it would be to trim the asm file if you run, say, --disable-everything --enable-decoder=h264
[23:44:07] <BBB> (i.e. then don't compile in the rv40/vc1 mc functions to decrease binary size)
[23:44:11] <BBB> it's not very important
[23:44:17] <BBB> but would be nice to have
[23:44:34] <lu_zero> BBB: create a config.mac and include it ^^
[23:44:41] <Dark_Shikari> couldn't you use multiple asm files for that?
[23:44:46] <BBB> I could
[23:44:48] <Dark_Shikari> and yeah you could do that
[23:45:14] <BBB> have the macro in h264_mc_template.asm and then use h264/vc1/rv40_mc.asm, include that and define the actual functions
[23:45:26] <BBB> but then you have 4 instead of 1 files, it's a little messy
[23:45:32] <BBB> it might be the best way, not really sure
[23:45:57] <BBB> I guess I'll bug mru to see if he's ok with a config.asm
[23:46:01] <BBB> I bet he'll object
[23:46:07] <BBB> "x86'ism"
[23:46:15] <Dark_Shikari> config.h is a Cism ;)
[23:46:29] <BBB> mru: ping
[23:48:30] <lu_zero> BBB: provided you can use it on gas and yasm I don't see it that x86'ism
[23:51:55] <BBB> true
[23:53:43] <lu_zero> still I'm wondering why this frenzy with yasm...
[23:56:18] <CIA-11> ffmpeg: rbultje * r24960 /trunk/libavformat/mmsh.c:
[23:56:18] <CIA-11> ffmpeg: stream_selection can be freed in the fail case, in which case it's unassigned.
[23:56:18] <CIA-11> ffmpeg: Therefore, init it with NULL to prevent a crash on invalid streams.
[23:56:18] <CIA-11> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>.
[23:57:45] <CIA-11> ffmpeg: rbultje * r24961 /trunk/libavformat/mmsh.c: Fix two compiler arnings related to printf-format of sizeof()-statements.