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

[irc at mansr.com]

[00:08:04] <peloverde> I'm not hearing it
[00:08:39] <saintdev> ./ffmpeg -y -i insane.flac -strict experimental -acodec aac -ab 80k -f mp4 ~/test1.mp4
[00:08:59] <saintdev> sounds like one of those kids toy spring microphones
[00:09:25] <peloverde> I was only testing at 256k because that's where the carl eugene complained
[00:09:39] <saintdev> oh
[00:10:27] <saintdev> well there's definitely a difference at 80k, with the hack sounding more similar to 3gpp
[00:11:44] <saintdev> yeah, seems to be better at 256k than it was
[00:12:23] <peloverde> Now I'm kind of curios why al17_44 is better at 128k than at 256k
[00:24:33] <peloverde> saintdev:  Does it sound better to you with "memset(cpe->ms_mask, 0, sizeof(cpe->ms_mask)); return;" at the top of search_for_ms()?
[00:26:36] <saintdev> no
[00:28:11] <peloverde> hmm, it makes al17 better
[00:30:00] <peloverde> Is there a way to tell svn to commit again with the same message in the case of a timeout
[00:32:05] <CIA-11> ffmpeg: alexc * r25001 /trunk/libavcodec/aacenc.c:
[00:32:05] <CIA-11> ffmpeg: aacenc: Don't set s->cur_channel before apply_window_and_mdct().
[00:32:05] <CIA-11> ffmpeg: In general s->cur_channel should be phased out.
[00:32:08] <peloverde> ^That took 7 tries :(
[00:32:15] <saintdev> :/
[00:34:38] <peloverde> I've had about 75% packet loss all day, makes the internet suck
[00:34:43] <CIA-11> ffmpeg: alexc * r25002 /trunk/libavcodec/aacenc.c: aacenc: Remove an unused variable from adjust_frame_information().
[01:04:06] <astrange> http://maxkle.in/a-chinese-villager-who-sells-more-software-daily-than-you-do/
[01:04:41] <Dark_Shikari> So that's the guy making the $20 GPL-violating shareware apps.
[01:08:18] <saintdev> lol
[01:08:59] <saintdev> somebody actually found him o.O
[01:18:51] <Compn> thats a pretty terrible article
[01:21:59] <drv> just some random blogger (with poor editing skills)
[01:59:45] <Compn> BBB : heres one that doesnt work in ffmpeg/mplayer >> http://174.37.61.90/b4umovies-www-desilive-tv
[01:59:57] <Compn> mms, rtsp, http give diff results too
[06:45:24] <KotH> salve
[06:46:00] <xxthink> the timestamp in flv format must be in the ascending order?
[06:51:24] <xxthink> ?
[06:52:41] <av500> what does the spec say?
[06:53:02] <xxthink> it doesn't methion in the spec
[06:53:19] <xxthink> methion->mention
[06:54:38] <xxthink> http://pastebin.com/9jzB6aWh
[06:54:44] <xxthink> this is what the spec says
[06:55:39] <funman> it depends if the current time is increasing or decreasing then?
[06:56:24] <saintdev> so if you're in a time machine, they can be in descending order?
[06:57:28] <xxthink> If a video tags with PTS=600 can be put in the flv file behind the video tag with PTS=1000
[06:57:44] <xxthink> Can this flv file played correctly by flash player
[07:01:12] <funman> http://www.smbc-comics.com/ <- can help detecting time direction
[07:02:50] <saintdev> funman: how about we just ask the doctor?
[07:06:53] <av500> xxthink: have you tried rule #3?
[07:07:26] <xxthink> av500: sorry. what does rule #3 mean?
[07:07:31] <av500> try it out
[07:07:40] <xxthink> how to try
[07:07:46] <xxthink> I can't understand
[07:08:14] <av500> if you cannot create a file with PTS=1000 before PTS=600, then why do you bother?
[07:08:23] <av500> if you can, you can try to play it
[07:08:24] <cartman> mru: ping
[07:08:54] <xxthink> av500: i c
[07:09:13] <xxthink> now I'm adjusting the tags in a flv file
[07:09:24] <xxthink> to test whethe the flash can play it
[07:15:37] <CIA-11> ffmpeg: bindhammer * r25003 /trunk/libavcodec/a64multienc.c: Checking return values of av_malloc(z) and report an error in case.
[07:15:38] <CIA-11> ffmpeg: bindhammer * r25004 /trunk/libavformat/a64.c: Solving memory leak and initialization problem with prev_pkt / pkt.
[07:17:16] <cartman> does anyone run fate?
[07:17:42] <spaam> i guess some ppl do it
[07:17:53] <cartman> I am having a problem with it
[07:18:08] <cartman> fate.sh fate.config doesn't seem to produce test data
[07:18:13] <cartman> hence diff shows errors
[07:18:25] <cartman> wondering if its a config problem
[07:19:28] <cartman> uh guess found the problem, nm
[07:19:42] <spaam> what was it ? :)
[07:19:55] <cartman> fate-suite/fate-suite double path
[07:19:58] <cartman> damn rsync :)
[07:27:13] <cartman> nice
[07:27:14] <cartman> works :D
[07:27:26] <cartman> how to make sense out of this report thing though :D
[07:29:42] <spaam> cant be that hard or do you want some fancy power point presentation for it? :)
[07:32:38] <cartman> spaam: well it has some numbers in it like a sha sum something
[07:32:42] <cartman> and test name
[07:32:58] <cartman> zmbv-8bit:0::RkZtcGVnIHZlcnNpb24gU1ZOLXIyNTAwNCwgQ29weXJpZ2h0IChjKS....
[07:33:02] <cartman> what would this mean? :D
[07:34:40] <spaam> ehm.. dunno :)
[07:50:38] <kshishkov> spaam: hej från Malmö
[07:50:57] <av500> hello Malmö
[07:51:17] <spaam> kshishkov: im going to move to malmö before new year;D
[07:51:26] <kshishkov> good for you
[07:51:32] * superdump waves towards the south-west
[07:51:40] <kshishkov> I'm going to move out of it in few days
[07:51:47] <spaam> hehe :)
[07:51:56] <spaam> what are you doing in malmö? :)
[07:52:01] <kshishkov> superdump: wave more carefully, you may hit Reimar or pJok
[07:52:16] <superdump> :)
[07:52:19] <av500> spaam: drinking trocadero
[07:52:22] <kshishkov> spaam: the same thing I did in Luleå - sightseeing
[07:52:27] <av500> and eating fish gone bad
[07:52:30] <kshishkov> av500: yes, did that
[07:52:45] <av500> good for you
[07:52:54] <kshishkov> av500: "fish gone bad" sounds like Copenhagen
[07:53:12] * av500 did not find Trocadero in IKEA
[07:53:16] <spaam> av500: haha :D
[07:53:44] <kshishkov> av500: probably you won't find surströmming there as well
[07:53:58] <av500> no, they want to keep customers coming back
[07:54:27] <kshishkov> depends on what kind of customers you like
[07:54:29] <spaam> kshishkov: nice :)
[07:59:23] <superdump> av500: in stockholm i found trocadero in ICA, Coop and a pertrol station
[07:59:25] <superdump> -r
[07:59:44] <av500> superdump: IKEA is closer :)
[07:59:49] <kshishkov> superdump: I could find it virtually everywhere
[08:00:10] <superdump> kshishkov: i haven't looked virtually everywhere so i wouldn't know
[08:00:12] <superdump> :)
[08:00:38] <superdump> still, it's not _that_ interesting a drink
[08:00:45] <superdump> barely interesting at all
[08:00:49] <kshishkov> well, all those small stores/cafes/restaurants usually offer it
[08:01:21] <kshishkov> superdump: and you come from country with very famous food traditions
[08:05:56] * KotH doesnt think that .se has faamous food traditions
[08:06:18] <KotH> unless you call selling tomatos in slices a famous tradition
[08:07:40] <superdump> KotH: i come from england, but i think it was possibly sarcasm
[08:07:55] <superdump> although i know kshishkov likes simple food - meat, potatoes, vegetables
[08:07:57] <superdump> :)
[08:08:07] <KotH> oh.. right
[08:08:10] <kshishkov> superdump: yes, that's what British are definitely famous for
[08:08:18] <KotH> well.. .uk is famous for its food :)
[08:08:39] <kshishkov> superdump: cheese and fish (more than vegetables) and fruits
[08:08:43] * KotH lost a few kg in the 10d he was in london
[08:10:38] <superdump> because you refused to eat anything? because the chocolate was inedible? something else?
[08:12:05] <av500> KotH: lol at sliced tomatoes!
[08:39:08] <KotH> superdump: i ate.. quite a lot... but only in turkish, chinese and indian restaurants :)
[08:39:28] <KotH> superdump: and there was a quite distinct lack of good chocolate
[08:39:51] <spaam> KotH: do you need to eat chocolate every day?
[08:40:41] <cartman> any irssi user around?
[08:40:52] <thresh> o/
[08:41:09] <cartman> thresh: any way to disable user list showing up upon joining a channel ?
[08:41:09] <Dark_Shikari> \o
[08:41:18] <cartman> its distracting
[08:41:23] <Dark_Shikari> people join channels?
[08:41:25] <Dark_Shikari> that implies leaving
[08:42:07] <thresh> cartman: no idea
[08:42:16] <cartman> ok
[08:42:23] <thresh> i hide join/leaves etc from activity bar only
[08:42:39] <cartman> thresh: how?
[08:42:55] <thresh> /set activity_hide_level = parts joins quits nicks modes
[08:43:04] <av500>  /ok
[08:43:08] <thresh> you can even hide activity fully for channels
[08:43:15] <cartman> thresh: how do I make irssi save that? :)
[08:43:16] <thresh> activity_hide_targets
[08:43:20] <thresh> /save
[08:43:22] <thresh> :D
[08:43:24] <cartman> cheers :D
[08:43:50] <spaam> cartman: do you want to hide messages also? ;)
[08:44:00] <cartman> spaam: there are sometimes useful, no :D
[08:44:14] <cartman> suggest a good theme too and we are done, pretty please
[08:44:35] <spaam> im using fear2
[08:45:09] * cartman checks
[08:45:46] <cartman> hmmm
[08:46:13] * cartman tests
[08:46:22] <cartman> simple ;>
[08:52:24] <KotH> spaam: i dont have to, i just do it :)
[10:02:57] <KotH> cartman: running fate on a mail server... interesting
[10:03:09] <cartman> KotH: nope
[10:03:10] <cartman> well
[10:03:13] <cartman> reverse dns crap :D
[10:03:17] <cartman> ++windows admins here
[10:03:38] <cartman> waiting for mans to submit my results :)
[10:06:23] * cartman wonders if KotH can add his ssh pubkey to the fate server
[10:08:57] <KotH> if you give me a few minutes to hack the machine, sure
[10:09:10] <cartman> ;>
[10:09:17] <cartman> how did you see me knocking? :D
[10:09:39] <KotH> it's my job to know these things ;)
[10:10:42] <cartman> guess I wait for mans ;)
[10:16:47] <KotH> greetings master of the black holes!
[10:17:59] <Rathann|work> \o/
[10:18:04] <Rathann|work> salut!
[11:12:18] <CIA-11> ffmpeg: vitor * r25005 /trunk/tests/ (ref/fate/dxa-scummvm fate2.mak): Add FATE test for ScummVM DXA flavor
[11:14:05] <CIA-11> ffmpeg: vitor * r25006 /trunk/tests/ (ref/fate/mjpegb fate2.mak): Add Apple MJPEG-B decoder FATE test
[11:15:05] <CIA-11> ffmpeg: vitor * r25007 /trunk/tests/fate2.mak: 10l, add flags forgotten in last commit
[11:15:55] <CIA-11> ffmpeg: vitor * r25008 /trunk/tests/ (ref/fate/rv30 fate2.mak): Add RealVideo 3 FATE test
[11:47:21] <cartman> mru: I got Pseudo-terminal will not be allocated because stdin is not a terminal. before fate.sh exit
[11:47:27] <cartman> did my report made it to the server?
[11:48:01] <thresh> ssh -t maybe?
[11:48:19] <mru> cartman: looks like it made it
[11:48:29] <mru> it's listing a darwin/clang config now at least
[11:48:36] <cartman> mru: neato
[11:48:42] <cartman> let me refresh web interface
[11:49:00] <cartman> guess its not updated yet, don't see it in fate.ffmpeg.org
[11:49:07] <mru> that's what I'm looking at
[11:49:14] <cartman> uh
[11:49:19] <mru> http://fate.ffmpeg.org/x86_64-apple-darwin10-clang
[11:49:21] <mru> that not you?
[11:49:51] <cartman> http://fate.ffmpeg.org/x86_64-apple-darwin10-clang
[11:49:52] <cartman> yey :D
[11:50:00] <cartman> yeah me
[11:50:42] <mru> maybe sorting by slot name isn't such a great idea when people seem to choose the names mostly randomly
[11:50:56] <cartman> yup
[11:51:17] <mru> and what's going on with ppc64?
[11:51:28] * cartman pets clang
[11:56:27] <BBB___> mru: http://bloggingthemonkey.blogspot.com/2010/08/ffpv8-neon-720p24.html somebody beat you to it
[11:57:10] <mru> I helped him
[11:57:11] <spaam> oh that blogpost again.
[11:57:26] <mru> I need to pick it up and fine-tune it
[11:58:02] <BBB___> spaam: what's wrong with it?
[11:58:07] <BBB___> mru: cool
[11:58:10] <BBB___> small world
[11:58:12] * BBB___ grumbles
[11:58:19] <spaam> BBB___: nothing. someone did post it before  :)
[11:58:25] <spaam> BBB___: in this channel :)
[11:58:29] <BBB___> I bet
[11:59:19] <spaam> the guy who have x86_64-macosx-gcc-4.0.1  . need to install yasm
[11:59:38] <mru> it's mike
[11:59:44] <mru> don't expect any reaction this year
[11:59:57] <mru> despite us having told him exactly what to do
[12:00:06] <mru> he's often slow with things like that
[12:01:06] <spaam> how hard can it be? :)
[12:01:28] <cartman> spaam: configure && make && make install , nothing else
[12:01:46] <BBB___> it's darwin
[12:01:51] <BBB___> sudo port install yasm
[12:01:52] <BBB___> but still
[12:02:09] <cartman> bleh ;)
[12:02:17] * cartman compiles with his bare hands
[12:03:36] <av500> cartman: not wearing gloves?
[12:03:59] <cartman> av500: bare :P
[12:03:59] * mru does not touch x86 opcodes without gloves
[12:13:51] <mru> cartman: http://www.fugly.com/media/IMAGES/Random/with-my-bear-hands.jpg
[12:14:14] <cartman> lol
[12:33:13] <CIA-11> ffmpeg: rbultje * r25009 /trunk/libavcodec/x86/Makefile: Fix vertical align.
[12:55:16] <BBB___> I'm reading the code a bit, and his criticism on vp8_mc_func is correct, I might want to revert it back so it's equal to h264_chroma_mc_func (i.e. no srcstride vs. deststride)
[12:55:26] <BBB___> but then I need to fix the x86 asm
[12:55:34] <BBB___> <lazy>
[12:55:36] <CIA-11> ffmpeg: diego * r25010 /trunk/doc/developer.texi: Mention that library micro version should be reset if minor version is bumped.
[12:55:36] <BBB___> what to do...
[12:57:29] <kierank_> who's this:http://www.reddit.com/user/marginallyselfemploy
[12:57:46] * kierank_ guesses _av500_
[12:57:53] <peloverde> It's me when I'm not ac-slater
[12:58:16] <cartman> heheh nice fiend kierank_
[13:02:13] <av500> kierank: yeah
[13:02:53] <av500> but the original article clearly shows that remote chinese village farmer benefit a lot from ffmpeg APIs being so complicated
[13:03:14] <av500> image we made it easy to use, they would have to go back to farming
[13:03:55] <cartman> lol
[13:04:04] <cartman> av500: all your fault
[13:04:20] <peloverde> Having familiaritity with some of his products by wrapper they mean GUI not API "wrapper"
[13:04:41] <cartman> yeah run ffmpeg.exe with options
[13:04:47] <cartman> easier than learning ffmpeg API, sadly
[13:06:56] <av500> peloverde: I know
[15:48:20] <Dark_Shikari> BBB: there is a very specific reason for the vp8 stuff
[15:48:38] <BBB> it was b/c we did the h+v filter in C instead of asm
[15:48:41] <Dark_Shikari> Wrong
[15:48:53] <Dark_Shikari> with h264, when I have an HV function, and I call H, I am _NOT_ doing the same thing as when I call H directly.
[15:48:58] <Dark_Shikari> In H.264, I want 16-bit output from H.
[15:49:03] <Dark_Shikari> Because hpel uses 16-bit intermediates.
[15:49:13] <Dark_Shikari> But when I call it directly for normal MC, I only want 8-bit output.
[15:49:18] <Dark_Shikari> Thus, the two Hs need to be different.
[15:49:26] <Dark_Shikari> But in VP8, both output 8-bit, in both cases.
[15:49:28] <Dark_Shikari> Therefore, they should be the same.
[15:49:38] <Dark_Shikari> The extra stride argument makes it easier to keep them the same.
[15:49:42] <Dark_Shikari> And thus reuse code and save code size.
[15:50:08] <BBB> I'm trying to make vp8_mc_func and h264_mc_func the same prototype so I can share code in the bilin funcs
[15:50:10] <BBB> call me crazy
[15:50:11] <BBB> just for fun
[15:50:17] <Dark_Shikari> No
[15:50:17] <BBB> I can always throw it out
[15:50:19] <Dark_Shikari> Don't
[15:50:24] <Dark_Shikari> there is a very good reason they don't
[15:50:33] <Dark_Shikari> the fact that one uses 16-bit intermediates and one uses 8-bit is sufficient to make that break.
[15:51:06] <BBB> 16-bit intermediates is ... chromamc or qpelmc?
[15:51:11] <Dark_Shikari> qpel
[15:51:13] <BBB> right
[15:51:17] <BBB> I'm talking chromamc
[15:51:21] <BBB> qpel is completely different
[15:51:22] <Dark_Shikari> oh, chroma MC
[15:51:32] <BBB> chromamc and bilin-vp8 are pretty much the same
[15:51:34] <Dark_Shikari> But chroma MC is luma MC.
[15:51:36] <BBB> I think they can share code
[15:51:48] <Dark_Shikari> And actually yes they are different
[15:51:54] <Dark_Shikari> in h264, there is no clamping in between H/V steps in chroma
[15:51:55] <BBB> really?
[15:52:01] <Dark_Shikari> because h264 is not fucking retarded
[15:52:05] <BBB> oh right
[15:52:06] <Dark_Shikari> this lack of clamping makes it very fast to implement
[15:52:11] <Dark_Shikari> in vp8, it's the same as luma
[15:52:28] <BBB> "h264 is not fucking retarded"
[15:52:33] <BBB> we should quote that somewhere
[15:52:40] <BBB> I think we discussed this before and you said the same thing
[15:52:41] <Dark_Shikari> yes, it's just mildly braindead.
[15:52:43] <BBB> I'm becoming alzheimerish
[15:52:51] <BBB> hm
[15:52:54] * BBB throws out idea
[15:53:31] <BBB> hm...
[15:53:43] * Dark_Shikari pokes BBB to work on xvp8
[15:54:00] <kierank__> one month till xiphcon...
[15:54:34] <Dark_Shikari> get the header writing working and I'll do the mb-level stuff
[15:54:57] <BBB> I somehow lost interest in xiphcon since you guys started calling it xiphcon
[15:55:00] <BBB> now the thing is
[15:55:07] <BBB> I _think_ I've been there, five years ago or so
[15:55:11] <BBB> did they have this five years ago?
[15:55:15] <Dark_Shikari> what does it have to do with xiphcon?
[15:55:19] <Dark_Shikari> this is about trollan'
[15:55:22] <BBB> I remember going to a con in NY 5 yrs ago
[15:55:28] <BBB> and it was boring as hell
[15:55:32] <Dark_Shikari> xiphcon is just a venue
[15:55:40] <BBB> trollin' is fun though
[15:55:44] <BBB> enough reason to do it
[15:55:44] <Dark_Shikari> then get moving =p
[16:20:07] <BBB> how do I get gdb to show me where I am in a function?
[16:20:16] <BBB> bt shows me the line number in the source file
[16:20:21] <Dark_Shikari> disass
[16:20:22] <BBB> I want the actual instruction
[16:20:28] <Dark_Shikari> disass $pc-30 $pc+30
[16:24:25] <Compn> instructions are in mplayer bugreports page
[16:24:26] <Compn> in the docs
[16:24:38] <mru> Dark_Shikari: some versions need a comma between the start and end
[17:09:27] <peloverde> It's interesting that it's far easier to fix where audacity abused private symbols than it is to handle the avutil-50 bump
[17:54:38] <CIA-11> ffmpeg: vitor * r25011 /trunk/tests/ (lavf-regression.sh ref/lavf/png): PNG image regression testing
[17:56:20] <CIA-11> ffmpeg: vitor * r25012 /trunk/tests/ (lavf-regression.sh ref/lavf/gif): Test decoding in fate-lavf-gif
[18:07:14] <BBB> is it just me or is gdb completely useless when combined with clang?
[18:16:48] <mru> s/combined with clang//
[18:28:30] <peloverde> siretart: How much do you care about having a binary audacity package that works with both 0.5 and 0.6?
[18:32:22] <siretart> peloverde: well, it would be really desireable to ensure that partial upgrades work
[18:32:58] <siretart> peloverde: would adding an av_match_ext symbol that just calls match_ext() to 0.5 help?
[18:34:08] <peloverde> I'm playing with something that is source compatible with both but only binary compatible with one at a time
[18:34:32] <peloverde> Trying to wrap the FIFO changes from libavutil50 is messy
[18:36:24] <BBB> mru: you're probably right, but that's still not entirely helpful
[18:36:37] <BBB> mru: it's like me making fun of gcc... at the end of the day I still have to use it :(
[18:36:42] <BBB> ffcc...
[18:36:45] <siretart> peloverde: ouch, I see. :-/
[18:36:51] <peloverde> siretart: but it is doable if it is really desirable
[18:37:02] <peloverde> I'm not sure how much they will like it upstream
[19:02:56] <BBB> Dark_Shikari: on x86-32, is r0m [rsp] or [rsp+4]?
[19:03:07] <BBB> or something else?
[19:14:01] <twnqx> r0m? rsp? on x86?
[19:15:08] <twnqx> BBB: with or without stack frame?
[19:15:30] <BBB> whatever yasm default is
[19:16:57] <twnqx> well, [esp] should be the return address
[19:17:23] <twnqx> just not sure if the first or the last argument is at [esp+4]
[19:20:13] <BBB> seems it's [esp+8], not [esp+4]
[19:20:19] <BBB> I wonder what's in [esp+4] then
[19:25:11] <roxfan> saved ebp, if prolog saves ir
[19:25:13] <roxfan> it
[19:26:29] <roxfan> or could be an implicit argument (e.g. this pointer or pointer to return structure)
[19:30:43] <BBB> pff....
[19:30:46] <BBB> that's one half fixed
[19:35:53] <Dark_Shikari> BBB: it depends on the stack offset
[20:02:09] <ramiro> where's the latest patch for LATM support?
[20:05:01] <BBB> oo it no longer crashes
[20:05:11] <BBB> now the output is still wrong, must be a typo somewhere
[20:08:29] <CIA-11> ffmpeg: vitor * r25013 /trunk/tests/ (ref/fate/sha fate2.mak): SHA fate test
[20:36:35] <BBB> Dark_Shikari: and how is r0mp different from r0m (and same for all r%dmp vs r%dm)
[20:43:00] <j0sh> .join #videoapi
[20:43:03] <j0sh> oops
[20:46:08] <BBB> can I use a single sourcetree to build two binaries/configs?
[20:46:15] <BBB> instead of having to duplicate all sources
[20:46:21] <peloverde> yes
[20:46:25] <peloverde> do out of tree builds
[20:46:27] <BBB> how?
[20:46:42] <BBB> I'm in svn/x86-32/ and want to run ../configure and build in .
[20:46:43] <BBB> how?
[20:46:54] <BBB> (sorry, I really don't know)
[20:47:02] <peloverde> mkdir ffmpeg-build1; cd ffmpeg-build1; ../ffmpeg/configure && make
[20:47:52] <mru> it's the only sane way to build stuff
[20:48:57] <BBB> awesome
[20:48:58] * BBB tries
[21:59:22] <saintdev> hmm, doesn't seem to be sensitive enough
[22:22:35] <peloverde> http://spectralhole.blogspot.com/2010/08/why-you-dont-want-to-build-you-chromium.html
[22:41:14] <spaam> why dont they send those patches upstream?
[22:45:03] <BBB> uh
[22:45:17] <BBB> Dark_Shikari: what kind of evil witchery is going on in x264_deblock_h_luma_intra_sse2() and the v one called by it?
[22:45:26] <BBB> Dark_Shikari: that stuff is so hideous that I just don't get it
[22:45:45] <BBB> it reads from negative rsp values, makes all kind of blunt alignment assumptions and if you just change a minor variable, everything collapses
[22:45:51] <BBB> it's witchery, burn it!!!112
[22:46:02] <BBB> but seriously, can someone explain me what's going on in there and how it works?
[22:47:29] <bcoudurier> peloverde, the mov dref patch is wrong
[22:47:35] <bcoudurier> FYI
[22:47:52] <peloverde> the patch may be wrong but the code is also wrong
[22:47:53] <bcoudurier> I should fix it properly, but I've been lazy I admit
[22:48:05] <bcoudurier> and it's not security critical
[22:48:34] <bcoudurier> I don't think the code is "wrong"
[22:48:53] <bcoudurier> the code is lacking a check for badly formated files
[22:49:01] <bcoudurier> I don't call that "wrong"
[22:49:32] <peloverde> when the badly formatted files make it infinite loop I call that wrong
[22:49:38] <bcoudurier> no it's not
[22:49:48] <bcoudurier> it seems that you don't know what you are talking about
[22:49:55] <bcoudurier> it's not infinite
[22:49:59] <bcoudurier> it's taking a long time
[22:51:15] <peloverde> Either way the bug should have been fixed ages ago
[22:51:30] <bcoudurier> probably, but fixed correctly
[22:51:47] <bcoudurier> and there are also many other bugs that should have been fixed ages ago
[22:51:52] <Dark_Shikari> BBB: what's wrong with it?
[22:52:02] <Dark_Shikari> 1) the 128 bytes below the stack is the "red zone"
[22:52:03] <Dark_Shikari> you can use it
[22:52:07] <Dark_Shikari> (on x86_64)
[22:52:15] <Dark_Shikari> 2) h does a transpose, then calls v
[22:52:24] <BBB> that one I understood ;)
[22:52:25] <Dark_Shikari> pengvado wrote it, ask him
[22:52:29] <BBB> red zone, ok
[22:52:33] <BBB> it looked very suspicious
[22:53:20] <BBB> hm...
[22:53:24] <BBB> half of clang works now
[22:54:42] <peloverde> Actually chrome had something like 50 patches against FFmpeg and most maintainers wound up fixing things correctly ages ago if the chrome patch was suboptimal
[22:56:56] <BBB> how do I run fate without it bailing out as soon as something fails?
[22:58:00] <bcoudurier> this patch is plain wrong, not suboptimal
[22:58:05] <bcoudurier> they know it
[22:58:31] <bcoudurier> they don't want to update it, and I'm currently busy, and the issue is not security critical
[22:58:46] <peloverde> it points to a real bug, fix it, don't shirk your duty, most of the patches they sent about aac were wrong I fixed the bugs properly
[22:59:53] <peloverde> How is a dref entry of size < 8 valid
[22:59:54] <peloverde> ?
[23:00:02] <bcoudurier> dref 12 is valid
[23:00:52] <peloverde> 12 < 8?
[23:02:05] <peloverde> Each reference needs a 4 bytes size and a 4 byte type identifier
[23:06:32] <BBB> pengvado: can you review my h264_deblock_sse2 patch on ML? thanks
[23:07:12] <bcoudurier> size 8 is wrong too
[23:07:27] <bcoudurier> size must be at least 12
[23:07:37] <peloverde> Then change the number to 12
[23:07:40] <peloverde> It's a one liner
[23:09:41] <bcoudurier> humm then I wanted to double check with the file, but couldn't find it
[23:09:58] <bcoudurier> asked scherkus about it, got lost
[23:10:37] <astrange> BBB: clang should support attribute_align_arg and them the asm will work
[23:10:54] <astrange> i know llvm supports it, so if clang-svn doesn't then it's just a frontend issue
[23:13:41] <BBB> astrange: I don't know what that is?
[23:14:16] <BBB> astrange: this isn't about aligning data on the stack in C, this is about assuming specific alignment when entering a new function in yasm
[23:14:23] <BBB> (called from clang/gcc-compiled C)
[23:14:26] <astrange> yes
[23:14:45] <astrange> in utils.c avcodec_decode_video* is set attribute_align_arg
[23:15:24] <BBB> yes
[23:15:26] <astrange> this makes gcc align the stack when coming from external libraries, and it keeps that alignment internally
[23:15:32] <astrange> ...i forget why it does that
[23:15:36] <BBB> but that's C
[23:15:38] <BBB> this is yasm
[23:15:44] <astrange> but in the end it means that it's still aligned when it calls into yasm
[23:16:02] <BBB> doesn't that depend on the functions called in between? :-p
[23:16:16] <astrange> iirc it didn't but i don't remember the details
[23:16:28] <astrange> if i'm wrong and your patch is the equivalent of gcc -mstackrealign then it's fine
[23:16:39] <BBB> hmk... well if pengvado knows how to do that then it's fine also
[23:16:44] <BBB> just would be nice if the bug were fixed
[23:20:17] <peloverde> https://cevans-app.appspot.com/static/video/clockh264aac_200021889.mp4
[23:20:27] <j0sh> peloverde: every time i read your blog, you've got a new background :)
[23:20:44] <mru> BBB: make -k
[23:22:06] <mru> astrange: nothing requires the compiler to maintain alignment greater than 4 on 32-bit x86
[23:22:31] <mru> gcc often keeps a 16-byte aligned stack
[23:22:36] <mru> other compilers do not
[23:22:45] <Dark_Shikari> mru: slightly more specific than that
[23:22:51] <Dark_Shikari> the way gcc ensures that DECLARE_ALIGNED wokrs is that it:
[23:22:55] <Dark_Shikari> a) ensures the stack is aligned to 16-byte
[23:22:57] <astrange> BBB: oh, leave out the and on x86-64
[23:22:58] <Dark_Shikari> b) aligns relative to the stack
[23:23:11] <mru> whatever
[23:23:15] <Dark_Shikari> Thus, if you call a gcc library with something that isn't compiled by gcc
[23:23:18] <mru> compilers aren't required to do it
[23:23:19] <Dark_Shikari> and the gcc library uses DECLARE_ALIGNED
[23:23:21] <Dark_Shikari> it will crash
[23:23:27] <Dark_Shikari> even if it's only C code
[23:23:34] <mru> but we're talking about a totally gcc-free build here
[23:23:34] <Dark_Shikari> (assuming there's something that requires the alignment, that is)
[23:23:48] <mru> there's yasm code requiring 16-byte alignment
[23:23:52] <mru> and clang doesn't provide it
[23:23:55] <BBB> right
[23:23:58] <Dark_Shikari> yes, so it gets disabled
[23:23:59] <mru> because it doesn't have to
[23:24:03] <mru> no, it crashes
[23:24:06] <BBB> Dark_Shikari: no, it crashes
[23:24:11] <Dark_Shikari> BBB: Because you didn't disable it.
[23:24:18] <mru> nor should we disable it
[23:24:19] <BBB> I prefer to fix
[23:24:31] <mru> we claim to support any compiler
[23:24:32] <BBB> it's not like gcc is the jehova of all compilers
[23:24:32] <Dark_Shikari> Well yes, but you could just do what x264 does and have slow_mod4_stack
[23:24:35] <Dark_Shikari> mru: and?
[23:24:38] <Dark_Shikari> _certain asm_ can be gcc-only
[23:24:40] <Dark_Shikari> if we want to.
[23:24:43] <Dark_Shikari> there's nothing wrong with that.
[23:24:44] <Dark_Shikari> we already do that.
[23:24:51] <BBB> dude, this is the loopfilter asm
[23:24:58] <BBB> you want to cripple all non-gcc builds for h264?
[23:25:03] <BBB> talking about unacceptable :-p
[23:25:04] <Dark_Shikari> BBB: there's mmx that doesn't require it
[23:25:13] <Dark_Shikari> if by "cripple" you mean 5% slower, sure
[23:25:15] <mru> Dark_Shikari: you're insane
[23:25:20] <BBB> my patch makes sse2 asm also not require it
[23:25:20] <Dark_Shikari> mru: about what?
[23:25:26] <mru> gcc should not have such special status
[23:25:32] <Dark_Shikari> mru: then you better go around patching ffmpeg
[23:25:36] <Dark_Shikari> because ffmpeg has TONS of code
[23:25:42] <Dark_Shikari> which is ifdeffed for gcc
[23:25:44] <mru> Dark_Shikari: guess what BBB is doing
[23:25:49] <Dark_Shikari> for one, the asm syntax is gcc-only
[23:25:53] <Dark_Shikari> in almost all of ffmpeg
[23:25:55] <Dark_Shikari> even your arm code
[23:25:58] <mru> yasm isn't gcc-only
[23:25:59] <Dark_Shikari> fucking everything is gcc only
[23:26:01] <Dark_Shikari> I don't _agree_ with it
[23:26:05] <Dark_Shikari> but that's how it is
[23:26:11] <mru> my arm code works fine with all arm compilers
[23:26:18] <Dark_Shikari> All arm compilers support GAS syntax?
[23:26:25] <mru> assembler != compiler
[23:26:28] <astrange> gas isn't part of gcc
[23:26:40] <astrange> actually llvm-mc might even support it now (though i'd still be surprised)
[23:26:41] <mru> and armcc knows how to call gas if it needs to
[23:26:44] <BBB> Dark_Shikari: I'm not asking you to fix it, I'll fix it, you just sit back and relax..
[23:27:17] <Dark_Shikari> BBB: please do not make the code slower on gcc.
[23:27:23] <Dark_Shikari> This means you must add an %ifdef to the asm.
[23:27:29] <Dark_Shikari> based on whether the compiler guarantees stack alignment.
[23:28:29] <mru> a while ago you were fine with the idea of disabling the function entirely
[23:28:45] <bcoudurier> humm peloverde, this file already errors out with -1
[23:28:47] <mru> now you're objecting to an unmeasurable "slowdown"
[23:28:49] <Dark_Shikari> mru: not quite
[23:28:55] <BBB> Dark_Shikari: ok, I can do that
[23:29:02] <peloverde> Probably new checks that have been added in the interim
[23:29:06] <BBB> how do I know whether the compiler is gcc or not?
[23:29:08] <astrange> clang svn supports attribute_align_arg
[23:29:10] <Dark_Shikari> What I meant was that as a crappy solution, disabling it on compilers we don't care about is not completely unreasonable.
[23:29:15] <mru> BBB: you can't
[23:29:16] <Dark_Shikari> astrange: yeah, but that's extra code on the caller side
[23:29:21] <Dark_Shikari> which is equivalent code to the asm side
[23:29:30] <Dark_Shikari> mru: sure you can
[23:29:31] <astrange> we already use it
[23:29:32] <BBB> decode_cabac_mb_mvd() has a bug also
[23:29:33] <Dark_Shikari> #ifdef __GNUC__
[23:29:37] <BBB> I fixed about half of the regtests
[23:29:47] <BBB> Dark_Shikari: oh, in the function init code?
[23:29:56] <Dark_Shikari> ?
[23:29:58] <astrange> admittedly i can't check clang-freebsd which might not _maintain_ stack alignment
[23:30:12] <astrange> but it will certainly realign it on entry to lavc once the compiler is updated
[23:30:12] <mru> Dark_Shikari: you can't test for __GNUC__ in yasm
[23:30:17] <BBB> Dark_Shikari: I need to know whether the compiler is gcc in yasm-code
[23:30:26] <BBB> this isn't inline asm, this is yasm
[23:30:30] <mru> astrange: clang/linux doesn't maintain it
[23:30:38] <BBB> clang/linux crashes also
[23:30:38] <Dark_Shikari> mru: isn't there a way to echo defines to a file?
[23:30:39] <peloverde> time yo create a config.asm?
[23:30:40] <Dark_Shikari> e.g. config.h?
[23:30:43] <mru> it would be failing on h264 if it compiled
[23:30:52] <BBB> but fate doesn't show it b/c compile fails b/c of mpegvideo_mmx.c
[23:30:58] <BBB> (on linux, not on fbsd)
[23:31:12] <mru> because someone enabled they crappy register allocator on bsd
[23:31:18] <peloverde> also doesn't clang claim to be __GNUC__
[23:31:22] <mru> yes it does
[23:31:24] <Dark_Shikari> ok, fuck it, just add the stack alignment.  just avoid adding stack accesses
[23:31:25] <mru> everything does
[23:31:34] <mru> testing for __GNUC__ is pointless
[23:31:42] <mru> it's like checking browser user-agent for mozilla
[23:31:45] <mru> everything says it is
[23:32:03] <peloverde> IMHO if you claim to be GCC, it should be expected that the compiler works like GCC
[23:32:15] <Dark_Shikari> unfortunately, peloverde, people are stupid
[23:32:17] <mru> it does work like gcc
[23:32:35] <mru> the stack alignment thing in gcc is undocumented
[23:32:38] <Dark_Shikari> no it isn't
[23:32:40] <Dark_Shikari> it's a commandline option!
[23:32:46] <Dark_Shikari> it's extremely documented
[23:33:01] <Dark_Shikari> it's a linux userspace convention to keep the stack aligned to 16 bytes.  do note this does NOT apply to the kernel
[23:33:06] <Dark_Shikari> as the kernel explicitly overrides this option
[23:33:06] <mru> when did they document it?
[23:33:16] <Dark_Shikari> It's been a well-documented commandline option for at least half a decade
[23:33:21] <Dark_Shikari> default stack alignment is by default 16
[23:33:35] <mru> no x86 abi standard requires that
[23:34:01] <astrange> x86-64 requires it
[23:34:23] <Dark_Shikari> mru: as I said, I'm talking about gcc.
[23:34:28] <mru> Dark_Shikari: nobody else is
[23:34:30] <astrange> and darwin
[23:34:35] <mru> we're talking about clang
[23:34:38] <mru> on 32-bit x86
[23:34:52] <mru> in that setup nothing promises anything about the stack
[23:34:54] <astrange> what does clang-freebsd do if you declare an m128 on the stack?
[23:35:01] <Dark_Shikari> mru: you specifically asked
[23:35:03] <Dark_Shikari> 09:33 <@mru> when did they document it?
[23:35:05] <Dark_Shikari> I answered
[23:35:45] <mru> well, if it's a command line option you can hardly rely on code providing any alignment anyway
[23:35:59] <mru> since whoever compiled the caller might have turned it off
[23:36:03] <peloverde> http://gcc.gnu.org/onlinedocs/gcc-4.2.4/gcc/i386-and-x86_002d64-Options.html
[23:36:15] <Dark_Shikari> mru: as I said, linux userspace convention
[23:36:18] <astrange> there are some options stating that changing them from default will not work when linked to anything else
[23:36:20] <Dark_Shikari> clang will probably eventually have to do this
[23:36:20] <peloverde> search for stack
[23:36:21] <mru> Dark_Shikari: apparently not
[23:36:30] <Dark_Shikari> mru: clang can get away with it because nobody actually uses clang
[23:36:35] <mru> it's only a convention if everybody does it
[23:36:37] <Dark_Shikari> if people ever seriously use it, it will have to fix itself
[23:36:43] <Dark_Shikari> More specifically
[23:36:44] <mru> not everybody is doing it
[23:36:48] <Dark_Shikari> if people ever use clang and gcc on the same system
[23:36:48] <mru> hence, no convention
[23:36:57] <Dark_Shikari> er... that's a stupid argument
[23:37:01] <Dark_Shikari> By that argument nothing in the world is a convention
[23:37:05] <Dark_Shikari> because there's always some idiot who doesn't do it
[23:37:05] <peloverde> I think few people care about clang/x86-32/linux
[23:37:20] <Dark_Shikari> peloverde: I think _fewer_ care about mixed clang+gcc
[23:37:24] <Dark_Shikari> which is what would break incredibly horribly
[23:37:49] <peloverde> I use clang as my c complier on x86_64 but all my system packages are compiled with gcc
[23:37:53] <mru> intentionally breaking mixed-compiler builds is stupid
[23:37:56] <Dark_Shikari> well yes, that's x86_64
[23:38:09] <mru> what's the point of having an abi if you're going to refuse to follow it?
[23:38:12] <Dark_Shikari> mru: then clang is very stupid
[23:38:18] <Dark_Shikari> since they're the ones who intentionally ignored the convention
[23:38:21] <mru> it follows the x86 abi
[23:38:30] <Dark_Shikari> no, you're missing a separate point
[23:38:33] <Dark_Shikari> I'm not talking about this function here
[23:38:42] <mru> nor am I
[23:38:52] <mru> the 32-bit x86 abi doesn't require 16-byte aligned stack
[23:39:04] <mru> ergo, assuming the stack is aligned is a violation of the abi
[23:39:05] <Dark_Shikari> I'm talking about the fact that GCC _assumes_ any function called has a stack alignment equal to what the commandline options declare.
[23:39:16] <mru> so gcc is broken
[23:39:17] <Dark_Shikari> No
[23:39:28] <Dark_Shikari> Again, the Linux userspace ABI is a subset of the x86 ABI
[23:39:46] <mru> url?
[23:39:49] <Dark_Shikari> there is not one single ABI in the entire world
[23:39:52] <Dark_Shikari> that everyone person abides by
[23:39:53] <astrange> it actually isn't
[23:39:54] <astrange> http://refspecs.linux-foundation.org/LSB_4.0.0/LSB-Core-IA32/LSB-Core-IA32/callingsequence.html
[23:39:55] <Dark_Shikari> there are many different ABIs
[23:40:11] <mru> yes, one or more per cpu
[23:40:14] <astrange> but the gcc stack code was written by an intel employee
[23:40:27] <astrange> so intel probably considers it more correct than the actual document
[23:40:28] <mru> none of the common x86 ones required an aligned stack
[23:40:47] <Dark_Shikari> arguably, intel has the right to declare the ABI for their own chips.
[23:40:54] <mru> yes
[23:41:11] <Dark_Shikari> I agree that the situation is a bit stupid
[23:41:14] <Dark_Shikari> but it's a de-facto stupid situation
[23:41:19] <Dark_Shikari> one that exists, regardless of how stupid it is
[23:41:21] <mru> but to the extent they have done so, they haven't required a 16-byte aligned stack
[23:41:25] <mru> they _could_ have
[23:41:25] <Dark_Shikari> and clang is the newcomer
[23:41:27] <mru> but they didn't
[23:41:30] <Dark_Shikari> and unfortunately, clang has to deal with the stupid
[23:41:33] <Dark_Shikari> even if the stupid is wrong
[23:41:35] <mru> icc doesn't align the stack either
[23:41:48] <Dark_Shikari> It does on Linux.
[23:41:50] <mru> no
[23:41:56] <Dark_Shikari> or wait, you're right, it doesn't
[23:41:58] <Dark_Shikari> it uses that other method
[23:42:02] <Dark_Shikari> or wait, I'm not sure
[23:42:04] <Dark_Shikari> I've only used ICL
[23:42:11] <Dark_Shikari> and I know I had to define slow_mod4_stack for ICL
[23:42:19] <Dark_Shikari> but ICL copycats MSVC so that says nothing
[23:42:32] <mru> I'm sure
[23:42:43] <mru> some troll disabled that asm function with icc for that reason
[23:42:54] <mru> instead of fixing it properly
[23:44:01] <Dark_Shikari> anyways, ffmpeg currently makes the assumption of aligned stack in a billion places
[23:44:13] <Dark_Shikari> specifically, it assumes that upon spawning a new thread, the stack will continue to be 16-byte aligned.
[23:44:48] <Dark_Shikari> I don't know if this is guaranteed by pthreads.
[23:44:55] <astrange> i found a thread about argument alignment but not post-argument alignment
[23:45:21] <Dark_Shikari> btw, gcc CANNOT align anything to greater than the assumed stack alignment
[23:45:25] <astrange> http://thread.gmane.org/gmane.comp.gcc.patches/190818/focus=195427
[23:45:29] <bcoudurier> humm peloverde does it error out on your machine ?
[23:45:30] <Dark_Shikari> so if you propose changing the gcc args, that'll kille verything
[23:46:56] <astrange> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44948#c4 gcc4.4 can align stacks to anything
[23:47:04] <astrange> but we supports gcc<4.4 so that doesn't matter
[23:48:23] <Dark_Shikari> gcc 4.4+ can do a lot of nice things that it would be great to be able to rely on.
[23:49:54] <BBB> so the other one is a miscmpilation
[23:50:03] <BBB> how do I know if it's a codebug or a compilerbug?
[23:50:10] <Dark_Shikari> flip a coin
[23:50:10] <BBB> basically it uses ecx for two things
[23:50:15] <BBB> obviously it crashes
[23:50:18] <Dark_Shikari> link?
[23:50:23] <Dark_Shikari> like, where's the relevant code
[23:50:30] <BBB> decode_cabac_mb_mvd
[23:50:38] <BBB> want me to past the asm somewhere from gdb?
[23:51:01] <astrange> yes
[23:51:23] <BBB> http://ffmpeg.pastebin.com/x24im1AX
[23:51:31] <BBB> the relevant code is in cabac.h
[23:51:42] <BBB> the variable "c" (the ac state) is in ecx
[23:51:53] <BBB> and ecx is also hardcoded inside
[23:51:57] <BBB> obviously this crashes
[23:51:57] <Dark_Shikari> it fails in a compilation of cabac?
[23:52:01] <BBB> no
[23:52:11] <BBB> it miscompiles cabac and randomly crashes half of the regtests
[23:52:12] <Dark_Shikari> but you jsut said it was in cabac.h
[23:52:13] <Dark_Shikari> I know
[23:52:19] <Dark_Shikari> so it fails in the compilation of cabac!
[23:52:23] <BBB> yes
[23:52:28] <Dark_Shikari> which cabac call fails?
[23:52:29] <BBB> sorry, I misread
[23:52:32] <Dark_Shikari> 1), 2), or 3)?
[23:53:10] <BBB> the one under ARCH_X86 && HAVE_7REGS && HAVE_EBX_AVAILABLE && !defined(BROKEN_RELOCATIONS)
[23:53:18] <BBB> just before the %else
[23:53:19] <Dark_Shikari> um...
[23:53:25] <Dark_Shikari> there are no such ifdefs in h264_cabac.c
[23:53:29] <Dark_Shikari> at least not in decode_cabac_mb_mvd
[23:53:31] <Dark_Shikari> there are three cabac calls
[23:53:33] <Dark_Shikari> which one fails?
[23:53:33] <astrange> it's get_cabac
[23:53:36] <astrange> compiler bug
[23:53:47] <BBB> line 530
[23:53:51] <astrange> it assigned "r"(c) to ecx but ecx is in the clobber list
[23:53:54] <BBB> cabac.h
[23:53:56] <BBB> not h264_cabac.c
[23:53:59] <Dark_Shikari> I know
[23:54:01] <Dark_Shikari> I was asking WHICH call
[23:54:03] <Dark_Shikari> from h264_cabac.c
[23:54:08] <Dark_Shikari> .....................................................................................
[23:54:10] <BBB> oh
[23:54:18] <BBB> ff_h264_decode_mb_cabac
[23:54:22] <Dark_Shikari> ... NO
[23:54:24] <Dark_Shikari> holy fuck
[23:54:25] <Dark_Shikari> how hard
[23:54:25] <Dark_Shikari> is this
[23:54:29] <Dark_Shikari> There are three get_cabac calls.
[23:54:33] <Dark_Shikari>     if(!get_cabac(&h->cabac, &h->cabac_state[ctxbase+((amvd-3)>>(INT_BIT-1))+((amvd-33)>>(INT_BIT-1))+2])){
[23:54:37] <Dark_Shikari>     while( mvd < 9 && get_cabac( &h->cabac, &h->cabac_state[ctxbase] ) ) {
[23:54:39] <Dark_Shikari>         while( get_cabac_bypass( &h->cabac ) ) {
[23:54:42] <Dark_Shikari> oh actually, 5
[23:54:45] <Dark_Shikari>             mvd += get_cabac_bypass( &h->cabac )<<k;
[23:54:47] <astrange> the first one
[23:54:47] <Dark_Shikari>     return get_cabac_bypass_sign( &h->cabac, -mvd );
[23:54:49] <Dark_Shikari> ok
[23:54:52] <Dark_Shikari> see that wasn't hard.
[23:54:58] <astrange> if you look from the top there are no branches before
[23:55:03] <astrange> 0x0819bfea <decode_cabac_mb_mvd+58>:    mov    0x4(%ecx),%esi
[23:55:09] <astrange> and that line is wrong all on its own
[23:55:23] <Dark_Shikari> it sorta bugs me that the one that fails is the one with the most magic in one line
[23:55:33] <astrange> what compiler version is this?
[23:56:52] <BBB> I think it's the second one
[23:57:06] <BBB> because right after that is the *.. = 0; return 0 from decode_cabac_mb_mvd()
[23:57:24] <BBB> clang version 2.8 (trunk 112587)
[23:58:14] <astrange> ew, that's new
[23:58:54] <BBB> this is linux, also
[23:59:00] <BBB> so it's not like it's weird stuff
[23:59:20] <BBB> now what do I do?
[23:59:23] <BBB> file a compiler bug report?
[23:59:27] <astrange> yeah
[23:59:55] <astrange> preprocess it and cut out everything below decode_cabac_mb_mvd then make it non-static