[FFmpeg-devel-irc] IRC log for 2010-04-11

[irc at mansr.com]

[00:44:26] <CIA-81> ffmpeg: michael * r22831 /trunk/libavformat/utils.c:
[00:44:26] <CIA-81> ffmpeg: Raise needed score for codec probing in CODEC_ID_PROBE before the last packet.
[00:44:26] <CIA-81> ffmpeg: Fixes issue1871
[06:16:08] <siretart> Dark_Shikari: hi
[06:18:15] <Dark_Shikari> siretart: we're considering dropping gpac in x264 for lavf
[06:18:19] <Dark_Shikari> because gpac sucks and is annoying to package/compile
[06:18:29] <Dark_Shikari> any opinion on this from an ubuntu/deb standpoint?
[06:33:02] <siretart> Dark_Shikari: lucid's lavf is too old, so this is maverick stuff anyways
[06:33:16] <Dark_Shikari> I mean in the future.
[06:33:20] <Dark_Shikari> I don't mean for this release.
[06:33:56] <siretart> ah, I see. no, I don't have concerns. one build dep less to care for. yay :-)
[06:34:03] <superdump> do we have an ffmpeg ppa?
[06:34:21] <superdump> or is that still on the todo?
[06:34:34] <kshishkov> ppa?
[06:34:37] <siretart> superdump: we could use the motumedia ppa. I've been using it for ffmpeg packages in the past
[06:34:58] <siretart> kshishkov: package archives with autobuilders for ubuntu
[06:35:05] <kshishkov> bleh
[06:35:16] <kshishkov> port description file anyone?
[06:36:52] <jai> bsd? macports?
[06:37:16] <kshishkov> yep, whatever
[06:37:21] <Dark_Shikari> siretart: oh yeah, and did we ever get an answer on what to do about ffms?
[06:37:42] * kshishkov has not used FFmpeg in distros since 0.4.5
[06:39:22] * kshishkov also curses for he finds no obvious way to force "xmmword" declaration in IDA where appropriate
[07:04:16] <superdump> mru: http://wss.co.uk/pinknoise/theorarm/ <--- maybe you should get some money from google for optimising ffmpeg's theora decoder and whooping its ass...?
[07:04:38] <kshishkov> superdump: read log from yesterday
[07:04:56] <Dark_Shikari> yay for reinventing the wheel eh
[07:05:07] <Yuvi> ffmpeg's already 10% faster than that (except maybe on armv5 and older)
[07:05:30] <Dark_Shikari> do a blog post about it or something
[07:06:00] <Yuvi> plus it's a pain in the ass to compile, the half-assed build system doesn't actually work
[07:07:22] <Dark_Shikari> also, superdump, MSU sent out the drafts of their 2010 benchmarks
[07:07:31] <superdump> yeah, seen that
[07:07:49] <Dark_Shikari> it's a bit embarassing how many h264 encoders are barely beating xvid
[07:09:32] <kshishkov> someone should try at least comparing VP family
[07:09:42] <kierank> speaking of encoders which are worse than xvid, was dicas in the msu test?
[07:09:46] <Dark_Shikari> no
[07:09:48] <Dark_Shikari> not this year
[07:10:04] <Dark_Shikari> go read the pdf
[07:10:11] <kierank> wanted to save themselves the embarassment
[07:10:25] <Dark_Shikari> they benched various others even though companies told them not to
[07:10:26] <Dark_Shikari> e.g. divx
[07:11:06] <superdump> Dark_Shikari: you said it used the last release of theora, does that include the thusnelda improvements?
[07:11:09] <superdump> i don't recall
[07:11:10] <Dark_Shikari> yes
[07:11:11] <Dark_Shikari> they used 1.1
[07:11:16] <superdump> oh dear...
[07:11:27] <Dark_Shikari> now, notably, there are two things to consider
[07:11:35] <Dark_Shikari> 1) the Ironman test is completely screwed because their decoder ignored the "offset"
[07:11:38] <Dark_Shikari> 1080p is encoded at an offset of 4
[07:11:41] <Dark_Shikari> i.e. croptop = 4
[07:11:56] <Dark_Shikari> 2) Their "high speed" encodes used -speedlevel 2, aka no motion estimation
[07:12:01] <Dark_Shikari> because theora was slow as balls
[07:12:12] <Dark_Shikari> But even if you ignore both of these, it still gets utterly thrashed.
[07:12:23] <Dark_Shikari> I told them about 1), hopefully they will fix it.
[07:16:01] <superdump> Bitrate/Quality. Usage area “Movies”, “Ice Age” sequence,
[07:16:03] <superdump>         “High Speed” preset, Y-PSNR
[07:16:17] <superdump> mainconcept actually matches x264
[07:16:19] <superdump> hehe
[07:16:45] <Dark_Shikari> in PSNR
[07:16:47] <superdump> Dark_Shikari: omg, your point 2) is hideous
[07:16:49] <Dark_Shikari> x264 is set to optimize for SSIM
[07:16:50] <superdump> yeah, i know :)
[07:17:01] <Dark_Shikari> Now, the single most interesting result from their tests
[07:17:07] <Dark_Shikari> is the Amazon graph.
[07:17:18] <Dark_Shikari> x264 _massacres_ everything else at high bitrates by 2db psnr or more.
[07:17:21] <Dark_Shikari> This makes no sense.
[07:17:23] <Dark_Shikari> x264 is optimizing for SSIM.
[07:17:34] <Dark_Shikari> And its advantage increases with bitrate very rapidly
[07:17:42] <Dark_Shikari> This makes me suspect something weird is going on.  Maybe it's MB-tree.
[07:18:13] <kierank> They should also correct the first page so that theora matches xvid since xvid says: "XviD (MPEG-4 ASP codec) " but theora just says "Theora"
[07:19:03] <kshishkov> kierank: but it's just Theora, nothing to add
[07:19:38] <kierank> It's called the "MPEG-4 AVC video codecs comparison"
[07:19:47] <kierank> so maybe they should clarify
[07:25:05] <siretart> Dark_Shikari: what about ffms? AFAIUI, it needs packaging, or is there any other open issue?
[07:25:41] <Dark_Shikari> siretart: just that
[07:25:44] <Dark_Shikari> it needs packaging
[07:25:48] <Dark_Shikari> btw, they switched from cmake to autoconf
[07:25:52] <Dark_Shikari> might make things easier
[07:27:01] <kshishkov> I never knew you'd praise autoconf like that
[07:27:13] <Dark_Shikari> given how awful the cmake build system was...
[07:28:42] <Dark_Shikari> hmm.  within the next month we're going to be announcing official x264 blu-ray support and releasing a free demo blu-ray image.
[07:28:55] <Dark_Shikari> what's the best way to get this kind of thing promoted?
[07:29:08] <kshishkov> add AACS support ;)
[07:29:10] <Dark_Shikari> lol
[07:29:18] <Dark_Shikari> it'll be a DVD-size, unencrypted blu-ray
[07:29:36] <Dark_Shikari> with 3 free full HD short films from lossless source
[07:29:44] <Dark_Shikari> I imagine you can figure out what two of them are.
[07:31:02] <Dark_Shikari> guess we'll want to submit it to digg, /. , etc.
[07:31:25] <kshishkov> you'd better make several labels for them, like "Enterprise quality from free product", "Advanced format made purely with opensource apps" and "From Touhou fans to Touhou fans"
[07:31:38] <Dark_Shikari> lol
[07:31:45] <kshishkov> that should cover ~90% of your target audience
[07:31:52] <Dark_Shikari> it doesn't contain any touhou
[07:32:14] * Dark_Shikari even created a cool little x264 title bumper http://mirror05.x264.nl/Dark/intro.mkv
[07:32:23] <superdump> Dark_Shikari: an interesting note that theora is included in the expections list for the settings used bein recommended by the developers
[07:32:34] <Dark_Shikari> no it isn't
[07:32:41] <Dark_Shikari> it's in the list of settings _not_ recommended by devs
[07:33:15] <siretart> Dark_Shikari: it is still on my todo list, unfortunately, there are higher priority items :-(
[07:43:05] <superdump> Dark_Shikari: that's what i meant
[07:43:14] <Dark_Shikari> oh k
[07:43:24] <superdump> i just wrote it badly (distracted) :)
[11:48:20] <CIA-81> ffmpeg: stefano * r22832 /trunk/libavcodec/eval.h:
[11:48:20] <CIA-81> ffmpeg: Move AVEvalExpr declaration at the beginning of the file, where it is
[11:48:20] <CIA-81> ffmpeg: less distracting.
[11:48:20] <CIA-81> ffmpeg: stefano * r22833 /trunk/libavcodec/ (ratecontrol.h eval.c eval.h):
[11:48:20] <CIA-81> ffmpeg: Rename AVEvalExpr to AVExpr, as suggested by Michael.
[11:48:21] <CIA-81> ffmpeg: The new name is shorter and less confusing.
[11:48:22] <CIA-81> ffmpeg: stefano * r22834 /trunk/libavcodec/ (eval.c eval.h ratecontrol.c): Rename ff_eval_free() to ff_free_expr().
[11:54:25] <blez> how can I export the error strings of ffmpeg
[11:54:33] <blez> and separate them into critical and not
[12:14:06] <pentanol> blez in a maling lists
[12:16:28] <blez> maling lists?
[12:22:19] <CIA-81> ffmpeg: cehoyos * r22835 /trunk/libavformat/flvdec.c:
[12:22:19] <CIA-81> ffmpeg: Set audio bit rate.
[12:22:19] <CIA-81> ffmpeg: Patch by Howard Chu, hyc highlandsun com
[12:28:01] <Compn> blez : probably you want to ask that question in the libav-users mailing list
[12:44:46] <mru> lol at dilbert: "we're using the law to keep justice away"
[14:10:14] <CIA-81> ffmpeg: stefano * r22836 /trunk/libavcodec/imgconvert.c:
[14:10:14] <CIA-81> ffmpeg: Make ff_fill_linesize() use the information stored in
[14:10:14] <CIA-81> ffmpeg: av_pix_fmt_descriptors.
[14:10:14] <CIA-81> ffmpeg: Allow simplification and a more generic implementation.
[14:16:44] <CIA-81> ffmpeg: stefano * r22837 /trunk/libavcodec/eval.h: Doxument ff_free_expr().
[14:51:11] <kshishkov> wbs: http://translate.google.com/#auto|en|Styrmansgatan
[14:55:47] <pJok> o_O
[14:58:17] <jai> en != fi last i checked
[15:00:31] <wbs> kshishkov: yeah, i think you've shown it before. quite fantastic, and a good example of the drawbacks in the google translate method :-)
[15:42:35] <j-b> good moroning
[15:42:45] <mru> morning j-b
[15:43:03] <kshishkov> is that standard VLC greeting now?
[15:43:27] <mru> ffmpeg dominates in subtle ways
[15:44:08] <j-b> kshishkov: I don't remember who introduced that to the channel, but yeah ;)
[15:44:14] <kshishkov> nope, the other person who uses it is also realted to VLC and (almost) no FFmpeg work
[15:44:19] <kshishkov> j-b: thresh
[15:44:36] <j-b> kshishkov: very likely :)
[15:47:00] <_av500_> bonjour j-b
[15:47:07] <_av500_> err, bonojour
[15:47:52] <kshishkov> boneaujour then ;)
[15:49:17] <jai> mru: http://pastie.org/914194
[15:49:20] <jai> merbzt: ^
[15:50:27] <BBB> anyone have suggestions on how to test my qcelp postfilter?
[15:50:40] <BBB> as in, does anyone know of a good qcelp encoder I could use?
[15:50:44] <mru> jai: please commit
[15:50:47] <mru> it's correct
[15:50:55] <mru> I simply forgot to do it
[15:51:05] <kshishkov> fine with me and I'm DCA maintainer
[15:51:45] <_av500_> kshishkov: i follow simple rule to add o after 3 chars
[15:52:17] <BBB> helolo?
[15:52:28] <kshishkov> _av500_: don't you know how French write "o" in their words?
[15:52:55] <BBB> j-b: we should talk about doing interesting things with money
[15:53:04] <BBB> j-b: how about some shared bounties?
[15:53:48] <j-b> BBB: agreed.
[15:53:56] <mru> giving it to me is interesting...
[15:54:20] <kshishkov> mru: you have no interest in petty cash
[15:54:20] <BBB> mru: how about beating theoraarm (as proposed by google) by making our theora better than theirs on arm?
[15:54:39] <j-b> and be LGPL
[15:54:44] <BBB> mru: you could do that
[15:54:54] <BBB> yes, lgpl please
[15:54:58] <jai> mru: done
[15:55:12] <j-b> is merbzt around?
[15:55:14] <jai> kshishkov: ah, i must've forgotten :|
[15:55:34] <CIA-81> ffmpeg: jai_menon * r22838 /trunk/libavcodec/dcadata.h: DECLARE_ALIGNED usage requires #inclusion of 'mem.h'.
[15:58:18] <BBB> j-b: it says here theorarm is bsd now (?)
[15:58:36] <j-b> did it change?
[15:58:38] <BBB> yeah
[15:58:53] <j-b> ok
[15:59:14] <j-b> that is why they paid, I guess
[15:59:28] <BBB> still, this libXYZ thing is like a disease, better put it all in ffmpeg
[15:59:44] <BBB> worst thing is, theorarm isn't part of xiph's libtheora :)
[15:59:48] <kshishkov> BBB: thanks for our next motto
[16:01:37] <BBB> my pleasure
[16:24:46] <j-b> how many applications do you have for SoC?
[16:25:37] <BBB> 11, but one of them is probably spam
[16:25:45] <BBB> I'm saying probably because if it is, it's quite good spam
[16:25:50] <BBB> so 10 realistically
[16:26:11] <BBB> kshishkov: can you apply as mentor? someone wants to do vc-1 interlaced
[16:27:37] <BBB> j-b: what about you?
[16:27:39] <kshishkov> I don't know how well it will go for me, so just use some sitz-mentor and I'll lend my hoof
[16:29:44] <j-b> BBB: 48
[16:29:54] <BBB> holy shit
[16:30:06] <BBB> kshishkov: I need you to talk to the student and make sure he's capable
[16:30:25] <j-b> BBB: we had 85 last year.
[16:31:00] <jai> BBB: tell him to come to IRC
[16:31:03] <jai> :)
[16:32:08] <j-b> BBB: so 11 applications, how many slots do you want?
[16:32:33] <kshishkov> ten, obviously
[16:32:42] <jai> heh
[16:33:33] <kshishkov> VLC ideas seems to be extremely simple compared to FFmpeg
[16:33:38] <j-b> indeed, they are.
[16:33:52] <jai> next time we should bait students with tasks like "cloud support for libavdevice" or something
[16:33:55] <kshishkov> how many people applied to x264 part though?
[16:34:08] * elenril wonders wtf is firefox trying to read ~/.lockmail
[16:34:12] <jai> a lot of people would apply if the buzzword count is just right
[16:34:12] <j-b> kshishkov: 8
[16:34:25] <j-b> jai: almost noone applied for the cloud one
[16:34:35] <thresh> that was a bad buzzword then
[16:34:38] <jai> j-b: heh, i would have bet otherwise :)
[16:34:49] <j-b> thresh: yeah, I need a new one for next year
[16:35:03] <j-b> thresh: somehting with 'Utlra-HD' in it
[16:35:09] <j-b> 'Ultra-HD'
[16:35:12] <_av500_> j-b: next year, recode it in objective c
[16:35:22] <j-b> _av500_: ;)
[16:35:38] <jai> "python bindings for ffmpeg" :)
[16:35:49] <elenril> that would be pretty cool actually
[16:35:54] <jai> :o
[16:37:05] <jai> hmm, actually that might even work
[16:37:32] <BBB> I think we should wrap ffmpeg into a libffmpeg
[16:37:40] <BBB> and then make applications use that instead of ffmpeg
[16:37:43] <BBB> great soc project
[16:37:58] <BBB> libffmpeg could also wrap libtheora and libvorbis and librtmp, so we can remove that from ffmpeg proper
[16:38:02] <BBB> we'll call it a "framework"
[16:38:11] <jai> with ctypes, it should work on windows too
[16:38:17] <BBB> excellent idea!
[16:38:24] <BBB> in fact, it could wrap directshow and quicktime also
[16:38:30] <BBB> I think that's an amazing idea
[16:38:34] <BBB> I shall apply for it next year
[16:38:35] <jai> World Domination FTW
[16:38:57] <elenril> BBB: isn't that called mplayer? ;)
[16:39:25] <BBB> elenril: amongst others, probably
[16:40:09] <j-b> gosh, this year SoC WebApplication is shityt
[16:40:23] <jai> its been pathetic for quite sometime
[16:40:37] <jai> atleast since 2009
[16:41:07] <j-b> from an admin PoV it is the worse shit ever
[16:41:33] <j-b> You cannot middle-click from the list of application to open them in a new tab
[16:42:20] <jai> weird
[16:42:21] <BBB> the lack of email notifications is terrible
[16:42:33] <jai> i thought there were email notifications
[16:42:40] <BBB> not for admins :(
[16:42:47] <jai> ah ok
[16:42:49] <BBB> afaics
[16:43:03] <BBB> j-b: I'd guess 8 slots would be great, 10 would be better but I'm not counting on it
[16:43:14] <BBB> j-b: also, don't forget we want students to pass qualification tasks and only 3 have so far
[16:43:29] <BBB> the libavfilter/audio guy is at least working on it, so that'd be 4
[16:43:34] <BBB> but I haven't heard from the others yet
[16:44:51] <jai> is he doing the task for ffmpeg or videolan?
[16:45:16] <_av500_> j-b: ack, the web app sucks
[16:45:32] <_av500_> it open in sep tab once it is not a "new" proposal any more
[16:45:55] <_av500_> so. add one comment to each and they all open in new tabs..
[16:45:57] <j-b> BBB: same for us. But we have had many people passing the qualification, this year
[16:46:46] <j-b> BBB: especially, since we have applications from developers of ffmpeg, xmms2, lives this year...
[16:47:15] <BBB> ffmpeg? hmm... who? :)
[16:47:27] <BBB> btw, is fedora shipping vlc?
[16:47:42] <j-b> BBB: ffmpeg? I won't tell :)
[16:47:53] <BBB> maybe he applied to us as well ;)
[16:48:13] <BBB> or was it kshishkov? :)
[16:48:43] <j-b> BBB: fedora are just plain assholes, but we are discussing with them...
[16:49:03] <BBB> I'd like to discuss that with them as well... I mean, I can't believe theyr
[16:49:03] <BBB> e
[16:49:22] <BBB> they're excluding one of the most popular freesoftware projects for fear of the P-word
[16:49:32] <BBB> thye could ship a crippled version
[16:55:44] <kshishkov> BBB: you're right, I've equally refused to be VLC GSoC mentor and/or student as well. Not that anybody has asked me...
[17:24:53] <merbanan> what am I missing ?
[17:27:24] <kshishkov> nothing serious I think
[17:28:29] <merbanan> debian issue or ?
[17:29:19] * kshishkov may have missed more than morebananas
[18:45:42] <CIA-81> ffmpeg: stefano * r22839 /trunk/libavcodec/ (eval.c eval.h):
[18:45:42] <CIA-81> ffmpeg: Avoid the use of the symbol ff_expr_s for referencing AVExpr.
[18:45:42] <CIA-81> ffmpeg: This way we have to deal only with struct AVExpr and AVExpr, which is
[18:45:42] <CIA-81> ffmpeg: slightly less confusing as the association between the two symbols is
[18:45:42] <CIA-81> ffmpeg: obvious.
[19:26:10] <SmkMnstr> i want libavcodec/libavformat for win32, osx, linux, and angstrom
[19:26:57] <SmkMnstr> i guess ill try to massage a ffmpeg dist that works for all and then rarely upgrade
[19:33:56] <mru> those are all supported targets
[19:35:36] <Kovensky> angstrom? o_O
[19:38:11] <mru> that's just linux
[19:38:21] <mru> it has fairly up to date ffmpeg packages
[19:39:21] <Dark_Shikari> that's like
[19:39:24] <Dark_Shikari> "windows, osx, linux, and ubuntu"
[19:39:38] <Dark_Shikari> "rocky planets, gas giants, and mars"
[19:39:45] <Dark_Shikari> http://tvtropes.org/pmwiki/pmwiki.php/Main/AndZoidberg
[20:05:17] <CIA-81> ffmpeg: stefano * r22840 /trunk/libavcodec/ (eval.c eval.h):
[20:05:17] <CIA-81> ffmpeg: Remove redundant file descriptions from copyright headers.
[20:05:17] <CIA-81> ffmpeg: File description is only kept in the @file doxy.
[20:05:17] <CIA-81> ffmpeg: stefano * r22841 /trunk/libavcodec/eval.h:
[20:05:17] <CIA-81> ffmpeg: Place some empty line in the doxy.
[20:05:18] <CIA-81> ffmpeg: Improve readability, also consistent with the predominant doxy style.
[20:06:44] <_av500_> Dark_Shikari: win, osx, linux x86 and linux arm :)
[20:13:28] <SmkMnstr> on angstrom/ARM the NEON and C64x+ implementations are very important
[20:13:30] <SmkMnstr> but i just found out it will be open embedded and not angstrom :)
[20:13:44] <SmkMnstr> now im determining what all libs will be needed under windows
[20:13:46] <mru> angstrom is a special case of open embedded
[20:14:19] <mru> ~curse gcc
[20:14:41] <mru> it doesn't realise it gets a/b and a%b at the same time
[20:14:47] <Dark_Shikari> lol
[20:14:57] <SmkMnstr> if this invovlves having a locale directory im going to be upset
[20:15:01] <mru> nothing a little asm can't fix :-)
[20:15:52] <Kovensky> * @diakopter helped build an actual bikeshed, 13 years ago.
[20:15:52] <Kovensky> <masak> what color was it?
[20:15:52] <Kovensky> <@diakopter> wood
[20:15:52] <Kovensky> <masak> sounds like a Solomonian solution to the whole issue.
[20:15:53] <Kovensky> <@diakopter> yeah. those who want to see it a certain color can just wear tinted glasses
[20:15:56] <Kovensky> <masak> :)
[20:16:07] <Kovensky> TODO: give tinted glasses to each developer in their favorite color
[20:16:18] <SmkMnstr> should i try just making visual studio project files for this and porting it?
[20:16:21] <Kovensky> :>
[20:16:22] * mru wants his rose-coloured
[20:16:25] <SmkMnstr> what could be the big diff why it 'dosnt build in windows'
[20:16:28] <SmkMnstr> i guess i can find out
[20:16:40] <mru> do not touch visual studio
[20:16:41] <SmkMnstr> without mingw that is
[20:16:44] <SmkMnstr> lol
[20:16:44] <mru> we will kill you
[20:16:50] <Dark_Shikari> heh, I got CC'd on a discussion about hugepages in linux kernel
[20:16:57] <Dark_Shikari> Linus is raging again
[20:16:58] <Kovensky> MSVC doesn't compile ffmpeg, and never will
[20:17:04] <SmkMnstr> why
[20:17:08] <Kovensky> ffmpeg is C99, MSVC only implements C89 and C++
[20:17:15] <Dark_Shikari> SmkMnstr: it doesn't compile the language ffmpeg is written in
[20:17:23] <SmkMnstr> oh hrm
[20:17:35] <Kovensky> and it only implements the part of C89 that C++ mandates IIRC
[20:17:43] <SmkMnstr> ok sorry i read about this earlier heh
[20:17:53] <SmkMnstr> it looks like c code to me
[20:17:59] <Dark_Shikari> yes, which msvc doesn't support
[20:18:01] <Dark_Shikari> it only supports C89
[20:18:07] <Dark_Shikari> a very old version of C
[20:18:20] <Dark_Shikari> Simple example of code that won't compile in msvc:
[20:18:24] <Dark_Shikari> int i;
[20:18:25] <Dark_Shikari> i = 0;
[20:18:26] <Dark_Shikari> int x = i;
[20:18:50] <SmkMnstr> that will def compile in msvc as c++
[20:18:54] <Dark_Shikari> Yes, but this isn't C++
[20:18:59] <SmkMnstr> could be in my project file
[20:19:07] <Dark_Shikari> That would make things harder
[20:19:11] <Dark_Shikari> C++ and C disagree on various things.
[20:19:22] <Kovensky> the most obvious one is casts to and from void*
[20:19:50] <mru> int class;
[20:19:52] <mru> int new;
[20:19:59] <Dark_Shikari> lol
[20:20:04] <Dark_Shikari> +1
[20:20:11] <Kovensky> void *new = &class;
[20:20:15] <enkidu> hi there. what about some kind of "garbage collector" for killing probably-dead ffserver connections?
[20:20:22] <andoma> typedef struct class new;
[20:20:25] <mru> there are some more subtle ones too involving structs
[20:20:27] <SmkMnstr> u just have to add a (void*) cast big woop
[20:20:40] <mru> (void*) casts are evil
[20:20:42] <SmkMnstr> im ignoring the reserved words criticism
[20:20:46] <mru> and casts of void*
[20:20:57] <Kovensky> also, inline struct initializers
[20:21:04] <Kovensky> that's the single most useful C99 feature IMO :P
[20:21:14] <mru> designated initialisers?
[20:21:16] <mru> .foo = bar
[20:21:17] <mru> ?
[20:21:18] <Kovensky> yes
[20:21:19] <SmkMnstr> void* casts are no worse than void* pointers IMO
[20:21:23] <mru> yes they are
[20:21:29] <mru> they are POINTLESS
[20:21:35] <SmkMnstr> ok slightly worse
[20:21:36] <mru> therefor they are evil
[20:21:44] <Kovensky> <@mru> they are POINTLESS <-- I see what you did there
[20:21:58] <mru> no pun intended
[20:22:00] <mru> honest
[20:22:08] <SmkMnstr> heh
[20:22:10] <Kovensky> heh
[20:22:17] <Kovensky> but finding puns is fun :)
[20:47:05] <Dark_Shikari> what's the easiest way to do a recursive find and replace on a lot of files?
[20:48:32] <mru> explain
[20:50:40] <Dark_Shikari> I want to replace one string with another
[20:50:41] <Dark_Shikari> across a ton of files
[20:51:06] <mru> do you have an easy way of listing the files?
[20:51:55] <Dark_Shikari> I guess I don't need recursive
[20:52:00] <Dark_Shikari> so in that case while *
[20:52:14] <Dark_Shikari> er, for file in *
[20:52:15] <mru> perl -pi -e 's/from/to/g' *
[20:52:34] <Dark_Shikari> what special characters won't that work with?
[20:52:44] <mru> that's a perl regex
[20:53:04] <Dark_Shikari> I meant for escaping things in the regex
[20:53:15] <mru> as I said, it's a perl regex
[20:53:18] <Dark_Shikari> I don't know perl
[20:53:20] <mru> standard rules apply
[20:53:25] <mru> you should learn perl
[20:54:24] <mru> \-escaping anything non-alphanumeric should be safe
[21:04:27] <iive> Dark_Shikari: npp can do that.
[21:27:00] <CIA-81> ffmpeg: stefano * r22842 /trunk/libavfilter/avfiltergraph.h: Apply grammar/consistency nits to avfilter_graph_add_filter() doxy.
[21:32:10] <SmkMnstr> got it building it windows :), now to integrate with my opengl app
[21:45:13] <CIA-81> ffmpeg: stefano * r22843 /trunk/libavformat/ (matroskadec.c internal.h cutils.c avformat.h mpegtsenc.c): Move the internal function declarations in avformat.h to internal.h.
[22:10:01] <mru> patches for another 7% faster dca decoding posted
[22:21:42] <Compn> nice
[22:22:18] <mru> I expect to boost it by another 20% at least
[22:23:22] <Compn> do you think google's theorarm project will have any good generic arm optimizations ffmpeg can copy ?
[22:23:32] <mru> no
[22:29:29] <Yuvi> only thing that might be useful is armv4 vp3 idct, if you care about pre-armv5 that is
[22:31:29] <mru> the code is ugly
[22:31:32] <mru> ugly code is rarely good
[22:31:44] <mru> and it's just base ARM, not even v6
[22:32:25] <mru> or indeed v5
[22:32:32] <Yuvi> there's some usat and uhadd8, but it's all mixed in
[22:32:44] <mru> must have missed those
[22:32:50] <CIA-81> ffmpeg: stefano * r22844 /trunk/libavcodec/ (eval.c eval.h ratecontrol.c):
[22:32:50] <CIA-81> ffmpeg: Rename ff_parse_eval() to ff_eval_expr().
[22:32:50] <CIA-81> ffmpeg: The new name expresses better what the function does.
[22:32:50] <CIA-81> ffmpeg: stefano * r22845 /trunk/libavcodec/ (opt.c eval.c eval.h):
[22:32:50] <CIA-81> ffmpeg: Rename ff_eval2() to ff_parse_and_eval_expr().
[22:32:51] <CIA-81> ffmpeg: The new name better expresses what the function does.
[22:32:58] <Yuvi> neon too
[22:33:56] <Yuvi> also, fun fact: apple's gas only accepts lowercase instructions
[22:34:13] <mru> omg, that neon code sucks
[22:35:28] <Yuvi> have you done any tremor vs. ffmpeg comparisons on a cortex?
[22:35:35] <mru> no
[22:35:37] <Vitor1001> mru: Is FFmpeg theora decoder is faster on arm than theorARM?
[22:35:43] <Yuvi> yes
[22:35:52] <mru> how much?
[22:36:12] <Yuvi> on a8, around 10% on average
[22:36:40] <mru> is that with all your speedups?
[22:36:58] <Yuvi> don't think so
[22:37:37] <Yuvi> it's been a bit since I tried, theorarm doesn't seem to have improved though
[22:38:29] <Compn> oh i thought theorarm was new or something
[22:38:40] <mru> nothing new about it
[22:38:44] <mru> it's been around for years
[22:38:46] * Compn not read blog post correctly
[22:38:49] <Compn> ah
[22:38:57] <Yuvi> 8 months or so I think
[22:39:04] <mru> apparently google paid the author to relicense it or something
[22:39:08] <Compn> ahhhh
[22:39:13] <mru> why they did that beats me
[22:39:16] * Compn not read article at all
[22:39:31] <Compn> well
[22:39:48] <Compn> cheaper to throw money at a problem than to throw a developer on a problem
[22:40:03] <mru> why not use ffmpeg if it's already faster?
[22:40:35] <Yuvi> (and they already use ffmpeg for chrome...)
[22:40:47] <Yuvi> probably a different part of google payed for it though
[22:48:59] <j-b> "Unknown Cook version, report sample!" whom should I report too
[22:49:01] <j-b> ?
[22:49:30] <peloverde> to samples.mplayerhq.hu of course
[22:49:41] <peloverde> and open a bug
[22:55:02] <Compn> at http://roundup.ffmpeg.org
[22:55:12] <Compn> upload to: ftp://upload.mplayerhq.hu/MPlayer/incoming
[22:55:19] <Compn> or your own file host, whichever is easier
[22:59:07] <Yuvi> yep, Chris DiBona says it was his department that funded it which is the same dept as GSoC