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

[irc at mansr.com]

[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-without-UNSPECs-td28955063.html
[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 :-)