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

[irc at mansr.com]

[00:48:38] <Compn> hahaha
[00:48:53] * Compn finds h264-in-ogg-in-avi
[00:49:04] <Compn> http://web.archive.org/web/20070924195347/www.leadcodecs.com/Download/H264/CarelessEnglish_540x264x237k.avi
[00:50:29] <Compn> where are my ogg buddies at ?
[00:58:12] <Compn> oh good, there are real avi versions too
[00:58:41] * Compn was afraid he was going to have to find some strange ogg program to demux ogg-in-avi
[01:00:02] <saintd3v> Compn: rofl
[01:10:32] <xxthink> http://www.pastebin.org/641127
[01:11:15] <xxthink> what does the line 4 in the pastebin mean ? this is some code from the handle_packet of ffmpeg
[01:12:37] <xxthink> because *p is the data type according to iso 138183-1
[01:13:12] <xxthink> if the data type is the PES packet, *p is the 1st byte of the start code of the PES packet
[02:08:25] <peloverde> Chrome managed to link without exploding my system, life is good
[02:43:33] <Compn> its probably a trap
[04:44:03] <peloverde> mind boggling http://forum.doom9.org/showthread.php?t=156287
[04:46:34] <Dark_Shikari> peloverde: he banned everyone who disagreed with him
[04:47:25] <drv> the thruth is out there
[04:47:56] <peloverde> I feel like I outgrew doom9 fiveish years ago
[04:50:01] <peloverde> But that whole thread seems full of stupid
[04:50:31] <peloverde> vaguely reminds me of the GNOMEies pimping Fluendo shit... only worse
[04:54:37] <peloverde> I think the real way to stick it to them is to make lavc fast
[05:04:19] <Yuvi> heh, it looks like openbsd backported the aes instructions for binutils
[05:04:22] <Yuvi> but not ssse3
[05:04:33] <Dark_Shikari> lol
[05:11:39] <peloverde> another reason to avoid gas?
[05:11:59] <Dark_Shikari> more like another reason to avoid bsd
[05:13:08] <peloverde> At least win64 has enough users to be worth bending over backwards for
[05:15:04] <Dark_Shikari> now this is funny
[05:15:12] <Dark_Shikari> x264 was crashing in deblocking despite me messing with trellis stuff
[05:15:14] <Dark_Shikari> it made no sense...
[05:15:20] <Dark_Shikari> and then I realized I had an array overflow on a function pointer array
[05:15:27] <Dark_Shikari> guess what function was immediately after the level-run coder...
[05:15:30] <Dark_Shikari> deblocking.
[07:41:37] <superdump> morning
[07:41:44] <kshishkov> morrow
[07:42:12] <elenril> dobré ráno
[07:42:17] <superdump> mru: i don't suppose marcelo sent an AMR-WB patch to -devel that got moderated because the attachment was too large did it?
[07:53:52] <saintdev> i have sound in long blocks \o/
[07:58:24] <saintdev> on that note, i think it was bedtime an hour ago :P
[08:08:43] <mru> superdump: nope
[08:19:23] <superdump> ok
[08:19:29] <superdump> thanks for checking
[08:19:31] <superdump> have fun :)
[08:52:36] <mru> let's see if the mips machine is happier with a cpu fan and no gdium on top of it
[09:00:07] <_av500_> it was a mips dual core stack before?
[09:00:22] <mru> yeah
[09:00:41] <mru> now the gdium is perched at an angle on top of the mac
[09:01:00] * mru needs a better server room
[09:01:03] <_av500_> post fate pics
[09:01:44] <mru> I also strapped an nvidia chipset fan to the sigma cpu
[09:01:47] * _av500_ has a well heated server room, but no servers...
[09:02:42] <_av500_> my sheeva cpu has a piece of thermo rubber on top, wonder what that is good for...
[09:04:14] <iive> keep it warm ?
[09:05:28] <mru> my sheevaplug is no longer a plug
[10:54:45] <mru> damn, still overheating
[10:55:10] <mru> maybe if I add a case fan too
[10:55:18] <mru> there are mounting holes...
[10:58:35] * pJok hands mru the liquid nitrogen
[11:23:49] <ods15> can someone explain to me what the "+" means in git fetch and push? I've read the description in the man page about 5 times and i still don't get it...
[11:47:55] <pengvado> ods15: what is there to explain? what a forced update is? how one could fail?
[11:48:31] <ods15> pengvado, figured it out, i didn't understand it simply meant "force"
[11:48:41] <ods15> the man page keeps saying "non fast forward update"
[11:48:53] <ods15> (i'm possibly out of date...)
[11:49:23] <ods15> pengvado, what does ffmpeg use? git-svn?
[11:50:54] <lu_zero> git-svn right now
[11:51:04] <CIA-93> ffmpeg: reimar * r24857 /trunk/MAINTAINERS: Add myself as maintainer for the PGS subtitle decoder.
[11:51:09] <pengvado> you mean what does it use on the server side to generate a git mirror of the svn repo?
[11:52:09] <lu_zero> each svn commit get converted
[11:52:11] <ods15> git push works?
[11:52:20] <lu_zero> right now no
[11:52:38] <ods15> and you can't really have git branches?
[11:52:50] <lu_zero> You canno push them
[11:52:53] <CIA-93> ffmpeg: reimar * r24858 /trunk/libavcodec/pgssubdec.c: Export the presentation video dimensions as avctx->width/avctx->height.
[11:53:30] <lu_zero> aas dev
[11:53:44] <ods15> what do you mean "right now no"? is there intention to drop the svn?
[11:56:52] <ods15> pengvado, so, currently, on every svn commit, the git repo does "git svn fetch"? and so everyone can use the git clone for read only?
[11:57:24] <ods15> sounds uncomftable for committing... do you use "git svn dcommit" for pushing?
[11:58:47] <lu_zero> brb
[12:00:23] <pengvado> I cloned mru's git repo before there was an official ffmpeg git mirror, and I never switched
[12:01:33] <pengvado> I do all my development in git, but commit to svn, not git-svn.
[12:01:51] <ods15> so you constantly copy patches?
[12:02:05] <pengvado> (on the rare occasion that I actually commit to ffmpeg, which I haven't done many times since switching to git)
[12:02:59] <ods15> umm.. does someone else commit for you? or do you just maintain your own branch on git for others to use? or do you just not do anything anymore like me? :)
[12:03:12] <ods15> (or am i missing a 4th option?)
[12:05:35] <pengvado> my major project (ffv2) is in a private branch. other than that, I have 7 commits this year, plus 4 patches that are mostly mine but were committed by other people.
[12:06:32] <ods15> so, do people clone from you? or is it completely private?
[12:07:23] <pengvado> I occasionally upload a copy of my repo to my server, but the copy I actually develop on isn't publically clonable.
[12:08:51] <pengvado> nnedi might count as another project using that model, since I plan to eventaully include it in swscale but it wasn't started as even part of the ffmpeg sourcetree, and so far is just in my git repo.
[12:12:48] <DonDiego> pengvado: i only found nnedi on doom9, are you user tritical there?
[12:13:43] <ods15> hya DonDiego
[12:14:56] <pengvado> I am referring to that same nnedi, but I'm not tritical
[12:15:00] <pengvado> http://forum.doom9.org/showthread.php?p=1427793#post1427793
[12:16:53] <DonDiego> ods15: don't kung-fu me with those "hya" shouts...
[12:18:06] <ods15> hya!
[12:20:57] * DonDiego steps aside and dodges the incoming ods15 ..
[12:34:02] <lu_zero> ^^?
[15:19:44] <CIA-93> ffmpeg: stefano * r24859 /trunk/libavcore/imgutils.c: Cosmetics: if( -> if (.
[15:19:46] <CIA-93> ffmpeg: stefano * r24860 /trunk/libavcodec/imgconvert.c: Cosmetics: remove useless ().
[16:34:34] * peloverde hates how every browser feels the need to invent its own build system
[16:34:58] * kshishkov hates building browsers anyway
[16:35:17] <kshishkov> once I tried building mozilla and ran out of free disk space
[16:37:41] <peloverde> since the chromium scaler appears to suck and libswscale is now LGPL everywhere, I was looking at replacing their scaler
[16:38:35] <kshishkov> sorry for creating such conditions
[16:39:14] <merbanan> kshishkov: did you get the package yet ?
[16:39:30] <kshishkov> merbanan: yes, on Wednesday, thank
[16:39:31] <kshishkov> s
[16:39:35] <merbanan> yey
[16:39:45] <merbanan> did the cheese survive ?
[16:39:51] <kshishkov> merbanan: though it's not enough for me :) So I'm going in person to get more
[16:39:59] <merbanan> hehe
[16:40:00] <kshishkov> yes, slightly deformed but overall fine
[16:40:48] <kshishkov> so any interested parties have time till Friday to leave Sweden
[16:41:22] <merbanan> when and where are you going ?
[16:42:15] <kshishkov> next Friday evening, ~22:00, Arlanda
[16:42:32] <merbanan> how long are you going to stay ?
[16:42:37] <kshishkov> two weeks
[16:43:01] <merbanan> ok ok, then we will have time to meet
[16:43:11] * kshishkov would prefer a lifetime though it's a bit unrealistic
[16:45:26] <kshishkov> merbanan: yes, I hoped so
[17:08:41] * kierank blames mru for the sky digibox packing up ;)
[17:38:55] <mru> kierank: I never worked on the Sky boxes
[17:39:02] <mru> in fact, I actively avoided them
[17:44:02] <kierank> that won't stop me from blaming you for it's failure ;)
[17:48:38] <ods15> mru, do you still commit to ffmpeg? do you use git svn dcommit?
[17:48:53] <mru> yes and yes
[17:49:08] <mru> nobody in their right mind still uses plain svn
[17:49:28] <ods15> i'm doing a slow migration of svn to git at work
[17:49:51] <ods15> heh, i still used svn until just about a month ago, and really, it wasn't that bad :) but i admit i enjoy git
[17:50:14] <mru> svn wasn't that bad once upon a time
[17:50:22] <mru> just like cvs wasn't that bad when it was new
[17:50:24] <mru> and rcs before it
[17:50:58] <ods15> never used rcs
[17:51:09] <peloverde> Now that the gsoc deadline has passed, can we switch?
[17:51:11] <ods15> and i'm amazed how little i remember about my short time with cvs
[17:51:33] <mru> peloverde: gsoc was never a concern for me
[17:51:40] <ods15> i remember it wasn't compressed by default, and you needed to pass "diff -u"...
[17:54:11] <ods15> mru, any general tips for the current slow migration i intend at work? most people will continue using svn, some will switch to git,main repo still svn
[17:54:48] <peloverde> mru: It was michael's concern, he said he was ok switching after soc was done
[17:55:06] <ods15> how do people use git-svn on the git clone from ffmpeg? they need all of the .git/svn/
[17:55:50] <peloverde> ods15: That is why I want to switch "for realz"
[17:56:29] <peloverde> You can't even rebuild the .svn info because it was a file:/// checkout
[17:57:00] <ods15> actually, git-svn kind of scares me - i saw non dtermenistic results from it!
[17:57:14] <mru> git-svn is ok
[17:57:22] <ods15> i have no idea why, and i even still have the old logs to prove it, 2 identical "git svn clones" gave me different results
[17:57:54] <ods15> it just randomly skipped commits, about 1 in a 1000
[17:57:56] <peloverde> git svn is ok as long as you don't have to collaborate with anyone besides the central repo
[17:59:24] <peloverde> in regard to the soc issue see https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/090534.html
[18:00:12] <peloverde> also using this as an chance to merge libswscale would be awesome too
[18:00:24] <peloverde> swscale always fucks up my git-bisect
[18:00:58] <ods15> why is the https on lists.mplayerhq.hu messed up... (gives firefox warning)
[18:01:48] <peloverde> It's not signed by a recognized CA
[18:02:23] <ods15> wasn't michael the one who advocated git in the first place? i vaguely recall
[19:05:43] <CIA-93> ffmpeg: rbultje * r24861 /trunk/ (5 files in 3 dirs):
[19:05:43] <CIA-93> ffmpeg: MMSH support, the most popular and widely used of all MMS variants. Written by
[19:05:43] <CIA-93> ffmpeg: Zhentan Feng <spyfeng gmail com> as part of Google's Summer of Code program.
[19:08:57] <Compn> huh
[19:09:06] <Compn> that one took a while :D
[19:12:20] <elenril> \o/?
[19:12:24] <merbanan> still awesome
[19:13:43] <ods15> why are vla's being removed?
[19:14:50] <funman> i assume fixed length arrays are simpler to allocate, and detecting stack overflows is easier too
[19:21:15] <Kovensky> ods15: I know mru classes them as "spawn of the devil" but I never asked the specifics :>
[19:22:22] <kierank> because if the array length is stupidly large for some reason you get a crash whereas with malloc you just error out
[19:22:37] <mru> and even if it works they are slower
[19:27:33] <iive> why are they slower?
[19:27:59] <mru> with gcc you lose a register
[19:28:51] <mru> multi-dimentional VLAs variable in anything but the outermost dimension require slower addressing
[19:32:03] <iive> even when other dimentions are fixed in size (and multiple of 2)?
[19:32:28] <iive> do you lose register if you use alloca instead?
[19:33:02] <mru> imagine char foo[2][x]
[19:33:14] <mru> now calculate &foo[1][2]
[19:33:39] <mru> &foo[1][0] is of course foo+x
[19:33:53] <mru> so &foo[y][0] is foo+x*y
[19:33:59] <mru> yes, multiplication
[19:34:26] <mru> alloca is just as evil btw
[19:34:41] <mru> it's almost exactly the same thing under a different name
[19:38:25] <CIA-93> ffmpeg: reimar * r24862 /trunk/libavcodec/truemotion1.c:
[19:38:25] <CIA-93> ffmpeg: Do not swap red and blue when decoding truemotion
[19:38:25] <CIA-93> ffmpeg: on big-endian.
[19:39:50] <funman> the GNU89 name?
[19:40:21] <mru> alloca is non-standard but widely supported
[19:40:50] <mru> memory from alloca remains allocated until the containing function returns
[19:41:02] <mru> VLAs are released when they go out of scope
[19:41:29] <CIA-93> ffmpeg: reimar * r24863 /trunk/libavcodec/truemotion1.c:
[19:41:29] <CIA-93> ffmpeg: Since the 24 bit format is decoded to endian-dependant
[19:41:29] <CIA-93> ffmpeg: BGR32 and not BGR24, do not swap red and blue on big-endian
[19:41:29] <CIA-93> ffmpeg: for this format as well.
[19:42:08] <iive> so if vla is not used in the function anymore it is released?
[19:43:33] <Kovensky> no, it's released when it goes out of scope :)
[19:43:40] <Kovensky> as in you can't possibly use it anymore
[19:45:36] <mru> I suppose the compiler might release whenever it can prove it won't be used again
[19:46:02] <mru> the important difference is if used in a loop, alloca() accumulates, VLA doesn't
[19:46:15] <mru> but more importantly, neither should be used, ever
[19:46:39] <ods15> <@mru> VLAs are released when they go out of scope - i'm not 100% sure about that
[19:46:47] <mru> I am
[19:47:20] <ods15> i vaguely remember looking at the assembly and seeing that gcc prepares some things in the begginning of the function in accordance to how many vla's are inside it
[19:47:27] <ods15> ok, you're sure then
[19:47:37] <mru> I didn't say they had no effect outside their scope
[19:47:52] <ods15> anyway, besides performance and possible crash, anything else bad about vla i should know?
[19:48:00] <mru> gcc sets up a frame pointer and such at the start of the function if there's a vla anywhere in it
[19:48:03] <ods15> (in what universe is vla slower than malloc?...)
[19:48:28] <mru> slower than fixed-size array
[19:48:38] <ods15> that's obvious
[19:48:39] <mru> and there is never a legitimate reason for using them
[19:48:53] <ods15> i differ on that opinion
[19:49:12] <mru> if you can prove the maximum size is acceptable for stack, use a statically-sized array of that size
[19:49:20] <mru> if you can't, you must use malloc anyway
[19:49:39] <ods15> anyway, i'll totally grant those 2 disadvantages, perf and safety (stack overflows truely are bad(tm)), i'm just wondering if there are other disdavantages i should be aware
[19:50:09] <mru> do you care about pre-c99 compilers?
[19:50:27] <ods15> not at work for sure
[19:50:43] <ods15> in general, barely.. iirc even 2.95 supports them
[19:50:50] <mru> btw, some compilers implement VLAs by calling malloc
[19:50:59] <ods15> (some older gcc's, 3.*, have issues with sizeof of vla..)
[19:51:32] <CIA-93> ffmpeg: reimar * r24864 /trunk/libavcodec/truemotion1.c:
[19:51:32] <CIA-93> ffmpeg: The 24-bit ydt also should not depend on endianness,
[19:51:32] <CIA-93> ffmpeg: since all of it ends up in a single 32-bit pixel.
[19:51:32] <CIA-93> ffmpeg: This seems likely to be wrong though, since it is different
[19:51:32] <CIA-93> ffmpeg: from the 15 and 16 bit modes and might explain the half-width
[19:51:32] <CIA-93> ffmpeg: issue for 24 bit truemotion.
[19:53:16] <ods15> that's interesting.. which? not gcc i expect
[19:53:28] <mru> no, not gcc
[19:54:57] <ods15> we have a bit of an odd rule at work, no malloc at runtime... i rarely need vla's, but i usually preffer them over some random MAX define
[19:55:12] <peloverde> hmm... sws is 12% faster than the chrome scaler
[19:55:49] <ods15> peloverde, which scaler does firefox use? libporn or whatever it use, is just for decoding?
[19:56:08] <peloverde> ods15: I don't do firefox
[19:56:41] <peloverde> chrome internals are hideous enough for mew
[19:57:03] <ods15> chrome took me hours to compile..
[19:57:21] <peloverde> chrome is very memory intensive to compile
[19:57:49] <peloverde> since i upgraded to 6GB it builds fairly quickly
[19:58:24] <mru> no malloc is a perfectly normal rule in a realtime system
[19:59:06] <ods15> mru, ok, didn't realize it was common
[20:01:02] <peloverde> I tend to prefer a no-malloc rule
[20:01:07] <mru> it's very hard to make any guarantees about malloc
[20:01:14] <mru> simpler to just not use it
[20:01:56] <mru> a pool allocator can be acceptable
[20:02:02] <mru> if you can prove you never run out
[20:04:11] <ods15> yeah, we constantly use pools, and it's then not a matter of proving, just a matter of setting maximums...
[20:11:39] <Kovensky> <@peloverde> chrome is very memory intensive to compile <-- and to run
[20:11:46] <Kovensky> even firefox uses less ram than it :/
[20:11:53] <peloverde> RAM is cheap
[20:11:59] <Kovensky> DDR400 isn't
[20:14:56] <mru> who uses ddr400?
[20:14:58] <Compn> i have some laptop ram, but i dont know if it will work with michaels' laptop
[20:15:53] <Compn> that ram with the LEDs are strange man
[20:16:05] <Compn> green/red leds to tell you if your memory is good/bad haha
[20:17:36] <ismail> I am not even sure over-expensive macbook pros have DDR400
[20:18:39] <J_Darnley> mru: people with athlon64's, etc
[20:19:00] <mru> who uses athlon64?
[20:19:12] * J_Darnley raises his hand
[20:19:21] <Kovensky> mru: every computer in here but the craptop (ddr2) and the new one (ddr3) use ddr400
[20:19:27] <Kovensky> and they have semprons
[20:31:25] <BBB> I hope I can sort-of push zhentan to finish mmsu at least, even though soc is over...
[20:31:51] <cartman> how many projects successfully done ?
[20:31:58] <BBB> all 7
[20:32:08] <BBB> not all are completely finished, but most are functional at least
[20:32:13] <BBB> i.e. on the roads to being submitted to svn
[20:32:23] <peloverde> wow
[20:32:40] <BBB> I think amrwb is the most widely anticipated
[20:32:47] <cartman> indeed :)
[20:33:01] <BBB> it's functional, being reviewed now, then will go to -devel for inclusion
[20:33:12] <BBB> form what I understand at least
[20:33:27] <BBB> then we can remove opencore and will have completely LGPLv2.1-compatible amr decoding stack
[20:33:44] <mru> I don't like the mod player
[20:33:54] <BBB> code, or person?
[20:33:56] <mru> both
[20:34:01] <BBB> I knew you'd say that
[20:34:05] <mru> I get the feeling he's trying dump a crapton of old code into ffmpeg
[20:34:25] <mru> without proper design or code review
[20:34:27] <cartman> \o/
[20:34:29] <BBB> that's why I'm trying to stop stefano from committing it so "we can work on it in svn"
[20:34:38] <BBB> and I'm pushing for patches for review
[20:34:48] <BBB> not "here's a patch for lavseq versioning"
[20:34:52] <mru> yeah
[20:35:11] <BBB> but rather "here's all patches, here's what they are required for, here's what they do and let's review what parts are really neessary for a function such as mod file playback"
[20:35:18] <cartman> wmv3 encoder done too?
[20:35:22] <BBB> but most people don't quite get that, and of course it's a lot of work...
[20:35:24] <BBB> cartman: ?
[20:35:38] <cartman> looking at http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010
[20:35:42] <cartman> guess thats outdated
[20:35:52] <BBB> right
[20:35:59] <BBB> not all of those were accepted ;)
[20:36:01] <BBB> they were ideas
[20:36:09] <cartman> uhm ok :)
[20:36:14] <kierank> dolby e is near completion too
[20:36:20] <kierank> just need to fix some more bugs
[20:36:34] <BBB> http://socghop.appspot.com/gsoc/org/home/google/gsoc2010/ffmpeg
[20:37:14] <cartman> G.723.1 Decoder/Encoder is nice too
[20:37:20] <BBB> kierank: is it helpful if I go thorugh the code as it is now for a basic review?
[20:37:22] <cartman> LGPL ftw!
[20:37:33] <BBB> he finished the encoder also
[20:37:36] <BBB> that's really awesome
[20:37:49] <BBB> I hope he keeps contributing, he's quite smart, and we can use more such encoders, if they're good
[20:37:59] <kierank> BBB: not with the current patch you have because it's changed a lot
[20:38:06] <BBB> ok...
[20:39:00] <cartman> if all the decoding bits are LGPL that would be quite a win :)
[20:40:02] <BBB> I'm quite sure all is lgpl :)
[20:40:13] <cartman> amr was missing :)
[20:41:01] <BBB> so many things are still missing
[20:41:12] <BBB> that's work ;)
[20:41:40] <cartman> many? whats missing except amr?
[20:41:50] <BBB> dolby-e :-p
[20:42:06] <cartman> uhm
[20:42:10] <cartman> ok :P
[20:42:17] <BBB> wmv3 (not vc1), vp6 several frame types, wmv2 some weird frame type
[20:42:23] <BBB> vp7
[20:42:35] <BBB> is that enough, or do you want more?
[20:42:46] <BBB> wma lossless, realaudio lossless
[20:42:51] <cartman> BBB: beats me
[20:44:32] <iive> BBB: wmv2 is complete
[20:44:44] <BBB> oh
[20:45:55] <ods15> wtf is this... http://www.openpkg.org/product/packages/?package=libnut
[20:46:03] <ods15> "Vendor  Oded Shimon et al."
[20:46:27] <cartman> you are such a vendor ods15
[20:46:35] <ods15> lol
[20:48:30] <BBB> iive: I thought one frame type was not implemented?
[20:49:46] <cartman> BBB: yeah thats fixed long time ago
[20:49:51] <cartman> by anonymous the mad coder
[20:49:59] <cartman> I love anonymous
[20:51:28] <BBB> well the others are still standing :-p
[20:51:58] <cartman> yeah anonymous is slacking
[20:52:05] <pJok> i know what is missing...!
[20:52:15] <pJok> 8bit RLE!
[20:52:23] <pJok> (encoder)
[20:58:17] <CIA-93> ffmpeg: vitor * r24865 /trunk/tests/ (ref/fate/ansi fate2.mak): Add FATE test for ANSI/ASCII animation and TTY demuxer
[20:59:54] <BBB> ascii video codec
[20:59:57] <BBB> that's what we need
[21:01:08] <cartman> yeah ascii pr0n perverts
[21:01:57] <BBB> well at least modern shells give you color ascii pr0n
[21:07:31] <peloverde> Expression Screen Codec, ProRes, Apple Intermediate
[21:14:41] <peloverde> Is there a description of SWS_FAST_BILINEAR vs SWS_BILINEAR anywhere?
[21:18:43] <Kovensky> fast is probably faster than the non-fast one, unless it's like the FAST_MODE code, then the non-fast one is faster
[21:24:30] <peloverde> Is there a quality difference?
[21:24:44] <peloverde> Is there any documentation?
[21:25:27] <peloverde> Who allowed swscale to become part of FFmpeg without appropriate documentation?
[21:26:04] <peloverde> I thought people were just complaining about "dump[ing] a crapton of old code into ffmpeg"
[21:32:56] <BBB> peloverde: ask user questions on ffmpeg-user :-p </waiting to be kickban'ed>
[21:33:25] <BBB> I thought swscale was pretty ok'ishly documented btw?
[21:35:48] <peloverde> The quality flags seem to have no documentation unless I'm looking in the wrong place
[21:39:00] <peloverde> hmmm... I had done a debug build my mistake, chromium bilinear seems much faster than SWS_FAST_BILINEAR unless I'm still doing something wrong
[21:40:05] <peloverde> There is this but it's pre-pure-LGPL swscale: http://www.bluishcoder.co.nz/2010/02/19/comparing-colour-space-conversion-libraries.html
[21:50:43] <BBB> does chromium use our code?
[21:50:50] <peloverde> not at the moment
[21:50:57] <BBB> what's their license?
[21:51:07] <peloverde> Something BSD-ish
[21:51:12] <BBB> take it
[21:53:16] <Kovensky> isn't libswscale a pile of stuff nobody ever wants to look at
[21:53:50] <kierank> get google to pay for lgpl
[21:54:07] <peloverde> swscale is lgpl
[21:56:17] <kierank> is all the asm lgpl now too?
[21:56:41] <peloverde> This whole thing is screwy i'm, getting valgrind errors not just in swscale but in their scaler too, and for their scaler I'm using their unmodified test code
[21:56:46] <peloverde> kierank: yes
[21:57:11] <kierank> oh, didn't know that
[22:04:16] <BBB> if the asm is lgpl and google's bsd chromium code is still twice as afst
[23:08:19] <kierank> anybody going to this: http://www.foms-workshop.org/foms2010OVC/
[23:09:36] <mmu_man> over the ocean for me
[23:11:24] <kierank> we should have a proper one in europe
[23:12:00] <kierank> with blackjack and...
[23:13:22] <kierank> that one looks like the real xiphcon