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

[irc at mansr.com]

[04:09:36] <astrange> fft65536() never finishes compiling with a checking llvm :/
[06:49:27] <cartman> moin
[06:49:34] <mru> morning
[06:49:41] <kshishkov> god morgon
[06:49:45] <av500> guten morgen
[06:50:06] <kshishkov> mru: please say hello for me at work
[06:50:20] <cartman> :>
[06:50:21] * av500 says "hello for me at work"
[06:50:57] <kshishkov> av500: too much
[06:58:34] <pJok> god morgon
[06:59:15] <kshishkov> hej hej
[06:59:38] * kshishkov has passed Ramlösa a day ago
[07:00:08] <pJok> going south or north?
[07:00:37] <kshishkov> north, to Disneyland^WHelsingborg
[07:01:08] <pJok> ah, close to me then
[07:01:17] <kshishkov> I know
[07:01:57] <kshishkov> and today I can try to pass by Enskede gård
[07:02:02] <pJok> vacation?
[07:02:11] <kshishkov> yes, semester
[07:02:25] <mru> pJok: he's not at work
[07:02:33] <mru> if you see him, please send him back :-)
[07:02:55] <pJok> mru, im not going that far north ;)
[07:03:09] <kshishkov> mru: that may give him too much strain :P
[07:03:45] <pJok> kshishkov, see if you can steal kärnan
[07:03:46] <kshishkov> pJok: could be worse, ~4 days ago I was in Luleå
[07:03:51] <pJok> i tried, it didn't work
[07:04:15] <kshishkov> kärnan? The same stuff as in Tchernobyl region?
[07:04:33] <pJok> nop, that rest of the danish fortification that is left in Helsingborg
[07:05:14] <kshishkov> that tower? No, I don't like to steal
[07:05:21] <kshishkov> especially something heavy
[07:05:22] <pJok> yeah
[07:06:05] <superdump> kshishkov: well, i doubt you'd come through enskede gård
[07:06:07] <av500> mru: at least on irc you should be able to cover for him....
[07:06:39] <superdump> as you'd probably be on a regional train going straight to the center and they don't come through here :)
[07:06:47] <superdump> unless you mean you're hanging around to say hello
[07:07:09] <kshishkov> superdump: no, just teasing you ;)
[07:07:16] <pJok> time to pack down and catch the bus
[07:09:11] <superdump> hehe
[07:11:18] <CIA-11> ffmpeg: mstorsjo * r25029 /trunk/libavformat/rtsp.c:
[07:11:18] <CIA-11> ffmpeg: rtsp: 10l, try to update the correct rtp stream
[07:11:18] <CIA-11> ffmpeg: This fixes a bug from rev 22917. Now RTSP streams where the individual RTCP
[07:11:18] <CIA-11> ffmpeg: sender reports aren't sent at the same time actually are synced properly.
[07:14:19] <vipw> the rtsp code includes support for "punch" packets to open some NATs when starting the rtp streaming
[07:14:35] <vipw> but the source attribute of the transport header is ignored and the punch packets are sent to the RTSP server, even when it states that the rtp stream will come from a different ip
[07:16:44] <wbs> vipw: hmm, good point. I'll see if I can do something about it
[07:16:51] <wbs> vipw: would you mind writing a bug report about it?
[07:17:00] <vipw> not at all
[07:17:20] <wbs> vipw: also, in which setups does this problem appear? what rtsp server are you using, and where do the packets come from, if not from the rtsp server?
[07:17:21] <vipw> i've even got an ugly patch for an older version of ffmpeg
[07:18:12] <wbs> great, give me the issue number once you've written the bug report
[07:18:13] <vipw> the rtsp server is a modified feng, the rtp packets will come from a sip server
[07:18:29] <wbs> ah, sneaky. :-)
[07:18:30] <vipw> it's kind of a corner case, i know :)
[07:22:05] <vipw> i can also prepare a patch if you can tell the "right" way
[07:22:52] <wbs> anything resembling a unified diff is good, svn diff or git diff/show/format-patch is even better
[07:23:39] <vipw> i'm not sure if there's a preferred way to store ip addresses, it's received as a string and needs to be sent as a string, but i see that the destination address is stored as a sockaddr
[07:24:28] <wbs> needs to be sent as a string, when building the rtp:// url, right?
[07:24:42] <wbs> in that case, just store it as a string, I'd say
[07:25:30] <vipw> yeah
[07:26:26] <vipw> and is it safe to use the INET6_ADDRSTRLEN define for its size?
[07:26:54] <vipw> i think that's a portability problem, but i suppose you've got something in place in ffmpeg
[07:27:00] <wbs> I'm not sure if that define is available on all platforms
[07:27:22] <wbs> and we don't use that define from before, so we've got no fallback in place for that one
[07:27:26] <vipw> i'm sure it's not
[07:27:30] <wbs> what's its number?
[07:27:59] <vipw> i think 46
[07:28:29] <wbs> ok.. well, you could just add a similar define in rtsp.h, like MAX_ADDRSTR_LEN 50 or so
[07:28:41] <wbs> perhaps with a comment explaining what it is supposed to do
[07:31:11] <vipw> not an ifndef define?
[07:32:08] <wbs> I think the freestanding one is just as good in this case, and not tied to any particular address family
[07:32:42] <wbs> (what if ipv8 comes along, then we just increase that define instead of changing all use of INET6_ADDRSTRLEN into something else)
[07:33:16] <av500> wbs: we are out of ipv6 addresses soon?
[07:34:30] <vipw> ipv8 is gonna kick ass
[07:35:14] <wbs> av500: nah, but the transition from v4 to v6 at least teaches me to avoid hardcoding any particular address family at all
[07:39:10] <KotH> salut
[08:00:27] <vipw> wbs: https://roundup.ffmpeg.org/issue2212
[08:03:00] <wbs> oh, goodie, it removes an ancient fixme from the code, too ;P
[08:03:42] <vipw> yeah
[08:03:50] <wbs> looks quite good to me in general, although the strncpy looks quite non-ff'ish
[08:04:00] <mru> strncpy is almost always wrong
[08:04:06] <wbs> if a strncpy overflows, it leaves the buffer unterminated, right?
[08:04:18] <mru> if the source doesn't fit, yes
[08:04:19] <vipw> exactly, it's a pita
[08:04:23] <mru> it doesn't overflow as such
[08:04:32] <wbs> yeah
[08:04:37] <mru> it always writes exactly N bytes too
[08:04:42] <mru> padding with zeros if needed
[08:04:50] <mru> strlcpy is usually better
[08:04:59] <mru> av_strlcpy() in ffmpeg
[08:05:16] <wbs> ah, yeah, that's the one
[08:05:51] <vipw> should i fix it up?
[08:06:11] <wbs> yeah, send a new patch with that fixed, that's the only issue I can see
[08:06:21] <mru> strlcpy has got to be good, drepper refuses to include it in glibc
[08:06:49] <wbs> after that, I'll give it a test spin... I'll probably wait for a comment from lu_zero and/or BBB before applying it though, if they have something else to say on it
[08:22:20] <vipw> ok, the new patch is in place
[08:22:35] <vipw> it has the same name, i couldn't remove the old one from roundup
[08:22:48] <vipw> so you have to use the timestamp
[08:23:09] <wbs> looks good to me, I'll give it a test spin in a while, I'm busy with some other things atm
[08:32:41] <hyc> meh. strlcpy is still missing the point.
[08:34:03] <hyc> I prefer "strcopy": while ((*dst++ = *src++)); return dst-1;
[08:34:17] <hyc> replaces both strcpy and strcat
[08:34:25] <mru> you are missing the point
[08:34:37] <hyc> yeah yeah, avoid buffer overruns
[08:34:45] <hyc> you can do a strl variant of that if you wish
[08:34:55] * mru makes note never to hire hyc for security-critical code
[08:35:00] <hyc> but it's still pointless to return the pointer to the beginning of the destination buffer
[08:35:08] <mru> strlcpy doesn't do that
[08:35:09] <hyc> since the caller always knows that address already
[08:35:44] <mru> but if it did, you'd have a point
[08:35:50] <hyc> and it's better to just pass the pointer to the end of the buffer, which then doesn't ever need to be recalculated.
[08:35:54] <mru> congratulations on your hypothetical point
[08:36:39] <hyc> using strlcpy is still clumsy becuase you have to keep updating the length passed in as you build a string
[08:39:29] <andoma> mru: got my beagleboard-xm today! so the shipping delay wasn't that long at all :)
[08:39:52] <av500> andoma: nice
[08:40:05] <av500> i dont see you in #beagle :)
[08:40:07] <mru> does it work?
[08:40:14] <andoma> havent booted it yet. just unpacked it
[08:40:21] <andoma> av500: gotta join
[08:40:35] <andoma> and i need to find a PSU
[08:41:08] <mru> if you're lucky it'll run off usb power
[08:41:27] <av500> mru: very lucky
[08:41:54] <mru> if you don't attach any usb devices it should be ok
[08:41:54] <av500> andoma: there a 2 issues around powering it over usb
[08:42:12] <av500> so a 5v psu might save you a lot of hassle
[08:42:16] <mru> the onboard eth doesn't need much power if you don't connect it
[08:42:30] <av500> mru: that is only one issue, the other is the otg crash with no gadget loaded
[08:42:42] <mru> so don't use those kernels
[08:43:03] <mru> but you'll want g_ether anyway if you're running like that
[08:43:55] <av500> mru: of course, but i still can rant that they are not able to give a good out-of-the box experience, because according ot koen, nobody wants to fix the bug
[08:44:35] <hyc> mru is too quick to hand out insults...
[08:45:10] * av500 waves to pool.ukrtel.net
[08:45:30] * av500 waves to DonDiego
[08:45:35] <mru> hyc is too quick to make a "point"
[08:47:42] <merbzt> yey, threading works
[08:47:51] <mru> doing what?
[08:48:12] <merbzt> encoding 335% cpu
[08:48:38] <mru> that's not very good
[08:48:57] <mru> unless you're hyperthreaded dual-core
[08:49:04] <mru> in which case it's very good
[08:49:38] <merbzt> i5 laptop
[08:49:47] <merbzt> hyperthreaded dual-core
[08:50:22] <mru> with HT that figure is rather meaningless
[08:50:32] <mru> how much speedup do you get?
[08:50:36] <mru> that's what matters
[08:51:00] <hyc> hmm. I was reading somewhere that x264 has a lot of Intel-specific optimizations and is not particularly AMD-friendly. I wonder how it will behave on the new Bulldozer cores.
[08:51:39] <mru> it is probably better tuned for intel
[08:51:46] <Dark_Shikari> that's a nice excuse for the phenom sucking
[08:51:48] <mru> but I wouldn't call it "not amd-friendly"
[08:52:30] <mru> some cpus take _any_ code as an insult
[08:52:42] <hyc> lol
[08:52:49] <Dark_Shikari> mru: in the interests of utter stupidity
[08:52:54] <Dark_Shikari> the bullzoder has each two cores share two FP units
[08:52:58] <Dark_Shikari> these "FP units" also do all integer SIMD.
[08:53:04] <Dark_Shikari> Yes, that's right.  It only has one integer SIMD unit per core.
[08:53:07] <Dark_Shikari> In 2010.
[08:53:13] <Dark_Shikari> On a desktop CPU.
[08:53:32] <mru> I'm confused
[08:54:02] <mru> what do you mean by "one unit"?
[08:54:11] <Dark_Shikari> one arithmetic unit
[08:54:14] <Dark_Shikari> i.e. handles one instruction per cycle
[08:54:22] <Dark_Shikari> like a core 2 has 3 ALUs
[08:54:29] <mru> ok
[08:54:35] <mru> one execution unit
[08:54:40] <Dark_Shikari> yes
[08:54:48] <Dark_Shikari> the phenom has 6 int units and 2 FP units per 2 cores
[08:54:52] <Dark_Shikari> the "FP units" double as SIMD units
[08:54:56] <Dark_Shikari> therefore, it has 1 SIMD unit per core
[08:54:59] <Dark_Shikari> therefore, AMD are idiots
[08:55:04] <mru> normally "one FP unit" would contain many execution units
[08:55:05] <hyc> http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=6
[08:55:19] <Dark_Shikari> well, given that 3 ALUs per core is relatively standard
[08:55:21] <mru> so be careful with such terminology
[08:55:25] <Dark_Shikari> I doubt "6 integer units" actually means way more than 6
[08:55:42] <mru> I would never use that phrase
[08:55:47] <merbzt> I get about 2 times the performance
[08:55:48] <Dark_Shikari> blame amd
[08:55:53] <mru> I'd say integer execution units
[08:55:56] <mru> or integer pipelines
[08:56:13] <mru> "integer unit" normally means the whole thing
[08:56:29] <hyc> there's still some confusion about the integer pipelines too
[08:57:11] <mru> a pipeline is a pipeline, nothing confusing there
[08:57:24] <hyc> AMD K8 had 3 ALUs and 3 AGUs in tight pairs
[08:57:50] <hyc> but the data cache only had 2 ports, so only 2 AGUs could actually operate simultaneously
[08:57:51] <mru> yes, and?
[08:58:05] <hyc> and if the 3rd AGU stalled, so did its ALU
[08:58:22] <mru> do you mean load/store units when you say agu?
[08:58:23] <hyc> Bulldozer seems to have only 2 ALUs and 2 AGUs per core
[08:59:00] <mru> obviously and LS unit needs an AGU
[08:59:10] <mru> but the AGU doesn't touch the cache as such
[08:59:25] <hyc> ah right.
[08:59:28] <wbs> vipw: the patch looks good, I'm waiting for more comments, will apply later unless someone else objects
[08:59:36] <hyc> there are only 2 LS units, and there are 3 AGUs.
[08:59:48] <mru> and sometimes the agu can be used for non-LS arithmetic too
[08:59:58] <mru> e.g. the lea instruction
[09:00:07] <wbs> vipw: if I'd known you'd send a patch, too, I'd have directed you to the mailing list directly
[09:00:51] <hyc> Bulldozer has dedicated load unit and dedicated store unit
[09:02:15] <hyc> the claim is that the 3rd ALU/AGU in K8 were almost never used
[09:05:14] <hyc> I wonder if that's mainly because of the LS bottleneck, or just that it required code to be written a particular way
[09:05:45] <mru> was the k8 out of order?
[09:06:23] <hyc> not completely, not like Core2
[09:06:40] <Dark_Shikari> all modern x86 CPUs are out of order
[09:06:42] <Dark_Shikari> atom doesn't count
[09:06:46] <Dark_Shikari> k8 had a big reorder buffer too.
[09:06:49] <mru> nothing is "completely" out of order
[09:07:07] <hyc> original K8 cannot move loads ahead of stores
[09:07:15] <Dark_Shikari> That's not exactly unreasonable.
[09:07:15] <mru> not ever?
[09:07:34] <hyc> right. Barcelona allowed loads to move ahead of stores with known non-conflicting addresses
[09:08:29] <mru> different words on same page?
[09:08:43] <mru> anything else would require a tlb lookup
[09:09:01] <hyc> probably. Bulldozer is supposed to allow speculative loads ahead of stores
[09:10:47] <mru> what kind of chip is bulldozer?
[09:11:04] <hyc> ?
[09:11:14] <mru> notebook, desktop, server?
[09:11:19] <hyc> server
[09:11:32] <hyc> I guess desktop too
[09:12:07] <hyc> there's a lot of debate over whether it will do well in the desktop space
[09:12:17] <hyc> but it seems pretty well suited to heavily threaded server loads
[09:12:23] <ohsix> "debate" olol
[09:14:54] <mru> heavily loaded servers generally benefit from many small cores instead of fewer, individually more powerful cores
[09:15:16] <mru> desktop is the exact opposite
[09:15:59] <hyc> yeah, but you can go too far in either extreme. I think Sun Niagara was too far...
[09:16:09] <mru> yeah, probably
[09:16:16] <mru> it did scale well though
[09:16:58] <hyc> hm. but its single-thread performance was too slow, you could have lots of transactions in flight but they all completed with pretty high latency
[09:17:37] <mru> and the T1 had one FPU per how many cores again?
[09:17:43] <mru> 4 or 8 iirc
[09:17:47] <hyc> yeah, 8
[09:18:50] <hyc> so AMD's going with one FPU per 2 cores. Seems ok.
[09:19:01] <Dark_Shikari> But "FPU" in this case means "SIMD unit"
[09:19:27] <mru> now you're confusing me again
[09:19:37] <mru> one fpu/simd per core or one per 2 cores?
[09:19:42] <Dark_Shikari> Two per two cores.
[09:19:59] <hyc> this page really helps explain  http://www.realworldtech.com/page.cfm?ArticleID=RWT082610181333&p=7
[09:20:29] <merbzt> mru: yes, per 2 "alu" cores
[09:20:49] <mru> yes WHAT?
[09:21:05] <mru> is there a block diagram somewhere?
[09:21:16] <hyc> yes, see the link I just pasted
[09:21:22] <mru> that's not a block diagram
[09:21:58] <merbzt> the simd/fpu is 256bits wide
[09:22:35] <Dark_Shikari> mru: http://www.maximumpc.com/files/u57670/bulldozer2.jpg
[09:22:39] <Dark_Shikari> that should be better
[09:22:49] <mru> that's more like it
[09:23:18] <mru> so 2 shared fpu/simd per 2 cores?
[09:23:27] <Dark_Shikari> yes, it's a bit weird.
[09:23:34] <mru> scheduling nightmare
[09:23:40] <Dark_Shikari> why?
[09:23:46] <mru> hard to predict
[09:23:48] <Dark_Shikari> HT already does this quite effectively
[09:24:00] <Dark_Shikari> and HT has been done on CPUs other than x86 as well -- also effectively
[09:24:04] <Dark_Shikari> Power6 I think it was?
[09:24:04] <hyc> 2 128-bit FPUs per 2 cores. But can be used as a single 256 bit FPU if only one core is using it
[09:24:18] <mru> lots of cpus have HT-like things
[09:24:51] <Dark_Shikari> mru: I would define here HT as "execution resources shared among multiple cores"
[09:25:29] <mru> in that case you'll find it on both power(pc) and mips
[09:25:38] <Dark_Shikari> yeah, my point being, it's been done.
[09:25:48] <mru> of course it has
[09:25:48] <Dark_Shikari> Has it always been paired with OOE?
[09:25:53] <Dark_Shikari> It doesn't seem like it makes too much sense without OOE.
[09:26:08] <mru> ooe certainly helps
[09:28:32] <mru> but it still makes execution somewhat unpredictable
[09:29:41] <hyc> if all of your code only does 128-bit ops, then there's no interference
[09:38:08] <hyc> but it kinda implies that on an 8-core chip, you might get best performance running only 4 threads, and using 256 bit AVX
[09:38:55] <Dark_Shikari> avx is float only, useless, etc
[09:39:01] <mru> unless you have a bunch of things that don't need more than 128 bits
[09:39:27] <mru> if you can put those in separate threads from the 256-bit things, and schedule them on different pairs, you could get even better performance
[09:39:35] <mru> and therein lies aforementioned nightmare
[09:39:43] <mru> Dark_Shikari: float isn't entirely useless
[09:39:52] <mru> it's useless for _video_
[09:40:11] <Dark_Shikari> Generally, on a desktop computer, you're processing audio and video at the same time
[09:40:18] <Dark_Shikari> video dwarfs audio in terms of cost, cpu-wise
[09:40:21] <Dark_Shikari> therefore, only video matters
[09:40:32] <Dark_Shikari> Now, on a mobile device or on an ARM or whatnot, audio actually costs enough relatively that it can matter
[09:40:42] <iive> i bet 3d for games uses a lot of floats
[09:40:50] <Dark_Shikari> the reason of course being that the complexity of audio processing for QCIF is the same as audio processing for 1080p
[09:41:26] <mru> on a portable music player power consumption matters too
[09:41:37] <Dark_Shikari> yeah, that too
[09:41:42] <Dark_Shikari> but this is a desktop CPU.
[09:41:45] <mru> if you can drop the cpu frequency, the battery lasts longer
[09:41:56] <Dark_Shikari> bulldozers don't go in ipods
[09:45:01] <cartman> doesn't ipod have a hardware video decoder for H.264 ?
[09:45:07] <Dark_Shikari> dsp, prolly
[09:45:11] <av500> cartman: sure
[09:45:21] <cartman> yeah so CPU should not matter
[09:45:50] <cartman> here an ARM11 tablet does 1080p thanx to ARM MALI GPU
[09:45:59] <av500> yes
[09:46:09] <cartman> av500: thanx for confirming me :P
[09:46:35] <av500> iphone has SOC with arm A8 and some video accell
[09:46:42] <av500> dsp and/or hw
[09:46:56] <cartman> whats the difference between a DSP & GPU ?
[09:47:07] <cartman> besides GPU does graphics display too
[09:47:08] <mru> everything
[09:47:08] <hyc> iphone doesn't use the PowerVR SGX?
[09:47:16] <av500> hyc: it does that too
[09:47:19] <cartman> mru: how so?
[09:47:22] <av500> but not for video decoding
[09:47:26] <mru> and a gpu doesn't do display
[09:47:38] <mru> the display controller does that
[09:47:48] <cartman> mru: true, but sends data to the controller
[09:47:51] <mru> your average nvidia chip has both
[09:48:03] <mru> on a soc they're usually quite separate
[09:48:04] <av500> mru: no, its them tiny pixels that do all the work!
[09:48:23] <cartman> whats the main use for a DSP?
[09:48:31] <mru> digital signal processing
[09:48:36] <hyc> lol
[09:48:46] <cartman> mru: Mr. Obvious
[09:49:13] <mru> what would you have me answer?
[09:49:43] <av500> something spoon fed?
[09:49:46] <cartman> don't be mean, trying to learn some shit here
[09:49:47] <cartman> :P
[09:50:02] <av500> cartman: lycos?
[09:50:18] <cartman> digital was there before
[09:50:18] <mru> DSP is a broad term
[09:50:30] <mru> before what?
[09:50:37] <cartman> search engines
[09:50:54] <mru> DSPs are not generally useful for search engines
[09:50:58] <av500> so you refuse to goolge things that existed before search engines?
[09:51:10] <hyc> but you could give audio and video as prime examples of digital signal processing applications
[09:51:14] <cartman> av500: altavista/digital came before lycos
[09:51:35] <cartman> mru: ok so DSP does broad range of things, and video processing is one of them
[09:51:57] <mru> yes, video processing is one thing they are used for
[09:52:02] <mru> audio processing is another
[09:52:17] <ohsix> cartman: its taken lumps, but its free http://www.dspguide.com/
[09:52:25] <cartman> ohsix: ok
[09:52:30] <mru> but also things like ignition control in engines
[09:52:35] <cartman> just trying to learn, stop being mean (generally :P)
[09:53:01] <cartman> mru: In my old work they used DSP for a UAV's autopilot
[09:53:05] <cartman> for floating point calculations
[09:53:08] <hyc> radar .. pretty much any real world signal that's been digitized
[12:10:30] <mru> wtf @ vc1 loop filter
[12:17:24] <BBB___> ?
[12:17:36] <BBB___> wasn't that another one in inline asm?
[12:17:37] <mru> it's weird
[12:17:49] <BBB___> (at least the mmx one)
[12:17:58] <mru> I'm talking about the spec
[12:19:25] <av500> voluntarily?
[12:19:42] <mru> €€€
[12:20:22] <BBB___> hhaha :)
[12:21:31] <cartman> ∑∑∑
[12:21:35] <cartman> as good as euro sign
[12:22:28] <kierank> i'm confused...my stack is suddenly doing bizzare things
[12:31:58] <Tjoppen> woo
[12:32:06] <Tjoppen> responses to my LXF demuxer
[12:35:01] <mru> kierank: like what?
[12:35:54] <KotH> making coffee?
[12:36:21] <kierank> valid pointers suddenly turning into null pointers
[12:36:21] <av500> cross dressing?
[12:36:24] <thresh> that reminds me I forgot to drink a coffee I made three hours ago
[12:36:38] <mru> thresh: my advice, make new coffee
[12:36:42] <av500> thresh: hopefully somebody put it into the fridge
[12:36:54] <av500> its what i do here to such orphans
[12:37:46] <merbzt> kierank: place data breakpoints on them
[12:41:05] <cartman> av500: bastard
[12:41:37] <superdump> wbs: when you e-mail the soc mentor list, you have to use the same address with which you registered
[12:41:43] <superdump> else the mail will be rejected
[12:41:47] <superdump> i see one rejected here
[12:41:48] <wbs> superdump: yes, I noticed
[12:41:54] <superdump> ok
[12:42:04] <wbs> and sent a new one from the right source address
[12:42:08] <superdump> aha, i see it :)
[12:42:32] <wbs> I always forget to set up the role rules in my mail client to associate the right source address with lists
[12:42:40] <wbs> guess I should set that as default outgoing address instead
[12:43:49] <mru> you can register alternate addresses with the list
[12:46:01] <superdump> or that
[12:50:03] <kierank> lol gcc segfaults when i place a data breakpoint on it
[12:50:29] <kierank> s/gcc/gdb
[12:50:38] <mru> ah, much saner
[12:50:55] <cartman> must be cosmic rays
[13:34:25] <wbs> vipw: in case you didn't see, BBB provided some more comments on the patch
[14:14:52] <BBB> Dark_Shikari: can you review my deblock x264->ffmpeg port patch (i.e. just say "yes looks good") so I can feel good about applying it?
[14:17:35] <mru> huh, freebsd/clang is green now
[14:17:52] <mru> must not be showing that ecx bug for some reason
[14:17:52] <BBB> different clang version probably
[14:17:58] <mru> slightly older than mine
[14:18:07] <BBB> well anyway
[14:18:58] <BBB> who owns the "llvm-gcc 4.2.1 (LLVM build 4.2-112544)" and "clang version 2.8 (trunk 112656)" boxes?
[14:19:13] <BBB> maybe an update of their llvm also helps
[14:19:13] <mru> linux/clang are mine
[14:19:33] <mru> and those are newer than the freebsd one
[14:20:03] <mru> the llvm-gcc rev generally trails the clang number
[14:20:09] <mru> even if built from the same checkout
[14:20:13] <BBB> hm...
[14:20:26] <BBB> fate doesn't look too bad right now
[14:20:40] <mru> the later commits probably only touch the non-llvm-gcc parts
[14:20:45] <BBB> is PathScale (tm) Compiler Suite Version 3.9.99-ece1355 yours also?
[14:20:48] <mru> yes
[14:21:33] <spaam> nice , only one thing is red now  :)
[14:21:41] <BBB> the red one has no functional log
[14:21:43] <BBB> it's a little useless
[14:22:40] <kierank> damn even the new version of gdb segfaults
[14:23:03] <elenril> any volunteers for applying a patch?
[14:23:24] <spaam> kierank: why did you break it ? )
[14:23:25] <BBB> sure
[14:23:34] <BBB> kierank: :(
[14:23:51] <kierank> spaam: dunno, suddenly my stack is b0rked after rebasing
[14:23:52] <BBB> kierank: I had those phases also... you have revision control over your work right?
[14:24:29] <kierank> yes
[14:25:17] <mru> spaam: the red cygwin report says something failed near the end of the configure script
[14:25:25] <mru> and it exited with code 130
[14:25:28] <mru> whatever that means
[14:28:22] <cartman> fate doesn't show what failed while configuring
[14:28:53] <mru> that's because nothing told it
[14:29:02] <mru> it's some crazy cygwin error
[14:29:08] <mru> the script just died
[14:39:51] <BBB> I think earlier it died with a shell segfault
[14:39:56] <BBB> the box might need a reboot or so
[14:40:10] <BBB> (shell segfault in fork halfway the configure script)
[14:41:17] <cartman> ah usual cygwin fork crap then
[14:41:21] <cartman> nothing fancy
[14:42:11] <vipw> wbs: thanks for the ping, i'll touch it up and resubmit
[14:47:08] <lu_zero> hi vipw
[14:48:04] <vipw> hi
[14:50:43] <wbs> vipw: good, good. :-)
[14:53:17] <vipw> is this how i should setup the addr len define? http://gist.github.com/563978
[14:53:57] <wbs> yes, I'd say so
[14:54:35] <BBB> nah, remove the 46
[14:54:56] <BBB> if INET_ADDRSTRLEN isn't there, the networking stack probably doesn't exist and networking should have been disabled
[14:55:00] <BBB> I can't imagine it not existing
[14:55:14] <wbs> but I don't think we usually indent the nested #ifs
[14:55:19] <BBB> that too
[14:55:31] <BBB> thanks for the patch by the way :)
[14:56:20] <vipw> hmm, i saw indented #ifs a few lines above
[14:56:39] <vipw> no problem
[14:57:27] <wbs> ah, the usual problem - knowing which parts to imitate and which not to ;P
[15:00:08] <CIA-11> ffmpeg: mstorsjo * r25030 /trunk/libavformat/amr.c: Set frame_size in the amr demuxer
[15:02:51] <lu_zero> wbs: you always imitate the wrong one
[15:03:08] <mru> everybody does
[15:03:20] <mru> I think it's some fundamental law of the universe
[15:03:35] <mru> and we often do indent #ifs
[15:03:42] <mru> when it helps readability at least
[15:37:06] <lu_zero> interesting I have a aac file that ffmpeg doesn't accept but mplayer does...
[15:37:25] <peloverde> lu_zero: dump it on samples and I will look at it
[15:37:40] <Dark_Shikari> BBB: looks fine to me if it passes///
[15:37:54] <BBB> passes make fate for all optimizations
[15:38:06] <BBB> I'll recheck that before I apply
[15:38:13] <BBB> tested on both x86-64 and x86-32
[15:38:17] <BBB> (but only osx)
[15:39:09] <janneg> lu_zero: mplayer with libfaad? probably latm then
[15:40:22] <lu_zero> peloverde and janneg I'm trying to figure out why
[15:40:35] <lu_zero> ffmpeg errors out with EINVAL
[15:41:03] <mru> EIGENVAL
[15:41:08] <peloverde> In what container is it?
[15:41:45] <lu_zero> elementary stream
[15:41:47] <lu_zero> at least should
[15:53:35] <lu_zero> ...
[15:53:47] <lu_zero> our probe system
[15:54:45] <lu_zero> small files do disappear because of that
[16:17:57] <peloverde> Does anyone know about iTunes HE-AACv2 support?
[16:18:21] <peloverde> Wikipedia says it supports it but I'm not hearing the PS parts on iTunes 10 for Windows
[16:19:42] <kierank> i had a look at the encoder/decoder library a few days ago and iirc there were debug symbols for he-aac decoding
[16:20:57] <kierank> this was for an itunes 9 though
[16:22:05] <peloverde> It can parse non backwards compatible PS fine
[16:22:31] <peloverde> http://samples.mplayerhq.hu/A-codecs/AAC/aacPlusDecoderCheckPackage_v2.1/bitstreams/File5.mp4 is NBC PS but the noise at the end is supposed to pan
[16:23:01] <peloverde> iTunes plays it without the stereo effects
[16:23:34] <peloverde> I wonder if it uses puer upsampling mode or soemthign awkward like that
[16:32:06] <kierank> who'd have thunk it; float based GAQ is slow as hell: http://pastebin.ca/1931851
[16:41:47] <BBB> (gdb) disass ff_h264_idct8_add_mmx
[16:41:47] <BBB> Dump of assembler code for function ff_h264_idct8_add4_mmx:
[16:41:50] <BBB> wtf
[16:41:55] <BBB> gdb is on crack
[16:45:35] <Dark_Shikari> disass $pc-30 $pc+30
[16:53:45] <CIA-11> ffmpeg: rbultje * r25031 /trunk/libavcodec/x86/ (6 files):
[16:53:45] <CIA-11> ffmpeg: Port latest x264 deblock asm (before they moved to using NV12 as internal
[16:53:45] <CIA-11> ffmpeg: format), LGPL'ed with permission from Jason and Loren. This includes mmx2
[16:53:45] <CIA-11> ffmpeg: code, so remove inline asm from h264dsp_mmx.c accordingly.
[16:55:18] <BBB> Dark_Shikari: not a crash, I want to see how it compiled the code, but it gives me the wrong function
[16:55:58] <BBB> does svn have a way to reset state on a file (I did svn mv on a file I don't want to move)
[16:57:43] <BBB> svn revert apparently
[17:02:10] <mru> BBB: if you just want to look at code, you can use objdump -d
[17:02:28] <BBB> ah, ok
[17:02:44] <mru> it's not quite as temperamental
[18:47:56] <BBB> mru: please update llvm to r112988 and fate will turn greener
[18:48:47] <mru> I rebuilt it at head a few hours ago
[18:48:51] <mru> is that already too old?
[18:49:15] <mru> 112953 to be precise
[18:51:37] <mru> heh, fixed just after
[18:51:50] <mru> updating
[18:52:34] <mru> this is why I have that i7
[18:55:29] <mru> hmm searching for ffmpeg in llvm bugzilla gets quite a few hits
[18:57:27] <spaam> mru: how fast can you compile llvm ? :)
[18:57:59] <mru> 10 minutes or so
[18:58:23] <mru> for both clang and llvm-gcc frontends
[18:59:12] <spaam> Nice :)
[19:13:07] <BBB> mru: thanks!
[19:13:32] <mru> now we just need to wait for someone to commit something
[19:16:36] <BBB> that shouldn't take too long
[19:17:31] <elenril> there's a patch i'd like to see committed if you're not too lazy ;)
[19:17:48] <BBB> I asked you to point me to it
[19:17:51] <BBB> you didn't respond :-p
[19:17:55] <elenril> you did?
[19:17:57] <BBB> yes
[19:18:01] <elenril> sorry, didn't notice
[19:18:24] <elenril> it's vorbis metadata writing
[19:18:33] <BBB> 10:23 "any volunteers to apply a patch?" I said @ 1023: "sure"
[19:18:37] <BBB> then, silence :-p
[19:19:25] <elenril> ah, i didn't think you were replying to me ;)
[19:19:38] <elenril> volunteers are usually harder to find here
[19:19:53] <BBB> what's the subject?
[19:20:00] <BBB> vorbis metadata only comes up with june threads here
[19:20:49] <vipw> i guess my patch is ready
[19:20:57] <BBB> oh right that one also
[19:21:10] <BBB> elenril: can you send me a link? it dropped out of my inbox already
[19:21:15] <BBB> I have your ping msg
[19:21:19] <BBB> but not the original patch :-p
[19:22:56] <elenril> ok
[19:23:08] <elenril> i guess i'll test it first, it's half a year old after all
[19:23:42] <peloverde> lu_zero: any update on that aac file?
[19:26:42] <BBB> elenril: holy shit
[19:27:02] <elenril> BBB: http://filebin.ca/urasrb/vorbis.patch
[19:27:04] <CIA-11> ffmpeg: rbultje * r25032 /trunk/libavformat/ (rtsp.c rtsp.h os_support.h):
[19:27:04] <CIA-11> ffmpeg: Send NAT punching messages to the address specified in the Transport:
[19:27:04] <CIA-11> ffmpeg: message, if available (RFC 2326, section 12.39), fixes issue 2212.
[19:27:04] <CIA-11> ffmpeg: Patch by John Wimer <john at god vtic net>.
[19:27:04] <CIA-11> ffmpeg: rbultje * r25033 /trunk/libavformat/rtsp.c: Reindent after r25032.
[19:27:04] <elenril> BBB: ?
[19:28:04] <BBB> elenril: old :-p
[19:28:11] <BBB> ok, so this patch is all? I'd expect something bigger
[19:28:24] <BBB> or is ogg_write_vorbiscomment() already in svn, we just don't use it?
[19:30:59] <BBB> elenril: applied
[19:31:10] <BBB> anything else needs applying?
[19:31:16] <elenril> thanks
[19:31:20] <CIA-11> ffmpeg: rbultje * r25034 /trunk/libavformat/oggenc.c: Vorbis metadata writing. Patch by Anton Khirnov <wyskas gmail com>.
[19:31:23] <elenril> nothing i know of
[19:31:31] <elenril> err that's not my patch
[19:31:39] <elenril> J_Darnley wrote it
[19:31:55] <elenril> sorry, should have mentioned that
[19:31:59] <BBB> oh
[19:32:00] <BBB> eh
[19:32:01] <BBB> oops
[19:32:04] <BBB> J_Darnley: sorry
[19:32:05] <BBB> let me fix that
[19:32:07] <spaam> haha
[19:34:16] <elenril> oh wow, clang is all green on linux 32bit
[19:34:19] <BBB> fixed
[19:34:24] <elenril> \o/
[19:34:32] <BBB> yeah, the clang bugs were all fixed also
[19:34:44] <BBB> (mru just updates to the latest svn/git/whatever)
[19:35:10] <BBB> llvm-gcc 4.2.1 (LLVM build 4.2-112940)	 will also go green
[19:35:36] <mru> it won't be 112940 though
[19:35:48] <BBB> awh :(
[19:35:55] <BBB> you didn't backport to 112940?
[19:35:59] <BBB> you just updated to a newer one?
[19:36:01] <BBB> so disappointing
[19:36:05] <mru> that still wouldn't be the same rev
[19:36:21] <BBB> oh right you explained, they're out of sync
[19:36:47] <mru> regardless of that, 112940 is the old version
[19:36:51] <mru> without the fix
[19:37:25] <mru> anyway, let's see what happens
[19:37:29] <mru> it had 10 more failures
[19:40:25] <J_Darnley> BBB: LOL, oops
[19:42:36] <BBB> J_Darnley: well, thanks fir the patch :-p
[19:42:47] <J_Darnley> no problem
[19:43:21] <J_Darnley> It was a feature I wanted
[19:46:38] <mru> BBB: so you wanted a config.asm?
[19:46:47] <BBB> if possible
[19:46:52] <mru> easy
[19:46:56] <BBB> \o/
[19:46:57] <mru> what do you want in it?
[19:47:03] <merbanan> a pony
[19:47:10] <BBB> yeah, a pony
[19:47:19] <mru> you'll have to enable large-file support for that
[19:47:23] <BBB> CONFIG_xyz_DECODER/ENCODER, to start
[19:47:41] <mru> you'll get all the config stuff
[19:47:45] <mru> but what's the syntax?
[19:47:53] <BBB> oh, %define MACRO value
[19:47:58] <BBB> so s/#/%/
[19:48:10] <mru> value being 0 or 1?
[19:48:15] <BBB> yes
[19:48:32] <BBB> it should also not have stuff like ARCH_X86_64, since that'll clash with stuff that yasm already defines
[19:48:49] <BBB> send me a patch so I can test and make sure it doesn't screw around with stuff yasm knows internally (somehow)
[19:49:07] <mru> we define that
[19:49:21] <mru> so that bit will be simpler
[19:54:37] <BBB> we define that?
[19:54:44] <mru> ARCH_FOO
[19:55:50] <peloverde> Hmm, the AAC reference decoder seems to be able to handle both real and broken channel configurations without trouble.
[19:56:21] <mru> what does it do with broken ones?
[19:56:52] <mru> hmm, os/2 went red
[19:57:13] <mru> but llvm-gcc did go green
[19:57:47] <mru> something ipv6 related on os/2
[20:01:43] <BBB> oh that again
[20:01:46] <BBB> ...
[20:03:08] <astrange> swscale build is broken with --disable-amd3dnow --enable-runtime-cpudetect
[20:03:12] <wbs> BBB: I think the issue is that os_support.h isn't  necessarily included in rtsp.h
[20:04:31] <BBB> yeah I noticed
[20:04:34] <BBB> I'll move it to network.h
[20:04:38] <BBB> that's where the other stuff is
[20:04:47] <mru> move what?
[20:05:39] <wbs> the fallback declaration of INET6_ADDRSTRLEN
[20:06:06] <BBB> moved
[20:06:16] <BBB> os/2 should work again now
[20:06:31] <wbs> btw, great job BBB and mru on cleaning up the fate failures!
[20:06:44] <BBB> not finished yet
[20:06:51] <BBB> mingw64 can be fixed more
[20:06:53] <mru> BBB: anything else you'd like in config.asm?
[20:06:57] <CIA-11> ffmpeg: rbultje * r25035 /trunk/libavformat/ (network.h os_support.h):
[20:06:57] <CIA-11> ffmpeg: Move INET6_ADDRSTRLEN to network.h, similar to other network-related fixups
[20:06:57] <CIA-11> ffmpeg: for broken OSes. This is included in rtsp.h, as opposed to os_support.h.
[20:06:57] <CIA-11> ffmpeg: Should fix OS/2 broken build on fate.
[20:07:04] <wbs> of course, but you've done huge progress already. :-)
[20:07:04] <mru> other than the usual enabled/disabled stuff
[20:07:14] <BBB> mru: no, not for now at least
[20:07:22] <BBB> wbs: thanks :)
[20:07:30] <mru> I'm just running the web page...
[20:08:17] <mru> anyone feel like tackling the gcc 4.5 failures on x86_32?
[20:12:38] <BBB> yay, llvm is green
[20:13:26] <cartman> BBB: they fixed your asm bug too
[20:13:33] <BBB> I know :-p
[20:13:40] <BBB> it wasn't my bug, it was their bug ;)
[20:13:47] <mru> one bug magically vanished
[20:13:58] <cartman> wish they would fix parsing windows.h too :P
[20:15:17] <astrange> the gcc 4.5 failure in lavf-mxf is an FP precision issue
[20:15:33] <astrange> in mpegvideo_enc.c 354 it checks
[20:15:34] <astrange> avctx->rc_buffer_size && avctx->bit_rate*av_q2d(avctx->time_base) > avctx->rc_buffer_size
[20:15:45] <astrange> and  avctx->bit_rate*av_q2d(avctx->time_base) == avctx->rc_buffer_size
[20:15:55] <mru> astrange: fp precision?
[20:15:56] <mru> wtf?
[20:15:59] <astrange> i saw it in make test for gcc 4.6 once and then totally forgot about it :/
[20:16:22] <cartman> astrange: how did you find that was the problem ? /* curious */
[20:17:01] <astrange> printed both sides in gdb and noticed they were really close when it did pass
[20:17:04] <astrange> iirc
[20:17:11] <mru> suggestions for a fix?
[20:17:40] <astrange> http://pastebin.com/epVFPNHL is this swscale fix ugly?
[20:20:21] <astrange> trying to reproduce it...
[20:34:43] <FishB8> I'm quite unfamiliar with the ffmpeg code base and I'm trying to figure out if there is an easy way to query if a video stream is interlaced or not.  I've been looking at AVStream docs and don't see anything. Am I looking in the right place
[20:34:46] <FishB8> ?
[20:36:11] <astrange> not failing, probably needs x87
[20:36:59] <astrange> mru: how do i see the ffmpeg command for lavf-mxf?
[20:37:37] <mru> try make V=1 ...
[20:39:13] <mru> the fate revamp may have broken that
[20:41:02] <astrange> it just prints "/Users/astrange/Projects/video/ffmpeg"/tests/fate-run.sh fate-lavf-mxf "" "" "/Users/astrange/Projects/video/ffmpeg" 'lavftest' '' '' ''
[20:41:23] <mru> then we'll need to fix that somehow
[20:41:28] <mru> but it's a bit non-trivial
[20:41:42] <mru> too much i/o redirection going on
[20:50:29] <mru> BBB: does %if !FOO not work in yasm?
[20:51:32] <Dark_Shikari> It should work.
[20:53:05] <mru> well, something is going wrong here
[20:53:34] <mru> it's barfing with error: (DECLARE_REG_SIZE:9) expression syntax error
[20:57:13] <mru> yep, that's it
[20:57:39] <mru> changing it back to %ifdef and defining only the enabled things works
[20:58:11] <mru> I would've preferred having the defines work the same way in C and yasm
[20:58:27] <mru> instead of having #if in C and %ifdef in yasm
[21:00:50] <Dark_Shikari> %if really should work...
[21:01:26] <mru> could being inside a macro definition have something to do with it?
[21:02:02] <Dark_Shikari> dunno
[21:02:07] <Dark_Shikari> I'm not a yasm expert
[21:02:17] <mru> more than I am one
[21:03:08] <BBB> mru: use %if var == 0
[21:03:22] <mru> how stupid can it be?
[21:03:23] <BBB> (I know nobody likes that)
[21:03:28] <BBB> or ! var (with a space)
[21:05:10] <mru> no luck
[21:05:18] <mru> same error
[21:06:04] <mru> == 0 seems to work
[21:06:08] <mru> retarded
[21:06:56] <mru> so how do you guys prefer it?
[21:07:24] <mru> any ugly ARCH_X86_64==0 can be replaced by ARCH_X86_32 of course
[21:08:35] <mru> aside: the freebsd machine seems flaky
[21:10:49] <BBB> what's wrong with fbsd?
[21:11:02] <mru> I'd say bad hw
[21:11:07] <BBB> uh
[21:11:40] <mru> randomly failing tests nobody has touched recently
[21:12:12] <BBB> seek errors...
[21:12:17] <mru> this time
[21:12:20] <BBB> with a segfautlt
[21:12:22] <BBB> weird
[21:12:23] <BBB> ok
[21:13:56] <CIA-11> ffmpeg: mstorsjo * r25036 /trunk/libavcodec/Makefile:
[21:13:56] <CIA-11> ffmpeg: Fix the dependencies of the RTP muxer
[21:13:56] <CIA-11> ffmpeg: This fixes building with --disable-evrything --enable-muxer=rtp, closing
[21:13:56] <CIA-11> ffmpeg: issue 2159.
[21:14:34] <mru> BBB: well, let me know how you want the yasm defines
[21:14:47] <BBB> 0/1 is fine
[21:15:01] <BBB> I like it if it's similar in config.h and config.asm
[21:15:35] <mru> shall I replace ARCH_X86_64==0 with ARCH_86_32 while at it?
[21:15:44] <mru> those are %ifndef ARCH_X86_64 now
[21:15:57] <BBB> yeah why not
[21:16:25] <BBB> or, for that, ask pengvado and dark_shikari
[21:16:38] <BBB> they might prefer if we stay as close as possible to x264, so we can exchange code more easily
[21:16:49] <mru> good point
[21:17:10] <mru> then defining only the enabled stuff might be better
[21:17:18] <mru> since it requires no change to the asm
[21:17:34] <BBB> ok
[21:17:36] <wbs> BBB: btw, if compiling with --disable-everything, with mmx enabled, I get this undefined symbol:
[21:17:39] <wbs>   "_ff_dct32_float_sse", referenced from:
[21:17:40] <BBB> let's do that then, if that's easier
[21:17:42] <wbs>       _ff_dct_init_mmx in libavcodec.a(fft.o)
[21:18:01] <mru> BBB: either way is easy for me
[21:18:12] <BBB> ok, then only define the stuff that's enabled
[21:18:36] <BBB> wbs: might want to file a bug for that, I'm not terribly familiar with that code and probably won't get to it today ;)
[21:19:05] <cartman> wbs: OSX?
[21:19:09] <wbs> BBB: ok, I'll see if I can figure it out myself
[21:19:10] <wbs> cartman: yes
[21:19:21] <cartman> wbs: static build never worked for me
[21:19:53] <wbs> cartman: works just fine for me, I guess this is some missing dependency
[21:20:03] <BBB> yeah, it probably is
[21:20:08] <BBB> shouldn't be too hard to fix
[21:20:40] <cartman> dunnow I tried 64bit build last time
[21:20:40] * BBB is moving h264 idct to yasm
[21:20:53] * cartman gives BBB a cookie
[21:20:54] <BBB> I'm probably using dynamic build though
[21:21:11] <BBB> no this is static
[21:21:16] <BBB> works fine for me, both x86-32 and x86-64
[21:21:59] <BBB> wbs: have you ever thought about the possibility of doing regression tests on rtp?
[21:22:06] <BBB> and wasn't lu_zero working on that also?
[21:22:10] <BBB> we should totally do that
[21:22:20] <wbs> BBB: not much, but yes, that would be quite valuable
[21:22:50] <wbs> rtpenc should be quite doable. rtpdec/rtsp is so much more twisted, so it's probably a bit harder
[21:23:14] <cartman> Makefile:280: target `fate-h264-conformance-frext-hpcamolq_brcm_b' given more than once in the same rule.
[21:23:17] <cartman> what the?
[21:23:31] <mru> what did you do?
[21:23:40] <cartman> configure && make
[21:23:47] <mru> broken make?
[21:23:56] <cartman> can't be
[21:24:01] <mru> of course it can
[21:24:06] <mru> everything can be broken
[21:24:09] <mru> and often is
[21:24:17] <cartman> well was working yesterday :)
[21:24:21] <cartman> and I didn't touch it
[21:24:26] <mru> a lot can happen in a day
[21:24:40] <cartman> GNU Make 3.81
[21:24:42] <cartman> cosmic rays
[21:25:05] <cartman> wbs: ok static build works on x86-64 indeed
[21:25:10] <wbs> hmm, ok, the link issue I had simply was that libavcodec/x86/fft.c wasn't rebuilt even though config.h had changed
[21:25:36] <wbs> could that stem from the fact that there's both a libavcodec/fft.d and libavcodec/x86/fft.d, and the build system only including one of them?
[21:26:27] <mru> shouldn't
[21:27:35] <wbs> hmm, well now it seems to rebuild it properly, dunno why it didn't earlier
[21:28:01] <cartman> mru: tests/fate/h264.mak and tests/fate.mak have duplicate entries
[21:28:10] <cartman> fate-h264-conformance-frext-hpcamolq_brcm_b exists in both
[21:28:14] <CIA-11> ffmpeg: mru * r25037 /trunk/configure: configure: make print_config() more flexible
[21:28:14] <CIA-11> ffmpeg: mru * r25038 /trunk/configure: configure: whitespace
[21:28:14] <CIA-11> ffmpeg: mru * r25039 /trunk/ (common.mak configure): Create config.asm for use with yasm
[21:28:33] <mru> cartman: nope
[21:28:43] <cartman> hmm
[21:28:56] <mru> tests/fate.mak does not contain the string h264
[21:29:00] <cartman> my fault
[21:29:08] <cartman> not my but somehow fucked up
[21:29:08] <cartman> :P
[21:29:10] <cartman> sorry
[21:29:33] <mru> BBB: you got your config macros
[21:29:46] <BBB> \o/
[21:30:01] <BBB> ok I'll break down the asm over the next few days also then
[21:30:10] <cartman> if you switch everything to YASM one could get rid of broken internal assemblers
[21:30:24] <mru> d'uh
[21:30:43] <cartman> its my turn to state the obvious
[21:30:56] <BBB> if you move everything to inline asm you could get rid of broken yasm versions
[21:31:05] <cartman> nice try
[21:31:23] <BBB> thanks for agreeing ;) care to help now? :-p
[21:31:29] <cartman> no
[21:31:32] <cartman> I'll test :P
[21:32:26] <BBB> mru: -Pconfig.asm means it always includes it?
[21:33:02] <BBB> that's pretty awesome
[21:34:48] <BBB> holy cow, gcc completely unrolls ff_h264_idct_add16_mmx()
[21:35:12] <BBB> that's HUGE
[21:35:37] <Dark_Shikari> another reason to use yasm