[FFmpeg-devel-irc] IRC log for 2010-02-07

[irc at mansr.com]

[01:14:49] <CIA-17> ffmpeg: michael * r21661 /trunk/libavcodec/h264_direct.c: ref_offset must be added after checking references validity.
[01:15:47] <CIA-17> ffmpeg: michael * r21662 /trunk/libavcodec/h264_direct.c: Add assert(sps.direct_8x8_inference_flag) to FIXME comment.
[01:18:04] <CIA-17> ffmpeg: michael * r21663 /trunk/libavcodec/h264_direct.c: Fix reference selection for colocated MBs from frames to fields.
[01:18:50] <CIA-17> ffmpeg: michael * r21664 /trunk/libavcodec/h264_direct.c: Fix colocated map.
[02:00:51] <CIA-17> ffmpeg: michael * r21665 /trunk/libavcodec/h264_loopfilter.c:
[02:00:51] <CIA-17> ffmpeg: Fix CAVLC+8x8DCT+MBAFF loopfiltering.
[02:00:51] <CIA-17> ffmpeg: Fixes issue1250
[02:02:04] <Dark_Shikari> nice
[02:09:54] <Kovensky> lol interlacing :D
[08:00:13] <_av500_> gee, headaches
[08:01:05] <kshishkov> why?
[08:01:32] <_av500_> beer?
[08:01:57] <_av500_> i doubt its the brussels tapwater
[08:04:56] <kshishkov> why do you get hangover from either of those?
[08:06:17] <_av500_> -EDONTKNOW
[08:07:40] <kshishkov> in Denmark they write on alcoholic drink ads "Enjoy $drink responsibly", here they write "Alcohol may be harmful to your health"
[09:07:37] <_av500_> kshishkov: good breakfast mostly cured it..
[09:08:32] <kshishkov> good for you
[09:09:25] <thresh> i've got a headache too, but i didnt drink enough alcohol yesterday to get it
[09:09:58] <kshishkov> what have you done instead?
[09:10:01] <jai> how was fosdem?
[09:10:11] <jai> s/was/is
[09:10:14] <pJok> _av500_, just eat before sleep
[09:10:21] <pJok> works every time fo rme
[09:10:24] <pJok> for me*
[09:10:35] <_av500_> pJok: hmm
[09:10:39] <kshishkov> pJok: I eat instead of drinking alcohol, works even better for me
[09:11:00] <pJok> kshishkov, and you are ukranian... aren't you supposted to take baths in vodka? ;)
[09:11:17] <thresh> kshishkov: slept :-(
[09:11:17] <kshishkov> pJok: no
[09:11:50] <pJok> kshishkov, i guess not all ukranians drink then... :)
[09:12:15] <thresh> pJok: i prefer a couple of aspirin tablets before the sleep
[09:14:54] <_av500_> jai: flickr.com/photos/av500 has fosdem pics
[09:15:27] <_av500_> videowall of 6 beagleboard running mrus ffplay in sync
[09:15:45] <pJok> thresh, eating works way better than any painkillers before sleep
[09:17:32] <thresh> not for me :(
[09:17:57] <jai> av500: awesome
[09:18:14] <kshishkov> thresh: "закуска градус крадет"?
[09:24:07] <thresh> av500: are those in 720p?
[09:29:37] <thresh> kshishkov: не, просто не помогает избавиться от головной боли
[09:43:50] <_av500_> thresh: 1080p movie cut in 6 parts, but movie trailers are 2.35 so less vertical pixels
[09:44:06] <_av500_> monitors run 1024x768
[09:44:34] <thresh> nice anyway
[09:47:45] <_av500_> yep
[09:48:13] <_av500_> it is hard to get material larger than 1080p to spread over 6 monitors...
[09:54:45] <jai> _av500_: which camera is that?
[09:54:53] <jai> the one you used to take the pictures
[09:55:12] <thresh> it says on flickr page
[09:55:34] <jai> hmm, i seem to have missed that
[10:05:21] <lu_zero_fosdem> h
[10:05:22] <lu_zero_fosdem> i
[10:05:45] <kshishkov> h
[10:05:46] <kshishkov> e
[10:05:47] <kshishkov> j
[10:05:58] <lu_zero_fosdem> Dark_Shikari: we got a question about x264.c in ffmpeg
[10:06:25] <lu_zero_fosdem> how hard would be make branch 0.5 and trunk in sync in your opinion?
[10:06:37] <lu_zero_fosdem> (and would it be worthy?)
[10:18:06] <_av500_> jai: crappy g1
[10:22:14] <twnqx> lu_zero_fosdem: given how long ago 0.5 was released, and how many changes there are since... i'd say very
[10:25:25] <_av500_> lu_zero_fosdem: gm
[10:26:55] <CIA-17> ffmpeg: stefano * r21666 /trunk/ (5 files in 2 dirs):
[10:26:55] <CIA-17> ffmpeg: Implement a physical concatenation protocol.
[10:26:55] <CIA-17> ffmpeg: Patch by Michele Orr? reverse(<moc.liamg at yp.rekam>).
[10:30:37] <lu_zero_fosdem> good morning
[11:00:59] <_av500_> http://www.youtube.com/watch?v=9pwUdRKllo0
[11:04:59] <superdump> Dark_Shikari: fyi, siretart is also interested in updating the libx264 shipped with ffmpeg 0.5 to work with curretn x264 iirc
[11:05:09] <superdump> maybe it was he that made the suggestion
[11:05:15] <superdump> i would think that it isn't difficult
[11:05:23] <superdump> and we could update the preset files too
[11:05:33] <superdump> then maybe it could land in lucid
[11:10:31] <twnqx> uh
[11:10:42] <twnqx> why not just release 0.6 or even 1.0?
[11:13:01] * twnqx never really understood that idea of backporting things to obsolete versions
[11:18:29] <superdump> twnqx: because we could push out a 0.5.1 almost immediately but there are a number of things we would like to land in 0.6
[11:19:17] <twnqx> but would the 0.5 api break any recent version of other apps anyway?
[11:19:23] <twnqx> wouldn't
[11:20:32] <Dark_Shikari> superdump: good idea
[11:20:35] <Dark_Shikari> I have a patch that does that.
[11:23:07] <Dark_Shikari> http://pastebin.com/m3769ee76
[11:23:11] <Dark_Shikari> that does up to API version 79
[11:23:16] <Dark_Shikari> adding the 83 changes is one more diff
[11:29:34] <peloverde> Do branch users want to update their libx264?
[11:30:07] <Dark_Shikari> I say "they should" ;)
[11:30:14] <kshishkov> peloverde: somebody called ffaacenc useful, it's your fault
[11:30:17] <Dark_Shikari> of course, if we do update the branch as siretart requests
[11:30:21] <Dark_Shikari> it _WILL NOT_ work with older libx264s
[11:30:50] <peloverde> Yes but if they are using branch and not trunk they may not want to update x264 substantially
[11:30:58] <Dark_Shikari> exactly
[11:31:56] <peloverde> Anyway I have to go because apparently the airline screwed my over on flights and I don't want to get stuck in BRU
[11:32:16] <peloverde> I'll try to catch up with siretart at the stand
[12:15:23] <siretart> Dark_Shikari: any change to create a change for ffmpeg 0.5 that works with both the version currently in ubuntu and with newer versions?
[12:33:37] <superdump> Dark_Shikari: i think one of siretart's prerequisites to addressing that possibility was that it must be backward compatible (i.e. it should work with both new and old libx264)
[12:33:48] <superdump> i guess it doesn't because of b_ to i_ changes and such
[12:36:50] <Dark_Shikari> superdump: worse than that
[12:36:55] <Dark_Shikari> the nal encapsulation change
[12:37:01] <Dark_Shikari> Of course, you can just ifdef the entire file if you want
[12:38:18] <Dark_Shikari> siretart: I could do it of course, but it'd basically involve a whole-file ifdef
[12:38:44] <Dark_Shikari> and I think that's too ugly, even if only to put in a branch that only exists to please outdated binary distros
[12:40:22] <twnqx> honestly... just deprectae distros that make such requirements
[12:41:04] <twnqx> it's like "udev 151 must support every kernel down to 2.4.0"
[12:41:59] <Dark_Shikari> the thing I cannot understand is
[12:42:02] <Dark_Shikari> "we want a new x264, but an old ffmpeg"
[12:42:04] <Dark_Shikari> why?
[12:42:10] <Dark_Shikari> can't you use a new x264, and a new ffmpeg?
[12:42:13] <Dark_Shikari> or an old x264, and an old ffmpeg?
[12:42:16] <twnqx> so you do not have the the new features!
[12:42:27] <superdump> the old ffmpeg is 'well-tested' as it's been distributed for a long time
[12:42:30] <twnqx> so your retarded users don't have to look hem up
[12:42:33] <superdump> its issues are better known now
[12:42:36] <superdump> i guess
[12:43:05] <twnqx> i mean.. are new codecs backported to ffmpeg-0.5?
[12:43:09] <Dark_Shikari> no
[12:43:12] <Dark_Shikari> not even bugfixes are backported
[12:43:17] <twnqx> to it's basically useless
[12:43:22] <Dark_Shikari> superdump: "well tested" means nothing if bugfixes aren't backported
[12:43:23] <twnqx> remove the branch and be happy
[12:43:42] <superdump> if it's not possible to have an ffmpeg binary that supports both new and old libx264 then it probably won't be done
[12:43:50] <Dark_Shikari> IMO, put simply, unless you backport all bugfixes, "latest release" is no different from "latest svn" stability-wise
[12:43:59] <Dark_Shikari> a binary?  now that is physically impossible
[12:44:00] <superdump> however, there's a possibility of a ppa
[12:44:03] <twnqx> current applications do not link or build against ffmpeg 0.5 due to api changes
[12:44:05] <Dark_Shikari> it's possible to have a _source tree_ that does
[12:44:07] <superdump> which is more interesting
[12:44:13] <Dark_Shikari> but not a single binary that does
[12:44:30] <superdump> mmm
[12:44:40] <twnqx> lots of bugs are - and will stay - unfixed, several of today's actually used formats are unsupported
[12:44:41] <Dark_Shikari> (ok, so in theory, you could make such a binary with gratuitous use of dlopen)
[12:44:41] <superdump> then i don't think it will pass ubuntu/debian policies
[12:44:55] <Dark_Shikari> by duplicating all the libx264.c code
[12:44:58] <Dark_Shikari> adding tons of function pointers
[12:45:01] <superdump> so rather 0.5.1 would just be with some backported bug fixes
[12:45:02] <Dark_Shikari> and similar things
[12:45:16] <Dark_Shikari> things which are far uglier than anything I've proposed so far
[12:45:17] <superdump> 0.6 will be too late for lucid
[12:45:18] <twnqx> superdump: is that really worth developer's time?
[12:45:22] <Dark_Shikari> or in fact, uglier than anything I have ever implemented
[12:45:29] <superdump> twnqx: if siretart wants to do it...
[12:45:51] <twnqx> well, debian is all about obsolete software, so it makes kinda sense...
[12:45:59] <superdump> Dark_Shikari: i think a nightly ppa would be more interesting personally
[12:46:08] <Dark_Shikari> superdump: yes, because it would make the distro quite a bit less shit
[12:46:25] <superdump> Dark_Shikari: that's the aim
[12:46:30] <Dark_Shikari> a distro is shit when you have threads on the distro's forums with guides on how to compile software for that distro, because the distro's own packages are totally useless
[12:46:34] <superdump> current x264 and ffmpeg easily installable :)
[12:46:58] <twnqx> Dark_Shikari: +1
[12:47:19] <superdump> and built by someone who knows 1) packaging for debian/ubuntu and 2) talks to us about it
[12:48:08] <Dark_Shikari> also, I'm bitter about ubuntu not supporting my laptop
[12:48:17] <twnqx> laptop is too new?
[12:48:22] <Dark_Shikari> yes
[12:48:27] <Dark_Shikari> windows 7 supported it, ubuntu did not
[12:48:36] <Dark_Shikari> because the version freeze for latest ubuntu was older than for windows 7
[12:48:43] <Dark_Shikari> yes, that's right: microsoft is more up to date than ubuntu
[12:48:55] <twnqx> that's pretty normal, don't you think?
[12:49:02] <Dark_Shikari> microsoft is _HARDLY_ known for being up to date
[12:49:15] <Dark_Shikari> hell, they don't even release critical security patches more than once a month
[12:49:20] <jai> Dark_Shikari: is there a problem with specific h/w?
[12:49:22] <Dark_Shikari> even when their OS is getting rooted left, right, and center
[12:49:23] <twnqx> but commercial drriver developers are more likely to support win than linux
[12:49:29] <Dark_Shikari> jai: sound driver requires a specific quirks mode
[12:49:38] <Dark_Shikari> took me half a day to figure that out
[12:49:49] <Dark_Shikari> also, lan/wireless are really finicky, never solved that
[12:49:52] <superdump> some intel hda quirk?
[12:49:55] <jai> Dark_Shikari: k
[12:49:57] <Dark_Shikari> dell-m6 quirk
[12:50:07] <superdump> Dark_Shikari: but through intel hda?
[12:50:19] <superdump> i.e. you have to select the correct codec variant?
[12:50:28] <jai> Dark_Shikari: my only suggestion would be to run a very recent kernel :)
[12:50:29] <superdump> for the correct quirks to be applied
[12:50:40] <Dark_Shikari> superdump: something like that
[12:50:43] <superdump> mmm
[12:50:50] <superdump> hda is a bit fucked up sometimes
[12:59:33] <Kovensky> <@Dark_Shikari> jai: sound driver requires a specific quirks mode <-- pretty much every realtek hda-based chip requires a special driver on win7 ._.
[12:59:49] <Kovensky> because of some new audio mode called 'pull mode' that realtek decided to enable without actually checking that it works
[12:59:56] <Dark_Shikari> gg
[13:00:03] <Kovensky> with pull mode enabled, sound cracks, pops, and overall sounds like a bad vinyl recorder
[13:00:30] <Kovensky> reducing sample rate / bits per sample helps reduce the noise, but doesn't kill it; you need to get a special "no pull mode" driver
[13:02:30] <superdump> good job realtek
[13:04:44] <jai> heh
[14:16:41] <siretart> Dark_Shikari: probably not worth for 0.5, but it would really great if post 0.6 versions of libx264.c/x264 could keep compatibility with versions that go with the 0.6 release
[14:17:00] <siretart> Dark_Shikari: as for ifdefs, it seems that dondiego and mru are fine with that
[14:56:50] <CIA-17> ffmpeg: michael * r21667 /trunk/libavcodec/h264_direct.c: Skip the fill_colmap() case thats for MBAFF if we dont have an MBAFF frame.
[15:06:08] <tetsuo55> anyone happen to see these warnings when compiling through visual studio?
[15:06:09] <tetsuo55> 24>h:\progs\Compiling\mpc-hc_dev\src\filters\transform\mpcvideodec\ffmpeg\libavcodec\h264.h(1283) : warning C4047: 'initializing' : 'int (*)[64]' differs in lev
[15:06:09] <tetsuo55> els of indirection from 'int *'
[15:06:34] <tetsuo55> and
[15:06:45] <iive> msvc is not supported
[15:07:09] <tetsuo55> 24>h:\progs\compiling\mpc-hc_dev\src\filters\transform\mpcvideodec\ffmpeg\libavcodec\h264_mvpred.h(81) : warning C4002: too many actual parameters for macro 'tprintf'
[15:07:41] <tetsuo55> yeah i know
[15:07:50] <tetsuo55> but it didnt give these warnings before the h264 split
[15:08:08] <tetsuo55> we use gcc to compile it, but gcc is called from visual studio
[15:09:20] <tetsuo55> we tried to figure out why msvc is complaining but have been unable to understand what that line of code is doing
[15:13:31] <CIA-17> ffmpeg: michael * r21668 /trunk/libavcodec/h264_ps.c: Check direct_8x8_inference_flag.
[15:14:47] <CIA-17> ffmpeg: michael * r21669 /trunk/libavcodec/h264_direct.c: Remove FIXMEs for cases that are disallowed by the spec.
[15:27:10] <tetsuo55> hmm, i guess we can consider h264 to be a wip for now
[15:27:14] <tetsuo55> :)
[15:32:22] <iive> aha, the warnings are definitely from msvc compiler, but you use them only for the client application, not to compile lavc
[15:32:37] <iive> i mean, you use the headers in the...
[15:32:49] <tetsuo55> i think i know why its happening
[15:32:53] <tetsuo55> we still have hybrid files
[15:32:55] <tetsuo55> grr
[15:33:05] <tetsuo55> (mixed old/new ffmpeg files)
[15:47:10] <CIA-17> ffmpeg: stefano * r21670 /trunk/cmdutils.c:
[15:47:10] <CIA-17> ffmpeg: Make parse_options() explicitely handle the case where an opt_func2
[15:47:10] <CIA-17> ffmpeg: function returns a negative value, rather than erroneously trigger the
[15:47:10] <CIA-17> ffmpeg: code which manages the case of unknown option.
[16:27:50] <CIA-17> ffmpeg: michael * r21671 /trunk/libavutil/ (mathematics.h mathematics.c): av_compare_ts()
[16:27:51] <CIA-17> ffmpeg: michael * r21672 /trunk/libavformat/utils.c: Use av_compare_ts() for interleaving per dts.
[17:14:47] <CIA-17> ffmpeg: michael * r21673 /trunk/libavutil/avutil.h: Bump minor for av_compare_ts()
[17:16:09] <CIA-17> ffmpeg: michael * r21674 /trunk/libavcodec/h264_direct.c: Factorize setting sub_mb_type out.
[17:41:13] <CIA-17> ffmpeg: michael * r21675 /trunk/libavcodec/h264_direct.c: Set direct MB partitioning for 16x8 and 8x16 colocated MBs to the respective true partitioning.
[18:47:42] <siretart> hi DonDiego
[18:47:46] <DonDiego> hi
[18:49:00] <siretart> no, im not at home yet
[18:49:41] <DonDiego> haha :)
[19:10:54] <CIA-17> ffmpeg: michael * r21676 /trunk/libavformat/utils.c:
[19:10:54] <CIA-17> ffmpeg: Directly use av_rescale_rnd() instead of av_convert_ts() as this cuts the
[19:10:54] <CIA-17> ffmpeg: number of calls to it down by 2.
[19:51:59] <Dark_Shikari> siretart: we don't intend to have any large, obnoxious API changes in x264 any time soon, so that should not be too hard
[19:52:46] <Dark_Shikari> how exactly do you want to do it?
[19:53:04] <Dark_Shikari> do remember it is impossible for a single binary to support multiple x264 API versions
[19:53:11] <Dark_Shikari> because a binary can only include one x264.h
[19:56:30] <DonDiego> about the 0.5 branch backports?
[19:56:47] <DonDiego> the binary need not support multiple versions
[19:56:54] <DonDiego> the source needs to
[20:02:41] <Dark_Shikari> siretart said the binary needs to, iirc
[20:02:56] <Dark_Shikari> which is probably not possible with extreme amounts of dlopen magic
[20:02:59] <Dark_Shikari> *without
[20:03:11] <DonDiego> i think that's a misunderstanding
[20:03:21] <Dark_Shikari> in that case, I can set up a patch to backport things
[20:03:27] <Dark_Shikari> it will be staggeringly ugly
[20:03:43] <DonDiego> we currently have a problem because some distros have a new enough x264 and others don't
[20:04:02] <DonDiego> it would be nice if both could build against 0.5
[20:04:29] <DonDiego> i don't mind a few ifdefs on the branch
[20:04:41] <DonDiego> it's nothing that we shall have to live with
[20:05:19] <Dark_Shikari> wait wait
[20:05:24] <Dark_Shikari> do you mean it should work with "0.5 x264, and new x264"?
[20:05:25] <DonDiego> hmm?
[20:05:28] <Dark_Shikari> or "OLD x264, and 0.5 x264?"
[20:05:38] <Dark_Shikari> your last statement implied the latter I think?
[20:06:00] <DonDiego> the 0.5 branch should work with:
[20:06:15] <DonDiego> - an x264 from the time the branch was cut (which it does atm)
[20:06:30] <DonDiego> - a current x264 (which it does not atm)
[20:06:38] <Dark_Shikari> ok, I can do that
[20:06:39] <DonDiego> clear now?
[20:06:49] <Dark_Shikari> as long as there are no requirements on code quality ;)
[20:06:55] <DonDiego> :)
[20:06:59] <Dark_Shikari> I won't do it if it's required that I make the code as clean and simple as possible
[20:07:04] <Dark_Shikari> but... it's 0.5, screw that =p
[20:07:08] <DonDiego> yes
[20:07:25] <DonDiego> ping me when you have it ready, i'll quickly review and approve it
[20:08:12] <Dark_Shikari> ok, I will maybe do it sometime today
[20:08:18] <DonDiego> cool
[20:08:23] <Dark_Shikari> btw, does it have to work with every x264 in between, too?
[20:08:33] <Dark_Shikari> I can do that, it will just be slightly trickier
[20:08:41] <DonDiego> i'll go to bed soonish, send me a mail if i should be offline
[20:08:51] <DonDiego> not necessarily
[20:09:03] <DonDiego> we were thinking about the changes that are in current trunk
[20:09:14] <DonDiego> these are two specific points
[20:09:24] <DonDiego> are there many in between?
[20:09:45] <Dark_Shikari> lemme see.  is there a good way to find all revisions that modified a given file when using git?
[20:09:58] <Dark_Shikari> oh, nevermind, the commit messages say when the API changed
[20:10:12] <elenril> git log file?
[20:10:17] <Dark_Shikari> ah, yup
[20:10:33] <Dark_Shikari> API change in local tree: 85, nothing that will affect ffmpeg.
[20:10:49] <Dark_Shikari> API change, DTS compression: 84, not used by ffmpeg
[20:11:01] <Dark_Shikari> API 83: x264_encoder_parameters, not used by ffmpeg but might be useful
[20:11:22] <Dark_Shikari> API 82: periodic intra refresh, not used by ffmpeg, but the b_keyframe feature is, so we'd have to count that
[20:11:32] <Dark_Shikari> API 81: timebase parameters added with vfr input support
[20:11:35] <Dark_Shikari> so we have to count that
[20:11:50] <Dark_Shikari> API 80: sliced threads, but _still_ not available in ffmpeg
[20:12:06] <Dark_Shikari> API 79: weightp, used by ffmpeg
[20:12:14] <Dark_Shikari> API 78: new b-pyramid mode, used by ffmpeg
[20:12:20] <Dark_Shikari> API 77: constrained intra, not used by ffmpeg
[20:12:29] <Dark_Shikari> API 76: The Big Change that broke everything, nal encapsulation simplification
[20:12:39] <Dark_Shikari> API 75: threaded lookahead, not available through ffmpeg
[20:12:53] <Dark_Shikari> API 74: intentional forcing of link error in case of incompatible API, not referenced in ffmpeg code
[20:13:06] <Dark_Shikari> API 73: multi slice, _still_ not available in ffmpeg
[20:13:25] <Dark_Shikari> API 72: frame-accurate parameter changing,  not used by ffmpeg
[20:13:31] <Dark_Shikari> API 71: encoder_delayed_frames, not used by ffmpeg
[20:13:39] <Dark_Shikari> API 70: MB-tree, used by ffmpeg.
[20:13:47] <Dark_Shikari> API 69: new AQ, not available through ffmpeg
[20:14:11] <Dark_Shikari> that leaves us with 82, 81, 79, 78, 76, 70.
[20:16:34] <Dark_Shikari> Yeah.  We have a lot of API changes.
[20:23:44] <DonDiego> maybe that is where ffmpeg's reputation comes from..
[20:25:57] <Dark_Shikari> We almost never break backwards compatibility though
[20:26:02] <Dark_Shikari> once in 2-3 years at most
[20:26:39] <Dark_Shikari> the main issue is that because ffmpeg uses the variables directly instead of the recommended param_parse API, it forces an x264 upgrade every single time ffmpeg is updated
[20:26:55] <Dark_Shikari> key/value pairs would avoid this problem
[20:27:14] <DonDiego> implement it
[20:27:27] <Dark_Shikari> it won't give any benefit until we have codec-specific options ;)
[20:28:10] <Dark_Shikari> also, I _like_ being able to use ffmpeg to force people to upgrade their x264
[21:09:58] <CIA-17> ffmpeg: michael * r21677 /trunk/libavcodec/h264_direct.c: Precalculate a few variables for direct mv prediction for interlaced MBs.
[21:54:45] <CIA-17> ffmpeg: michael * r21678 /trunk/libavcodec/h264_direct.c:
[21:54:45] <CIA-17> ffmpeg: Merge mv&ref related code for spatial direct MV code.
[21:54:45] <CIA-17> ffmpeg: a bit more than 10 cpu cycles faster.
[22:09:35] <astrange> Assertion failed: (false && "Ran out of registers during register allocation!"), function assignRegOrStackSlotAtInterval, file RegAllocLinearScan.cpp, line 1183.
[22:09:38] <astrange> i liked gcc's better
[22:47:23] <astrange> michael broke the build :(
[22:58:56] <CIA-17> ffmpeg: michael * r21679 /trunk/libavcodec/h264_direct.c: Zero a/b only in the branch where they need to be zeroed.
[23:16:41] <CIA-17> ffmpeg: michael * r21680 /trunk/libavcodec/h264.h: Ooops, 10l forgot to commit h264.h.
[23:17:14] <Compn> Dark_Shikari : have you already put in 'if x264 version is XXX and ffmpeg version is YYY then error "you need to upgrade ffmpeg and x264!" ? :P
[23:17:40] <Dark_Shikari> lol michael
[23:57:40] <Compn> fosdem over or are you irc from there ?
[23:57:57] <Compn> any interesting questions/comments from people ?