[FFmpeg-devel-irc] IRC log for 2011-02-02

[irc at mansr.com]

[00:01:02] <mru> ah, I see what's going on
[00:01:19] * kierank forgets its 2011
[00:02:33] <mru> he's upscaling chroma by doing a 16x16 idct with zeros outside the top-left quadrant
[00:02:44] <mru> so it's dreadfully slow _and_ shit quality
[00:04:00] <lu_zero> Dark_Shikari: pong
[00:04:22] <Dark_Shikari> oh, I gave your name to a Marvell guy looking for rtp people
[00:04:36] <lu_zero> ah
[00:07:24] <lu_zero> do they need something specific?
[00:10:09] <Dark_Shikari> I don't really know
[00:10:13] <Dark_Shikari> it just involved something related to RTP and VLC
[00:10:15] <Dark_Shikari> and they were going after me
[00:10:21] <Dark_Shikari> and I was like "fuck, I don't know about that stuff"
[00:10:26] <lu_zero> =)
[00:10:34] <lu_zero> we'll see then ^^
[00:16:53] <Kovensky> "The Total Perspective Vortex is allegedly the most horrible torture device to which a sentient being can be subjected." <-- I thought it was Vogon poetry?
[00:17:06] * Kovensky should resume reading
[01:09:47] <mru> Dark_Shikari: got any good still images where chroma blocking would be unusually noticable?
[01:38:27] <astrange> BBB: you don't see the mpeg4 issues? does make fate run test as well?
[01:38:39] <astrange> BBB: h264 patch ok though, i'll apply iy
[01:38:47] <mru> make fate runs every test we have
[02:23:42] <Dark_Shikari> mru: you mean yv12 chroma blocking?
[02:23:46] <Dark_Shikari> or compression chroma blocking?
[02:23:52] <Dark_Shikari> (be more specific in what you're looking for)
[02:25:39] <mru> dct blocking
[02:26:49] <Dark_Shikari> explain what you're using this for
[02:27:15] <mru> to demonstrate that libjpeg is shit
[02:27:25] <Dark_Shikari> as compared to what?
[02:27:32] <Dark_Shikari> why chroma in particular, etc
[02:27:37] <Dark_Shikari> tell the whole story and I'll find you the most obnoxious thing possible
[02:27:38] <mru> older versions of libjpeg
[02:27:46] <Dark_Shikari> what in particular about chroma
[02:28:04] <mru> since v7 the idiot uses his "clever" dct scaling to upscale chroma
[02:28:35] <mru> I'm expecting that to introduce blocking compared to a bilinear upsampling or whatever
[02:28:37] <Dark_Shikari> on decode you mean?
[02:28:40] <mru> yes
[02:29:03] <Dark_Shikari> hmm.
[02:29:28] <Dark_Shikari> gmaxwell might know more about the worst possible case for this, he knows more about interpolation vs dct theoretics than I do.
[02:30:13] <mru> he's taking the 8x8 coeffs and padding to 16x16, then doing a horrendously slow 16x16 idct
[02:30:29] <Dark_Shikari> loool
[02:30:53] <mru> 40-50% slower than w/o that "feature"
[02:30:57] <mru> total
[02:31:07] <mru> a comment in the code says it's faster
[02:31:14] <Dark_Shikari> looool
[02:32:53] <Dark_Shikari> mru: here's a simple thing to start with, create an image with a rapid chroma gradient
[02:32:56] <Dark_Shikari> and see how well that works
[02:33:16] <Dark_Shikari> hmm... the ideal would be the case where the gradient between blocks is different from that within blocks.
[02:33:20] <mru> that occurred to me as well
[02:33:37] <Dark_Shikari> so you could generate an image where the slope across block boundaries is higher than the slope within blocks.
[02:33:53] <mru> but I'd like a something real as well if possible
[02:33:56] <Dark_Shikari> Of course
[02:34:45] <Dark_Shikari> Next thing you know, he'll be combining Y, U, and V coefficients
[02:34:47] <Dark_Shikari> and doing RGB idcts
[02:34:55] <mru> obviously most images have more information in the luma plane
[02:35:21] <Dark_Shikari> mru: actually, I have a set of test images I used for a blind test to convince my boss that 4:2:0 subsampling sucked for an image editing application
[02:35:33] <mru> that might do it
[02:36:21] <Dark_Shikari> not necessarily useful to use, but you could use it to see what kind of things are most sensitive to chroma changes.
[02:38:48] <Dark_Shikari> uploading now
[02:39:06] <Dark_Shikari> it includes 4 images: 4 photoshop screenshots and 1 SAI screenshot
[02:39:21] <Dark_Shikari> each one has three types (randomized, blind): original RGB, YV24, and YV12
[02:39:26] <Dark_Shikari> (all were converted back to RGB and stored as png)
[02:40:41] <astrange> Y guided edge interpolation would be a good way to do chroma upscaling, if you could notice it
[02:40:44] <astrange> which i doubt
[02:41:15] <mru> plain bilinear has to be better than 8x8 block based
[02:41:16] <astrange> i wrote a program against jpeg6 that broke with 8, but it sounds like the solution is not to upgrade past 6...
[02:41:34] <mru> there's a compile-time switch to turn of the crap
[02:41:43] <mru> and then it's actually a little faster than v6
[02:42:33] <BBB> astrange: thanks for pushing
[02:42:41] <BBB> astrange: make fate completes succesfully, including all vsynth tests
[02:43:04] <BBB> astrange: can you post a new patch, so I can test it in a separate branch and make sure it's not a local hack somewhere that makes things work?
[02:45:16] <Dark_Shikari> mru: http://x264.nl/developers/Dark_Shikari/Photoshop%20Test.tar
[02:45:26] <Dark_Shikari> mapping of the blind test files (SPOILERS): http://pastebin.com/CLiXa3N9
[02:46:02] <astrange> hold on, i forgot to eat dinner
[02:46:19] <astrange> running build+test
[02:48:39] <Dark_Shikari> also if you can't tell the difference between rgb and yv12 on some of those you're blind
[02:56:41] <mru> heh, pretty obvious which one is yv12
[02:56:47] <mru> the other two are harder to tell
[02:57:37] <Dark_Shikari> Impossible to tell IMO
[02:57:42] <Dark_Shikari> in some cases there's no difference pixel-wise
[02:58:48] <mru> yeah, I couldn't say
[02:59:44] <Dark_Shikari> You can see though what kinds of images tend to die more with chroma futzing.
[03:00:04] <mru> ones with sharp chroma edges of course
[03:03:13] <BBB> astrange: who needs dinner when you can merge ffmpeg-mt??
[03:03:53] <BBB> mru: did you ever figure out that ppc vp8 bug?
[03:03:59] <mru> me? no
[03:04:00] <BBB> mru: the -2 that should be -1 overread
[03:04:03] <BBB> hm...
[03:04:09] <BBB> who here can write/read ppc asm?
[03:04:23] <mru> that's not asm, that's intrinsics
[03:04:32] * mru can only read/write asm
[03:04:35] <BBB> that much I figured, but it's the same to me :-p
[03:04:43] <BBB> it's stuff-that-is-not-regular-C
[03:04:51] <mru> well, I can mostly read them
[03:04:56] <mru> I wouldn't write them
[03:05:30] <BBB> can you fix 'em?
[03:05:41] <mru> possibly
[03:12:19] <CIA-38> ffmpeg: Alex Converse <alex.converse at gmail.com> master * r770c410fbb ffmpeg/libavcodec/x86/fft_sse.c:
[03:12:19] <CIA-38> ffmpeg: Fix ff_imdct_calc_sse() on gcc-4.6
[03:12:19] <CIA-38> ffmpeg: Gcc 4.6 only preserves the first value when using an array with an "m"
[03:12:19] <CIA-38> ffmpeg: constraint.
[03:12:19] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[03:12:21] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rc73d99e672 ffmpeg/libavcodec/ (32 files in 4 dirs):
[03:12:21] <CIA-38> ffmpeg: Separate format conversion DSP functions from DSPContext.
[03:12:21] <CIA-38> ffmpeg: This will be beneficial for use with the audio conversion API without
[03:12:21] <CIA-38> ffmpeg: requiring it to depend on all of dsputil.
[03:12:22] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[03:32:02] <Compn> Dark_Shikari : so whens your computer demos over cloud computing company go public so i can invest in it ? :P
[03:32:08] * Compn forgot the name again
[03:32:46] <Compn> gaikai
[03:33:37] <Dark_Shikari> we're more likely to be bought
[03:34:04] <Dark_Shikari> possible buyers include telecomms (comcast, etc), software makers (adobe, etc), publishers (electronic arts, etc), retailers (gamestop, etc).
[03:34:28] <Compn> so theres no way i can invest money and get a return huh? :\
[03:34:30] <Compn> ehe
[03:34:39] <Dark_Shikari> =p
[03:34:40] <Dark_Shikari> nope
[03:34:43] <Compn> shucks
[03:35:05] <Compn> well keep me on your investor list for future projects
[03:35:18] * Compn not fond of mutual funds and stock markets
[03:40:22] <astrange> git doesn't compile for me
[03:40:22] <astrange> cd doc && texi2html -monolithic --init-file /Users/astrange/Projects/video/ffmpeg/doc/t2h.init developer.texi
[03:40:26] <astrange> Unknown option: init-file
[03:40:41] <astrange> /sw/bin/texi2html 1.64
[03:41:06] <mru> too old
[04:37:10] <ravipriya419> Hi, I want to build vlc. for that I needed libavcodec. so i installed ffmpeg. But vlc configure still asks for libavcodec.
[04:37:57] <ravipriya419> my friend suggested me to install ffmpeg-devel. But i cuoldn't find ffmpeg-devel. can anyone please help me in my problem
[04:41:27] <Jumpyshoes> ravipriya419: http://www.ffmpeg.org/download.html he probably means the current ffmpeg repository (i.e. not the stable release). also, this should be in #ffmpeg
[04:44:36] <astrange> BBB: http://pastebin.com/rXv2Jbbq
[04:44:47] <astrange> haven't had any time to rebase on top of git so i don't know if that applies...
[06:28:19] <Dark_Shikari> mru: http://gcc.gnu.org/wiki/reload
[06:44:59] <saintdev> mru: something like "Chapter 6: Chroma Upsampling Error Tests" on http://www.tomshardware.com/reviews/hqv-2-radeon-geforce,2844-6.html may be what you're looking for
[06:46:51] <elenril> morning
[06:55:52] <elenril> still no -mt? ;)
[07:32:50] <astrange> BBB: http://www.speedyshare.com/files/26634359/ffms2-chroma-chaos.mkv decodes wrong with one thread, some chroma problem
[07:32:59] <astrange> that's really surprising, it shouldn't have changed at all
[07:48:16] <KotH> salve
[07:48:54] <cartman> moin
[07:49:16] <KotH> günaydin cartman
[07:49:44] <cartman> ehlo KotH
[08:46:22] <av500> ahoi
[08:46:27] <kshishkov> hejsan
[08:47:58] <KotH> fujisan
[08:48:15] <kshishkov> ?
[08:49:05] <KotH> http://www.fujisan.com
[08:49:39] <kshishkov> I know about that mountain but why have you mentioned it here and now?
[08:50:25] <Dark_Shikari> houraisan
[08:51:14] * kshishkov suspects is has something to do with that game series by permanently drunk Japanese
[09:06:22] <Sean_McG> I'm fixing vf_scale to not use sws_getContext now that it's deprecated -- do I have to populate the SwsContext structure *before* or *after* I call sws_init_context() ?
[09:07:17] <kierank> http://www.imdb.com/title/tt1740707/
[09:07:17] <kshishkov> isn't it supposed to be filled by init func?
[09:07:40] <Sean_McG> with defaults, presumably
[09:08:32] <kshishkov> ah, comment to sws_alloc_context() says it must be filled before init
[09:08:50] <Sean_McG> that's what I read, yeah
[09:50:32] <pJok> kshishkov, is there any reason that ffmpeg allows you to have multiple instances of the same command running on the same outputfile?
[09:50:54] <kshishkov> because there's no reason to prevent you
[09:51:08] <kshishkov> especially if that file is /dev/stdout
[09:52:00] <pJok> well, its smart with stdout, but not so practical when you write to the same file, from my experience ;)
[09:52:29] <kshishkov> just don't do that
[09:53:15] <kshishkov> also I don't know a tool that has that approach
[09:53:36] <kshishkov> except for databases
[09:54:12] <pJok> well, its just an implementation bug in the distributed encoder system i poke around in
[09:54:22] <pJok> that happens to take the same job on two machines simultaneously
[09:58:03] <kshishkov> well, I'd install AM system there
[10:38:33] <lu_zero> j-b: do you have libvlc documentation/examples at hand?
[10:38:47] <av500> the source?
[10:39:52] <j-b> http://git.videolan.org/?p=libvlc-demos.git;a=summary
[10:40:14] <j-b> http://git.videolan.org/?p=vlc.git;a=tree;f=doc/libvlc;hb=HEAD
[10:40:22] <j-b> this would seem the right places :D
[10:44:10] * lu_zero is suggesting somebody to use libvlc instead of straight ffmpeg since they want playlist support
[10:45:50] <j-b> playlists are a mess
[10:46:12] <av500> +1
[10:46:27] * av500 thinks that overloadeing .m3u with 3 totally different things was a bad idea
[10:48:12] <j-b> not to mention, asx, wsx, zpl, wpl, wpl that are all variants of M$ mess
[10:48:46] <av500> yeah
[10:52:39] <av500> j-b: is there a ffmpeg wrapper for libvlc :)
[10:53:06] <j-b> I hope not
[10:53:16] <j-b> but, i've seen some dshow wrappers and puked
[10:53:40] <av500> I mean, can I use libvlc from ffmpeg api :)
[10:53:49] <j-b> I hope not
[10:59:14] <lu_zero> their problem is the mms related nested redirection through playlist
[10:59:26] <lu_zero> so vlc had been the obvious idea =P
[11:00:19] <av500> lu_zero: hey, we support that :)
[11:05:12] <j-b> vlc has been more tested for porn
[11:05:27] <j-b> while ffmpeg is 'serious business'©®
[11:05:31] <kshishkov> and MPlayer - for anime which disqualifies them both
[11:07:55] <cartman> use ffplay for pr0n
[11:08:34] <kshishkov> cartman: or look into its source - it's pornography too
[11:08:49] <cartman> sure :P
[11:11:16] <lu_zero> av500: we-> who?
[11:12:50] <av500> lu_zero: $dayjob
[11:13:21] <lu_zero> av500: ^^;
[11:15:05] <j-b> saste: I still don't see why you don't adopt a sub-systems maintainers policy
[11:36:58] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * rb9a639ddd6 ffmpeg/libavcodec/arm/asm.S:
[11:36:58] <CIA-38> ffmpeg: ARM: add helper macro for declaring constant data
[11:36:58] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[11:37:20] <elenril> lu_zero: api bump!
[11:37:50] <lu_zero> elenril: where is the commit in ml?
[11:38:00] * lu_zero should run in a bit
[11:45:17] <Tjoppen> lunsj
[11:46:46] * av500 got a bugfixed mpeg2 decoder, size increased by 100%
[11:47:26] <av500> or maybe they forgot to strip it
[11:47:34] <cartman> likely
[11:48:00] <kshishkov> it's from India so can be just all those checks for exactly one buggy case
[11:48:31] <cartman> I re'd some C# code from Chinese it had something like this
[11:48:39] <cartman> int wifiSignalLevel = random() % 5
[11:48:51] <pJok> cartman, awesome coding
[11:48:58] <cartman> that explains the wireless stability
[11:49:16] <cartman> it even managed to connect offline wireless modems!
[11:49:27] <kshishkov> maybe it was just simulator
[11:49:36] <av500> wirulator
[11:56:12] <saste> j-b: how does it work?
[11:56:44] <saste> j-b: do you mean having every developer having commit rights on a limited part of the tree?
[11:56:51] <j-b> no
[11:58:19] <j-b> Some developer or group of developer have the reference tree for a limited part of it (lavfi, lavf)
[11:58:36] <j-b> they merge the relevant patches in their tree
[11:59:02] <j-b> and a developer or a group of developers merges the different important trees to the main ones
[11:59:20] <saste> j-b: that can work as well
[11:59:32] <j-b> that is mostly as the linux kernel works
[11:59:46] <j-b> linus merges trees from the submaintainers
[12:00:02] <j-b> submaintainers merges trees from other developers or direct patches
[12:00:14] <j-b> if a submaintainer tree is unclean, linus doesn't pull it
[12:00:22] <saste> j-b: but it requires some coordination for preventing API/ABI diversion
[12:00:30] <elenril> so how does this --8<-- thing work?
[12:00:38] <elenril> i didn't find any docs anywhere
[12:00:40] <cartman> scissor
[12:00:46] <saste> j-b: for example no version bumps in "submaintainers" tree
[12:01:09] <j-b> saste: well, a bit of coordination, but not much
[12:01:16] <saste> j-b: they are applied to the main branch when submaintainers tree are merged
[12:01:32] <j-b> saste: like the reference lavf tree can update its lavf version without the other to care
[12:02:28] <saste> j-b: a problem which i see with this approach is that changes are not tested until they're merged
[12:02:39] <saste> j-b: indeed fate works only for the "main" branch
[12:02:52] <av500> fate could work on any branch
[12:03:08] <j-b> I don't see why fate couldn't run on other branches
[12:03:11] <pJok> damnit
[12:03:24] <pJok> autobuilds of win-ffmpeg all over :/
[12:03:51] * av500 sends pJok to have lunch
[12:04:49] <pJok> av500, already had lunch
[12:06:09] <saste> av500: do you mean a fate for each topic branch?
[12:06:15] <j-b> yes
[12:06:20] <saste> av500: if that can be done I'm for it
[12:07:11] <j-b> saste: I mean, it is just a suggestion
[12:07:31] <j-b> saste: but that can let the right people manage the right parts
[12:08:09] <j-b> like having D S work on lavc/x86, and wbs on lavf/network...
[12:08:40] <j-b> but, I am a crazyFroggy, so ignore me :D
[12:09:25] <saste> j-b: how do you do with vlc?
[12:09:31] <av500> the ugly part
[12:09:46] <av500>  /undo
[12:09:59] <av500> worng channel
[12:10:14] <saste> j-b: do you follow this submodules maintainership model?
[12:10:36] <j-b> saste: we don't do anything, because we are not enough (the core is 3-5people at most) and because we are less important and we don't consider every commit as a release
[12:10:43] <j-b> saste: however, i would love to, yes
[12:10:57] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r75ea596de1 ffmpeg/ffplay.c:
[12:10:57] <CIA-38> ffmpeg: ffplay: factorize code from video_thread() into configure_video_filters()
[12:10:57] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:11:02] <j-b> saste: and seriously, noone cares about VLC
[12:11:10] <av500> lol
[12:11:12] <j-b> it isn't important
[12:11:16] <j-b> it isn't like FFmpeg
[12:11:16] <kshishkov> neither is FFmpeg
[12:11:28] * kshishkov looks at download numbers for FFmpeg
[12:11:49] <av500> kshishkov: you have to add the vlc download numbers
[12:11:51] * j-b counts 600M downloads of FFmpeg in the last year
[12:12:30] <kshishkov> av500: why, those people definitely choosed to download wrapper
[12:12:46] <av500> kshishkov: using lavc without is hard
[12:13:16] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r5fce60c3a9 ffmpeg/libavfilter/avfilter.c:
[12:13:16] <CIA-38> ffmpeg: Log debug information in filter_samples().
[12:13:16] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:46:57] <DonDiego> saste: how would you feel about a public branch for your libavfilter work?
[13:06:38] <mru> it's on my todo list to somehow allow developer repos on ffmpeg.org
[13:06:50] <mru> meanwhile, I'm sure j-b would host it
[13:07:48] <av500> yeah, lets have v-o host dev repos for ff.org and ff.org host dev repos for v-o :)
[13:27:23] <lyakh> mru: hi, so, regarding your review: shall I submit the next version or wait for your ff_mpa_synth_filter() rework?
[13:28:38] <mru> feel free to help me with it
[13:28:55] <lyakh> mru: in what way?
[13:29:36] <mru> ff_mpa_synth_filter() needs some love
[13:30:04] <mru> it needs to be able to call apply_window_mp3() through a function pointer like the float version does
[13:31:29] <lyakh> that's what my patch does, or would you like that part as a separate patch?
[13:31:40] <mru> your patch doesn't do it cleanly
[13:31:54] <lyakh> so, you want that context added everywhere?
[13:32:04] <mru> I want _some_ context
[13:32:11] <mru> it obviously can't be the full mpegaudio one
[13:33:17] <lyakh> ok, I'm afraid, explaining this to me will take you longer, than doing it yourself, since I'd now have to ask "what some context" and "why obviously" etc etc
[13:33:20] <mru> perhaps put all the state variables and the function pointer into a struct
[13:33:38] <mru> I don't mind doing it, but I don't have time today
[13:33:43] <lyakh> ok, so, several context pointers in a new struct
[13:33:54] <lyakh> it can wait until tomorrow, no problem;)
[13:34:04] <mru> I might not have time then either
[13:34:23] <mru> but next week is likely
[13:39:14] <av500> lu_zero: ping
[13:40:20] <lyakh> mru: I would be tempted then to embed that struct in both contexts, but that's kinda silly - to embed a pointer to a struct in itself... Without embedding we'd have to take care about its lifecycle, add alloc / free, etc
[13:53:36] <kshishkov> bink^W mate!
[13:59:16] <kshishkov> hmm, time to try IRC command /bink
[14:01:02] <jannau> elenril: I think you misunderstood me. I would prefer having the actual commit which changed the api in API changes and not the commit which increases the version
[14:01:22] <av500> kshishkov: try /nick binkishkov
[14:01:45] <elenril> jannau: why
[14:01:53] <mru> elenril: because it makes sense
[14:01:54] <elenril> people usually test against the version
[14:02:06] <mru> but the version is already written there
[14:02:25] <mru> the rev is handy if someone wants to look up exactly what changed
[14:02:28] <jannau> elenril: it's easier to see the change
[14:02:54] <elenril> ok
[14:03:09] <jannau> and it's already useable with that commit
[14:03:12] <elenril> except for lavf i'm doing one bump per several changes
[14:03:23] <elenril> you think i should do three bumps?
[14:03:27] <mru> no
[14:03:41] <mru> but the file should list the rev that introduced the change
[14:04:19] <jannau> list one rev for each change
[14:05:30] * mru notes in passing that the latest update to icc 12 still fails on gif
[14:06:23] <mru> and what happened to snow on freebsd/clang?
[14:07:37] <cartman> mru: http://llvm.org/bugs/show_bug.cgi?id=9123
[14:08:10] <mru> that's the build failure
[14:08:23] <cartman> right, I thought you mean a build failure
[14:08:27] <mru> on freebsd it crashes during testing
[14:09:42] <mru> anyone in the mood for reviewing 2k lines of neon vp8 code?
[14:09:56] <av500> lgtm
[14:10:03] <cartman> queued
[14:10:04] <cartman> :p
[14:10:34] <av500> mru: 2k lines? you can do loops, you know?
[14:11:08] <BBB> mru: go for it
[14:11:18] <BBB> mru: just submit it, benjamin and I will look
[14:11:22] <BBB> I can probably half-read it
[14:11:26] <BBB> benjamin should be able to totally read it
[14:11:37] <BBB> mru: is it faster than libvpx?
[14:11:51] <mru> BBB: considerably
[14:11:58] <BBB> \o/
[14:12:00] <BBB> awesome
[14:12:03] <BBB> let's remove libvpxdec
[14:12:05] <mru> >40% in some cases
[14:12:13] <kshishkov> even without edge_emu?
[14:12:16] <merbzt> anyone wanna do 422 support in the h264 decoder ?
[14:12:26] <mru> with whatever ffmpeg command line does
[14:12:30] * kshishkov looks for Dark_Shikari 
[14:12:32] <BBB> non-edge_emu
[14:12:38] <mru> and libavfilter off
[14:12:49] <av500> merbzt: ?
[14:12:50] <mru> lavfi slows it down by 5% due to the stupid memcpy
[14:12:52] <BBB> merbzt: how difficult is that? :-p
[14:12:54] <kshishkov> mru: in omapfbplay?
[14:13:04] <merbzt> no idea
[14:13:29] <av500> merbzt: what for?
[14:13:45] <merbzt> decode support for that format
[14:13:50] <merbzt> avc-intra mainly
[14:28:05] <elenril> jannau: in that case, why the ..
[14:41:09] <kierank> you need to watch that troll film at fosdem
[14:41:21] <av500> which one?
[14:41:25] <kierank> http://www.imdb.com/title/tt1740707/
[14:41:55] <av500> upload to samples
[14:42:18] <kierank> I would but Compn wouldn't be happy
[14:42:46] <kshishkov> do we have space for it there anyway?
[14:43:11] <kierank> kshishkov: some bink samples will be deleted for that
[14:43:18] <kierank> or maybe vp8
[14:43:36] <av500> delete both fringe format samples
[14:44:35] <mru> av500: hmm, that film was put on pirate bay today
[14:44:47] <av500> but thats illegal
[14:45:00] <mru> it's not illegal to search the site
[14:46:22] <kierank> hmmm the blu-ray might even be x264 encoded
[14:46:30] <kshishkov> mru: it's illegal to know about it because *AA says so
[14:46:47] <cartman> MafiAA
[14:47:19] <kierank> hmm no english subtitles for it
[14:47:57] <jannau> elenril: when we don't forget to do version bump and APICHANGES in the same commit
[14:49:14] <mru> kierank: you don't speak norwegian?
[14:49:24] <kierank> nope
[14:49:33] <mru> nor do I, but I understand it
[14:49:46] <Compn> what troll film ?
[14:49:53] <mru> yes
[14:49:54] <Compn> the rare exports ?
[14:50:10] <kierank> someone needs to fansub it or whatever they do
[14:50:27] <kshishkov> mru: at least you've had practice on live Norvegian people
[14:50:52] <Compn> kierank : the version in english i saw was good
[14:50:52] <av500> we need libavsub
[14:50:53] <Compn> :P
[14:51:11] <av500> kierank: bastard
[14:51:12] <kierank> http://www.youtube.com/watch?v=TLEo7H9tqSM
[14:51:13] <Compn> also did you know it was a shortfilm first? i queued up the shortfilms
[14:52:40] <mru> kshishkov: when I lived in oslo I was actually able to do a convincing imitation of a norwegian
[14:53:03] <mru> took the locals several minutes to suspect anything
[14:53:15] <kshishkov> mru: well, either you or Andreas come from place near Norwegian border too
[14:53:33] <kierank> av500: I could download it but it'll take all day to upload
[14:53:43] <av500> kierank: :)
[14:53:47] <av500> its ok
[14:54:18] <kierank> download it at fosdem
[14:54:33] <av500> ub there?
[14:54:43] <kierank> no
[14:54:49] <Compn> kierank : did you download the rare exports short films ?
[14:54:49] <cartman> scp -r kierank.local:~/Movies .
[14:55:01] <kierank> Compn: what films?
[14:55:40] <Compn> one sec
[14:56:14] <Compn> Rare Exports, Inc. (2003)
[14:56:15] <Compn> http://www.imdb.com/title/tt0435312
[14:56:20] <Compn> The Official Rare Exports Inc. Safety Instructions 2005
[14:56:21] <Compn> http://www.imdb.com/title/tt0769542
[14:56:38] <Compn> cinemageddon.net/details.php?id=87299
[15:06:31] <ubitux> "A new general optimization level, -Ofast has been introduced. It combines the existing optimization level -O3 with options that can affect standards compliance but result in better optimized code. For example -Ofast enables -ffast-math."
[15:06:35] <ubitux> mpf.
[15:06:48] <mru> yeah, don't use
[15:07:00] <cartman> ubitux: Gentoo user's are rejoicing everywhere
[15:07:07] <cartman> s/'//
[15:07:07] <mru> those things can be useful on carefully audited code
[15:07:43] <mru> -ffast-math really does make things faster, but if assumes there will never be any inf or nan values
[15:07:55] <mru> or denormals in general
[15:08:57] <mru> -Ofast might also make assumptions about integer arithmetic never overflowing or similar
[15:10:21] <cartman> http://gcc.gnu.org/gcc-4.6/changes.html huge
[15:11:37] <ubitux> The -Wsuggest-attribute=[const|pure|noreturn]  flag is available that informs users when adding attributes to headers might improve code generation.
[15:11:41] <ubitux> this is fun too
[15:11:52] <mru> that could actually be useful
[15:12:17] <mru> does it also warn about incorrect application of those attributes?
[15:12:32] <ohsix> it knows, so why not
[15:12:39] <mru> it's also gcc
[15:12:56] <ohsix> functions marked noreturn and pure will at least raise warnings if they return
[15:13:11] <ohsix> er, pure is something else; but i've seen a warning about it before
[15:15:43] <mru> const means the return value depends only on the parameter values with no side-effects
[15:15:54] <mru> pure means the same thing but allows global data to be read
[15:16:22] <mru> and also data pointed to by parameters
[15:16:47] <mru> so strlen() is pure but not const
[15:20:24] <av500> GCC now supports the Loongson 3A processor. Its canonical -march= and -mtune= name is loongson3a
[15:20:29] <av500> we are saved
[15:20:58] <mru> ah, the bogomips
[15:21:32] <cartman> Chinese?
[15:21:42] <av500> ...Basic support was added for Cortex-A15 and is available through -mcpu=cortex-a15.
[15:21:47] <av500> yay for the eagleboard
[15:21:52] <kshishkov> mru: bogoMIPS
[15:22:02] <kshishkov> mru: also with x86 emulation
[15:22:11] <av500> for doublebogo?
[15:22:15] <mru> a15 is still a v7-a, "basic" support doesn't mean much
[15:22:32] <mru> and with out of order execution, scheduling isn't very important either
[15:22:35] <kshishkov> mru: basic support means now you have its name as an option
[15:22:43] <mru> probably, yes
[15:23:02] <kshishkov> like FFmpeg configure introducing basic support for QNX x86
[15:23:03] <cartman> kshishkov: indeed
[15:23:17] <mru> qnx is on fate now
[15:23:25] <cartman> QNX will be valuable when RIM releases its Playbook
[15:23:38] <mru> I should set up a beagle with qnx/arm
[15:23:46] <kshishkov> you did :)
[15:23:52] <mru> not for fate
[15:23:53] <kshishkov> but without fate
[15:24:13] <kierank> why does RIM need to release a device with QNX on it?
[15:24:25] <mru> kierank: because they bought qnx
[15:24:25] <kshishkov> mru: at least you had spare Beagle for that
[15:24:29] <cartman> kierank: because they bought it?
[15:24:35] <kierank> mru: well why do they need qnx i mean?
[15:24:43] <kshishkov> kierank: because QNX sucks royally with multimedia?
[15:24:46] <av500> kierank: because RIMos is dead
[15:24:53] <mru> kshishkov: not quite true
[15:24:55] <kierank> why couldn't they use linux
[15:24:58] <kierank> nih?
[15:25:01] <av500> no
[15:25:03] <av500> ttm
[15:25:10] <mru> qnx isn't a bad os
[15:25:26] <kshishkov> yep, but it's for different tasks
[15:25:40] <mru> says who?
[15:25:41] <av500> kierank: linux from scratch: 2ys, buying an os with 100engineers that workd on it: 6mo
[15:25:55] <kierank> k
[15:26:27] <kshishkov> mru: well, I know people in Ukraine working on nuclear station controlling software, they praised it
[15:26:57] <av500> that station did output more power than asked for, indeed
[15:27:12] <kshishkov> mru: and you know guy working on getting playback on QNX-driven HW and he complains about it
[15:27:27] <mru> qnx is not to blame for that
[15:27:47] <mru> on the beagle it was faster than linux
[15:28:09] <mru> using a stock qnx 6.5 bsp
[15:29:13] <av500> faster doin what?
[15:29:35] <mru> playing movies
[15:30:08] <mru> with you-know-which app
[15:31:06] <kshishkov> have you also tried omapfbplay there?
[15:31:16] <mru> no
[15:33:48] <av500> ahm the $serious app?
[15:34:07] <mru> the $$$serious app
[15:35:05] <kierank> why (is the app) so $$$serious?
[15:35:22] <mru> the $$$ refers to my bank account
[15:38:11] <kshishkov> kierank: if the company hired mru to optimise it then it's really serious
[15:39:40] <av500> mru: so all you did to make it faster was to run it on qnx and not linux.....
[15:39:51] <av500> did you consult RIM as well?
[15:40:38] <av500> kierank: now you know why they picked qnx
[15:42:15] <cartman> heheh
[15:42:34] <kierank> knowing RIM it's probably a useless app
[15:42:44] <kierank> that they think is the next best thing since sliced bread
[15:43:01] <cartman> Blackberry worked out well
[15:43:12] <kshishkov> compared to what?
[15:43:28] <kshishkov> Diego claims it's one of the least usable phones
[15:43:29] <cartman> kierank: other phones? until iPhone came in.
[15:43:39] <cartman> kshishkov: ^^
[15:44:03] <kierank> well it had push email that worked
[15:44:05] <kierank> that was about it
[15:44:13] <mru> kierank: I was not hired by RIM, if that's what you thought
[15:44:30] * mru curses android
[15:44:31] <cartman> kierank: it saves Egyptians' ass
[15:44:33] <mru> phone locked up
[15:44:39] <mru> all I did was try to make a call
[15:44:42] <cartman> saved*
[15:45:08] <cartman> mru: adb logcat :p
[15:45:10] <kshishkov> mru: but that's not a proper task for modern smartphone
[15:45:17] <mru> cartman: it rebooted now
[15:45:22] <mru> I guess watchdog woke up
[15:45:33] <cartman> nice
[15:47:05] <av500> mru: N1 is the worst phone I ever owned
[15:47:13] <av500> wrt making phone calls
[15:47:18] <av500> or receiving them
[15:47:24] <cartman> WFM
[15:47:27] <cartman> now go away
[15:47:36] <kierank> windows mobile is worse
[15:47:44] <av500> might be
[15:47:47] <mru> bah, the thing is _still_ booting
[15:47:47] <cartman> he he :D
[15:48:03] <cartman> mru: you sure didn't install a system update?
[15:48:13] <mru> a few days ago
[15:48:13] <cartman> mru: time to plug adb logca to see wtf its doing
[15:48:22] <av500> in android, system update installs you
[15:48:33] * cartman rmmod av500 
[15:48:48] <av500> cartman: try
[15:48:56] <pJok> mru, its probably rebuilding the dalvik cache
[15:49:00] <cartman> I'll use -f in order :P
[15:49:02] <pJok> that can take forever
[15:49:14] <mru> it's shoing a silly animation
[15:49:21] <pJok> yeah
[15:49:25] <pJok> its probably rebuilding
[15:49:39] <pJok> i was afraid i had bricked mine when i upgraded it with a custom rom
[15:49:43] <av500> ...compiling....
[15:49:48] <mru> 303
[15:49:51] <cartman> av500: optimizing
[15:50:03] <pJok> just turned out to take exeptionally long to boot the first time
[15:50:05] <cartman> pJok: there is always fastboot
[15:50:13] <av500> cartman: nope
[15:50:25] <av500> not if you kill the bootloader
[15:50:31] <cartman> av500: well...
[15:50:35] <av500> ask jannau
[15:50:39] <cartman> or install wrong radio fw
[15:51:06] <cartman> Thats kind of expected
[15:51:10] <pJok> cartman, i dont have it enabled... im thinking of rolling my own 2.3 for it with SD being initialized way earlier in the procress so i can actually dump stuff like the dalvik cache and internal programs onto my sd card... its not like i use the mount sd card as drive feature anyways
[15:51:37] <cartman> pJok: got a Nexus S?
[15:51:51] <pJok> cartman, if i did, i wouldn't have that problem ;)
[15:52:02] <pJok> cartman, i have a htc desire
[15:52:20] <mru> that's ~= n1, right?
[15:52:21] <cartman> pJok: ah custom roms out of AOSP :P
[15:52:50] <pJok> cartman, its a "stock n1 rom" with sense ui on top
[15:52:54] <pJok> mru, yeah
[15:53:39] <pJok> cartman, upgraded to 2.2 before it was official for the desire
[15:53:50] <cartman> pJok: I wouldn't dare to :p
[15:54:26] <pJok> cartman, i dont care... the bootloader is already patched, so what ever i throw at it, it should gobble it up
[15:56:04] <pJok> cartman, i just need to figure out how to roll my own 2.3 and fix that sd card stuff
[15:56:31] <cartman> pJok: shared libs. in sdcard is supported wit 2.3 now but no idea about dalvik cache
[15:56:43] <pJok> well
[15:56:46] <pJok> its just unionfs
[15:57:00] <pJok> there are a lot of app2sd solutions for it
[15:57:37] <pJok> ah well
[15:57:38] <pJok> time to run
[16:20:43] <mru> the damn phone is _still_ animating
[16:21:00] <BBB> astrange: so what happened? :-p
[16:34:24] <kierank> av500: I have asked to get english subtitles for the troll film
[16:39:07] <av500> trolls got him
[17:01:00] <cyclist> high. i just wanted to say that it shouldn't be possible for one to be part of the ffmpeg steering comittee if they dont understand, for example, the MPEG standard. In order to be part of that people should prove AV coding skill by having written an encoder. get your shit together people. wtf with the whitespace gurus running the proj?
[17:01:17] <ohsix> will ffplay use the proper pixel size if you set the DAR during encoding (source is 1.28:1 or something)
[17:02:19] <ohsix> not sure if either of the things i'm usign to preview the output respect DAR
[17:02:26] <Kovensky> cyndis: because our whitespace is better than yours
[17:02:30] * Kovensky runs
[17:03:06] <av500> whotf was that?
[17:03:14] <BBB> a troll
[17:03:18] <Kovensky> wrong hilight
[17:03:21] <Kovensky> but yeah, lol
[17:03:36] <j-b> lol
[17:03:51] <av500> even I wrote an encoder one
[17:03:55] <j-b> mpeg1 ?
[17:04:07] <av500> it took the midle pixel of each line and stored that
[17:04:14] <av500> decoder made the whole line that color
[17:04:17] <Flameeyes> yeah because whoever wrote the reference encoders for h264 were very good at coding, don't you think so Dark_Shikari? :P
[17:04:22] <Kovensky> I never wrote an encoder, but I don't think it'd be very hard to take YV12 data, rot13 it and write it encoded ;)
[17:04:49] <Kovensky> then to decode you'd have to irot13 the input data and present it as YV12
[17:04:51] <j-b> Kovensky: you need to asm the rot13 though :D
[17:05:25] <av500> and then rot13 the asm
[17:05:28] <BBB> mru: your neon code is really nicely organized
[17:05:35] <BBB> mru: with some imagination I can pretty much read it
[17:06:00] <BBB> mru: so for sixtap filters, you're basically using a complete 8xword register and not use the last two words right?
[17:06:03] <Kovensky> nah, that's the job for those crazy CPU people, not encoding people
[17:06:19] <av500> I dont like the label names
[17:06:38] <Kovensky> actually, as bonus points for the rot13-based codec, it can support any colorspace!
[17:06:48] <Kovensky> now, someone just need to make a matroska mapping for it...
[17:06:51] <Kovensky> +s
[17:13:51] <mru> BBB: yes, that's right
[17:14:01] <mru> I don't know of a better way
[17:15:02] <mru> btw, robclark did the ground work for epel and loopfilter
[17:15:09] <mru> I just made it twice as fast
[17:17:29] <av500> mru: what res can you now decode on omap3?
[17:17:39] <mru> av500: which omap3?
[17:17:52] <mru> a 1GHz one should manage 720p fine
[17:18:02] <av500> oh
[17:18:19] <av500> nice
[17:18:39] <av500> but some mhz needed for audio and $the_rest
[17:18:50] <mru> the 600MHz can almost do it
[17:18:56] <av500> k
[17:19:05] <av500> I will add it here and test
[17:20:38] <BBB> mru: let me check, I thought we did that different for x86
[17:20:53] <mru> BBB: h or v?
[17:21:04] <BBB> both, I think
[17:23:12] <BBB> I think we run four rows rows/cols at once, then multiply all of them with the first two coeffs, then the second 2 coeffs and the third 2 coeffs, and then sum it
[17:23:20] <mru> hold on, you're confusing me
[17:23:35] <mru> the only place the full width isn't used is some of the width-4 ones
[17:23:58] <BBB> width=4
[17:24:46] <mru> for width 8 it uses 6 registers with 8 values in each
[17:25:26] <mru> the width 4 ones don't quite fill the registers since doing that would cost more than it saves
[17:28:14] <mru> does x86 have multiply-accumulate?
[17:29:20] <BBB> no :(
[17:29:25] <BBB> it has pmaddubsw
[17:29:29] <av500> it has complicate
[17:29:38] <BBB> and then sum of two neighbouring ones
[17:29:45] <BBB> but not sum of all values into a single one
[17:30:12] <BBB> anyway, sounds like neon has an insutrction that saves much more than this, so then it's ok
[17:30:17] <BBB> just an x86'ism ;)
[17:30:31] <mru> I don't see the neon code calculating anything that isn't used
[17:30:45] <mru> except some of the width=4 parts
[17:31:42] <mru> the horizontal ones there can't easily be packed
[17:36:56] <mru> BBB: the mc functions do overread horizontally to a multiple of 8
[17:37:06] <mru> iirc you said that was ok
[17:37:44] <BBB> overread at end is always ok
[17:37:47] <BBB> overread before start is not
[17:38:05] <BBB> also, when you say "3% faster", you mean overall, not in that function, riht?
[17:38:08] <mru> nor would it be beneficial
[17:38:12] <mru> overall, yes
[17:39:23] <mru> the decode_block_coeffs asm is ~ twice as fast as the C code
[17:39:29] <mru> gcc really made a mess of that functino
[17:39:46] <BBB> I'm planning to do that after ffmpeg-mt is merged
[17:39:48] <BBB> one thing at a time ;)
[17:39:59] <mru> no pressure
[17:47:21] <av500> is -mt merged already?
[17:47:31] <mru> no
[17:47:40] <BBB> astrange: ping :-p
[17:50:33] <mru> pJok: is it normal for android boot to take >2h?
[17:50:46] <av500> mru: no
[17:51:05] * mru ponders pulling the battery
[17:55:53] <av500> mru: do it
[17:56:12] <mru> I did
[17:57:01] <mru> ah, now it booted normally
[18:00:25] <wbs> mru: how long did it take, an hour?
[18:00:55] <mru> wbs: it didn't finish
[18:00:59] <mru> I pulled the battery
[18:01:01] <mru> after 2h
[18:01:14] <mru> then it booted in the usual 30s
[18:01:15] <wbs> ah, I should read up properly first ;P
[18:24:01] <lu_zero> av500: pong
[18:25:29] <wbs> lu_zero: would you mind pushing the rtsp patches you ok'd earlier today?
[18:26:15] <av500> lu_zero: about free.fr, but I need to go home now
[18:27:31] <BBB> wbs: I'll commit them later today
[18:27:35] <BBB> if he doesn't beat me to it
[18:28:06] <lu_zero> wbs: had a day walking from a meeting to another
[18:28:22] <lu_zero> and I'll be back in 3 hours (leaving almost now)
[18:28:49] <lu_zero> av500: send me an email or write me once you are at home ^^
[18:48:23] <astrange> BBB: what happened with what? i went to sleep
[18:54:26] <BBB> astrange: I was hoping you'd post ffmpeg-mt again
[18:54:31] <BBB> did my patch fix your make fate?
[18:54:43] <astrange> 23:44 <@astrange> BBB: http://pastebin.com/rXv2Jbbq
[18:55:16] <BBB> did make fate pass?
[18:55:21] <j-b> who understands the reasoning in libavcore/libavutil?
[18:55:54] <astrange> i still see the encoding problems (using the -mt tree, not anything based on ffmpeg git), but h264 was fixed
[18:57:18] <BBB> j-b: what reasoning? for the split?
[18:57:51] <BBB> astrange: ok, I'm going to compare your patch in a new branch to my current patch, and then see how it went away here
[18:58:01] <BBB> maybe I made a local chance that fixed it while sleeping or so
[18:58:07] <BBB> I tend to do that, and then forget about it
[18:59:39] <j-b> BBB: yes
[18:59:42] <BBB> and your patch does not apply :-p
[18:59:53] <ruggles> j-b: i think it was to keep libavutil as generic utilities not specifically related to multimedia and libavcore for general multimedia things to share between libs.
[19:00:11] <michaelni> ruggles, yes :)
[19:01:04] <michaelni> ive used things from libavutil in several of my projects that where not MM related
[19:01:26] <BBB> astrange: can you rebase against master?
[19:04:12] <astrange> have to look for that filter-branch script
[19:05:34] <Dark_Shikari> mru: That's a really nice asm function btw
[19:05:36] <Dark_Shikari> it's surprisingly clean
[19:05:51] <Dark_Shikari> mru: can't you give your labels names?
[19:06:03] <astrange> look = type filter-branch into gmail search, done
[19:10:39] <j-b> ruggles: ok
[19:12:55] <mru> Dark_Shikari: which function?
[19:14:25] <BBB> the ones that have 1: and 2:, presumably?
[19:15:17] <kshishkov> but that's very convenient labels
[19:25:44] <_av500_> and easy to predict
[19:44:02] <Dark_Shikari> mru: your vp8 decode coeffs
[19:44:19] <Zor> didn't ffmpeg have some macro for 'nicer' 4ccs?
[19:44:42] <mru> lu_zero: ping
[19:46:21] <BBB> Zor: MKTAG('f','c','c','x') or AV_RL32("fccx")
[19:48:10] <Compn> Zor : see riff.c ?
[20:02:44] <elenril> awesome, yet another TL;DR thread!
[20:02:52] <elenril> because we don't have enough of those
[20:07:25] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rc3beafa0f1 ffmpeg/ (3 files in 3 dirs):
[20:07:25] <CIA-38> ffmpeg: ac3enc: Change EXP_DIFF_THRESHOLD to 500.
[20:07:25] <CIA-38> ffmpeg: This patch changes the exponent difference threshold in the exponent
[20:07:25] <CIA-38> ffmpeg: strategy decision function of the AC-3 encoder. I tested lowering in
[20:07:25] <CIA-38> ffmpeg: increments of 100. From 1000 down to 500 generally increased in quality
[20:07:25] <CIA-38> ffmpeg: with each step, but 400 was generally much worse.
[20:07:26] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:10:51] <Dark_Shikari> mru: response to my comment about label names?
[20:11:18] <kshishkov> Dark_Shikari: 1-9 are ideal for label names
[20:11:32] <mru> Dark_Shikari: I'm don't know what to call them
[20:11:50] <mru> you don't label lines in C code, do you?
[20:12:07] <kshishkov> maybe he rewrites x264 in Basic
[20:13:29] <_av500_> mru: h_loop, v_loop
[20:13:34] <_av500_> no?
[20:13:59] <mru> Dark_Shikari: are you talking about the coeff decode or all the functions?
[20:17:36] <DonDiego> and the best troll ever award goes to...
[20:17:40] <DonDiego> *drumroll*
[20:17:55] <DonDiego> Microsoft for publishing a H.264 playback Chrome extension:
[20:17:58] <DonDiego> http://blogs.msdn.com/b/interoperability/archive/2011/02/01/greater-interoperability-for-windows-customers-with-html5-video.aspx
[20:18:06] <mru> yeah, read about that
[20:18:19] <Zor> that was sort of hilarious
[20:18:33] <DonDiego> indeed :)
[20:18:41] <mru> it's nice to see them accepting defeat on vc1
[20:19:03] <mru> h264 won, and they're not trying to deny it
[20:19:40] <Dark_Shikari> lool
[20:19:48] <_av500_> and they acknoledge that browser and codec are orthogonal
[20:19:49] <Dark_Shikari> mru: coeff decode
[20:21:45] <kshishkov> mru: well, I've looked through your patches - they look good and I believe they work correctly too. It's just a bit strange to me to see d0[1] instead of s1 but that's not even a nitpick
[20:22:14] <mru> vld1 doesn't work on s regs
[20:22:27] <kshishkov> ah
[20:23:08] <mru> btw, speed tip: loading all elements {d0[]} is faster than loading only one {d0[0]}
[20:23:26] <mru> so if you don't care about clobbering the whole reg, use the former form
[20:24:16] <mru> that's because the single-element load has to do a read-modify-write on the register
[20:24:35] <Zor> >H.264 isn't an open standard and isn't supported by Firefox or Opera, so in what way is this in support of interoperability? Commercial interests absolutely, but interoperability certainly not. You should be ashamed of yourselves.
[20:24:37] <Zor> herp derp
[20:24:53] <Zor> (comment in the above blog post)
[20:25:20] <elenril> why h.264?
[20:25:24] <kshishkov> Zor: they have H.264 plugin for Firefox as well
[20:25:29] <elenril> why not a general dshow plugin
[20:25:37] <elenril> (or whatever they're calling it these days)
[20:25:54] <J_Darnley> elenril: That wouldn't be in the HTML5 spirit
[20:26:28] <elenril> because it would be actually useful and not completely braindead?
[20:26:42] <elenril> makes sense i guess
[20:26:43] <J_Darnley> Sounds like what I said
[20:27:23] <elenril> which reminds me that i wanted to drop the second _ from map_meta_data
[20:27:31] <J_Darnley> PLEASE!
[20:27:43] <mru> elenril: send a patch
[20:27:52] <elenril> J_Darnley: why didn't you write a patch?
[20:28:11] <Zor> the HTML standardization process has always been pretty dumb
[20:28:12] <J_Darnley> Because I made the suggestion before I wrote any code
[20:28:32] <J_Darnley> And then I saw the inertia any change like that would have
[20:36:46] <Dark_Shikari> hahahahahhahahahahahahaha.
[20:36:48] <Dark_Shikari> Hacker news thread
[20:36:54] <Dark_Shikari> Headline: reddit has 1 billion monthly page views
[20:36:59] <Dark_Shikari> Comment A: what does that translate to in ad revenues?
[20:37:02] <Dark_Shikari> Comment B: About $3.50.
[20:38:46] <kshishkov> well, $3.50 income sounds like doubling its value
[20:41:43] <ruggles> weird. issue 2581 did not show up in the roundup mailing list when first submitted by the user. possibly because it didn't have a message, just an attached text file.
[20:47:48] <ruggles> mru: regarding loading all elements vs. one element, that's possibly why iirfilter is slower when saving coefficients to xmm registers before the loop. movss clears upper bits when moving from memory but leaves them unmodified when moving xmm-to-xmm.
[20:49:14] <elenril> J_Darnley: see - wasn't that hard
[20:52:01] <kierank_> j-b
[20:52:03] <kierank_> http://news.ycombinator.com/item?id=2171212
[20:53:25] <mru> j-b: your website is down
[20:55:11] <kierank_> mru: works4me
[20:55:20] <mru> yeah, now it loads
[20:55:27] <mru> must've been a glitch
[20:55:43] <elenril> ffdshow uses x264?
[20:56:08] * elenril thought it was decoders only
[20:57:58] <kierank_> elenril: maybe as a directshow encoder
[20:57:58] <kierank_> dunno
[21:14:17] <{V}> elenril, apparently "x264 encoder re-added and updated." http://ffdshow-tryout.sourceforge.net/wiki/old_changelogs#beta_2
[21:18:07] <_av500_> j-b: btw, what happened to these laptops?
[21:29:26] <KSHawkEye> Hey, I'm trying to cross compile FFmpeg for windows 32 and 64 bit with mingw-w64. I'm configuring it with "../source/configure --prefix=/home/kyle/software/ffmpeg/ffmpeg --enable-gpl --enable-version3 --enable-nonfree --enable-postproc --enable-runtime-cpudetect --enable-memalign-hack --arch=i686 --target-os=mingw32 --cross-prefix=x86_64-w64-mingw32-" and I get this make error: http://pastebin.com/Ta20mB4d Anyone have any ideas?
[21:30:05] <jannau> KSHawkEye: #ffmpeg
[22:05:07] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r4868bebe5b ffmpeg/ (doc/APIchanges libavformat/version.h libavutil/avutil.h):
[22:05:07] <CIA-38> ffmpeg: Add forgotten minor API bumps and APIChanges entries
[22:05:07] <CIA-38> ffmpeg: The bumps are for adding version.h and avio_{get/put}_str functions in
[22:05:07] <CIA-38> ffmpeg: lavf and making av_dlog public in lavu.
[22:05:07] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[22:05:17] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r87e4d9b252 ffmpeg/ (doc/ffmpeg.texi ffmpeg.c):
[22:05:17] <CIA-38> ffmpeg: ffmpeg.c: rename map_meta_data option to map_metadata
[22:05:17] <CIA-38> ffmpeg: It's consistent with the -metadata option and easier to write.
[22:05:17] <CIA-38> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[22:08:34] <DonDiego> saste: i just reviewed three of your docs patches (crc/framecrc/image2), do you have more pending?
[22:10:26] <jannau> DonDiego: image2 is already committed
[22:10:46] <DonDiego> so? :)
[22:11:27] <mru> a little extra review can't hurt it
[22:12:27] <DonDiego> i'm trying to teach some (technical) writing in the process, so i sure hope it's useful
[22:13:40] <jannau> it was just a reaction to the "pending", more review is of course good
[22:13:55] * _av500_ thinks in 2011 ff api docs should be utube videos
[22:14:05] <_av500_> more audience
[22:14:48] <superdump> audience?
[22:15:35] <_av500_> well, most tech blogs have stopped writing, its all utub vids
[22:15:56] <_av500_> superdump: /me thinks in 2011 ff api docs should be utube videos
[22:16:03] <_av500_> in case you missed that
[22:16:17] <mru> _av500_: http://www.youtube.com/watch?v=iIalNEW-LQ8
[22:16:20] <mru> they are :)
[22:16:35] <_av500_> thats the blonde?
[22:16:40] <mru> ack
[22:16:43] <mru> what else?
[22:17:18] <kierank> _av500_: i approve
[22:17:20] <_av500_> so, we enact api example at fosdem?
[22:17:41] <mru> do you bring girls?
[22:17:53] <_av500_> we will only encode girls?
[22:18:15] <mru> any good video needs at least one girl
[22:18:44] <_av500_> btw, DonDiego what about yv?
[22:56:52] <lu_zero> mru: pong
[22:56:58] * lu_zero is just back
[22:57:21] <mru> lu_zero: care to comment on anssi's swscale patch?
[22:57:32] <mru> http://patches.ffmpeg.org/patch/764/
[22:58:24] <lu_zero> I read it
[22:58:55] <lu_zero> I was about to when I got caught and translated outside ^^;
[22:59:32] <lu_zero> it might break my changes a little
[22:59:45] <lu_zero> but nothing that big I think
[23:18:26] <DonDiego> gnite
[23:27:33] <j-b> av500: these?
[23:28:42] <_av500_> these?
[23:29:07] <_av500_> ah, the hp ones with exploding speakers
[23:29:45] <j-b> av500: nah