[01:03:22] <Kovensky> <@Dark_Shikari> the developer who does git format-patch | sendmail. <-- git send-email [01:07:54] <peloverde> At least by default git-send-email gives a summary and a chance to cancel [04:09:48] <Dark_Shikari> I wonder what michael will think of my patch [04:10:06] <Dark_Shikari> I think I'm going to scare him [04:10:15] <Dark_Shikari> or maybe anger him, I tore apart his beloved decoder [04:18:08] <elenril> noone on the ffmpeg team would go to such flaming if it was a real issue << lol [04:18:53] <Dark_Shikari> <3 michael [06:45:54] <CIA-92> ffmpeg: mstorsjo * r23692 /trunk/ffserver.c: ffserver: Use avcodec_copy_context instead of manually copying an AVCodecContext [06:53:58] <CIA-92> ffmpeg: mstorsjo * r23693 /trunk/libavcodec/libvorbis.c: [06:53:58] <CIA-92> ffmpeg: libvorbis: Only drop 1-byte packets at end of stream [06:53:58] <CIA-92> ffmpeg: This fixes handling of totally silent packets during the encoding, that [06:53:58] <CIA-92> ffmpeg: also are 1 byte in size. [06:53:58] <CIA-92> ffmpeg: This fixes issue 2013 [07:08:46] <av500> peloverde_: ping [07:08:51] <peloverde_> pong [07:09:01] <av500> wrt facebook [07:09:10] <av500> the image there shows a user "rikiji" [07:09:21] <av500> and there are 2 hits for rikiji and ffmpeg: [07:09:48] <av500> http://www.hwupgrade.it/forum/archive/index.php/t-1437356-p-16.html [07:10:04] <av500> http://forum.ubuntu-it.org/index.php?PHPSESSID=31fb8a415eacbe05bb255a301fa8cb7b&topic=83511.msg507973#msg507973 [07:10:59] <peloverde_> thanks, interesting [07:13:25] <kshishkov> av500: have you heard the story about "Linux" trademark? [07:13:54] <av500> my wife used Linux washing powder... [07:14:05] <kshishkov> not that one [07:14:09] <pJok> god morgon, kshishkov :) [07:14:18] <kshishkov> goda morgnar, pJok [07:14:27] <av500> kshishkov: but yes [08:28:28] <merbzt> can someone commit the dts patches ? [08:29:03] <wbs> merbzt: the ones from yesterday evening? sure [08:32:52] <CIA-92> ffmpeg: mstorsjo * r23694 /trunk/libavcodec/dca.c: [08:32:52] <CIA-92> ffmpeg: Support DTS-ES extension (XCh) in dca: move subband_samples into context structure [08:32:52] <CIA-92> ffmpeg: Patch by Nick Brereton, nick at nbrereton dot net [08:33:48] <CIA-92> ffmpeg: mstorsjo * r23695 /trunk/libavcodec/dca.c: [08:33:48] <CIA-92> ffmpeg: Support DTS-ES extension (XCh) in dca: move original code around to allow reused by DTS-ES code [08:33:48] <CIA-92> ffmpeg: Patch by Nick Brereton, nick at nbrereton dot net [08:34:53] <CIA-92> ffmpeg: mstorsjo * r23696 /trunk/libavcodec/dca.c: [08:34:53] <CIA-92> ffmpeg: Support DTS-ES extension (XCh) in dca: update and add channel mapping tables for DTS-ES mappings [08:34:53] <CIA-92> ffmpeg: Patch by Nick Brereton, nick at nbrereton dot net [08:35:41] <CIA-92> ffmpeg: mstorsjo * r23697 /trunk/libavcodec/dca.c: [08:35:41] <CIA-92> ffmpeg: Support DTS-ES extension (XCh) in dca: add code to handle DTS-ES extension [08:35:41] <CIA-92> ffmpeg: Patch by Nick Brereton, nick at nbrereton dot net [08:36:33] <CIA-92> ffmpeg: mstorsjo * r23698 /trunk/libavcodec/dca.c: [08:36:33] <CIA-92> ffmpeg: Support DTS-ES extension (XCh) in dca: Cosmetic cleanup [08:36:33] <CIA-92> ffmpeg: Patch by Nick Brereton, nick at nbrereton dot net [08:37:00] <wbs> merbzt: done [08:49:19] <CIA-92> ffmpeg: cehoyos * r23699 /trunk/libavformat/utils.c: [08:49:19] <CIA-92> ffmpeg: Fix failure in av_read_frame on timestamp rollover. [08:49:19] <CIA-92> ffmpeg: Patch by Stephen Dredge, sdredge A tpg com au [08:58:55] <kshishkov> merbzt: is it wholly in? If yes you should ask Martin to mention XCh support in Changelog [09:03:39] <wbs> sure, just tell me what to write (I haven't got a clue about that format) - I guess lavc minor should be bumped, too? [09:07:14] <kshishkov> micro, not minor, I think. And it's should be in lines "DTS-ES extension (XCh) decoding support" [09:07:33] * kshishkov is ashamed not to add entries to Changelog for a long time [09:19:14] <merbzt> me too :/ [09:19:20] <merbzt> wbs: thanks [09:20:12] * KotH is not ashamed having not added anything to changelog ever [09:26:16] <kshishkov> KotH: that's because you're no FFmpeg dev [09:29:28] * pJok adds kshishkov to Changelog [09:32:40] <KotH> kshishkov: and because i'm a shamless plug :) [09:34:01] <kshishkov> KotH, that makes me want to say some remark about Turks [09:34:54] <av500> mechanical ones? [09:36:43] <merbzt> ahhh [09:36:53] <merbzt> good day in #ffmepg-devel [09:37:53] <kierank> what about young ones? [09:38:12] <av500> young mechanical turks(tm) [09:39:08] <KotH> kshishkov: you can say whatever you want [09:39:25] <KotH> kshishkov: but remember! somday we'll be where you live! [09:39:26] <KotH> ;) [09:39:48] <av500> KotH: you have to take Vienna 1st... [09:39:52] <kshishkov> KotH: actually I prefer to stop myself before saying some things [09:40:14] <kshishkov> av500: s/Wien/Niedermayerstadt/ [09:40:36] <kierank> av500: I read some article that was trolling Darmstadt [09:40:46] <av500> kierank: aha [09:40:51] <av500> what did it troll about? [09:41:11] <kierank> the fact that they wanted to build a high speed station there even though the town is not worthy of one [09:41:18] <av500> ah that one [09:41:29] <av500> yes, its stupid [09:41:32] <kshishkov> what is high speed station? [09:41:47] <av500> kshishkov: well, more a low speed station for a high speed train [09:42:18] <kshishkov> av500: I've seen only zero-speed stations so far [09:42:27] <av500> new high speed line from FRA to mannheim [09:42:31] <av500> and DA wants a stop [09:42:48] <KotH> av500: nah.. we skipped vienna and are now in berlin ;) [09:42:59] <av500> KotH: right [09:43:08] <av500> you can keep the swamp [09:43:35] * KotH keeps the swiss chocolate [09:43:47] <av500> kierank: so the article is mostly right... [09:44:03] <kshishkov> av500: I have the impression that West Berlin is a myth and it's all EAST [09:44:54] <av500> kshishkov: well, both parts of the city are broke now [09:45:04] <av500> so much for re-unification :) [12:37:56] <Tjoppen> is there any way to determine whether a video codec supports B-frames? except hard coding the cases of course [12:39:38] <Tjoppen> a quick look seems to indicate that only the mpeg1/2/4 encoders support them. I might get away with a simple if(codec_id == ...) thing, although a bit ugly [12:42:05] <CIA-99> ffmpeg: pross * r23701 /trunk/libavcodec/iff.c: IFF PBM decoder: Add a pad byte if image width is odd <aleksi dot nurmi at gmail dot com> [12:44:44] <mru> Tjoppen: what are you trying to do? [12:47:19] <Tjoppen> keeping encoder setup from failing [12:47:45] <Tjoppen> I'm copying settings from the decoder and applying any user overrides to thbat [12:48:52] <Tjoppen> I guess another solution could be to simply refuse to use B-frames unless explicitly told to do so [12:49:03] <mru> what's the problem with b-frames? [12:51:50] <Tjoppen> only the mpeg1/2/4 encoders support them [12:52:09] <mru> yes, so only they will use them [12:52:20] <Tjoppen> if I go and encode h263 avcodec_open() will fail [12:52:28] <mru> really? [12:52:30] <Tjoppen> yep [12:52:42] <Tjoppen> see MPV_encode_init() [12:53:08] <Tjoppen> line 398: av_log(avctx, AV_LOG_ERROR, "b frames not supported by codec\n"); [12:54:49] <mru> ok, I see [12:55:01] <mru> this needs to be fixed [12:55:09] <Tjoppen> in general it'd be nice to be able to detect these things. qpel is another case [12:55:21] <mru> there are two solutions [12:55:23] <Tjoppen> really, all checks near that line [12:55:34] <mru> 1. make init adjust the settings to whatever is supported [12:55:43] <mru> 2. add codec_caps for stuff [12:56:05] <Tjoppen> I believe michael is opposed to #1 [12:56:15] <mru> that's stupid [12:56:24] <Tjoppen> some codecs already do similar things though [12:56:35] <Tjoppen> overriding settings that are "wrong" [12:56:50] <mru> what if some codec allows at most, say, 4 b-frames [12:56:53] <mru> and you request 8 [12:57:02] <mru> even codec_cap won't handle that [12:57:31] <mru> better to have init override impossible settings, at least in some cases [12:57:38] <Tjoppen> or maybe have an out-AVCodecContext for "adjusted" settings? [12:57:50] <mru> of course some things should fail hard [12:57:54] <mru> like bad sample rates for audio [12:58:14] <mru> those params describe the input [12:58:25] <mru> if it's out of bounds, the encoder simply can't handle it [12:58:28] <Tjoppen> right. as opposed to desired settings [12:58:32] <mru> other things are merely requests [13:01:59] <Tjoppen> if modifying the struct is out, what about returning more helpful information such as which field is the offending one, along with a suggested value? [13:02:31] <Tjoppen> that way even bad sample rates and resolutions can be handled [13:06:31] <Tjoppen> for instance, the h263 encoder could say if(avctx->width > 352){avctx->bad_setting = AV_SETTING_WIDTH; avctx->bad_setting_suggest = 352; return AVERROR_EINVAL;} [13:10:24] <mru> codecs already advertise some constraints in the struct AVCodec [13:13:24] <Tjoppen> true, but not all can be put in a struct that way [13:13:37] <mru> some are min/max [13:13:45] <mru> some are yes/no [13:13:53] <mru> (which is a special case of min/max) [13:13:58] <Tjoppen> a recent example would be the aac encoder (or aac in general) where the maximum bitrate allowed depends on samplerate and the number of channels [13:14:14] <mru> yeah, that's more complicated [13:14:39] <mru> what do audio encoders do with invalid bitrates? [13:14:41] <Tjoppen> or dvvideo, where only about 5-10 settings are valid [13:15:02] <mru> dnxhd too [13:15:10] <Tjoppen> aacenc fails, other ignore it and code at their maximum [13:15:15] <_av500_> ffmpeg could also have a flag to allow it to chose sane values if asked by user [13:15:23] <_av500_> or to fail [13:15:29] <mru> that's a good idea [13:15:39] <Tjoppen> kinda like how the error recovery works atm? [13:15:47] <mru> no [13:16:07] <mru> we're talking about encoder settings, right? [13:16:32] <mru> with the fixup flag set, invalid params would be automatically changed to the nearest supported value [13:17:25] <_av500_> vp8 would be replaced by h264 BP... [13:17:58] <Tjoppen> indeed. have a "strict" and a "best effort" mode, and perhaps a couple in between [13:19:31] <mru> or do it the gnome way: hardcode or auto-choose everything [13:39:48] <merbzt> HAHAHA, flamefest on ffmpeg-dev [13:40:06] <merbzt> if I only had that much time to write mails [13:40:40] <_av500_> mru: just make sure it cannot print [13:41:09] <Tjoppen> fika. [13:41:31] <_av500_> no fika on stupid train [13:41:39] <mru> that is a stupid train [13:41:51] <mru> swedish trains actually have half-decent coffee [13:41:53] <_av500_> well it has fika, but i doubt i will like it [13:42:00] <mru> only half though [13:42:09] <_av500_> the water is good? [13:43:09] <KotH> merbzt: which "discussion"? [13:43:35] <_av500_> coeff 63? [13:43:40] <wbs> BBB: are you ok with the url_alloc/url_connect patches? [13:44:00] <BBB> if michael is ok I'm probably ok also... as long as they fix the issue, I'm OK [13:44:08] <BBB> make sure we can set priv_data options after alloc [13:44:13] <BBB> that's my only requirement :) [13:44:20] <BBB> but you would probably know that already [13:44:34] <wbs> yes, and that's taken care of :-) [13:47:37] <merbzt> er cvs-log [13:59:42] <CIA-99> ffmpeg: mstorsjo * r23702 /trunk/libavformat/ (avio.c avio.h allformats.c avformat.h): [13:59:42] <CIA-99> ffmpeg: Add an av_register_protocol2 function that takes a size parameter [13:59:42] <CIA-99> ffmpeg: This allows extending the URLProtocol struct without breaking binary [13:59:42] <CIA-99> ffmpeg: compatibility with code compiled with older definitions of the struct. [14:01:01] <CIA-99> ffmpeg: mstorsjo * r23703 /trunk/doc/APIchanges: Add an APIchanges entry for av_register_protocol2 [14:01:52] <mru> btw why does vp3 idct use the same function pointer as normal idct? [14:02:00] <mru> it's not the same function [14:04:24] <CIA-99> ffmpeg: mstorsjo * r23704 /trunk/libavformat/ (avio.c avio.h avformat.h): Split url_open and url_open_protocol into url_alloc and url_connect [14:04:54] <Tjoppen> looks like the http code has gone through a bit of a round trip. the chunked encoding stuff is my old compact code :) [14:06:00] <CIA-99> ffmpeg: mstorsjo * r23705 /trunk/doc/APIchanges: Add an APIchanges entry for url_alloc() and url_connect() [14:06:58] <merbzt> mru: it's the same but different [14:07:23] <mru> they're not even remotely interchangable [14:07:52] <mru> there's no reason you'd ever want to use mpeg2 idct with vp3 or vice versa [14:08:04] <mru> except perhaps for comic effect [14:08:09] <mru> but for that we have bink [14:10:06] <CIA-99> ffmpeg: mstorsjo * r23706 /trunk/libavformat/ (avio.c avio.h avformat.h): [14:10:06] <CIA-99> ffmpeg: Add priv_data_size and priv_data_class to URLProtocol [14:10:06] <CIA-99> ffmpeg: This allows url_alloc to allocate and initialize the priv_data. [14:11:49] <CIA-99> ffmpeg: mstorsjo * r23707 /trunk/doc/APIchanges: Add an APIchanges entry for priv_data_size and priv_data_class [14:13:28] <CIA-99> ffmpeg: mstorsjo * r23708 /trunk/libavformat/http.c: Allocate the HTTPContext through URLProtocol.priv_data_size [14:14:45] <CIA-99> ffmpeg: mstorsjo * r23709 /trunk/libavformat/http.c: Add an AVClass to the HTTPContext [14:15:53] <CIA-99> ffmpeg: mstorsjo * r23710 /trunk/libavformat/ (rtsp.c http.c): [14:15:53] <CIA-99> ffmpeg: Make the http protocol open the connection immediately in http_open again [14:15:53] <CIA-99> ffmpeg: Also make the RTSP protocol use url_alloc and url_connect instead of relying [14:15:53] <CIA-99> ffmpeg: on the delay open behaviour. [14:17:22] <wbs> BBB: there, now we should have gotten rid of the regressions and have a clean api [14:19:17] <BBB> \o/ [14:19:50] <BBB> there's now a crash on ffmpeg-user with http streaming [14:19:53] <BBB> can you look into that? :-p [14:20:57] <wbs> ugh ;P [14:21:02] <wbs> I'll give it a look later [14:22:42] <BBB> I think I almost have a vp8 decoder patch ready to resubmit to ML [14:23:42] <mru> BBB: add a pack4x8 macro to mathops.h or something [14:23:52] <mru> it can be easily optimised [14:24:39] <mru> and it's useful elsewhere [14:24:42] <BBB> I agree [14:26:11] <BBB> give me a second while I finish the actual vp8 patch, then I'll resubmit a patch for that [14:32:21] <BBB> what was the verdict on the vp56mv int->int16_t conversion? [14:32:40] <mru> probably good [14:33:09] <mru> someone raised an obligatory bikeshed over the possibility of extra sign extension being done here and there [14:34:57] <BBB> I'm trying not to be involved in bikesheds too much these days [14:35:06] <BBB> I've noticed how much you can get done if you don't contribute to bikesheds [14:39:02] <mru> whatever I want to do, there's always a bikeshed blocking my path [14:39:12] <mru> and if there isn't one, reimar builds one [14:40:37] * KotH paints it red [14:41:11] * mru gets C4 [14:45:40] * KotH buys an N^2 mine on the otaku black market [14:51:45] <BBB> how do I get the .text size? [14:51:48] <BBB> (for mru) [14:51:58] <BBB> just ls --size vp56.o is enough? [14:53:41] <_av500_> mru: on2 did not get vp8 to 120mio quality by bikeshedding :) [14:55:42] <ohsix> BBB: theres 'size', but i think it measures more than .text; you can dump and parse section headers with objdump too [14:56:24] <ohsix> size lists text data and bss here, on 2 lines [14:57:21] <ohsix> (really old distro, nothing newer within reach to see what it does now) [14:58:21] <mru> BBB: readelf -S [14:58:38] <mru> or 'size' [15:01:05] <BBB> size did it, thanks [15:03:08] <CIA-99> ffmpeg: benoit * r23711 /trunk/libavutil/common.h: Add missing parentheses in MKTAG and MKBETAG macros. [15:05:22] <janneg> BBB: wrong parens added [15:05:49] <janneg> it need parens around the macro arguments [15:06:04] <mru> BBB: oh, and separate that from the rest of the patch [15:06:15] <mru> add the macro first as a separate commit [15:06:35] <BBB> okiedokie [15:06:41] <BBB> janneg: oh right [15:07:09] <mru> also << has higher precedence than | so those parens aren't needed [15:07:16] <mru> but gcc might throw a fit [15:07:30] <mru> imo that warning should be turned off [15:07:51] <ohsix> check out "ten most active lists today" http://gmane.org/ [15:08:09] <mru> world domination... [15:09:42] <mru> that's an odd collection btw [15:11:26] <BBB> mru: I do it just for the warning [15:11:47] <ohsix> was that dithering thing the only reason there wasn't already a dc only idct? [15:11:56] <mru> no [15:11:59] <mru> that was lazyness [15:13:58] <BBB> the parens around are needed if you use the result directly in weird mathops btw, or that's what I was always taught [15:14:07] <BBB> anyway, let me compile a version taht uses #if BIGENDIAN [15:15:06] <mru> parens around all of it are needed to protect it if used as an operand in an expression [15:15:13] <mru> imagine this [15:15:21] <mru> #define FOO(a, b) a + b [15:15:34] <mru> FOO(x, y) * 3 [15:15:55] <ohsix> premature optimization and all that; michael needs to get a faster computer so the code can get to a point where it can actually be massaged for what he's looking for instead of just taking it out at the knee [15:16:39] <mru> maybe I should send him my old core2 [15:19:10] <BBB> bleh, I don't want to disassemble today [15:19:11] <BBB> maybe later [15:19:17] <BBB> the patch isn't required for vp8 anyway [15:21:07] <mru> btw, some silly people don't know why parens around macro expansions are sometimes needed [15:21:14] <mru> so they cargo-cult them everywhere [15:21:18] <mru> #define FOO (0) [15:21:24] <mru> I want to kill such people [15:21:31] <mru> but my boss wouldn't let me [15:21:52] <BBB> I know why they're needed, but don't want to waste my time writing it and your time reading it [15:24:42] <ohsix> should have cited the irc log for the dc stuff; then he'd know what you were doing hurf [15:25:09] <mru> he subscribes to the logs by mail [15:25:24] <ohsix> ya but he didn't put 2&2 together [15:25:33] <mru> he didn't want to [15:25:49] <ohsix> maybe, can't really assume that though [15:26:13] <mru> besides, why would I care about the value if I wasn't planning on using it? [15:26:29] <ohsix> i wouldn't read irc logs if they were posted daily; i might like to search them, but i wouldn't have a linear timeline for topics in both places [15:31:29] <mru> hmm... I made a list of top bikesheds of all time on ffmpeg-devel [15:31:37] <mru> sorted by number of posts [15:31:46] <mru> any guesses as to what's on top? [15:33:47] <ohsix> no clue [15:34:48] <mru> 238 [PATCH] QCELP decoder [15:35:20] <mru> 231 Realmedia patch [15:35:40] <mru> 178 Google Summer of Code participation [15:35:50] <mru> 170 [PATCH] ALS decoder [15:35:55] <mru> 155 [PATCH] Implement PAFF in H.264 [15:36:49] <BBB> is realmedia patch my rdt patch? [15:36:56] <BBB> that one was bikeshed-supreme [15:37:16] <mru> I've no idea what it is [15:37:35] <mru> I just sorted and counted the subject lines in the archive [15:37:52] <mru> hey wait [15:37:54] <mru> 111 [PATCH] RDT/Realmedia patches #2 [15:38:03] <mru> 111 [PATCH] WMA Voice decoder [15:38:07] <mru> you're popular [15:40:13] <BBB> \o/ [15:40:26] <BBB> I think realmedia patch and rdt/realmedia patches are the same thread [15:40:29] <BBB> just different subject [15:41:36] <mru> I didn't bother writing an actual thread parser just for this [15:41:54] <BBB> wasn't the aac decoder bikeshed supreme as well? [15:42:02] <BBB> I thought there were like 10 threads for that [15:42:06] <BBB> named #1, #2, #3 etc. [15:42:33] <mru> it went up to round 10 or so [15:43:26] <mru> but they're only 20-30 each [15:43:33] <peloverde_> How do you know these weren't very long but very productive discussions? :p [15:43:41] <mru> lol [15:44:43] <peloverde_> and seriously and more importantly how can we reduce bikshedding on future patches? [15:45:11] <mru> when michael is involved, impossible [15:45:13] <ohsix> keep your own trees that people can pull your work from [15:45:54] <ohsix> getting too much into discussions with people who are just going to mill around with one concern is probably not useful either [15:46:17] <mru> ohsix: you mean people like yourself? [15:46:34] <ohsix> like how [15:46:49] <mru> maybe you should have your short-term memory checked [15:47:04] <ohsix> if i had demonstrated as much on here i'd accept your point, but i'm more talking about 63 and that thread [15:47:22] <mru> let's talk about alsa instead [15:47:44] <mru> or ffmpeg vs xiph [15:47:44] <ohsix> that would be you bikeshedding :P [15:48:05] <ohsix> and thats more of an opinion thing; and we can both have some of those [15:48:08] <mru> last time you compared using ffmpeg to stabbing people with knives [15:48:18] <ohsix> nope [15:48:23] <mru> oh yes you did [15:48:34] <_av500_> ffmpeg is to the lone woman what the vcr is to the boston strangler [15:48:35] <ohsix> knives were mentioned but that is a willful mischaracterization of what i said [15:49:11] <mru> what the fuck did you intend to mean then? [16:08:22] <BBB> is there a mmx instruction to write the highest 4 bytes (rather than movd:lower 4 bytes) into a memory location (or the other way around)? [16:48:36] <BBB> kurosu: ping, so what was the issue with the mc/mmx code exactly? [17:04:43] <BBB> wbs: you've tested all these patches right? :-p [17:04:50] <BBB> (I'm reading through cvslog for a bit) [17:11:45] <wbs> BBB: yes, I've tested it [18:15:55] <kurosu> BBB: I haven't seen the latest patch, but you were unpacking to dwords some of the computations [18:16:22] <kurosu> because the results of some of them were not fitting in the expect word [-32767;32768] [18:16:34] <Dark_Shikari> BBB: use psrlq or whatever to shift [18:16:35] <Dark_Shikari> then write [18:17:25] <kurosu> this doesn't really matter as long as the whole range of the results is 16bits, which seems the case here [-32*255;190*255] IIRC [18:18:03] <kurosu> like in the vc1 mc code, you just need to use unsaturating maths and add bias/do saturating math/remove bias [18:18:16] <kurosu> without unpacking results to dwords, keeping all in words [18:20:56] <janneg> mru: experimental doesn't work like that for decoders. I had not enough energy to argue with baptiste [18:21:21] * mru locks baptiste in a bikeshed and melts the key [18:22:11] <Dark_Shikari> Why not just make libvpx the default? [18:22:15] <Dark_Shikari> and change the default later? [18:22:25] <Dark_Shikari> what's so hard about this [18:22:26] <mru> that's exactly what the experimental flag would do [18:22:39] <mru> if baptisted hadn't shedded it into oblivion [18:24:55] <Dark_Shikari> er.... [18:24:59] <Dark_Shikari> you can do that without experimental [18:25:16] <Dark_Shikari> for example, take libfaad [18:25:18] <Dark_Shikari> ffmpeg aac is default [18:25:20] <Dark_Shikari> libfaad is a secondary option [18:25:31] <mru> libfaad doesn't even exist [18:25:34] <Dark_Shikari> there's no "experimental flag" for libfaad [18:25:38] <Dark_Shikari> You know what I'm talking about. [18:25:41] <Dark_Shikari> When it did, this was how it worked. [18:25:47] <mru> actually, I don't [18:25:50] <Dark_Shikari> ....? [18:25:53] <janneg> Dark_Shikari: that's just order of the register_decoder calls [18:25:54] <mru> there is no concept of default codec [18:25:58] <Dark_Shikari> Yes there is. [18:26:02] <Dark_Shikari> The one that's called first is used first. [18:26:04] <Dark_Shikari> What janneg said. [18:27:06] <janneg> but allcodecs.c is sorted by type and name and not by codec id and priority [18:27:07] <mru> and native aac was registered way before libfaad [18:27:15] <mru> so libfaad was never "default" [18:27:37] <Dark_Shikari> it was before native aac existed [18:27:40] <Dark_Shikari> and then [18:27:42] <Dark_Shikari> when ours was added [18:27:44] <Dark_Shikari> ours was made "default" [18:27:49] <Dark_Shikari> and libfaad was "not default" [18:27:56] <Dark_Shikari> So why, for vpx, can't it be the reverse? [18:27:58] <Dark_Shikari> libvpx is "default" [18:28:01] <Dark_Shikari> ours is "not default" [18:28:03] <Dark_Shikari> and then later we can change it? [18:28:06] <Dark_Shikari> you are bikeshedding. stop it. [18:28:24] <ohsix> BLUE! [18:28:52] <ohsix> seems everyone gets into the spirit of things but not everyone is calling names :D [18:30:28] <mru> I see nothing but hand-waving from baptiste [18:31:09] <janneg> I'll send a patch [18:44:03] <BBB> kurosu: huh? [18:44:16] <BBB> kurosu: no, I used dwords because pmaddbla did that for me [18:44:21] <BBB> kurosu: the result is 9bit or so [18:44:29] <BBB> maybe less [18:44:30] <BBB> but anyway [18:44:37] <BBB> oh wait it was actually 16bit [18:44:42] <BBB> but still [18:45:06] <BBB> kurosu: so it was because the instruction made me, not because I wanted to [18:47:18] <BBB> mru: don't bother with the experimental [18:47:32] <BBB> mru: if it's an issue, I'll simply add the bilin flter so the vector test suite passes [18:47:39] <BBB> mru: I was hoping it wouldn't be an issue [18:47:51] <Dark_Shikari> BBB: do that, then we can kill libvpx [18:47:56] <BBB> no [18:47:58] <BBB> libvpx encodes [18:48:05] <mru> kill libvpx decode [18:48:09] <BBB> k... [18:48:27] * BBB goes look into the cursed and undocumented bilinear filter [18:48:44] <Dark_Shikari> well yes [18:49:02] <peloverde_> I would say don't bother with bilin until it appears in the spec [18:49:18] <mru> +1 [18:49:28] <mru> teach them what spec means [18:49:40] <BBB> that was my logic [18:49:48] <BBB> but then I can't apply it without it being experimental [18:49:52] <BBB> which is a little silly maybe [18:49:59] <mru> huh? [18:50:21] <mru> if it decodes everything in the spec properly, it's good to go imo [18:50:27] <BBB> it does [18:50:36] <mru> we could even claim those other files are invalid [18:50:42] <kierank> lol [18:50:42] <peloverde_> I agree with mru [18:50:45] <mru> and call it an encoder bug [18:50:53] <BBB> well, the spec does say that whenever libvpx and spec disagree, libvpx is correct [18:51:08] <BBB> it's just that this is a very extended way of saying that the spec is wrong [18:51:14] <peloverde_> Then it's not a spec it's a textual description of libvpx [18:51:15] <mru> it's like an mpeg2 encoder using qpel mc [18:51:27] <BBB> it's like writing a spec that says : "empty; whatever is missing but present in libXYZ, libXYZ is right" [18:51:50] <kurosu> BBB: whatever. I'll benchmark what I propose once your code has been accepted. But my point was: pmaddwd is not mandatory [18:52:05] <BBB> kurosu: ok [18:52:12] <peloverde_> It's insulting that google wants to call this a standard but their implementation has priority status [18:52:35] <BBB> kurosu: I'm learning mmx by doing this, so I might well be wrong in many places [18:52:43] <BBB> all I can test is that it's faster and bit-exact [18:52:47] <BBB> it might not be fastest [18:52:54] <kierank> peloverde_, it's known as the mozilla development model. If you don't get your paycheck from them they don't care. [18:53:40] <Dark_Shikari> peloverde_: that's why we have to change tha [18:53:41] <Dark_Shikari> *that [18:53:44] <Dark_Shikari> we have to get libvpx out of ffmpeg, asap [18:53:52] <BBB> make x264 output vp8 [18:53:57] <Dark_Shikari> everyone uses ffmpeg. once libvpx is gone, google will no longer have control [18:54:05] <Dark_Shikari> they won't be able to arbitrarily break things [18:54:08] <Dark_Shikari> because they won't control the decoder [18:54:09] <kurosu> BBB: I don't recall why we did this for vc1: either the code was register-starved, or it was faster [18:54:22] <peloverde_> Don't gst and firefox wrap libvpx? [18:54:23] <Dark_Shikari> kurosu: pmaddwd saves 2 regs [18:54:26] <BBB> kurosu: ok... feel free to test it, it'd be better if you teach me while doing so ;) [18:54:27] <Dark_Shikari> peloverde_: chrome wraps ffmpeg [18:54:31] <peloverde_> as do the dshow filters [18:54:43] <peloverde_> Dark_Shikari, chrome does but google controls chrome and can patch libvpx back in [18:54:47] <BBB> peloverde_: firefox is quickly becoming irrelevant [18:54:50] <Dark_Shikari> They can, but we'll make it hard for them. [18:55:24] <Dark_Shikari> Especially when our implementation is twice as fast. [18:55:33] <peloverde_> BBB, firefox is losing marketshare but it still is the #2 browser [18:55:37] <Dark_Shikari> And furthermore [18:55:41] <Dark_Shikari> When ours is twice as fast [18:55:43] <Dark_Shikari> what will firefox do? [18:55:46] <mru> vlc would probably be happy to use ffmpeg by default [18:55:48] <Dark_Shikari> They will have to work very hard to justify not using it. [18:55:56] <BBB> ok [18:55:57] <BBB> so now [18:55:59] <BBB> back to basics [18:56:01] <Dark_Shikari> thus, our goal needs to be to make it so much better [18:56:02] <mru> firefox will never use ffmpeg [18:56:04] <BBB> how do I make this beast experimental? [18:56:07] <BBB> so I can commit it [18:56:10] <BBB> my hands are itching [18:56:11] <Dark_Shikari> mru: but we can make them suffer for not doing it [18:56:11] <mru> it's against their charter [18:56:22] <BBB> mru: firefox != chris blizzard [18:56:29] <BBB> chris blizzard is a moron and the firefox people know it [18:56:32] <mru> mozilla charter: [18:56:42] <Dark_Shikari> stop flaming [18:56:43] <BBB> they have asked sflc about ffmpeg, legal implications etc. [18:56:43] <mru> 1. all mozilla products shall suck [18:56:43] <Dark_Shikari> it doesn't _matter_ [18:56:51] <BBB> and sflc has said what they should say [18:56:54] <Dark_Shikari> 1) we make it super fast [18:56:57] <Dark_Shikari> 2) if they don't adopt ffmpeg, they suffer [18:57:01] <Dark_Shikari> 3) if they do adopt ffmpeg, we win [18:57:03] <Dark_Shikari> win-win situation [18:57:06] <BBB> and Dark_Shikari is right, by being better we will always win [18:57:08] <Dark_Shikari> now stop it and get back to coding [18:57:13] <mru> it's good to have an optimist around [18:57:23] <Dark_Shikari> there's no optimism [18:57:25] <BBB> is it CODEC_CAP_EXPERIMENTAL? [18:57:27] <Dark_Shikari> I don't expect them to do anything but suffer [18:57:57] <peloverde_> BBB, the consensus (here) is no CODEC_CAP_EXPERIMENTAL [18:58:05] <mru> a true freetard has to suffer [18:58:14] <mru> it's part of their philosophy [18:58:17] <BBB> I thought they just said let's mark is exp. until it passes the test vector suite [18:58:27] <mru> seeig themselves as victims, suffering for a noble cause [18:58:34] <Dark_Shikari> mru: it doesn't matter [18:58:36] <Dark_Shikari> we don't care what they see [18:58:39] <Dark_Shikari> we don't care what they do [18:58:41] <BBB> hehe. mru is a little right [18:58:41] <peloverde_> I tohught we said that non-spec filrs don't matter [18:58:42] <Dark_Shikari> we care that we are better [18:58:56] <Dark_Shikari> peloverde_: we could do that [18:58:57] <BBB> mru, Dark_Shikari: opinions on experimental? [18:58:58] <BBB> yes / no [18:58:59] <peloverde_> *I thought we said that non-spec files don't matter [18:59:03] <Dark_Shikari> and if google complains, we could say that it isn't in the spec [18:59:09] <BBB> I already told them [18:59:13] <BBB> they say they're working on it [18:59:17] <BBB> that was >1 week ago [18:59:18] <Dark_Shikari> Then we're working on it. [18:59:20] <Dark_Shikari> Commit now. [18:59:23] <Dark_Shikari> Now. [18:59:38] <Dark_Shikari> Stop the bikeshed. Stop the debate. Just fucking commit it. [18:59:41] <Dark_Shikari> We can work with it from there. [18:59:52] <peloverde_> statim [19:00:37] <mru> commit w/o experimental [19:05:13] <janneg> BBB: commit, CODEC_CAP_EXPERIMENTAL does nothing now. it can be added later if someone insists [19:06:00] <BBB> janneg: agreed [19:07:30] <CIA-99> ffmpeg: alexc * r23712 /trunk/libavcodec/ps.c: Cosmetics whitespace. [19:08:46] * BBB complains that test-builds before commit take ages if you change common.h or mathops.h [19:10:05] <peloverde> That's why I try to get changes in common headers committed early if at all possible [19:10:07] <elenril> why test-build, fate will do that for you [19:10:08] * elenril runs [19:10:27] <peloverde> you should subtly break x86/linux :) [19:11:09] <BBB> forgiveness can be hard to receive :-p [19:11:55] <mru> BBB: get a faster computer [19:12:07] <BBB> nobody wants to buy me that pretty new mac [19:12:22] <CIA-99> ffmpeg: rbultje * r23713 /trunk/libavutil/common.h: Add av_clip_int8(), used in the upcoming VP8 decoder. [19:12:31] <Dark_Shikari> I don't see the commit yet [19:12:50] <mru> BBB: why would you want a mac? :-) [19:13:01] <BBB> Dark_Shikari: I'm slow [19:13:05] <mru> the sony ones are much nicer [19:13:11] <BBB> they don't run osx [19:13:18] <mru> even better [19:13:43] <CIA-99> ffmpeg: rbultje * r23714 /trunk/libavcodec/ (h264pred.h h264pred.c): Make "topright" argument to pred4x4() const. [19:13:49] <mru> there simple is no macbook that fulfills my requirements [19:13:57] <elenril> mru: http://www.igniq.com/images/joytech_ps2_monitor_170505.jpg you mean this? [19:14:06] <Honoome> mru: you know, s/freetard/$religious_organisation/ holds true as well :P [19:14:29] <mru> elenril: hehe [19:14:50] <mru> Honoome: yes, and religious people are also generally unhappy [19:15:23] <Honoome> right [19:16:19] <CIA-99> ffmpeg: rbultje * r23715 /trunk/libavcodec/mathops.h: [19:16:19] <CIA-99> ffmpeg: Add a macro to pack 4 bytes into native byte-order so they can be written [19:16:19] <CIA-99> ffmpeg: at once using a single 32-bit store. [19:18:02] <CIA-99> ffmpeg: rbultje * r23716 /trunk/libavcodec/ (h264pred.h h264pred.c arm/h264pred_init_arm.c): [19:18:03] <CIA-99> ffmpeg: Add intra prediction functions for VP8. [19:18:03] <CIA-99> ffmpeg: Patch by David Conrad <lessen42 gmail com> and myself. [19:18:03] <CIA-99> ffmpeg: rbultje * r23717 /trunk/libavcodec/ (h264pred.c arm/h264pred_init_arm.c): Reindent after r23716. [19:18:06] <peloverde> BBB, another testbuild trick is --disable-everything --enable-decoder=vp8 [19:19:03] <Honoome> I need a coffee :/ [19:19:55] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/MustHaveCaffeine [19:20:04] <CIA-99> ffmpeg: rbultje * r23718 /trunk/libavcodec/vp56.h: Change a / 256 into a >> 8. [19:20:11] <BBB> almost there... [19:20:56] <BBB> can somebody else help with throwing out libvpx once we agree it can be thrown out? [19:21:18] <peloverde> mru seems to take great joy in removing wrappers? [19:21:33] <BBB> I was hoping for his kind assistance, esp. since it gives him so much pleasure [19:21:42] <mru> peloverde: it's not the process as such [19:21:46] <mru> it's the cleanliness that results [19:21:59] <mru> it's like killing roaches in the kitchen [19:22:22] <Honoome> elenril: glad to see I'm not the only one living on that wiki :P [19:23:37] * elenril doesn't read it all that much lately [19:24:07] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/ItsPopularNowItSucks [19:24:17] * mru suspects elenril has memorised it all [19:24:30] <mru> which would explain why he doesn't read it much anymore [19:24:39] <elenril> yeah, that too [19:25:05] <CIA-99> ffmpeg: rbultje * r23719 /trunk/ (10 files in 2 dirs): [19:25:05] <CIA-99> ffmpeg: Native VP8 decoder. [19:25:05] <CIA-99> ffmpeg: Patch by David Conrad <lessen42 gmail com> and myself. [19:25:15] <saintdev> \o/ [19:25:23] <Dark_Shikari> \o/ [19:25:25] <elenril> \o/ [19:25:58] <peloverde> \o/ [19:26:03] <elenril> maybe we should /. it or something [19:26:23] <peloverde> send an announcement to the webm list [19:26:48] <mru> wait for some asm optimisations [19:26:57] <mru> so it's clearly faster than libvpx [19:27:01] <BBB> it already is [19:27:13] <mru> even without asm? [19:27:40] <Dark_Shikari> without asm it's faster than vp8 without asm [19:27:41] <Dark_Shikari> er, libvpx [19:27:47] <Dark_Shikari> don't announce it yet, let's write the asm [19:27:49] <Dark_Shikari> and then remove libvpx [19:27:52] <Dark_Shikari> I say it'll take us a week or three. [19:27:54] <Dark_Shikari> Then we announce. [19:28:04] <peloverde> people will find it anyway [19:28:13] <mru> we don't need big thunder [19:28:33] <Dark_Shikari> mru: we announce the thunder when we're 40% faster. [19:29:54] <CIA-99> ffmpeg: alexc * r23720 /trunk/libavcodec/ (13 files): Move Parametric Stereo related ps* files to aacps*. [19:30:17] <BBB> mru: yes even without asm [19:31:01] <mru> ffvp8 w/o asm is faster than libvpx with? [19:31:04] <Dark_Shikari> no [19:31:25] <Dark_Shikari> BBB: can you commit some asm for starters so we have .asm files for me to easily merge things into? [19:31:36] <Dark_Shikari> easier to have low-friction commits that way [19:31:40] <BBB> I'll submit a patch for review [19:31:50] <BBB> if any part is OK'ed I'll apply it [19:32:02] <Dark_Shikari> I can write ssse3 mc [19:32:26] <BBB> coolish [19:35:00] <peloverde> Is any of the libvpx assembly worth borrowing [19:35:09] <peloverde> before they de-yasm-ify [19:35:16] <Dark_Shikari> they're not deleting the git history [19:35:30] <Dark_Shikari> I don't recall seeing anything really good in there [19:35:36] <Dark_Shikari> i.e. nothing that wasn't the naive approach [19:35:43] <Dark_Shikari> which means it's only useful if we're not going to write our own [19:39:15] <Dark_Shikari> BBB: does the code currently use idct_dc_add [19:39:16] <Dark_Shikari> ? [19:39:26] <Dark_Shikari> oh, you never fixed the splatting [19:39:30] <Dark_Shikari> in your asm [19:39:41] <Dark_Shikari> and you never unrolled the idct dc and use padd/psub instead... wait what [19:39:43] <Dark_Shikari> your patch is old [19:39:48] <Dark_Shikari> I thought you already updated this [19:41:47] <Honoome> if somebody has problems of self-esteem related to their code, one very good solution is to read some ruby on rails related code... [19:41:57] <Honoome> that'll definitely make you feel like a _very_ good coder [19:42:04] <j0sh_> lol [19:42:19] <j0sh_> rails code uses a lot of magic, but i havent looked at it lately [19:42:40] <Honoome> j0sh_: rails itself is bad, but not as bad as some of the code written around it [19:42:44] <mru> is ruby still as horribly slow as it was some years ago? [19:42:56] * Honoome is fighting with "bundler".. as the name leaves to intend, it's a bad thing by design [19:43:06] <j0sh_> mru: the newer ruby implementations have made a lot of progress speed-wise [19:43:12] <Honoome> mru: depends on the task... there are some obvious things that are stupidly slow [19:43:31] <Honoome> 0xf000000..0xfff00000.min [19:43:37] <mru> a few years ago my toy script interpreter outran it by orders of magnitude [19:43:38] <Honoome> this'll take a huge bloody amount of time [19:44:03] <Honoome> because it actually _iterates_ through all the objects.. it's a frigging range (so it's ordered) [19:44:03] <mru> of course my toy language isn't comparable to ruby at all [19:44:19] <mru> seems like an obvious optimisation [19:44:31] <Honoome> they fixed it in 1.9 [19:44:32] <peloverde> So when is the public release of mruscript? [19:44:40] <Honoome> but of course... half the code does not work with 1.8 [19:44:46] <Honoome> s/8/9/ [19:45:04] <Honoome> and not all the code that is declared "works with 1.9" actually does [19:45:15] * Honoome could repat the story of the fcgi gem that compiled... with undefined symbols [19:45:19] <j0sh_> 1.9 is starting to feel like perl 6 [19:45:19] <mru> peloverde: http://git.mansr.com/?p=libtc;a=blob;f=src/script.c [19:45:52] <Honoome> j0sh_: yeah more or less.. 1.9.1 is not usable and they moved on to 1.9.2 already, with more stuff to break [19:46:05] <Honoome> Rails 2.3.5 (and 2.3.8) are both declared to work on 1.9, but their own testsuite explodes on 1.9 :/ [19:46:12] <mru> I heard perl6 was to be released the day before duke nuken forever [19:46:32] <Honoome> with Gentoo I'm trying to do the best to support 1.9 as it is but it's giving me headaches to fix all the packages :/ [19:46:34] <mru> Honoome: reminds me of java 1.3 times [19:46:43] <Honoome> mru: and ruby2 the day after I guess [19:46:58] <Honoome> and those will be the three days that RMS will be the most useful to the world... [19:47:17] <peloverde> java 1.4 broke the class loader in strange ways [19:47:23] <mru> well, the third day we'll all be playing DNF [19:47:42] <mru> java 1.4 was a huge break against a lot of 1.3 things [19:47:59] <mru> but used alone, it was more bearable [19:48:10] <mru> I haven't really touched java since [19:48:30] <Honoome> mru: not sure if 1.9 is like that... they did change quite a bit of things though [19:48:35] <Honoome> including the String class (d'oh!) [19:48:36] <mru> I hear they added enums, <templates>, @annotations, and god knows what [19:48:47] <mru> ^^ in java... [19:49:07] <Honoome> with 1.5 iirc [19:49:27] <peloverde> I really don't think there was anything in 1.4 that I found particularly helpful above 1.3 [19:49:30] <Honoome> but it's not <templates> it's <generics> ... which of course the C++tards will tell you are "despisable" because they can't do all the things that templates do... [19:49:49] <mru> looks a hell of a lot like templates to me [19:49:49] <peloverde> 1.5 added a stdio compatible formatter [19:49:53] <Honoome> on the other hand, generics are just the sane stuff you can get with templates, so ... :P [19:50:07] <Honoome> mru: templates in C++ iirc are turing-complete on their own [19:50:07] <mru> peloverde: yeah, printf was one of the things I cursed the lack of the most [19:50:19] <mru> Honoome: no, the _error messages_ are turing complete [19:50:36] <mru> whatever that means [19:50:37] <Honoome> you can expand a 1MB source file into something equivalent to a 24MB pre-processed file, with templates [19:50:51] <Honoome> mru: the error messages are a realistic turing test... inverse [19:51:04] <peloverde> I wrote my first AAC decoder in java 1.3 (without printf) that made debugging super fun [19:51:17] <mru> Honoome: tried feeding them to an xml parser? [19:51:26] <Honoome> you can't be an human if you can understand C++ error messages [19:51:38] <Honoome> mru: no, actually xml makes more sense to me than some template-heavy C++ code [19:54:34] <Tjoppen> I wouldn't really compare java's generics with c++ templates. the similarity is mostly superficial [19:55:02] <mru> I used templates in the general sense [19:56:02] <peloverde> Perhaps even the most generic sense? :) [19:56:12] <Tjoppen> generics are kinda like throw() in C++. doesn't give you any guarantees - only run-time enforcement [19:56:29] <mru> I'm not talking about implementation specifics [19:57:06] <BBB> Dark_Shikari: I was creating a vp8 decoder patch, I can only do one thing at a time [19:57:14] <BBB> Dark_Shikari: so yes the patch is several days old :-p [19:57:24] <mru> the <> in java looks like it's a way to apply the same code to different data types [19:57:28] <mru> that's a template to me [19:57:29] <BBB> it's still faster than C, feel free to comment on the ML and I'll resubmit in a few days [19:59:48] <mru> Dark_Shikari: hey look, michael replied to your "patch" [20:00:07] <Tjoppen> kinda, except a List<Dog> can contain Cats for instance. but whatever [20:00:38] <mru> as I said, I know nothing about the new java stuff [20:00:47] <mru> I've just seen some random fragments [20:00:55] <mru> many of them on tdwtf [20:01:19] <Honoome> mru: didn't I tell ya that calling those templates would have brought you to complains? :P [20:01:25] <mru> btw, does eclipse still have a class with a name >100 chars long? [20:02:06] <Tjoppen> probably. definately, if you count inner classes [20:02:23] <Dark_Shikari> mru: lol [20:02:52] <Honoome> mru: want to know what's the longest ELF symbol I can find on my tinderbox? :) [20:03:12] <mru> Honoome: if you want to do the search, sure [20:03:26] <mru> are you counting c++ mangled names? [20:04:16] <Honoome> yes [20:04:28] <Honoome> 403 characters, it's a gnash symbol [20:04:32] <mru> lol [20:04:37] <Honoome> _ZN5gnash13iterator_findERN5boost11multi_index21multi_index_containerINS_8PropertyENS1_10indexed_byINS1_14ordered_uniqueINS1_13const_mem_funIS3_RKNS_9ObjectURIEXadL_ZNKS3_3uriEvEEEEN4mpl_2naESC_EENS5_INS1_3tagINS_12PropertyList8OrderTagESC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_EENS6_IS3_iXadL_ZNKS3_8getOrderEvEEEESC_EESC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_SC_EESaIS3_EEEi [20:04:48] <Honoome> sorry 402, I have a final @ that I use for versioning [20:05:02] <mru> eeeew [20:06:55] <Honoome> if I exclude C++ symbols, mangled with the latest g++ ABI (so starting with _Z) I get another at 384 characters, but I have no clue where it comes from... and it looks like C++ stuff anyway [20:07:57] <Honoome> [I have a database of all the symbols exported.. well almost all of them...] [20:08:11] <Honoome> I could tell you which packages likely bundle part of FFmpeg :P [20:08:23] <roxfan> some people collect stamps... [20:08:23] <mru> what do you have that db for? [20:08:36] * mru collects beagle boards [20:09:10] <Honoome> mru: collisions detections and identification of bundled code [20:09:49] <Honoome> the former was the original intent, the latter is happenstance, but it turns out useful to find if somebody ever bundled a vulnerable function when they come by [20:10:29] <roxfan> mru: has fft16_neon been tested on real hw? i see it loads some data from a structure with :128 align but the structure is only 4-byte aligned... [20:10:51] <mru> of course it's tested [20:11:56] * Honoome wonders how one person can be so stupid about code... [20:12:04] <roxfan> any idea why that works then? according to arm docs this should result in a fault [20:12:14] <mru> it works because the alignment is guaranteed [20:12:40] <Honoome> so you got a sorta-package-manager that uses a "$packagename-$version-$gitsha-$branch" scheme to install packages.. [20:13:01] <Honoome> how do you extract the branch? fullpath.split("-")[3] ... [20:13:19] <Honoome> what happens if fullpath (which is obviously absolute) contains '-'? [20:13:24] <mru> it breaks [20:13:35] <mru> but I can top that [20:13:36] <Honoome> it reports the most bogus data possible.. [20:13:49] <mru> a build system written in javascript [20:14:04] <mru> in such a way that '.' anywhere in the absolute path is illegal [20:14:05] <Honoome> nokia's qmake replacement? [20:14:10] <Honoome> hahaha [20:14:22] <mru> think version numbers [20:14:48] <Honoome> who uses versioned tarballs anyway? [20:14:54] <Honoome> who uses tarballs! just git fetch it! [20:17:20] <roxfan> mru: i downloaded a random armv7 build of libavcodec.so and 'mppm' array is only 32-byte aligned [20:17:34] <mru> try a proper build instead [20:17:37] <roxfan> maybe kernel silently fixes the fault? [20:18:15] <mru> my kernels have fixup disabled [20:18:24] <mru> there's no point arguing [20:18:38] <roxfan> i'm not arguing, i'm trying to understand [20:19:02] <mru> 32-byte alignment is plenty btw [20:19:06] <mru> did you mean bit? [20:19:13] <roxfan> how do you guarantee 128-byte alignment? i only see ".align 4" in the .S file [20:19:17] <mru> bit [20:19:24] <mru> 16-byte [20:19:29] <mru> 1<<4 == 16 [20:20:27] <roxfan> oh indeed 128 is in bits [20:20:37] <roxfan> sorry for the false alarm :/ [20:24:09] <mru> IAddWebComponentToEnterpriseApplicationDataModelProperties [20:24:14] <Dark_Shikari> BBB: do you have a vp8 test video I can use to test my asm? [20:24:15] <mru> that's an actual class name [20:24:19] <mru> from eclipse [20:24:42] <BBB> http://code.google.com/p/webm/downloads/detail?name=vp8-test-vectors-r1.zip&can=2&q= [20:25:15] <mru> counting inner classes the winner is ConfigureWorkingSetAssignementAction$WorkingSetModelAwareSelectionDialog$Gra [20:25:18] <mru> yedCheckModelElementSorter [20:25:21] <BBB> Dark_Shikari: and then http://ffmpeg.pastebin.com/d3KKb0jj [20:25:31] <BBB> Dark_Shikari: run it with unpatched source to get the md5s for ref.md5s [20:26:34] <Dark_Shikari> oh, cool [20:26:49] <Honoome> YAI! I "fixed" bundler [20:26:56] <Honoome> or rather made it slightly less broken [20:31:40] <peloverde> Should these test vectors be added to FATE? [20:31:52] <mru> sure, why not? [20:36:57] <wbs> BBB: FWIW, the crash on -user that you mentioned, it's not at all related to http. it's a bug on the 0.6 branch that has been fixed in trunk since. 23344 should be the revision fixing that [20:37:34] <peloverde> How does one go about adding tests to fate? [20:37:49] <wbs> BBB: I'm not subscribed to -user, so I can't give a sensible reply there, though [20:37:51] <mru> you hope and pray that mike will eventually do it [20:38:00] <mru> that's why we need a new system [20:38:30] <peloverde> is mike willing to open up fate? [20:38:44] <Honoome> I thought the code was already open [20:38:49] <mru> diego asked him and got handwaving replies [20:39:01] <mru> the server-side code is not available [20:39:08] <mru> and it's probably ugly beyond belief [20:39:19] <mru> I'd like to do it a bit differently [20:39:38] <peloverde> I'd like to build the testspecs into FFmpeg itself [20:39:46] <mru> they're already there actually [20:40:18] <Honoome> mru: no doubt it's ugly :P [20:40:47] <kierank> it's php isn't it? [20:40:51] <mru> python [20:40:56] <mru> and maybe some php too [20:40:58] <mru> I don't know [20:41:09] <mru> mike likes python for some reason [20:41:20] <peloverde> I thought they lived in http://fate.multimedia.cx/fate-tests.sqlite.bz2 [20:41:31] <mru> they also live in tests/fate* [20:41:50] <Honoome> damn, I still got one test failure on bundler due to _the bloody paths_ =_= [20:43:17] <peloverde> Then what's this nonsense about fate not being versioned/not being able to run fate on branches? [20:43:42] <mru> the test files aren't versioned for starters [20:44:01] <peloverde> the same files should be usable [20:44:01] <mru> and the fate runner scripts use the refs from the db, not from the repo [20:44:40] <peloverde> that seems trivial to fix then, no? [20:45:19] <mru> I'd like to do completely restructure it [20:45:36] <Dark_Shikari> BBB: I'm getting "all results bitexact" even when I completely break it [20:46:01] <Dark_Shikari> er, "results identical" [20:47:11] <peloverde> What do you want it to look like? and can it be done quickly? [20:47:30] <peloverde> I *need* some sort of aacdec tests in fate [20:47:44] <mru> I need time to do it [20:48:35] <mru> I should make it high priority [20:49:48] <peloverde> I would be very much appreciative if you did [20:50:03] <peloverde> And I'm willing to help with it [20:50:17] <BBB> Dark_Shikari: huh? can't be, I tested various buggy things and broke it :) [20:50:30] <BBB> Dark_Shikari: make sure the test files actually trigger your code [20:51:09] <Dark_Shikari> BBB: your regression.sh is broken on cygwin [20:51:14] <Dark_Shikari> it generates no output [20:51:19] <Dark_Shikari> because you need "-" not /dev/stdout [20:51:48] <BBB> it was a hackscript, not supposed to be portable beyond mac and perhaps linux [20:51:53] <Dark_Shikari> I know I know [20:51:56] <Dark_Shikari> but it's _shorter_ =p [20:52:50] <BBB> I didn't know - worked :-p [20:53:01] <peloverde> Also why does that script use /bin/bash? I don't see any bashisms [20:53:06] <Dark_Shikari> I didn't know there was a /dev/stdout [20:53:10] <BBB> hehe :) [20:53:16] <BBB> peloverde: bad habit, that's all [20:53:22] <Dark_Shikari> I thought stdout was just a particular stream opened by the shell [20:53:27] <BBB> really, the script is a complete hack and probably completely broken, I suck at shell [20:53:29] <peloverde> There is lots of funs stuff in dev [20:54:11] <siretart> peloverde: hi [20:54:19] <mru> peloverde: what's the best way to test aac anyway? [20:54:39] <mru> since it's not quite exact across machines [20:54:45] <peloverde> snr/off-by-one [20:55:29] <siretart> peloverde: I don't remember who exactly proposed that, but I'd like to hear your opinion on backporting the HE-AAC2 decoder to 0.6. do you think it's feasible? [20:55:44] <Honoome> Dark_Shikari: /dev/stdout is a symlink to /proc/self/fd/1 [20:55:49] <Dark_Shikari> Honoome: aha. [20:55:52] <Honoome> so it does not always work as intended, obviously :P [20:55:53] <Dark_Shikari> is that supposed to be portable? [20:55:55] <Dark_Shikari> i.e. is it posix? [20:56:05] <Honoome> probably it is posix, portable, I wouldn't bet on it [20:56:33] <Honoome> I think freebsd has it (I should check on the vm to be sure) but there it's implemented differently, obviously [20:56:41] <Honoome> given that there is no /proc there [20:56:50] <Honoome> [no _mandatory_ /proc that is] [20:57:01] <mru> /dev/stdout is not required [20:57:07] <mru> nor is /proc [20:57:13] <Dark_Shikari> well proc is a given [20:57:16] <Dark_Shikari> just was wondering about dev. [20:58:00] <CIA-99> ffmpeg: rbultje * r23721 /trunk/libavcodec/ (h264pred.c mathops.h): Rename PACK4x8() to PACK4UINT8(). [20:58:00] <CIA-99> ffmpeg: rbultje * r23722 /trunk/libavcodec/h264pred.c: Reindent after r23721. [20:58:20] <mru> http://www.opengroup.org/onlinepubs/000095399/basedefs/xbd_chap10.html [20:59:25] <peloverde> siretart, I suppose it's feasible [20:59:30] <mru> BBB: in future, please don't immediately rename stuff just because someone asks you to [21:00:11] <peloverde> siretart, I would start with the two bugfixes for LC/HEv1 first [21:01:26] <peloverde> What are the filenames on the 0.6 branch? did it pick up the aac.c->aacdec.c transition? [21:02:10] <Dark_Shikari> bah, what's the option to make ffmpeg not print the progress info? [21:02:15] <mru> -v 0 [21:02:20] <mru> or less [21:02:23] <Dark_Shikari> will it still print start_timer stuff? [21:02:29] <Dark_Shikari> ok, good, it does. [21:02:44] <siretart> peloverde: no, it's still 'aac.c' [21:04:17] <peloverde> There shouldn't be issues backporting ps if you don't mind that any third part patches against AAC will be clobbered [21:04:51] <siretart> 'third part patches'? [21:05:01] <mru> first part, second part, third part [21:05:02] <peloverde> sorry "third party" [21:05:19] <siretart> I see [21:08:27] <Honoome> peloverde: I guess you could have "third hunky" since we talk about patches :D [21:09:11] <mru> junky [21:09:19] <mru> junkie [21:09:43] <mru> which is pretty close to third party actually [21:12:24] <siretart> peloverde: what are the revisions for the HEv1 bugfixes? [21:12:32] <mru> http://article.gmane.org/gmane.comp.video.videolan.vlc.general/17813 [21:13:27] <peloverde> siretart: r23660, r23673 [21:13:31] <CIA-99> ffmpeg: cehoyos * r23723 /trunk/libavcodec/mpegvideo_common.h: [21:13:31] <CIA-99> ffmpeg: Use right-shift instead of division by two. [21:13:31] <CIA-99> ffmpeg: Patch by Dark Shikari [21:14:16] <Dark_Shikari> <3 michael [21:14:17] <Dark_Shikari> the shocking effectivity of the dc idct is likely due to the shocking low [21:14:18] <Dark_Shikari> quality of flvs ;) [21:14:20] <Dark_Shikari> hah [21:14:40] <Honoome> the compiler is so bad that it doesn't replace /2 with >>1? o_O [21:14:52] <mru> Honoome: it can't for signed types [21:14:57] <Dark_Shikari> what mru said [21:15:24] <Honoome> d'oh! [21:15:46] <Honoome> sign-extension, right [21:15:56] <mru> no [21:16:10] <peloverde> consider -1/2 [21:16:12] <mru> -1/2 == 0 [21:16:18] <mru> -1 >> 1 == -1 [21:17:01] <Honoome> hm.. all in all it's actually making me understand why adding negative values to enum can throw gcc off [21:17:58] <siretart> peloverde: do'h, now I see your nominations on -cvslog. too much backlog :/ [21:29:12] <BBB> mru: isn't MN maint of mathops.h? [21:29:18] <BBB> mru: but fair enough [21:29:25] <mru> he thinks he is [21:29:28] <mru> in practice I am [21:30:50] <BBB> well that's complicated [21:30:56] <BBB> can you two fight out who maintains what? [21:31:18] <mru> no [21:31:23] <BBB> I'll grab popcorn and be amused at the sideline [21:32:51] <peloverde> git blame mathops.h | wc -l = 158 [21:33:01] <peloverde> git blame -w mathops.h | grep mru | wc -l = 60 [21:33:12] <peloverde> git blame -w mathops.h | grep michael | wc -l = 3 [21:33:30] <mru> see what I mean [21:35:42] <mru> hmm, someone broke loads of things on fate [21:36:12] <mru> the ppc is just misconfigured [21:36:36] <mru> on ia64 our old friend the gprel22 is back [21:37:10] <mru> and on openbsd gcc segfaults [21:37:49] <mru> that may have been a fluke though [21:37:55] <mru> it's not at latest rev [21:38:56] <peloverde> why does gcc-4.3 on AVR32 have so many failures? [21:39:06] <michaedw> I think I have root-caused problems with ffmpeg playback of .h264 files (Annex B bytestreams) [21:39:31] <michaedw> it appears that the file is read in 1K chunks [21:39:40] <michaedw> and that the decode_frame function does not deal gracefully with split NAL units [21:39:52] <mru> you need to use the parser [21:40:38] <michaedw> ok; --enable-parser=h264? [21:40:50] <michaedw> (during configure) [21:40:56] <mru> please take this to #ffmpeg [21:41:01] <michaedw> ok, thanks [21:41:17] <michaedw> (Dark_Shikari suggested #ffmpeg-devel :-) [21:41:46] <mru> whom do you trust more? [21:42:23] <Dark_Shikari> I assumed you meant an ffmpeg bug. [21:42:25] <Dark_Shikari> Not a bug in your code. [21:43:38] <Dark_Shikari> BBB: ping [21:43:55] <Dark_Shikari> oh nvm, got it, Im' stupid. [21:44:58] <michaedw> well, there have been a number of unresolved bug reports, and the behavior of ffmpeg is less than helpful; it attempts to decode but fails with many messages like: [21:45:00] <michaedw> [h264 @ 0x914c620]error while decoding MB 0 37, bytestream (-4) [21:45:00] <michaedw> [h264 @ 0x914c620]concealing 2209 DC, 2209 AC, 2209 MV errors [21:45:30] <BBB> Dark_Shikari: pong [21:45:41] <BBB> oh, I guess n/m is for me [21:46:03] <Dark_Shikari> yeah [21:46:08] <michaedw> I don't know whether you would consider that a "bug" if there's a command-line flag that causes the file to be broken in saner chunks, but it's not the best user experience [21:46:09] <mru> Dark_Shikari: correct protocol is "nick: unping" [21:46:24] <Dark_Shikari> lol [21:46:25] <mru> michaedw: please go to #ffmpeg [21:46:32] <Dark_Shikari> mru: I don't think anyone will know there either =p [21:46:37] <michaedw> ok, thx [21:46:48] <mru> it's not an ffmpeg dev question [21:47:28] <michaedw> I neglected to say that I intended to submit a patch to fix it, and was just looking for advice on where to insert the sanity check [21:47:41] <michaedw> but I can ask that on #ffmpeg too [21:47:55] <mru> you haven't even shown it to be a bug yet [21:48:20] <mru> /redirect michaedw #ffmpeg [21:48:29] <mru> damn, no such command [21:48:31] <Dark_Shikari> michaedw: submit a bug report [21:48:38] <peloverde> Speaking of bugs roundup is looking pretty gruesome these days [21:48:39] <mru> I don't think there's a bug [21:48:40] <Dark_Shikari> there's a guide on the site [21:48:45] <Dark_Shikari> mru: well then it's his job to demonstrate it is [21:49:05] <mru> he's somehow not using the parser [21:50:28] <Honoome> peloverde: complain to lu_zero :P [21:50:37] <peloverde> That's not what I mean [21:51:25] <Honoome> do it anyway! :P [21:51:25] <peloverde> We are opening new bugs far faster than we are closing old ones, we need to do some bug squashing [21:51:38] <mru> let's do it the gcc way [21:51:45] <mru> just close them [21:52:06] <saintdev> oh, i thought it was ignore the bug for 3 years, then close it invalid [21:52:39] <mru> release coming up, let's close some bugs so it doesn't look so bad [21:52:54] <Honoome> saintdev: or keep it open after five years and a number of minor versions [21:53:20] <saintdev> Honoome: well that doesn't cut down on the number of open bugs... [21:53:30] <Honoome> that's still what they do [21:53:41] <saintdev> true [22:00:03] * Honoome is on the cc of a precompiled headers bug [22:00:13] <Honoome> which I hit when I was developing an UO server emulator [22:00:25] <Honoome> that was years before I joined Gentoo... [22:00:27] * mru doesn't use c++ so has no need for pch [22:00:44] <Honoome> mru: I was young and inexperienced [22:00:57] * mru has been there too [22:01:02] <mru> not c++ though [22:01:07] <mru> but other silly things [22:07:25] <BBB> Dark_Shikari: the filter functions are high in my list, so if you want to do something fun and a little more complex, work on sse2/ssse3/mmx filter functions [22:07:40] <BBB> (high in my list = take a lot of cpu time) [22:08:03] <michaedw> mru: configuring with --enable-parser=h264 solved it, with no change to the ffmpeg command line; thanks! Sorry for the noise. [22:08:15] <Dark_Shikari> BBB: I'm doing mc right now [22:08:21] <Dark_Shikari> I just rewrote mmx idct_dc [22:08:23] <Dark_Shikari> and wrote an sse4 version [22:08:29] <Dark_Shikari> you do the loopfilter [22:11:46] <Honoome> ohhh sse4, shiny :) [22:11:52] <Honoome> 4.1, 4.2, 4a or 4b? :P [22:12:34] <Dark_Shikari> it's mostly just a function that would be slower on any cpu that doens't have sse4 [22:12:39] <Dark_Shikari> regardless of the instructions actually used [22:12:44] <Dark_Shikari> and 2 clocks faster with [22:12:47] <Dark_Shikari> on i7 [22:12:52] <mru> is there any extension i7 940 doesn't have? [22:13:11] <Honoome> ah, well then I can be grateful for the laptop ;) although my workstation only has 4a [22:13:16] <michaedw> btw, --enable-gprof appears to break get_cabac_noinline() in libavcodec/cabac.h [22:13:37] <mru> it would [22:13:59] <mru> unable to find a register in class GENERAL_REGS? [22:14:02] <michaedw> yes [22:14:24] <mru> don't use that flag [22:14:28] <mru> we should probably remove it [22:14:32] <mru> gprof is useless [22:16:57] <michaedw> ok; thanks. I was thinking of measuring the cabac performance on Pentium-M cores and tuning (if there's room to tune). Would that be of value? [22:17:12] <Dark_Shikari> cabac is pretty heavily tuned [22:17:14] <mru> gprof is useless for profiling [22:17:17] <Dark_Shikari> and yes, gprof is utterly useless [22:17:19] <Dark_Shikari> use oprofile [22:17:32] <mru> gprof can give a call graph [22:17:35] <mru> if that were ever useful [22:17:37] <Dark_Shikari> the only tuning possible imo is probably algorithmic changes, maybe merging some of the horrible hacks x264 added recently [22:17:45] <Dark_Shikari> s/x264 added/I added to x264 [22:17:52] <mru> there's a difference? [22:18:01] <michaedw> :) I thought the table lookup was a good change [22:19:07] <Dark_Shikari> which table lookup [22:19:12] <Dark_Shikari> that's not very specific [22:19:14] <Dark_Shikari> =p [22:19:34] <michaedw> and I figured it was already pretty well tuned, but there may be variant tunings appropriate for Pentium M (which is still relevant in some embedded devices) [22:20:00] <mru> my old laptop is p-m [22:20:09] <Dark_Shikari> p-m isn't very interesting except for having an awful sse unit [22:20:09] <twnqx> post-mortem? :X [22:20:17] <twnqx> oh, pentiumm [22:20:27] <mru> the wifi is half-dead [22:20:53] <mru> the new i5 is so much nicer [22:21:02] <twnqx> i have a wifi-card from intel that confused intel engineers... because it doesn't work [22:21:06] <Honoome> appletv iirc is a pentium-m [22:23:01] <BBB> Dark_Shikari: I'll apply if there's a little more review, mru jsut called me trigger-happy [22:23:02] <michaedw> Dark_Shikari: your blog post on "Finite state machines and CABAC", which is of course not recent, but that's the kind of optimization opportunity I thought there might be more of [22:23:03] <BBB> which is true :-p [22:24:31] <BBB> Dark_Shikari: and I'll do the loop filter once MC has some decent ops in [22:24:43] <michaedw> also, L2 cache is at a premium, -Os sometimes performs better than -O2 (at least with older gcc) [22:25:13] <Dark_Shikari> michaedw: grep x264 log for recent cabac changes [22:25:18] <Dark_Shikari> and I think you mean "L1I" not "L2" [22:25:24] <Dark_Shikari> and that's true of all intel chips [22:25:37] <mru> what is L1 at nowadays? [22:25:46] <Dark_Shikari> 32k [22:25:48] <Dark_Shikari> same as always [22:25:49] <Dark_Shikari> 32k/32k [22:25:56] <mru> why is that? [22:26:10] <mru> even tiny embedded arm9 chips have 32k [22:26:21] <Dark_Shikari> latency [22:26:31] <Dark_Shikari> intel would have to increase L1 latency in their arch to increase the cache size [22:26:34] <michaedw> true in general of Intel x86en, extra-true of P-M (from what I've been seeing on this device) [22:26:37] <Dark_Shikari> the size of the chip doesn't matter [22:26:53] <Dark_Shikari> the biggest chip in the world is still bottlenecked by how much L1 you can fit near the alu [22:27:15] <astrange> cabac tuning: remove the memory load/stores from the x86 asm so subsequent cabac calls can reuse them from registers [22:27:44] <Dark_Shikari> BBB: ping [22:27:46] <BBB> pong [22:27:49] <mru> cortex-a9 can be configured with 64k/64k L1 [22:27:52] <Dark_Shikari> Explain the ordering of your taps [22:27:55] <astrange> tuning 2: delete the 3-4 "bit &= 1;" and change it to "return bit & 1;" at the end because compilers can't compine and/test/branch to and/branch across if statements [22:27:58] <Dark_Shikari> why does doing the last tap first magically avoid overflows? [22:28:06] <astrange> doubt there's much more than that [22:28:24] <BBB> Dark_Shikari: first the negatives, then the positives [22:28:28] <Dark_Shikari> But they're not in that order. [22:28:31] <BBB> Dark_Shikari: the negatives never overflow, since they're small [22:28:33] <michaedw> also, I am thinking of implementing a data-partitioning post-processor for H.264 streams, for use with unequal error partitioning [22:28:39] <BBB> Dark_Shikari: ? [22:28:44] <michaedw> er, error protection [22:28:46] <Dark_Shikari> some of the time the negatives are last [22:28:48] <Dark_Shikari> some of the tmie they're first [22:28:50] <Dark_Shikari> depending on the position [22:28:54] <BBB> huh? [22:29:07] <BBB> are you looking at the correct table? [22:29:14] <Dark_Shikari> -6,123,12,-1 [22:29:17] <BBB> the negatives are always in the same position [22:29:24] <BBB> in fourtap, negatives are [0] and [3] [22:29:25] <Dark_Shikari> oh, I see what you mean [22:29:28] <Dark_Shikari> they're always on the outside [22:29:29] <BBB> in sixtap, they're [1] and [4] [22:29:32] <Dark_Shikari> the makes the code really fucking annoying [22:29:35] <michaedw> astrange: thanks, those sound like good suggestions, I'll measure the impact [22:29:35] <BBB> yes [22:29:44] <BBB> I didn't say my code was pretty, just that it worked [22:29:46] <Dark_Shikari> ... are they always negative? [22:29:48] <BBB> yes [22:29:54] <BBB> and the others are always positive [22:30:43] <mru> of course the negatives are there [22:30:47] <mru> it's an interpolation filter [22:31:01] <astrange> tuning 3 (for x86-64/arm/other non-asm platforms): port the use of cmov back to the C code and hope compilers do it right [22:31:12] <astrange> or write cabac asm for arm [22:31:20] <Dark_Shikari> oh, I got an idea. [22:31:20] <BBB> ah, a review [22:31:29] <BBB> MN also wants me to remove the splats [22:31:30] <BBB> damn [22:31:34] <BBB> maybe tomorrow [22:31:42] * BBB should seriously do work that he's being paid for now [22:32:21] <Dark_Shikari> check my email [22:34:37] <michaedw> astrange: I'm more likely to take the port-back-to-C route and see what I need to do to the C to get good asm. which compiler do you consider most relevant for ARM -- gcc 4.5? llvm-gcc? and which tunings interest you most -- cortex-a9? hard-float ABI? NEON? [22:34:40] <Honoome> hm [22:34:59] <Honoome> astrange just reminded me that I either fiddle with the ebuild or I make sure ffmpeg's configure understand "barcelona" [22:35:00] <mru> float is irrelevant to cabac [22:35:14] <mru> Honoome: send patch [22:35:28] <Honoome> mru: yeah yeah I know, it just escaped my mind for... a bit [22:35:34] <mru> michaedw: gcc 4.3 and 4.5 are relevant for arm [22:35:39] <michaedw> mru: yes, but NEON may not be, and the choice of float ABI affects how parameters are passed [22:35:58] <mru> you won't be able to use neon for cabac decode [22:38:02] <mru> and either way, both abis should be supported [22:38:37] <michaedw> mru: NEON bitwise operations may be worth experimenting with; CodeSourcery has been working on reducing the friction. http://old.nabble.com/-PATCH,-ARM-%3A-rewrite-NEON-bitwise-operations-withou... [22:38:52] <mru> bwaahahaha [22:38:55] <Dark_Shikari> >20 cycle latency [22:38:58] <Dark_Shikari> >experiment with neon bitwise ops [22:39:01] <Dark_Shikari> >20 cycle latency [22:39:02] <Dark_Shikari> >20 cycle latency] [22:39:05] <Dark_Shikari> >20 cycle latency [22:39:18] <michaedw> to move data from integer to NEON or vice versa, yes [22:39:29] <mru> only from neon to arm [22:39:31] <mru> arm to neon is fast [22:39:43] <mru> it's a result of the pipeline organisation [22:40:11] <mru> anyway [22:40:21] <mru> rule #1: gcc CANNOT use neon _AT ALL_ [22:40:30] <michaedw> it puts a premium on replacing conditionals with arithmetic [22:40:31] <mru> do not even let it try [22:41:17] <michaedw> gcc isn't yet good at vectorizing pre-existing code, true [22:41:27] <mru> that's an understatement [22:41:45] <mru> you're lucky if the code even does the right thing [22:42:01] <mru> let alone faster [22:42:04] <Dark_Shikari> +10000 [22:42:07] <mru> there's a good reason we disabled it in ffmpeg [22:42:08] <michaedw> but it does a good job on C code that's written specifically to be vectorized [22:42:10] <Dark_Shikari> we're committing fno-tree-vectorize to x264 in a few days [22:42:13] <mru> bwahahahaah [22:42:18] <Dark_Shikari> because on C code that was written "specifically to be vectorized" [22:42:21] <Dark_Shikari> it CRASHED X264 [22:42:25] <Dark_Shikari> because it used aligned loads improperly [22:42:26] <mru> as I said [22:42:38] <Dark_Shikari> and all because I converted a memset to a loop [22:42:44] <Dark_Shikari> I had the gall to write C code [22:42:51] <Honoome> mru: oh well it seems someone else already handled that, ./configure --cpu=barcelona does not complain any longer ;) [22:43:24] <mru> patch still needd [22:43:26] <michaedw> sorry, should have mentioned that I cherry-picked loads of fixes from the CodeSourcery compiler [22:43:26] <mru> +e [22:43:31] <Honoome> mru: uhm? what for? [22:43:39] <mru> to set various things properly [22:43:59] <mru> what cpu is barcelona? [22:44:09] <mru> michaedw: codesourcery is just as bad as plain gcc at vectorising [22:44:11] <mru> if not worse [22:44:18] <michaedw> the FSF releases aren't as stable with aggressive ARM optimizations (especially NEON) as they might be [22:44:24] <Honoome> mru: barcelona is amdfam10 [22:44:30] <michaedw> probably worse at vectorizing general code [22:44:43] <mru> Honoome: then add barcelona to the relevant line in configure [22:44:53] <mru> just search for amdfam10 [22:45:20] <michaedw> but their changelog is a good guide to which changes to cherry-pick from bugs and mailing list archives [22:45:28] <mru> michaedw: compilers are a joke [22:45:34] <mru> gcc-based ones doubly so [22:46:09] <michaedw> they're just tools [22:46:18] <michaedw> not always the right tool for the job [22:46:24] <mru> they're tools in both senses [22:46:36] <Honoome> mru: it seems to work already o_O that line only enables cmov/fastcmov and they are both enabled already [22:46:44] <mru> if you want anything resembling performance, you have no choice but writing asm yourself [22:46:58] <mru> Honoome: ah right, it's amd64 [22:47:14] <Dark_Shikari> michaedw: they just aren't as stable period [22:47:17] <Dark_Shikari> that vectorization crash? [22:47:18] <Honoome> not even sure if gcc understands -march=barcelona in 32-bit [22:47:19] <Dark_Shikari> that was on x86t [22:47:20] <Dark_Shikari> *x6 [22:47:21] <Dark_Shikari> *x86 [22:47:31] <michaedw> mru: agreed. but I prefer to write the asm, then find a way to prod the compiler into generating something close to the same asm from C. [22:47:47] <mru> Honoome: it does [22:48:00] <Honoome> mru: then will double check and see to patch that in case [22:48:07] <mru> michaedw: and then have the next release of the compiler fuck up all over again [22:48:08] <michaedw> reduces the risk of writing code that is pessimal on someone else's chip [22:48:11] <mru> no thanks [22:48:27] <Honoome> Dark_Shikari: -ftree-vectorize is _known_ to produce bad code on x86; it has a much *much* better history on x86-64 [22:48:46] <mru> we've seen orders-of-magnitude slowdowns there too [22:48:55] <michaedw> x86 is too register-poor to get much value out of it [22:48:56] <peloverde> -ftree-vectorize is gcc's audio encoders? [22:49:10] <mru> x86 has the same sse regs as -64 no? [22:49:28] <Honoome> mru: no doubt on the slowdowns, I'm referring to positively bad code (crashing code) though [22:49:33] <Dark_Shikari> mru: no, x86_64 has 16 of them [22:49:46] <mru> oh right [22:49:47] <michaedw> and generally needs to be combined with manual cache-bypassing load/store [22:49:53] <mru> 16x128bit? [22:49:55] <Dark_Shikari> yes [22:50:19] <mru> so can we just agree that compilers suck? [22:50:43] <Dark_Shikari> BBB: ugh. I have some code that's failing on only a few of the test cases (MC code) [22:50:48] <Dark_Shikari> but I'm pretty sure I got the overflow case right [22:50:53] <michaedw> mru: sure :-) [22:51:05] <Dark_Shikari> .... oh damn. I didn't [22:51:08] <Dark_Shikari> it's [1] and [4] [22:51:10] <Dark_Shikari> not [0] and [5] [22:51:23] <astrange> do you have the patch that made gcc produce crashing code? [22:52:07] <Dark_Shikari> astrange: the pixel_t patch did it [22:52:12] <Dark_Shikari> it's the pixel_memset function that crashes it [22:52:15] <Dark_Shikari> I don't know on what compilers [22:52:21] <Dark_Shikari> we got a bug report from s55 from handbrake [22:52:23] <Dark_Shikari> talk to the handbrake guys [22:52:28] <Dark_Shikari> it's on win32, iirc [22:52:43] <Dark_Shikari> I suspect it's another case of gcc not realizing what is and isn't aligned [22:52:57] <Honoome> mru: sent the patch [22:53:01] <michaedw> so this data-partitioning H.264 post-processor would need to decode the incoming stream as far as the CABAC expansion, then extract the residual blocks and re-CABAC them separately from the rest of the stream [22:53:53] <michaedw> that means 4 separate CABAC contexts, 1 for decode and 3 for encode [22:55:21] <CIA-99> ffmpeg: stefano * r23724 /trunk/libavformat/avformat.h: Fix date specification accepted by parse_date(). [22:55:24] <CIA-99> ffmpeg: stefano * r23725 /trunk/libavformat/avformat.h: Mention how "now" is interpreted in the parse_date() doxy. [22:55:25] <CIA-99> ffmpeg: stefano * r23726 /trunk/doc/ffmpeg-doc.texi: [22:55:25] <CIA-99> ffmpeg: Extend documentation for the ffmpeg -timestamp option. [22:55:25] <CIA-99> ffmpeg: '(' and ')' are used instead of '{' and '}' in the date specification [22:55:25] <CIA-99> ffmpeg: as the latter confound the texinfo interpreter. [22:55:26] <CIA-99> ffmpeg: stefano * r23727 /trunk/ffmpeg.c: [22:55:26] <CIA-99> ffmpeg: Rename rec_timestamp to recording_timestamp, for consistency with [22:55:26] <CIA-99> ffmpeg: recording_time. [22:55:44] <BBB> Dark_Shikari: yeah, for sixtp it's [1] and [4], fourtap is same as sxtap except that [0] and [5] are zero, so [1] in sixtp is [0] in fourtap, etc. [22:56:05] <Dark_Shikari> k, got it working [22:57:42] <Dark_Shikari> BBB: one protip [22:57:45] <Dark_Shikari> packuswb X, Y [22:57:48] <Dark_Shikari> where you don't intend to use the Y half [22:57:53] <Dark_Shikari> you can put ANYTHING there if you intend to movd afterwards. [22:57:56] <Dark_Shikari> including X [22:57:58] <Dark_Shikari> e.g. packuswb X, X [22:58:11] <BBB> I guess that makes sense [22:58:19] <Dark_Shikari> so if you don't have a zero reg [22:58:21] <Dark_Shikari> you can do Whatever You Want [22:58:38] <BBB> I remember adding a pxor for that somewhere :-p [22:58:44] <Dark_Shikari> yup [22:58:49] <Dark_Shikari> anyways, _almost_ done rewriting it [22:58:56] <Dark_Shikari> just a last few tweaks and then I'll give it to you [22:59:10] <BBB> I can just commit, then you commit on top [22:59:16] <BBB> increases your ohloh status :-p [22:59:28] <Dark_Shikari> ok [22:59:32] <Dark_Shikari> however [22:59:33] <Dark_Shikari> before you do that [22:59:36] <Dark_Shikari> I'd like you to see what I did [22:59:43] <BBB> ok [22:59:53] <BBB> send it up, or reply on-list so others can see it too :-p [22:59:56] <michaedw> has any particular profiling/tuning been done on the ffmpeg "data partitioning" code path, which has the same issue (3 CABAC contexts, in this case for decode)? [23:00:07] <Dark_Shikari> also, can I promote an ff_pw_X to xmm_reg if I need it for xmm? [23:00:12] <Dark_Shikari> (without breaking existing stuff)? [23:01:06] <BBB> that you need to ask others, I have no idea ;) [23:02:25] <Dark_Shikari> well whatever, I'll add one more instruction to avoid asking that question [23:02:28] <Dark_Shikari> also the answer is "no" [23:02:51] <BBB> I guess you tried and it broke? :) [23:03:02] <Dark_Shikari> yes [23:03:10] <Dark_Shikari> ok, finally, I think I'm ready [23:03:47] <Dark_Shikari> oh, I'm a moron. I had ffv2 locally committede. [23:05:54] <Dark_Shikari> BBB: see ffmpeg ml [23:06:07] <Dark_Shikari> I'd like you to understand every change I made [23:06:15] <Dark_Shikari> if it seems stupid say so [23:06:17] <Dark_Shikari> because it might be. [23:06:20] <Dark_Shikari> also I didn't bench any of my mc changes. [23:06:27] <Dark_Shikari> also the mc code is going to suck gigantic cocks on atom [23:07:39] <Dark_Shikari> I did bench the idct stuff though. it's faster. [23:08:03] <BBB> I'll bench it... probably have to do that tonight, wife is calling :-p [23:08:24] <BBB> if I have questions I'll bug you tonight or tomorrow, I'll look at it [23:10:00] <BBB> the filter expansions make sense... I did bench it and it didn't really make a speed difference (which is why I decreased them; I had them as your _h first), but I guess it doesn't make logical sense that it's not faster like this... [23:10:17] <Dark_Shikari> more importantly [23:10:21] <Dark_Shikari> it lets us do what I did in the V functions [23:10:31] <BBB> right, separating the V ones makes sense [23:10:47] <BBB> I was going to try that, but got busy putting the VP8 C decoder in svn instead ;) [23:11:15] <BBB> there's no changes int he rest of the h4 4x4 filter, is there? [23:11:27] <Dark_Shikari> h is the same yes [23:11:33] <Dark_Shikari> nothing major [23:11:37] <Dark_Shikari> V was rewritten entirely [23:11:44] <Dark_Shikari> well the main loop was [23:11:50] <BBB> h6 also looks similar [23:11:54] <BBB> let's see what you did to my v [23:11:54] <Dark_Shikari> yes [23:12:28] <Dark_Shikari> I suspect h can be further optimized, but I didn't spend much time on it [23:12:31] <Dark_Shikari> I just converted the opening part [23:12:33] <Dark_Shikari> like you said [23:13:38] <BBB> hm, so for v4, you free up regs by using [r4] instead of loading the filter in memory, that's smart, I guess [23:13:44] <CIA-99> ffmpeg: mru * r23728 /trunk/libavcodec/ (bfin/vp3_bfin.c h264idct.c vp3dsp.c vc1dsp.c): Improve some uses of ff_cropTbl with constant offset [23:13:45] <BBB> oh no you still use mm5 [23:13:49] <BBB> so same number of regs [23:14:03] <BBB> but you don't splat them, as you said earlier [23:14:12] <BBB> interesting, let's see how different that is [23:14:17] <Dark_Shikari> it reduced the number of moves [23:14:18] <BBB> then v6, my v6 was pretty horrible [23:14:35] <BBB> oh shit wife is calling [23:14:40] <BBB> ok, v6 will come tonight :p [23:16:08] <Dark_Shikari> night [23:17:29] <Honoome> f-ck [23:18:03] <mru> what's wrong? [23:19:02] <Honoome> I've been waiting two weeks for the specs of a job, I receive them, get back to hack at it... another dev introduced the use of bundler (it's a rails app) ... and now I'm spending two weeks just to get the thing working _again_ [23:19:06] <CIA-99> ffmpeg: mru * r23729 /trunk/ (configure libavcodec/Makefile libavcodec/beosthread.c): [23:19:06] <CIA-99> ffmpeg: Remove beosthreads support [23:19:06] <CIA-99> ffmpeg: Relevant BeOS variants support pthreads, so there is no need to [23:19:06] <CIA-99> ffmpeg: maintain the beos-native threads interface. [23:19:43] <Honoome> [because I don't trust installing the gems through rubygems... what I install is what I'm _sure_ works after testing the heck out of it] [23:19:49] <ohsix> btw to the /dev/stdout convo earlier; that _is_ a bashism (and there are other paths like /dev/tcp that are also handled in the shell), the real /dev/stdout is there to catch other shells more than anything else [23:21:08] <Honoome> ohsix: >/dev/stdout is a bashism, /dev/stdout as a file parameter shouldn't be touched by bash (but work by the fact that there is a /dev/stdout for compatibility with bash, at that point) [23:23:44] <mru> Honoome: guess why I refuse to work on anything web related [23:24:04] <Honoome> mru: oh I know... I was just in a bit of a pinch :/ [23:24:16] <Honoome> now I'm just trying to finish this task to drop out of the project [23:26:53] <CIA-99> ffmpeg: flameeyes * r23730 /trunk/configure: [23:26:53] <CIA-99> ffmpeg: Add barcelona to the list of cmov/fast_cmov compatible CPUs. [23:26:53] <CIA-99> ffmpeg: For GCC, barcelona is just an alias for amdfam10, so simply add it in [23:26:53] <CIA-99> ffmpeg: there. [23:27:27] <Dark_Shikari> can I make all the vp8 mc functions, global or not, have ff for consistency? [23:27:31] <Dark_Shikari> it makes all the macros cleaner [23:27:39] <Dark_Shikari> so that a macro doesn't have to know if the function it's calling is asm, or a C wrapper around more asm [23:27:41] <mru> of course [23:27:43] <Dark_Shikari> k [23:27:54] <mru> there are no rules for static symbols [23:28:02] <mru> except the usual c/posix ones [23:28:22] <mru> and it's polite to keep names reasonably descriptive [23:28:31] * mru glares at coreavc [23:29:54] <Dark_Shikari> moment of truth: sse mc regression time [23:29:59] <Dark_Shikari> *regression test [23:30:08] <Dark_Shikari> AND IT WORKS. [23:30:09] <Dark_Shikari> \o/ [23:30:20] <Dark_Shikari> I love the abstraction layer. [23:30:31] * Honoome glares at ivi_common.o [23:30:35] <Honoome> over 500k of .bss ?! [23:33:42] <Honoome> that's a grand total of 4MB of .bss for the whole ffmpeg build... poor poor cows [23:35:13] <mru> I keep telling kshishkov to use less .bss... [23:35:44] <michaedw> it looks like intra_gb_ptr is only used in ff_h264_decode_mb_cavlc(). Does that mean that ffmpeg's h.264 decoder doesn't handle the combination of CABAC and data partitioning? [23:35:57] <mru> hmm, is that maxim's file? [23:36:25] <ohsix> Honoome: ya, only mentioned it cuz it was said no bashisms were visible [23:36:44] <Honoome> mru: ivi_common.c? looks that way [23:37:16] <michaedw> sorry, that should have gone to #ffmpeg [23:37:56] <Kovensky> <Honoome> that's a grand total of 4MB of .bss for the whole ffmpeg build... poor poor cows <-- cows? o_O [23:38:03] <mru> copy-on-write [23:38:04] <Honoome> Copy-on-Writes [23:38:08] <Kovensky> lol [23:38:13] * Kovensky facepalms [23:38:44] <mru> there's also the theory that .bss stands for bull-shit segment [23:39:02] <mru> it kind of ties in [23:40:00] <spaam> haha .) [23:40:20] <ohsix> wasn't it some ancient grandfathered assembler thing [23:43:43] <mru> Honoome: see r21977 [23:43:56] <mru> that file's .bss was even bigger before [23:44:00] <mru> due to a silly typo [23:44:41] <Honoome> gha [23:46:15] <michaedw> My employer might be interested in sponsoring some work on ffmpeg to support experiments with data partitioning and unequal error protection. What would be an appropriate channel to explore that? [23:48:22] <mru> Dark_Shikari or michael [23:49:33] * kierank wonders why michaedw's employer would be interested in such things considering their vast purchase [23:50:04] <mru> what did they buy? [23:50:09] <kierank> tandberg [23:50:15] <michaedw> interop is good [23:50:22] <kierank> LOL [23:51:28] <mru> michaedw: which part do you work in? [23:51:32] <michaedw> and hey, it's a big company, and different efforts move at different sppeds [23:51:51] <michaedw> it's telepresence-related [23:52:35] <michaedw> (telepresence. that has to be the silliest marketing coinage in this area.) [23:53:19] <kierank> the fact that is in all recent michael bay films is even sillier [23:54:23] <michaedw> getting the end of the dinosaur that operates the eyes to talk to the end that operates the tail can be ... slow. [23:55:24] <michaedw> and the end that my eyes are connected to thinks that we ought to make an attempt to measure things before we go merging apples and rutabagas [23:56:21] <kierank> get some more "human network" adverts please [23:56:27] <kierank> with more baba o'reilly [23:56:30] <kierank> those rocked [23:57:05] <michaedw> so if anyone would be interested in measuring what's achievable within the existing, under-implemented corners of the H.264 spec, we might have common interests :-)