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

[irc at mansr.com]

[00:02:02] <Kovensky> I have only seen two options in ffms2theora when I tried it
[00:02:09] <Kovensky> both were ratecontrol related
[00:02:16] <Dark_Shikari> yes, you can pick the bitrate or quality
[00:02:18] <Dark_Shikari> and 2-pass or not
[00:02:20] <Dark_Shikari> and gop size.
[00:02:21] <Dark_Shikari> and that's it.
[00:02:30] <Dark_Shikari> vbv?  why would anyone want _that_?
[00:02:32] <Kovensky> oh, there was gop size
[00:03:01] <Kovensky> Dark_Shikari: the 2-pass thing is moot, at least according to Daiz
[00:03:11] <Kovensky> ffms2theora instacrashes on pass=2
[00:04:02] <Dark_Shikari> lol
[00:04:07] <Dark_Shikari> don't compare moot to theora
[00:04:10] <Dark_Shikari> moot is much better
[00:04:12] <Yuvi> you can also choose to do no ME or disable fast skip
[00:04:44] <mru> lol
[00:10:28] <CIA-34> ffmpeg: michael * r21844 /trunk/libavcodec/h264_cabac.c: Drop a few redundant slice_num checks.
[00:17:41] <peloverde> Odd that the FOSDEM talks are all in xvid avi... At least it's not ogg
[00:18:08] <Dark_Shikari> lol xvid
[00:18:27] <Yuvi> the live broadcast was wmv with swapped uv planes iirc
[00:18:31] <Dark_Shikari> lol
[00:18:35] <Dark_Shikari> WMV
[00:18:38] <Dark_Shikari> from FOSDEM
[00:18:39] <Honoome> uhm interesting read about extern inlines and SunCC… although I still find the whole thing braindamaged
[00:18:59] <Honoome> Yuvi: really? okay next year me and lu_zero need to manage that :P
[00:19:50] <peloverde> Dark_Shikari: the freetards love WMV because you can buy a plugin from fluendo
[00:20:07] <Dark_Shikari> lol
[00:20:17] <BBB> I always found that funny
[00:20:26] <BBB> fluendo can just use free software, like ffmpeg, stamp a license on it
[00:20:29] <BBB> and we're all happy
[00:20:45] <BBB> but somehow they reagainreinvented the wheel and everyone is happy
[00:21:00] <Dark_Shikari> no, pretty much just the freetards are happy
[00:21:01] <peloverde> some people question that interpretation of theLGPL2
[00:21:08] <Dark_Shikari> all the people who actually care about open source aren't happy
[00:21:21] <Dark_Shikari> it's sad that the biggest threat to open source is from people who claim to support it
[00:21:23] <Honoome> BBB: I guess it's sorta like the RMS and his selling of indulgences for dual-licensed software
[00:21:42] <Dark_Shikari> but I guess that's always true.
[00:23:12] * Honoome had a fight tonight as well with an acquaintance of his… “Silverlight is proprietary, Flash was better”…
[00:23:29] <Dark_Shikari> lol
[00:23:34] <Dark_Shikari> Technically, flash actually is open
[00:23:35] <Honoome> too bad that we have a silverlight-compatible full implementation that works, and is free software… yet we have none complete for Flash…
[00:23:47] <BBB> when the tax stuff is done, I'll go to the sflc and put some stuff on paper for good money
[00:23:54] <BBB> then fun starts
[00:24:09] <BBB> put it on planet.gnome, just a scan, and let hell break loose
[00:24:32] <peloverde> I tend to try to avoid both of them when possible
[00:24:34] <Dark_Shikari> BBB: want a contribution?
[00:24:59] <BBB> always
[00:25:10] <Honoome> peloverde: me as well but if I have to choose I pick the one that I can look at the source of ;)
[00:25:10] <BBB> patent numbers are welcome ;)
[00:26:30] <peloverde> OTOH, flash is proliferated enough that I need it
[00:26:38] <peloverde> Also I thought moonlight doesn't support silverlight DRM
[00:26:53] <Honoome> I think they are working on it
[00:27:03] <Dark_Shikari> lol
[00:27:09] <Dark_Shikari> freetards supporting drm
[00:27:26] <Honoome> but for the case in place that I ended up fighting about (Italian national TV) there is no DRM
[00:27:29] <Honoome> and works pretty well with Moonlight
[00:27:49] <peloverde> If hulu offered silverlight and didn't require the DRM I'd gladly choose that option
[00:28:07] <peloverde> but my guess is that they would require it should they go that route
[00:28:24] * Honoome lives outside US so … nothing there anyway
[00:30:01] <peloverde> Also another thing that irks me about silverlight is streaming sites that require it and just stream mp4, why not offer quicktime plugin or flash or <video>, why do i need to install yet another plugin to view your shit. You can serve the same assets to all of the above
[00:30:41] <mru> and then there's the theora decoder running on the mono vm...
[00:30:55] <Dark_Shikari> lol
[00:31:01] <mru> it's been done
[00:31:07] <Honoome> peloverde: I love greasemonkey for that
[00:31:28] <mru> I don't know exactly what he did
[00:31:34] <peloverde> the quality of theora with the speed of managed code, you can't lose
[00:32:43] <Dark_Shikari> lol
[01:58:41] <Yuvi> I could've sworn clang required an = with -isysroot, now it only works without one
[02:52:24] <CIA-34> ffmpeg: michael * r21845 /trunk/libavcodec/h264_cabac.c: 2 cpu cycles faster context calculation for decode_cabac_intra_mb_type()
[06:38:40] <elenril> morning
[06:42:48] <kshishkov> god morgon
[06:43:08] <KotH> moikka moi
[06:47:05] * elenril looks around for volunteers to apply his patch
[06:47:37] <kshishkov> try with banana
[06:49:19] * elenril puts a <banana> in the channel
[07:17:51] <andoma> mru: a classic ... imagine what happend at the office when the ppl around here found out :)
[09:23:07] <mru> morning
[09:23:15] <kshishkov> god morgon
[09:24:36] <pJok> god morgen
[09:25:40] <av500> Guten Morgen
[09:29:29] <kshishkov> mate!
[09:30:46] <pross-au> Hey
[09:32:45] <kshishkov> looks like BIKb should be made as totally separate decoder
[09:34:04] <pross-au> Yeah?
[09:34:20] <pross-au> there is no dct
[09:34:35] <kshishkov> that's not the problem
[09:34:49] <CIA-34> ffmpeg: pross * r21846 /trunk/libavcodec/iff.c: Support <8-bit ILBM uncompressed bitmaps
[09:34:54] <kshishkov> coding methods could be piled up during those years
[09:35:35] <kshishkov> but in your case almost everything differs
[09:36:46] <pross-au> oh okay
[09:37:35] <pross-au> so we'll need CODEC_ID_BINK_B ?
[09:37:41] <kshishkov> yes
[09:38:28] <pross-au> imho you should s/CODEC_ID_BINK/CODEC_ID_BINKVIDEO/g
[09:38:49] <kshishkov> I do already
[09:39:01] <pross-au> some years ago, i searched high & low for other BIK'x' revisions
[09:39:10] <pross-au> couldnt find any
[09:40:46] <kshishkov> you can try the whole list of games using RAD codecs
[09:41:48] <pross-au> I've tried a lot
[09:41:52] <pross-au> haha
[09:42:01] <pross-au> BIKd ?
[09:42:41] <kshishkov> never seen that
[09:42:49] <kshishkov> let's see for the samples... http://radgametools.com/binkgames.htm#games
[09:42:59] <pross-au> somebody has put it on the multimedia wiki
[09:43:21] <pross-au> ah it was vlad
[09:56:47] <CIA-34> ffmpeg: pross * r21847 /trunk/libavformat/iff.c: Support IFF ANNO (annotation) chunk type
[10:20:55] <B4gder> regarding my previous visit here about a "Rockbox and ffmpeg coordination effort", here's what's been discussed in the R camp http://www.rockbox.org/mail/archive/rockbox-dev-archive-2010-02/0019.shtml
[10:22:01] <Dark_Shikari> avoiding forks sounds good
[10:22:19] <B4gder> yes indeed, nobody wins on forks in the long run
[10:22:42] <mru> good, first objective achieved
[10:22:50] <B4gder> Mike and Mohamed to reply in that thread are both codec hackers
[10:22:56] <B4gder> who reply
[10:23:54] <mru> why do you guys split the codecs like that?
[10:24:00] <B4gder> split?
[10:24:03] <mru> "Porting codecs to rockbox generally entails isolation of the codecs, ..."
[10:24:07] <av500> mru: there is infrastructure in ffmpeg to select fixed vs float codec? at build time?
[10:24:28] <mru> all codecs in ffmpeg are either fixed-only or float-only
[10:24:29] <B4gder> ah yes, because we pick each codec on their own merit
[10:24:41] <B4gder> so when we get a codec from ffmpeg, we get only that single one
[10:24:44] <mru> ffmpeg has configure flags to enable only what you want
[10:25:44] <B4gder> and also, I think those are questions and thoughts worth to discuss if we can find a way to better work so both teams get happier
[10:26:09] <mru> if our configure options are not sufficient, that's something we can work on
[10:26:17] <mru> I know they can be improved in some areas
[10:26:42] <av500> there is the no-malloc issue of rb codecs, no?
[10:26:48] <B4gder> yes
[10:26:54] <mru> we don't use malloc all that much
[10:27:05] <Dark_Shikari> why no malloc?  malloc-everything-at-start is equivalent to alloca
[10:27:11] <B4gder> but the truth is we actually have some "fake malloc" to work with some of them
[10:27:19] <Dark_Shikari> no _dynamic allocation_ makes sense
[10:27:21] <Dark_Shikari> no _malloc_ does not
[10:27:21] <B4gder> we have no malloc at all
[10:27:28] <Dark_Shikari> B4gder: sure you do
[10:27:29] <B4gder> we have fixed buffers
[10:27:32] <Dark_Shikari> you have things that are effectively malloc
[10:27:40] <Dark_Shikari> a fixed buffer is a kernel malloc on load
[10:27:52] <B4gder> not quite
[10:28:00] <mru> Dark_Shikari: that assumes you *have* a kernel
[10:28:08] <Dark_Shikari> mru: rockbox runs on ipods, not 8-bit microcontrollers
[10:28:26] * mru is working on a project with ffmpeg on a tiny rtos
[10:28:31] <Dark_Shikari> Yeah, but this isn't that =p
[10:28:44] <mru> there is malloc though...
[10:28:55] <mru> or enough of one at least
[10:29:06] <av500> you can always fake a malloc from a small fixed heap...
[10:29:13] <B4gder> exactly
[10:29:14] <Dark_Shikari> again
[10:29:15] <mru> av500: that's not fake
[10:29:18] <av500> tear down the heap after your tear down the codec
[10:29:21] <Dark_Shikari> there are two things meant by malloc
[10:29:23] <Dark_Shikari> "dynamic allocation
[10:29:26] <Dark_Shikari> and "allocation"
[10:29:31] <Dark_Shikari> banning dynamic allocation is fine
[10:29:38] <Dark_Shikari> banning allocation just means the coder will find another way to do it
[10:29:43] <mru> on blackfin I use a dedicated chunk of ram for ffmpeg heap
[10:29:45] <Dark_Shikari> which will be a malloc disguised under a different name
[10:30:01] <Dark_Shikari> and NO decoder in ffmpeg should use dynamic allocation
[10:30:03] <mru> and another chunk for bss
[10:30:05] <Dark_Shikari> without very good reason
[10:30:05] <B4gder> Dark_Shikari: I said no malloc, I didn't say no allocation
[10:30:05] <av500> B4gder: but your codecs dont all use the "fake" approach, right?
[10:30:13] <Dark_Shikari> B4gder: malloc is allocation
[10:30:15] <B4gder> most of them don't
[10:30:17] <Dark_Shikari> other forms of allocation are disguised mallocs
[10:30:24] <B4gder> Dark_Shikari: ?
[10:30:30] <Dark_Shikari> alloca increases stack size
[10:30:30] <B4gder> read my words again
[10:30:34] <Dark_Shikari> increasing stack size results in a kernel malloc
[10:30:37] <B4gder> we have allocation, not malloc
[10:30:42] <mru> Dark_Shikari: not necessarily
[10:30:46] <Dark_Shikari> All allocations are mallocs somewhere
[10:30:51] <Dark_Shikari> mru: yes obviously if the stack is already large enough, etc
[10:30:51] <KotH> Dark_Shikari: "no malloc" == no heap
[10:30:59] <Dark_Shikari> KotH: there's always a heap
[10:31:02] <B4gder> no allocations do not imply malloc
[10:31:04] <KotH> Dark_Shikari: nope
[10:31:04] <Dark_Shikari> it just might not be _your_ heap.
[10:31:13] <mru> Dark_Shikari: and you can easily forbid growing the stack
[10:31:22] <Dark_Shikari> mru: but you still declare a static stack size
[10:31:26] <Dark_Shikari> and that static stack size is a malloc
[10:31:29] <KotH> Dark_Shikari: in embedded apps you avoid heaving a heap because of its properties to fail allocation
[10:31:29] <Dark_Shikari> it's just in kernelspace.
[10:31:34] <mru> Dark_Shikari: not always
[10:31:38] <Dark_Shikari> KotH: again, you're entirely missing the point
[10:31:41] <Dark_Shikari> static allocation cannot fail
[10:31:42] <KotH> Dark_Shikari: could be
[10:31:43] <mru> it can be a static link-time allocation
[10:31:46] <Dark_Shikari> even if you're using malloc
[10:31:55] <KotH> Dark_Shikari: yes
[10:32:02] <Dark_Shikari> link-time allocation is done in the kernel.
[10:32:04] <Dark_Shikari> ... via malloc
[10:32:06] <mru> no
[10:32:09] <mru> it's done by the linker
[10:32:12] <mru> static linker
[10:32:17] <B4gder> exactly
[10:32:27] <Dark_Shikari> mru: but it still has to allocate something somewhere
[10:32:28] <Dark_Shikari> it's not magic
[10:32:31] <mru> output is a flat image you can dump wherever you like
[10:32:42] <Dark_Shikari> mru: and the image has to be allocated
[10:32:50] <KotH> Dark_Shikari: have you ever worked with deep embedded apps ? ie apps that do run on bare metal, no OS, no kernel, no helper libs?
[10:32:57] <mru> in embedded systems its commonplace to statically link *everything* into a single image
[10:33:01] <mru> OS and all
[10:33:11] <Dark_Shikari> KotH: but we're not on such an app.
[10:33:16] <mru> we can be
[10:33:17] <Dark_Shikari> the ipod is not a "deep embedded" system
[10:33:21] <B4gder> it is
[10:33:23] <KotH> Dark_Shikari: er.. rockbox is such an app
[10:33:34] <Dark_Shikari> KotH: er, no...
[10:33:40] <Dark_Shikari> I'm pretty sure rockbox doesn't run on 8-bit microcontrollers
[10:33:42] <Dark_Shikari> with no ram
[10:33:50] <mru> no, but it runs on 32-bit micros
[10:33:52] <av500> Dark_Shikari: it runs on 32bit micros with no ram
[10:33:55] <KotH> Dark_Shikari: you dont need an 8 bit uC to do such stuff
[10:33:57] <Dark_Shikari> the ipod has ram
[10:34:05] <av500> it runs on 2MB, no os
[10:34:05] <mru> nothing runs w/o ram
[10:34:14] <Dark_Shikari> the ipod runs without an OS?
[10:34:16] <pross-au> nothing runs without tape
[10:34:17] <Dark_Shikari> then how can it run apps?
[10:34:23] <mru> Dark_Shikari: old ipod
[10:34:23] <Dark_Shikari> magic pixie dust?
[10:34:26] <av500> Dark_Shikari: it is not an ipod app
[10:34:27] <Dark_Shikari> Ah, old ipod
[10:34:28] <KotH> Dark_Shikari: at the company i work for, we only write such apps... on arm7 and cortex-m3 uC
[10:34:30] <Dark_Shikari> av500: I know
[10:34:31] <mru> not the touch
[10:34:48] <Dark_Shikari> also, really, 2MB?  I recall hearing that the ipod software was >1mloc
[10:34:59] <av500> Dark_Shikari: rb runs on jb6000 with 2mb
[10:35:03] <mru> Dark_Shikari: which ipod?
[10:35:07] <Dark_Shikari> mru: true, don't know about that.
[10:35:14] <Dark_Shikari> av500: well 2mb should be enough for anyone.
[10:35:16] <mru> the original ipod was tiny
[10:35:32] <Dark_Shikari> and really, all you have to do is as follows:
[10:35:43] <Dark_Shikari> 1) Ensure the audio decoder has static allocation only (i.e. mallocs all at start, predictable)
[10:35:46] <av500> Dark_Shikari: well, the 2mb are only there for buffering, the original design had 256k :)
[10:35:50] <Dark_Shikari> 2) Calculate how much it will need.
[10:35:54] <B4gder> Dark_Shikari: I think you're missing the point
[10:36:00] <Dark_Shikari> 3) Make a wrapper function that overrides malloc and runs off a static heap
[10:36:06] <Dark_Shikari> 4) Bam, done, now you don't have to rewrite ffmpeg
[10:36:14] <B4gder> and that attitude is not helping
[10:36:16] <mru> replacing malloc in ffmpeg is trivial btw
[10:36:19] <Dark_Shikari> mru: exactly
[10:36:26] <Dark_Shikari> my point being you should never have to modify decoder code to do that
[10:36:27] <mru> configure --malloc-prefix=foo
[10:36:36] <Dark_Shikari> all you have to do is calculate how much space you need
[10:36:37] <av500> mru: or at link time
[10:36:38] <Dark_Shikari> override malloc
[10:36:54] <Dark_Shikari> obviously the decoders have to be well-behaved, but that's a separate issue
[10:36:54] <B4gder> if this is gonna work, you need to realize that we're willing to cooperate, not simpyl doings things the way you think is the best
[10:37:02] <Dark_Shikari> B4gder: I'm making a suggestion
[10:37:12] <B4gder> yes, but you're not listening
[10:37:16] <Dark_Shikari> no, you're not listening
[10:37:21] <B4gder> I do
[10:37:23] <Dark_Shikari> I'm telling you in 3 lines of code or so, you can eliminate all the mallocs
[10:37:26] <Dark_Shikari> and get your static heap
[10:37:29] <Dark_Shikari> without modifying ffmpeg
[10:37:32] <B4gder> hahaha
[10:37:38] <B4gder> ok, forget I tried
[10:37:40] <Dark_Shikari> As long as the decoder is well-behaved.
[10:37:58] <mru> some people just don't want to talk
[10:38:02] <Dark_Shikari> pretty much.
[10:38:16] <Dark_Shikari> seriously, come into a channel and tell the project how they should run things
[10:38:20] <Dark_Shikari> how they should write their code
[10:38:28] <mru> that's not quite what he was doing
[10:38:41] <mru> he was saying they have to modify our code to be able to use it
[10:38:46] <mru> and didn't give good reasons for it
[10:39:22] <Dark_Shikari> sounds like a lot of projects that use ffmpeg
[10:39:24] <Dark_Shikari> for that matter, a lot of distros
[10:40:14] <Honoome> distros get to it mostly from the projects
[10:40:44] <Honoome> when we have need to have a specific FFmpeg revision, say, trunk rather than 0.5 branch, is often because some other project only works with that, e.g. x264, to call up one :P
[10:41:47] <pross-au> its far easier to fork stuff then to cooperate
[10:41:52] <pross-au> that's why it happens
[10:41:54] <merbzt> yes :/
[10:44:37] <mru> pross-au: easier short-term
[10:44:42] <mru> long-term it's pure pain
[10:44:54] * mru used work in a fork shop
[10:45:16] <pross-au> rockbox is hardly short-term
[10:46:22] <mru> hi Zagor
[10:46:32] <Zagor> hi
[10:48:56] <KotH> Zagor: Zagor as the comic Zagor?
[10:49:57] <Zagor> heh, no. Zagor as the randomly invented name sometime in the mid-80s.
[10:51:57] <KotH> then you might want to read the comic once, as it predates you :)
[10:52:25] <Zagor> yeah, I know about it
[10:52:54] <Zagor> I didn't for the first 15 years of using the nick, though :)
[10:53:49] <merbzt> we sort of scared away your brother a few minutes ago
[10:54:09] <mru> he'll be back
[10:54:17] <merbzt> :)
[10:54:26] <Dark_Shikari> he will.  I've been chatting to him via pm.
[10:55:09] <mru> did you explain that you're a bull-headed, arrogant bastard, and there's nothing to be done about that? ;-)
[10:55:10] <Zagor> yeah, I sort of wanted to listen to the discussion
[10:55:37] <Dark_Shikari> mru: lol
[10:55:52] <Dark_Shikari> we talked and we went over various things e.g. what ffmpeg needs from rockbox for this
[10:55:54] <merbzt> mru talking to himself again :)
[10:56:03] <Dark_Shikari> here's a paste of one bit
[10:56:04] <Dark_Shikari> 18:48 <Dark_Shikari> I would start by putting together:
[10:56:04] <Dark_Shikari> 18:49 <Dark_Shikari> 1) a set of rockbox patches (i.e. what rockbox changes)
[10:56:08] <Dark_Shikari> 18:49 <Dark_Shikari> 2) a set of things that would be necessary for rockbox to use libavcodec directly instead of slashing out codecs
[10:56:11] <Dark_Shikari> 18:49 <Dark_Shikari> for example, "disabling codecs needs to work better" would
[10:56:15] <Dark_Shikari> 18:50 <Dark_Shikari> 3) a set of needs that rockbox has, i.e. things it would like ffmpeg devs to keep in mind when writing new audio decoders
[10:56:18] <Dark_Shikari> 18:50 <Dark_Shikari> 4) a set of specific things that it would like changed (can probably be included as a summary of 1) ) with regard to any existing decoders that it makes significant use of.
[10:56:22] <Dark_Shikari> 18:51 <Dark_Shikari> the eventual goal should be to make ffmpeg Do What You Need without changes.
[10:56:47] <merbzt> ffmpeg needs fixed point execution paths
[10:56:52] <kshishkov> or add a bit of glue to FFmpeg to replace RockBox completely :P
[10:57:27] <Zagor> kshishkov: haha, good luck with that
[10:57:49] <kshishkov> fair enough, MPlayer goes first
[10:57:52] <Dark_Shikari> lol
[10:58:45] <Zagor> Dark_Shikari: 2) will likely never happen. we run each codec separately in order to optimize them as much as we can
[10:59:05] <Zagor> for example sram usage is a major issue
[10:59:17] <mru> codecs in ffmpeg *are* separate
[10:59:24] <mru> they just share some common code
[10:59:46] <Zagor> ok, then what does "slashing out codecs" mean?
[11:00:05] <mru> what rockbox is doing ;-)
[11:00:32] <mru> picking out just the files needed by a specific codec and patching it up to build
[11:00:56] <av500> Zagor: hi
[11:01:13] <Dark_Shikari> Zagor: we want to optimize them as much as we can too
[11:01:14] <Zagor> av500: hi
[11:01:17] <av500> KotH: and I thought I am the only other person that read Zagor comics...
[11:02:33] * kshishkov wonders what happened to make so many RockBox devs come here
[11:03:30] <av500> kshishkov: friendly chatter
[11:04:02] <Compn> someone must have offered them some beer at fosdem? :P
[11:04:15] <twnqx> lol
[11:04:22] <kshishkov> av500: still a bit suspicious
[11:05:33] <KotH> av500: in late 70s, early 80s, they were quite famous in .tr... and that's the way i got my hands on them
[11:05:46] <av500> KotH: they were too in .yu :)
[11:05:51] <Dark_Shikari> beer?  more like whiskey, they must be on some serious alcohol to consider dropping by here ;)
[11:05:52] <mt> kshishkov:  I've been around for months, I just don't talk that much. :)
[11:05:55] * Dark_Shikari runs
[11:06:05] <Zagor> I feel a bit like I'm restarting the discussion from scratch here, which was not my intention.
[11:06:15] <KotH> Dark_Shikari: you are aware that optimizing for low ram footprint can mean to make a codec less cpu efficient?
[11:06:21] <Honoome> Dark_Shikari: you lost on lu_zero bringing Troll Beer :P
[11:06:27] <kshishkov> mt: yes, I know
[11:06:30] <Dark_Shikari> KotH: you can do both.
[11:06:43] <Dark_Shikari> we have CONFIG_SMALL
[11:06:44] <KotH> Dark_Shikari: but not always
[11:06:46] <Dark_Shikari> why not CONFIG_LESS_RAM?
[11:06:51] <KotH> ah.. ok
[11:06:54] <KotH> that'd be a good idea
[11:06:56] <Dark_Shikari> :)
[11:07:01] <kshishkov> KotH: golden rule of computing - you can lose in memory or speed (or both)
[11:07:13] <KotH> kshishkov: lol
[11:07:17] <Dark_Shikari> also, I doubt most decoders use that much ram
[11:07:20] <Dark_Shikari> I mean, it's audio, it's easy
[11:07:27] <Dark_Shikari> does rockbox do video at all btw?
[11:07:32] <Dark_Shikari> if not, they have it easy ;)
[11:07:32] <Honoome> kshishkov: the “or both” refers to theora I guess? :D
[11:07:46] <Zagor> Dark_Shikari: some, but not in the same codec structure
[11:07:55] <Zagor> we have an mpeg player plugin
[11:07:55] <KotH> Dark_Shikari: "that much" depends highly on your enviroment
[11:08:00] * kshishkov fears ot tell Honoome there are reference decoders in existence
[11:08:01] * Dark_Shikari looked at rockbox for his crappy $30 player but it didn't really support it properly, it required reinstalling original firmware to use USB
[11:08:09] <KotH> Dark_Shikari: something that uses 1k of mem in one of our apps here, is _A_DAMN_LOT_
[11:08:19] <Dark_Shikari> KotH: yeah, but music players generally have more than 1k.
[11:08:30] <KotH> Dark_Shikari: how much do you think?
[11:08:36] <Honoome> kshishkov: oh shush I'm just taking a cheap shot at xiph as usual ^^;; yes I'm definitely ranty about them since I had to deal with libtheora/libvorbis in Gentoo and with FLAC format on xine
[11:08:39] * twnqx recently saw a mp3 player software for the commodore c64
[11:08:41] <KotH> Dark_Shikari: the one i have has a coupl of 10k of ram
[11:08:46] <Dark_Shikari> KotH: 32K to 2MB I would guess
[11:08:48] <Dark_Shikari> is the distribution
[11:09:16] <Dark_Shikari> at 32K I'd start getting worried though, ffmpeg is not exactly efficient at code size
[11:09:24] <Dark_Shikari> data would be the least of my concerns
[11:09:26] <kshishkov> Honoome: personally I just know that Theora exists but I've not touched it for yeats
[11:09:29] <kshishkov> *years
[11:09:54] <Honoome> lucky you… libtheora used to have this nice feature that the stuff they released actually _missed some source files_ …
[11:09:56] <Dark_Shikari> (do such devices have separate EEPROM for data or similar?)
[11:09:58] <Zagor> theora is another codec ripe for code sharing...
[11:10:15] <Dark_Shikari> well, ffmpeg's theora decoder is getting completely overhauled anyways
[11:10:20] <Dark_Shikari> because xiph being better than ffmpeg at anything is a bit embarassing
[11:10:28] <KotH> Dark_Shikari: definitly less then 1MB
[11:10:35] <KotH> Dark_Shikari: though, i cannot find the numbers anymore
[11:10:36] <Honoome> so for instance you disabled MMX support, or built on 64-bit, and you would have an unbuildable libtheora :P
[11:10:56] <KotH> Dark_Shikari: and the smallest mp3 players work on 8kB ram
[11:11:17] <Zagor> KotH: but they don't decode in the cpu then
[11:11:18] <Dark_Shikari> 8kb is probably not even enough to hold the framebuffer on mine...
[11:11:28] <Dark_Shikari> and you can't get much smaller than a $30 4GB player
[11:11:29] <KotH> Zagor: that i dont know
[11:11:34] <Zagor> I do :-)
[11:11:44] <kshishkov> Dark_Shikari: what a wonderful opportunity to optimize x264 for MP3 players ;)
[11:11:49] <Dark_Shikari> kshishkov: lol
[11:11:54] <Dark_Shikari> you can encode one frame per day
[11:12:05] <av500> depends on the frame size
[11:12:21] <av500> tamagotchi live streaming...
[11:12:29] <KotH> lol
[11:12:33] <KotH> do tamagochis still exist?
[11:12:37] <av500> yes, new ones
[11:12:38] <KotH> havent seen one in ... decades
[11:12:45] <KotH> o_0
[11:12:49] <KotH> they still build them?
[11:12:58] <av500> http://www.engadget.com/2010/02/15/tamagotchi-renamed-tamatown-tama-go-no-change-in-amount-of-atte/
[11:13:01] <kshishkov> you'd be ashamed to be seen with one anyway
[11:13:01] <Honoome> they are laid, not produced
[11:17:02] <KotH> o_0
[11:17:09] <KotH> av500: holy... egg...
[11:17:20] <KotH> kshishkov: well, target market is .jp anyways
[11:17:45] <KotH> kshishkov: and giving that japanese people carry their cell phone on a strap aroudn their neck...
[11:17:45] <Dark_Shikari> which is a "special" market
[11:17:58] <KotH> s/special/totally insane/
[11:18:00] <KotH> ^^'
[11:18:42] <kshishkov> s/insane/culturally different/
[11:18:55] <kshishkov> it's insane _here_
[11:19:08] <KotH> it's a different form of insanity
[11:19:11] <KotH> believe me
[11:19:14] <KotH> i've lived there
[11:19:18] <KotH> i've seen it
[11:19:21] <KotH> i've survived it
[11:19:46] <Dark_Shikari> go to akihibara every day for one week.
[11:20:22] <mru> Dark_Shikari: have you been there?
[11:20:42] <Dark_Shikari> no, but I've heard scary stories from people who have.
[11:21:01] <Dark_Shikari> and when I go to japan, I will go there, so I can tell scary stories to everyone else too.
[11:21:06] * mru has been there
[11:21:11] <Dark_Shikari> And so I can fill my backpack with doujins.
[11:21:13] <Dark_Shikari> but that's secondary
[11:21:29] <mru> it's not nearly as scary as the stories make it out to be
[11:21:36] <Dark_Shikari> well it is a bit more toned down lately
[11:21:38] <mru> but telling stories is more fun
[11:21:45] <Dark_Shikari> they kicked a lot of the prostitution off the street
[11:21:56] <Dark_Shikari> and now instead we have a "rent a girlfriend" service
[11:28:28] <twnqx> mru: it is scary! just watch durarara!!
[11:29:34] <mru> as I said, I've been there, wasn't scary at all
[11:30:06] <kshishkov> welcome here!
[11:31:42] <Dark_Shikari> mru: http://www.engadget.com/2010/02/15/st-ericssons-u8500-brings-dual-core-1-2ghz-arm-cortex-a9-to-the/
[11:35:29] <av500> the Ghz race on the phones will be much more fun than on the desktop :)
[11:36:03] <Dark_Shikari> And people wonder why I decided to make ARM a priority for x264... =p
[11:36:24] <Dark_Shikari> now we just need a good compiler
[11:36:38] <twnqx> nah, a 3ghz octocore arm
[11:37:08] <av500> Dark_Shikari: well, all these beasts coming out these days have stuff like 1080p enc/dec in HW....
[11:37:36] <Dark_Shikari> usually not encode
[11:37:43] <Dark_Shikari> and usually not a very good or flexible encoder
[11:37:45] <av500> encode is coming too
[11:38:16] <Dark_Shikari> and plus, TI wants to work with us
[11:38:17] <Dark_Shikari> so...
[11:40:48] <mru> the coming TI video hw is quite programmable
[11:42:14] <Dark_Shikari> still doesn't have a sad16x16 instruction ;)
[11:42:36] <Dark_Shikari> sad16x16 result, src, srcstride, ref, refstride
[11:42:43] <Dark_Shikari> 5 argument instructions, easy enough
[11:43:19] <mru> Dark_Shikari: what makes you say it doesn't?
[11:43:43] <Dark_Shikari> last I recall it was still all async units
[11:43:53] <mru> so?
[11:44:06] <Dark_Shikari> async units can't be called synchronously by CPU instructions
[11:44:13] <mru> so?
[11:44:19] <Dark_Shikari> that means there's no sad16x16 instruction
[11:44:31] <mru> the accelerator can have such an instruction
[11:45:45] <Dark_Shikari> it's asynch, it doesn't have latency of just a couple clocks
[11:45:51] <Dark_Shikari> thus it's not going to be useful to call for a single SAD
[11:47:37] <mru> that's not you it's supposed to be used
[11:47:51] <mru> and you don't know the latency
[11:47:59] <Dark_Shikari> asynch units aren't going to have single-digit-clock latencies
[11:48:19] <mru> you're thinking about it in the wrong way
[11:48:33] <Dark_Shikari> it's useless to simply say "here are 10,000 SADs that I need done"
[11:48:40] <Dark_Shikari> you need complex logic behind those SADs
[11:48:45] <mru> the async unit is programmable
[11:48:53] <Dark_Shikari> then how is it any different from a CPU?
[11:48:58] <mru> you code your ME algorithm on it
[11:49:17] <mru> the main code running on the arm then fires off a command like "find the best MV for this block"
[11:49:31] <mru> that will of course have considerable latency
[11:49:39] <Dark_Shikari> order of magnitude?
[11:49:45] <Dark_Shikari> 100 clocks? 1000? 10000?
[11:49:48] <Dark_Shikari> 100,000?
[11:49:59] <mru> depends on the algorithm
[11:50:01] <mru> obviously
[11:50:28] <Dark_Shikari> er
[11:50:32] <Dark_Shikari> I mean the latency to the unit
[11:50:47] <mru> sending a command should take a few cycles
[11:50:53] <Dark_Shikari> just a few cycles? that's it?
[11:50:55] <Dark_Shikari> and the results?
[11:51:01] <mru> it's a memory write
[11:51:05] <Dark_Shikari> so basically if it's only a few cycles
[11:51:05] <mru> or looks like one
[11:51:10] <Dark_Shikari> then what I do is like this:
[11:51:16] <Dark_Shikari> 1) send ME search commands
[11:51:20] <Dark_Shikari> 2) do intra search, etc on main CPU
[11:51:26] <Dark_Shikari> 3) spinlock to wait until 1) completes
[11:51:30] <Dark_Shikari> 4) mode decision based on results
[11:52:18] <Dark_Shikari> that would fit the x264 model very well
[11:52:21] <mru> "it is capable of executing a reasonable algorithm within 900 cycles per macroblock"
[11:52:23] <Dark_Shikari> it would avoid having to split the encoding completely
[11:52:25] <Dark_Shikari> ..... Wow
[11:52:35] <Dark_Shikari> 900 cycles per MB as in throughput or latency?
[11:52:44] <Dark_Shikari> and are those CPU clocks, or asynch unit clocks?
[11:53:25] <Dark_Shikari> basically I'm wondering if that means "if we run 1000 MBs through, it takes 900,000 clocks"
[11:53:25] <mru> accelerator clocks of course
[11:53:38] <Dark_Shikari> or "if we run 1 MB through, it'll take 900 clocks"
[11:53:42] <Dark_Shikari> and what does the accelerator run at?
[11:53:44] <Dark_Shikari> 50mhz?  500mhz?
[11:54:10] <mru> 500 is probably not far off
[11:54:21] <Dark_Shikari> so that means this actually fits the x264 model
[11:54:26] <Dark_Shikari> now harass them to get me some hardware and a toolkit
[11:54:30] <Dark_Shikari> I want to write code for this thing =p
[11:55:45] <mru> oh, and there's a special accelerator for intra pred
[11:57:14] <Dark_Shikari> what exactly does it do?
[11:57:25] <Dark_Shikari> I mean, it can do "intra pred", but one intra pred takes like 5-20 cycles
[11:57:38] <Dark_Shikari> so that doesn't make sense to put on an accelerator except for decoding (with the whole chaining idea)
[11:59:11] <mru> many of these units have their own arm core
[11:59:59] <Dark_Shikari> why not just multithread the encoder then?
[12:00:03] <Dark_Shikari> and abuse the arm cores?
[12:00:14] <mru> they are arm9 or m3
[12:00:18] <mru> no fancy stuff
[12:05:47] <Dark_Shikari> anyways, we need to get their help and get x264 optimized on an OMAP
[12:13:37] <mru> and the netra
[12:13:53] <Dark_Shikari> netra?
[12:14:08] <mru> successor to davinci
[12:14:24] <mru> triple video accels
[12:15:33] <mru> 1GHz A8 and C674x dsp too
[12:17:01] <mru> http://wiki.neurostechnology.com/index.php/OSD3.0
[12:19:26] <mru> omap4 is dual-A9, single video accel, dsp
[12:28:49] <KotH> Dark_Shikari: toned down is an understatement. most of the maid cafes are gone
[12:29:08] <Dark_Shikari> :/
[12:29:09] <KotH> Dark_Shikari: other than that.. you dont stumble on the really weird stuff unless you look for it...
[12:29:12] <Dark_Shikari> that's what made it good
[12:29:21] <Dark_Shikari> now it's just a really big shop for touhou doujins
[12:29:47] <KotH> i liked it better before the maid cafes came
[12:30:25] <merbzt> mru: is this you ? http://www.flickr.com/photos/koenkooi/2692388640/
[12:30:41] <mru> damn, you found me
[12:31:20] * kshishkov has the most unrecgnozable photo of MÃ¥ns
[12:31:44] <KotH> kshishkov: show us
[12:32:27] <kshishkov> let me find it
[12:32:46] <Dark_Shikari> mru: obnoxious cdecl question
[12:32:50] <Dark_Shikari> I have
[12:32:52] <Dark_Shikari> const int16_t (*l1mv0)[2] = (const int16_t (*)[2]) &h->fref1[0]->mv[0][ h->mb.i_b4_xy ]; const int16_t (*l1mv1)[2] = (const int16_t (*)[2]) &h->fref1[0]->mv[1][ h->mb.i_b4_xy ];
[12:32:58] <mru> omg
[12:33:02] <Dark_Shikari> I want to be able to address these as l1mv[0] and l1mv[1]
[12:33:05] <Dark_Shikari> instead of l1mv0 and l1mv1
[12:33:11] <Dark_Shikari> how the hell would I declare that?
[12:33:22] <thresh> how the hell do you read that
[12:33:27] <Dark_Shikari> thresh: you start by adding the missing line break
[12:33:42] <thresh> i'm actually lost after the third space
[12:33:46] <Dark_Shikari> lol
[12:33:50] <thresh> okay, fifth
[12:33:54] <Dark_Shikari> it's a pointer to a const int16_t mv[2]
[12:35:12] <mru> Dark_Shikari: try const int16_t (*l1mv[2])[2] = { (const int16_t (*)[2]) &h->fref1[0]->mv[0][h->mb.i_b4_xy], (const int16_t (*)[2]) &h->fref1[0]->mv[1][h->mb.i_b4_xy] };
[12:35:30] <mru> those casts look scary though
[12:35:42] <Dark_Shikari> impressive.
[12:35:43] <kshishkov> KotH: http://shishkov.homeunix.net/mans.jpg
[12:35:44] <Dark_Shikari> Yeah
[12:35:51] <Dark_Shikari> thanks
[12:35:58] <Dark_Shikari> yeah, that's a seriously obnoxious set of declarations
[12:35:59] <mru> kshishkov: lol
[12:36:03] <Dark_Shikari> I mean seriously, that's like 3 dereferences each
[12:36:25] <Dark_Shikari> well, it compiled
[12:36:35] <kshishkov> mru: I can guarantee it's you - April 7th, KTH
[12:36:40] <mru> take that, java
[12:36:51] <mru> kshishkov: I recognise the place very well
[12:37:09] <mru> and I own a coat that colour
[12:40:32] <Dark_Shikari> well, I just shrunk a loop by about a factor of 2 with that
[12:40:45] <mru> nice
[12:40:56] <Dark_Shikari> I'm being inspired by michael's optimizations
[12:41:00] <Dark_Shikari> to go back and optimize those annoying parts of x264
[12:41:17] <kshishkov> to make them incomprehensible?
[12:41:23] <Dark_Shikari> lol
[12:41:38] <Dark_Shikari> I love some of michael's mini-opts
[12:41:45] <Dark_Shikari> like the whole "if the mv is 0, you can skip half of spatial direct"
[12:41:50] <Dark_Shikari> which triggers shockingly often
[12:42:18] <kshishkov> yeah, the hard part is to predict what happens often
[12:46:59] <twnqx> ain't that profilers are for?
[12:47:06] <twnqx> +what
[12:47:57] <kshishkov> they are of little help in that case
[12:48:19] <kshishkov> since they usually work on whole functions, not conditions
[12:48:22] <twnqx> so you'd have to implement performance counters for yourself to do statistics?
[12:48:39] <twnqx> mh
[12:48:40] <Dark_Shikari> printf
[12:48:42] <Dark_Shikari> not hard.,
[12:48:47] <twnqx> no, just annoying
[12:48:57] <Dark_Shikari> not really
[12:49:16] <mru> some cpus have sw counters
[12:49:28] <mru> write to a register to trigger an event
[12:49:40] <mru> probably not useful here though
[12:51:21] <Dark_Shikari> on a vaguely related note, I have a class this semester on OSs
[12:51:36] <Dark_Shikari> fun stuff, like writing kernel-level synch primitives
[12:51:42] <Dark_Shikari> semaphores, mutexes, cvs
[12:51:51] <Dark_Shikari> pretty easy though :/
[12:52:02] <Dark_Shikari> especially if you're allowed to be lazy and just turn off interrupts during the synch code
[12:52:30] <mru> what kernel are you using?
[12:52:31] * twnqx orders the second core to write to the memory location
[12:52:38] <Dark_Shikari> mru: OS/161, simulated MIPS kernel
[12:52:43] <mru> sim, bah
[12:52:47] <Dark_Shikari> designed for a system that only exists in simulation
[12:52:52] <Dark_Shikari> with a bus that's never been implemented in hardware
[12:52:56] <kshishkov> pure fiction then
[12:52:59] <mru> typical academia
[12:53:01] <Dark_Shikari> though it's actually arch-generic
[12:53:11] <Dark_Shikari> the arch-specific parts are obviously for the sim
[12:53:17] <Dark_Shikari> but it would not be hard to port
[12:53:21] <mru> we actually got to play with real hardware in uni
[12:53:23] <Dark_Shikari> it's chosen because it's _incredibly_ small
[12:53:29] <av500> Dark_Shikari: will you port x264 to it?
[12:53:30] <Dark_Shikari> we do too, but that's not what this class is for
[12:53:33] * twnqx remembers his simulated assembler classes
[12:53:40] <Dark_Shikari> 1) it's an entire OS in ~17kloc
[12:53:44] <mru> better to use something real like ucos or atomthreads imo
[12:53:46] <Dark_Shikari> 2) It has almost nothing--and we have to fix that
[12:53:54] <kshishkov> we had to write CPU emulator and assembler for one of our projects
[12:53:57] <Dark_Shikari> scheduler, synch primitives, execve, etc
[12:53:58] <twnqx> optimizing data structures to the point where one of the authors of the simulator didn't understand why the code worked :P
[12:54:09] <Dark_Shikari> mru: is it an OS in 17kloc? ;)
[12:54:19] <mru> less
[12:54:24] <Dark_Shikari> o.0
[12:54:29] <mru> ucos is tiny
[12:54:35] <mru> a few k lines
[12:54:44] <Dark_Shikari> an OS smaller than h264.c
[12:55:07] <Dark_Shikari> btw, it was chosen because we can more easily focus on writing the code instead of debugging shit when we can trivially attach gdb to a simulator
[12:55:21] <Dark_Shikari> and while debugging a real chip is nice and fun... it's also aggravating
[12:55:22] <Dark_Shikari> and painful
[12:56:02] <twnqx> help me debug my FPGA
[12:56:11] <twnqx> i think i need a JTAG reding software
[12:57:56] <mru> a good jtag debugger is much easier to use than gdb on a sim
[12:58:02] <mru> gdb is pain
[12:58:30] <Dark_Shikari> dunno, it's not too bad
[12:58:39] <Dark_Shikari> it works pretty well
[13:01:58] <mru> maybe you've never used a good jtag debugger
[13:02:36] <Dark_Shikari> hmm.  is there any less shitty way to structure code like this?
[13:02:37] <Dark_Shikari> http://pastebin.com/m1dca8a98
[13:02:56] <Dark_Shikari> if(A) {do X} else {do Y}  if(B) {do X} else {do Y} if(!A && !B) {do Z}
[13:03:15] <Dark_Shikari> if/else is sometimes a bit limiting of a paradigm
[13:06:05] <Kovensky> on that case, you could split Z and put on the else cases of A and B
[13:06:09] <Kovensky> in*
[13:07:06] <Kovensky> hmm, nvm
[13:07:09] <janneg> no, that would do Z two times for !B && !B
[13:07:19] <Kovensky> I said split
[13:07:38] <Dark_Shikari> oh, and I don't want to increase code size
[13:07:40] <Dark_Shikari> so no duplicating shit
[13:07:43] <Kovensky> but it would also do a part of Z if !A && B or A && !B
[13:08:03] <kshishkov> loop is most obvious
[13:08:06] <Kovensky> http://pastebin.com/m1be43e60 <-- this is what I had in mind, but it changes the logic
[13:08:14] <Dark_Shikari> won't work
[13:08:19] <Dark_Shikari> the spec says what it say
[13:08:36] <janneg> it could be just moved as if (!A) do Z; to else of the if (B)
[13:08:40] * av500 proposes a goto, hides
[13:09:04] <Dark_Shikari> how about http://pastebin.com/m3ffc6ba7
[13:09:42] <av500> wouldnt nm insist you replace that all with "? :" stuff?
[13:09:46] <kshishkov> it should work
[13:09:48] <KotH> kshishkov: rotfl
[13:10:06] <Kovensky> http://pastebin.com/m14727281
[13:10:09] <Dark_Shikari> also, notably the "else" branches are rare
[13:10:15] <Dark_Shikari> and to take _both_ the elses is about 1% of the time
[13:10:27] <Dark_Shikari> which is why Kovensky's solution is bad
[13:10:27] <twnqx> tmp = 0; if (a) tmp|=1; if (b) tmp|=2; switch(tmp) {case....}
[13:10:28] <twnqx> :P
[13:10:50] <Dark_Shikari> so I guess hiding it inside a branch nobody cares about works
[13:11:03] * Kovensky fails
[13:11:10] * Dark_Shikari should have said that first
[13:11:33] <Kovensky> <@Dark_Shikari> and to take _both_ the elses is about 1% of the time <-- shouldn't the if be the exceptions, and else the rule?
[13:11:36] <Dark_Shikari> oh wow.  I'm a phenomenal idiot.  there is a loop right above that, which I can merge all this code with
[13:11:42] <Kovensky> at least I remember reading something to that effect
[13:11:53] <Dark_Shikari> Kovensky: oh, good question. mru, doesn't gcc have fuckwitted rules for this?
[13:11:54] <twnqx> tmp = (a?1:0) | (b?2:0); switch (tmp) { case ...}
[13:12:18] <mru> rules for what?
[13:12:33] * twnqx does too much verilog, which allows to evaluate multiple variables in one case statement quite neatly
[13:12:42] <Dark_Shikari> mru: which side of the if it inlines
[13:12:53] <mru> I've seen gcc do all kinds of things
[13:12:54] <janneg> twnqx: tmp = (!!a<<) | (!!b);
[13:13:10] <janneg> twnqx: tmp = (!!a<<1) | (!!b);
[13:13:27] <av500> switch((!!a<<1) | (!!b)){...
[13:13:33] <twnqx> janneg: tmp = (!a<<1) | (!b); and invert the meanings
[13:13:35] <Dark_Shikari> die die die die die
[13:13:48] <Kovensky> DIE THE DEATH
[13:13:48] <Kovensky> etc
[13:14:23] <Dark_Shikari> great equalizer, etc, etc
[13:17:58] <Dark_Shikari> 21:16 < ksf> "It takes about ten gigabytes or so of disk space to check out and build the source tree."
[13:18:01] <Dark_Shikari> 21:17 < benmachine> which source tree is this
[13:18:04] <Dark_Shikari> 21:17 < Dark_Shikari> homo sapiens?
[13:18:11] <Dark_Shikari> (apparently, chromium)
[13:18:51] * Kovensky wonders how dreadfully big would mozilla-central be if it used git
[13:19:50] * KotH remembers that m14 or m15 filled his 1.5G scratch partition when compiling
[13:19:58] <Honoome> Dark_Shikari: chromium-os?
[13:20:11] <Honoome> because not sure about the check-out, but the build for chromium sure does not arrive to 10GBs…
[13:20:20] <Dark_Shikari> dunno
[13:20:27] <Dark_Shikari> just copying random stuff from another channel
[13:20:37] <Honoome> [which would sound bloody strange, because OpenOffice just takes about 8GB or so to build…]
[13:20:52] <Dark_Shikari> 8gb to build
[13:20:52] <Dark_Shikari> lol
[13:20:58] <Dark_Shikari> for a fucking text editor
[13:21:05] <Dark_Shikari> (ok, so I'm trolling with that)
[13:21:19] <Honoome> Dark_Shikari: for a fucking text editor with a chart software that is unable to understand dates…
[13:21:23] <Dark_Shikari> lol
[13:21:27] <Honoome> and that has feature regressions against Microsoft Chart for DOS!
[13:21:29] <bilboed-pi> the actuall OOo isn't that big, it's just that they ship a truckload of their own copies of dependencies
[13:21:31] <Dark_Shikari> for a fucking chart software that can't handle more than 2^16 rows
[13:21:52] <kshishkov> Honoome: IIRC, MS Office itself had feature regressions against Write for Windows
[13:22:19] <Honoome> for a drawing application that exports spellchecker underlines when exporting images, and for which the fix is targeted for 3.3 milestone…
[13:22:19] <kshishkov> bilboed-pi: they copied that from Mozilla
[13:22:38] <kshishkov> WYSIWYG
[13:23:23] <elenril> lol
[13:23:35] <Honoome> kshishkov: really, what good is a spreadsheet/charting application that doesn't understand that by-date graphs can't have the same distance between feb 2-feb 3 and feb 3-feb 10?
[13:23:44] <elenril> text editor << ooo can do that?
[13:24:58] <Dark_Shikari> elenril: no syntax highlighting though
[13:24:59] <Dark_Shikari> kinda sucks
[13:25:02] <kshishkov> elenril: even Emacs can do that
[13:25:13] <Honoome> fwiw gnuplot is cryptic, but now that I've been given the scripts to do the generation, it takes magnitudes of memory and time less to use that =_=
[13:25:17] <Kovensky> lolemacs
[13:25:20] <kshishkov> Honoome: well, I don't like charting
[13:25:25] <Kovensky> I know one emacs shortcut \o/
[13:25:38] <kshishkov> Honoome: but it's drawing sucks too
[13:25:41] <mru> Kovensky: which one?
[13:25:45] <kshishkov> vi?
[13:25:47] <Kovensky> C-x C-c
[13:25:55] <mru> come try it on my emace ;-)
[13:25:57] <mru> emacs
[13:25:59] <Dark_Shikari> eight megabytes and constantly swapping
[13:26:06] <Kovensky> cheater :>
[13:26:14] <mru> emacs makes any computer slow
[13:26:21] <Honoome> kshishkov: the only thing that it does *better* than inkscape is flowcharts
[13:26:32] * mru likes xfig
[13:26:34] <kshishkov> Dark_Shikari: not funny anymore. Unless your OS still swaps it with 2GB RAM free
[13:26:43] * mru doesn't have swap
[13:26:58] <kshishkov> Honoome: yes, and I'd say it's better to enhance Inkscape
[13:27:08] <Dark_Shikari> eventually munches all computer storage
[13:27:14] <Kovensky> IIRC windows doesn't allow you to completely remove swap
[13:27:14] <mru> inkscape is a pile of stink too
[13:27:25] * mru doesn't run windows
[13:27:27] <kshishkov> mru: xfig was fine unless you tried Cyrillic captions
[13:27:31] <Honoome> kshishkov: probably… but I tried talking with inkscape upstream and almost had a rude answer to them ;_;
[13:27:38] <Kovensky> some guy solved the problem by putting the swap on a ramdisk
[13:27:38] <Kovensky> lol
[13:27:39] <Dark_Shikari> emacs makefiles annihilate C shells
[13:27:56] <Honoome> [emacs for the win, by the way :P]
[13:27:56] <KotH> Honoome: if you think that gnuplot is cryptic, you have never used ploticus :)
[13:28:09] <Honoome> KotH: not even heard of that before ;)
[13:28:11] <elenril> Dark_Shikari: what editor do you use btw?
[13:28:17] <mru> gnuplot is nice too
[13:28:18] * Kovensky didn't like emacs too much
[13:28:21] <Dark_Shikari> emacs macht alle computer sheisse
[13:28:26] <Dark_Shikari> elenril: notepad++
[13:28:29] <KotH> Honoome: it's the tool, when gnuplot is just not flexible enough anymore :)
[13:28:30] <kshishkov> good German
[13:28:35] <mru> emacs is useless out of the box
[13:28:38] <Kovensky> "emacs eats all your computer's cheese"
[13:28:39] <mru> you need to customise it
[13:29:05] <kshishkov> elentril: the only way to make Dark_Shikari use something different is to convince Touhou author to release all games for Linux only
[13:29:09] <mru> escape meta alt control shift
[13:29:09] <Honoome> KotH: I don't think the problem with gnuplot is lack of flexibility in my case… it's more a matter of having no idea where the heck to find the documentation
[13:29:15] <Kovensky> <@mru> emacs is useless out of the box <-- I could tell that far
[13:29:20] <Honoome> mru: have you tried emacs 23 yet?
[13:29:23] <mru> no
[13:29:40] <Dark_Shikari> I prefer vim 1972
[13:29:47] <Honoome> KotH: at the end, to do a stacked area chart the solution I've been given is to chart the first line normally, and the second as the sum of the first and second :P
[13:29:48] <Dark_Shikari> but that's beaten by ed 93876492
[13:30:04] <kshishkov> cat +infinity
[13:30:22] <kshishkov> or quantum butterfly
[13:31:39] <KotH> Honoome: there is a ps file that is the documentation
[13:31:49] <KotH> Honoome: you have to read all of it to find the one command you need
[13:32:14] <Honoome> KotH: I even read gnuplot in action, but half of tha stuff assumes you completed your statistics course at university
[13:32:14] <KotH> Honoome: after having it read a couple of dozen times, you'll know in which section the thing you are looking for could proably be
[13:32:28] <KotH> of course
[13:32:34] <Honoome> given I almost failed statistics in high school and I didn't proceed to university, that's a bit too far out for me :P
[13:32:39] <KotH> none said that gnuplot doesnt assume prior knowledge
[13:33:00] <KotH> uh.. then you're lost but for the most simple graphs
[13:33:19] <KotH> beside: not going to uni might not be the worst idea
[13:33:45] <Honoome> KotH: I started working right after high school, didn't care about italian university… would have been different had it been german or british
[13:33:50] <KotH> i was quite good in statistics in highschool... i couldnt even figure out what the prof was talking about at the uni ^^'
[13:34:04] <mru> most of what I learned in uni, I wasn't taught
[13:34:06] <KotH> Honoome: oh.. italian...
[13:34:16] <KotH> Honoome: well.. i dont blame you then :)
[13:34:58] <Honoome> heh :) -- but yeah gnuplot I don't really want to learn extensively ;) just is nice to produce the graphs for benchmarks and similar stuff… an image makes it much more clear to the users what you're talking about
[13:35:24] <Honoome> luckily for now I found someone who gave me the two scripts that produces the graphs I need to show the Ruby packaging in Gentoo :D
[13:35:31] <mru> ascii-art ftw
[13:36:58] <KotH> Honoome: ppt? ;->
[13:37:23] <Honoome> KotH: that's something I have to consider for the next FOSDEM or something like that :P
[13:37:55] <KotH> Honoome: make a video and play it on a video wall... much more impressive
[13:37:58] <KotH> :)
[13:39:12] <mru> we need to think of some new features for the wall
[13:43:00] <KotH> dont play a single video, but orchestrate the different displays to a show
[13:46:48] <kshishkov> done by mru already
[13:47:34] <KotH> nope
[14:08:21] <av500> KotH: video mirror: each BB encodes one 6th with a webcam, they pass it to the "other side", decode there and display
[14:08:22] <janneg> re-render BBB in 3840x2.048
[14:08:31] <av500> janneg: I looked into that
[14:08:42] <av500> BBB took like 50000h on a sun cloud
[14:08:48] <av500> for 1080
[14:10:22] <janneg> 50k h real time?
[14:10:47] <kshishkov> of course not
[14:11:10] <kshishkov> that's >5 years after all
[14:16:04] <av500> http://www.bigbuckbunny.org/index.php/our-renderfarm-and-how-it-works/
[14:16:31] <av500> ...Luckily they were generous and gave us 50′000 hours, allowing an optimistic 4-5hrs per frame. ....
[14:16:50] <kshishkov> they were in parallel
[14:16:52] <janneg> reading that already. looks like the final rendering was just 1-2 hours
[14:17:25] <janneg> per frame
[14:19:56] <av500> for 1080
[14:20:25] <janneg> does the rendering scales linearly with the number of pixels?
[14:20:30] <av500> kshishkov: yes, in parallel :) have your gdium join the renderfarm?
[14:20:43] <av500> janneg: no idea
[14:21:28] <kshishkov> av500: no, but I sometimes use my 1GHz ARM (NEONless) to transcode from 1280x760 H.264 to something better playable
[14:22:06] <mru> sheeva?
[14:22:23] <kshishkov> yes
[14:23:02] <kshishkov> too lazy to use BeagleBoard for that
[14:23:38] <av500> mru: BB rendercluster? how many will TI give us :)
[14:23:58] <av500> they sold 10k so far, we need them all
[14:24:06] <twnqx> lol
[14:24:15] <janneg> I fear they would be ram and limited
[14:24:21] <janneg> -and
[14:24:32] <av500> for 1 frame?
[14:24:33] <kshishkov> 640k is enough
[14:25:09] <av500> ok, we render in libaa
[14:25:16] <av500> and we make a vt100 wall
[14:27:45] <kshishkov> yes, someone should lend some power to that Kiwi guy to finish asciiart version of star wars
[14:28:18] <janneg> argh, blender uses scons
[14:30:33] <av500> scones?
[14:30:43] <mru> with jam
[14:31:07] <av500> clotted cream ftw
[14:31:24] <janneg> no, autohell replacement
[14:31:41] <mru> yeah, replaced with a hotter hell
[14:32:05] <kshishkov> mozilla/oo.o-style
[14:34:06] <CIA-34> ffmpeg: rbultje * r21848 /trunk/libavcodec/Makefile:
[14:34:06] <CIA-34> ffmpeg: Add missing dependency. Patch by James Darnley <$firstname dot $lastname at
[14:34:06] <CIA-34> ffmpeg: gmail dot com>.
[14:35:08] <Kovensky> lolautohell
[14:35:21] <kshishkov> autocrap too
[14:36:02] * Kovensky maintains an autohell build system ._.
[14:36:09] <kshishkov> and you always need the latest version to build it
[14:37:09] <Honoome> janneg: there's a cmake-based buildsystem available as user patch as well
[14:37:15] <Honoome> [still better than the crap that is called scons :P]
[14:39:15] <lu_zero> well
[14:39:24] <lu_zero> scons in blender works well enough
[14:39:27] <lu_zero> and no
[14:39:48] <lu_zero> I'm not so sure the cmake stuff in blender is anyway superior than the scons one
[14:39:49] <kshishkov> "good enough is an enemy of good"
[14:40:22] <lu_zero> kshishkov: the main problem with blender is that has a code layout a bit annoying
[14:41:41] * kshishkov used Blender twice - once on PocketPC
[14:44:49] <DonDiego> BBB: i hereby grant you the useless commit message award
[14:45:01] <DonDiego> "Add missing dependency."
[14:45:20] <DonDiego> for the makefile that's about as useful as "bug fix" is for a C file
[14:45:43] <mru> it's worse even
[14:45:50] <mru> you can't add something that's missing
[14:46:10] * lu_zero will put "add missing dependency on a C commit and a bug fix on a makefile commit
[14:46:12] * kshishkov runs svn commit -m "change characters in some file(s)"
[14:46:25] <mru> I've seen worse
[14:46:29] <mru> I've seen "..."
[14:46:30] <lu_zero> kshishkov: s/change/switch/
[14:46:37] <merbzt> bring out the champagne !! \o/
[14:47:07] <kshishkov> mru: some people use single space for commit message
[14:47:08] <lu_zero> the worst would be feeding the diff to svn message
[14:47:18] <DonDiego> in that case it would be better
[14:47:27] <DonDiego> because it would at least explain *something*
[14:47:28] <lu_zero> DonDiego: the wrong diff
[14:47:29] <kshishkov> merbzt: nothing stronger than Pommac for you :P
[14:47:46] <merbzt> I want trocadero
[14:47:58] * kshishkov sighs
[14:47:59] <mru> I worked at a place where policy was that after a commit, the developer had to _manually_ send an email to a list
[14:48:15] <mru> and the email was to contain the cruft cvs ci prints to the console
[14:48:17] <merbzt> :)
[14:48:19] <lu_zero> mru: you got 1commit per day?
[14:48:53] <DonDiego> BBB: *please* don't treat commit messages as just a bump on the road
[14:48:55] <CIA-34> ffmpeg: thilo.borgmann * r21849 /trunk/libavcodec/alsdec.c: Limit the Rice parameter used for progressive decoding in ALS.
[14:48:56] <mru> then you had to do the same commit again in a different repo using a different, even worse, vcs
[14:49:10] <DonDiego> BBB: you should be communicating with *us* in them
[14:49:15] <Kovensky> worse than cvs? wtf
[14:49:24] <mru> oh, there are plenty
[14:49:25] <lu_zero> Kovensky: there are plenty
[14:49:30] <DonDiego> and with your future self that forgot what you did in mid-february 2010
[14:49:44] <kshishkov> Kovensky: ever heard of Microsfot Source Safe?
[14:49:57] <Kovensky> yes, never dealt with it though
[14:50:07] <lu_zero> like monotone...
[14:50:15] <av500> clearcase
[14:50:21] <lu_zero> monotone is orrible
[14:50:31] <lu_zero> I'm not sure clearcase is that bad
[14:50:35] <mru> I am
[14:50:45] <lu_zero> as bad as monotone?
[14:50:45] <av500> I am
[14:50:47] <mru> clearcase is cvs with lots of brick walls added
[14:50:53] <lu_zero> uh
[14:50:56] <lu_zero> wonderful
[14:51:08] <lu_zero> and there is somebody paying to use it
[14:51:08] <av500> I know people that work with clearcase and they go to a clearcase admin to have a file/folder created....
[14:51:15] <Kovensky> <@mru> clearcase is cvs with lots of brick walls added <-- nice, they even give the place you should bang your head against
[14:52:01] <kshishkov> SourceSafe has an additional point of being able to crash DB and losing _all_ your data
[14:52:16] <av500> kshishkov: that is a M$ core feature
[14:52:31] <mru> clearcase is built around a db made by a company that's gone bankrupt _twice_
[14:52:38] <mru> and they print that in the manual
[14:52:53] <kshishkov> av500: yes, they made it with Jet engine used for other data loss product like Access
[14:52:55] <KotH> what db?
[14:53:00] <mru> don't remember
[14:53:11] <av500> stillalivedb
[14:53:11] <lu_zero> sigh...
[14:53:32] <Kovensky> kshishkov: loljet
[14:53:33] <av500> it must be a good db to survive 2 bankruptcies
[14:53:36] * kshishkov looks at wikipedia
[14:53:40] <mru> clearcase _requires_ a full-time _team_ to look after it
[14:53:42] <Kovensky> kshishkov: microsoft itself said they won't port jet to 64bit
[14:53:47] <kshishkov> what? IBM product? bleh
[14:53:49] <thresh> clearcase awwwwwwwwwwww
[14:54:12] <kshishkov> developed by Rational Software? that's even sickier!
[14:54:50] <KotH> mru: taht's strategy
[14:54:55] <mru> anyway, what's that magic git command to take two branches and interleave the histories?
[14:54:57] <KotH> mru: selling a product wont give you any profit
[14:55:05] <KotH> mru: selling an SLA will give you lots of profit
[14:55:41] <elenril> a seven letter acronym?
[14:56:13] <Kovensky> mru: git merge?
[14:56:17] <mru> no
[14:56:22] <mru> git merge creates a merge commit
[14:57:04] <Honoome> mru: interleave? hm I did something before but it was a real mess… rebase is not enough?
[14:57:20] <mru> no
[14:57:26] * thresh got interleaving history in ffmpeg+swscale git repo
[14:57:30] <KotH> elenril: service level agreement
[14:57:34] <mru> I want two histories interleaved in the order they happened
[14:57:34] <elenril> what's so wrong with a merge commit
[14:57:36] <KotH> elenril: aka, a support contract
[14:57:36] <thresh> though those arent 'branches' really, just a subtries
[14:57:43] <thresh> subtree
[14:58:11] <mru> thresh: how'd you do it?
[14:59:15] <thresh> nothing magical. http://www.kernel.org/pub/software/scm/git-core/docs/howto/using-merge-subtree.html
[14:59:51] <thresh> hmm wait
[15:00:43] <thresh> i do have merge commits.
[15:01:04] <thresh> sorry, my brain melts in the end of a workday
[15:04:00] <janneg> mru: the general history rewriting command is git filter-branch. I don't think it will trivially interleave brnaches in commit order but it should be possible
[15:04:14] <mru> I know of filter-branch
[15:04:27] <mru> but I can't seem to figure out a way to make it do what I want
[15:05:42] <janneg> I think you have to script around it
[15:06:28] <janneg> well, cherry pick is probably enough
[15:06:47] <mru> I don't want to cherry-pick thousands of commits
[15:09:22] <mru> surely someone has done this before...
[15:09:41] <lu_zero> mru bilboed-pi did something iirc
[15:10:09] * bilboed-pi reads backlog
[15:10:38] <janneg> ask in #git. I don't see a solution not acting on single commits
[15:10:53] <bilboed-pi> oh, merging ffmpeg and swscale git commits together ?
[15:11:03] <mru> same kind of thing
[15:11:09] <bilboed-pi> tricky
[15:11:12] <BBB> oops
[15:11:17] <BBB> DonDiego: will fix
[15:11:18] <BBB> sorry
[15:11:22] <mru> that's what I keep telling people
[15:11:26] <mru> that it's tricky
[15:11:31] <mattg> mru: just wondering if you managed to reproduce the green issue i was having on ARM with that file i sent over the other day?
[15:11:54] <mru> mattg: I tried decoding it on arm/linux and had no problems
[15:12:05] <mru> apart from some error messages you said you always got
[15:12:22] <mru> there's an alignment problem somewhere but I can't find it
[15:13:24] <mattg> ok, thanks for your help. i'm still getting the green unfortunately - i've turned on the various error_recognition and error_concealment flags so not sure why libavcodec is still throwing out such strange frames.
[15:13:40] <mattg> any advice on where i should look?
[15:13:57] <mru> my guess is it's the error concealment that has the misalignment
[15:14:06] <mru> try turning it off entirely
[15:14:14] <snatches> who might I speak with regarding the development to support alpha channel in the H264 codec for Flash?
[15:14:24] <mattg> will try that mru - thanks
[15:14:30] <mru> h264 doesn't support alpha
[15:15:01] <av500> snatches: alpha?
[15:15:09] <BBB> av500: transparency
[15:15:20] <janneg> mru: http://dustin.github.com/2008/12/31/archaeology.html
[15:15:26] <av500> BBB: I know what that is :)
[15:15:32] <BBB> well you asked :)
[15:15:39] <snatches> yes.  I'm working on a green screen project and trying to include ffmpeg
[15:15:48] <BBB> a friend of mine did something cool to enable a z-channel (3d) in a mpeg1/2 stream
[15:16:04] <av500> snatches: ok, and?
[15:16:45] <snatches> The issue now is file size.  Our current method gives us a great video, but file size is much larger than when I use ffmpeg.
[15:16:58] <snatches> here's the example: http://hamhock.wildentity.com/green_test_jason.html
[15:17:25] <janneg> mru: not pretty but at least the script for reordering the commit is already written
[15:18:01] <av500> snatches: so, replace the green by background, no?
[15:18:11] <snatches> exactly
[15:18:27] <av500> so why do you need alpha?
[15:19:08] <snatches> because the background is all in flash.  This keeps video size down.
[15:19:21] <av500> yes
[15:19:38] <av500> encode front + green in h264, decode h264, replace green by background
[15:20:06] <av500> h264 does not have an alpha channel, so you need to add one post decode
[15:21:27] <mru> janneg: I think I forgot to mention I want to preserve tags...
[15:22:19] <snatches> unless I'm not understanding you, I don't want to put my background into the video.  i want to leave it in flash.  the only way to isolate the subject of my video and include it in flash is if I can eliminate the green background of the src video.
[15:22:36] <mru> which you can't
[15:22:37] <av500> snatches: yes
[15:22:47] <av500> [16:19] <av500> encode front + green in h264, decode h264, replace green by background
[15:23:24] <av500> if flash does not let you convert green to transparent you have a problem
[15:23:59] <snatches> then i think that I have a problem :)
[15:24:10] <av500> :)
[15:24:16] <av500> you can keep it :)
[15:24:35] <snatches> what? you don't want my problems?  I give them away free of charge :)
[15:24:51] <janneg> mru: I think you would have to retag. but unless there are very important reason to do it I would just say it's tricky and might mangle history without anyone noticing
[15:24:57] <av500> unless you pay money to get rid of them. I dont want them
[15:25:21] <snatches> well, that segues into the next question.
[15:25:23] <av500> snatches: u sure flash has no "mask" feature or so?
[15:27:00] <snatches> it does, but in order to truly immerse a live actor into a 3D office environment, it just seems that this green screen/alpha channel method is the way to go.  We have it working, i'm just trying to optimize it now with ffmpeg
[15:27:22] <av500> how do you use ffmpeg from flahs?
[15:28:59] <snatches> Currently, we are using Final Cut Pro to key out all of the green behind our actor.  FCP exports to an flv using the On2 VP6 codec, which is what you see in that example
[15:29:49] <av500> ok
[15:29:51] * Kovensky wonders why did movie production go for green color key instead of pink color key like game programmers
[15:30:04] <av500> Kovensky: think porn
[15:30:08] <av500> too much pink
[15:30:15] <snatches> this works great, but this project must be viewed over the web, so we are trying everything we can to reduce the file size of these videos.  ffmpeg has proven to be a huge asset to us in reducing file sizes of videos in other projects.
[15:30:16] <Kovensky> =p
[15:30:41] <av500> snatches: you dont make sense, sorry
[15:30:48] <av500> is this a video or a swf file?
[15:31:03] <av500> if its a video, yes you can use ffmpeg to compress it, actor and office included
[15:31:05] <snatches> you are referring to the link I sent you?
[15:31:30] <av500> if you want actor + green and static office, you need e.g. flash - if flash supports that
[15:31:36] <snatches> The office backgound is a swf.  The swf then pulls in an flv video file
[15:31:55] <av500> well, then find out if in flahs you can replace green with alpha....
[15:31:59] <av500> it is a FLAHS issue
[15:32:10] <snatches> flv video is strictly the actor isolated
[15:32:31] <snatches> Flash can't do it, it must be down in video production
[15:32:32] <av500> and what is around the actor?
[15:32:35] <merbzt> only VP6A supports the needed alpha channel
[15:32:49] <av500> snatches: ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
[15:32:59] <av500> I knew flash has some alpha stuff
[15:33:19] <merbzt> only on2 supports it
[15:33:20] <snatches> merbzt, yes I read that, but that codec doesn't seem to be included in my version of ffmpeg
[15:33:32] <snatches> yes, and that's what were using currently http://hamhock.wildentity.com/green_test_jason.html
[15:33:46] <merbzt> there is on vp6 encoder in FFmpeg
[15:34:03] <av500> snatches: so what is the problem?
[15:34:43] <snatches> I guess the problem now is how to use the vp6 codec in my version of ffmpeg.
[15:34:57] <snatches> if I can use that, I can convert my videos without a problem
[15:35:06] <av500> snatches: but why not use the vp6 codec from e.g. adobe?
[15:35:11] <merbzt> there is no vp6 encoder :)
[15:35:31] <merbzt> only on2 or adobe
[15:36:24] <snatches> if we have to use adobe, we will.  I'm just trying to see if ffmpeg can offer me a smaller file size for these videos.  This content will be going out to many different companies, with various connection speeds.  gotta get it as small as possible
[15:36:56] <snatches> mebzt, there is only a decoder, right?
[15:37:19] <av500> snatches: even great ffmpeg will not reduce vp6 size by 10x....
[15:38:05] <snatches> I believe you av500, but I'm a firm believer in seeing it for myself :)
[15:38:34] <av500> well, lacking a vp6 encoder, the comparison is easy...
[15:38:39] <av500> what bitrate do you get?
[15:42:15] <snatches> trying to figure that out
[15:47:24] <merbzt> snatches: the only option is to use h264, but then I'm not sure it would be possible to use alpha channels
[15:47:45] <Kovensky> there's no alpha in h.264
[15:48:59] <snatches> Kovensky, that's what I keep hearing.  Does that mean that it is physically impossible to do alpha channel in h.264, or is it just that there isn't an encoder available that does it?
[15:49:19] <Kovensky> IIRC it's not in the specs
[15:50:14] <Kovensky> IIRC it only uses planar 4:2:0 YUV, with some profiles supporting 4:2:2 and 4:4:4
[15:51:18] <snatches> this is getting to the edge of my abilities.  Kovensky, does either 4:2:2 or 4:4:4 support alpha channel, or is that un-related?
[15:54:09] <kierank> there's some alpha blending support iirc but nobody supports it
[15:54:21] <av500> snatches: it is not supported
[15:54:58] <snatches> kierank: which codec supports alpha blending?
[15:55:07] <av500> VP6A, the one you are using
[15:55:34] <kierank> h.264 as well in one of the newer spec revisions
[15:55:51] <snatches> av500: to answer your earlier question about my current bitrate, the video was exported at 700
[15:57:22] <DonDiego> BBB: please, if you write a one-line commit message that includes the patch sender credits, that should be a red flag
[15:57:56] <kshishkov> red flags with hammer and sickle or red flag with stars?
[15:58:00] <DonDiego> BBB: take a moment to think about your message, then make it explicit and concise..
[15:58:59] <DonDiego> but not generic please
[15:59:26] <Honoome> kshishkov: rotfl :)
[15:59:52] <av500> "this is my commit, there are many like it but this one is mine...."
[16:00:22] <KotH> lol
[16:00:29] <KotH> boys, you're nuts!
[16:00:30] <lu_zero> brrr...
[16:01:04] <Honoome> lu_zero: still snow-ing? :P
[16:01:19] <lu_zero> Honoome: I'm taking a break from the pony
[16:01:29] <lu_zero> your branch passes the feng-destroyer test
[16:01:31] <kshishkov> Honoome: maybe it's h264-ing instead
[16:01:32] <Honoome> sigh, I'm still fighting with EC2
[16:01:54] <kierank> what's the problem Honoome
[16:01:54] <DonDiego> BBB: if your commit message could be used to describe many of the changes to a particular file, then it's pointless
[16:01:58] <Honoome> lu_zero: did you have any doubt?
[16:01:59] <lu_zero> kshishkov: I have h264.c and h264_loopfilter.c open in fact
[16:02:05] <lu_zero> Honoome: obviously.
[16:02:09] <Honoome> …
[16:02:13] <Honoome> thanks…
[16:03:28] <Honoome> kierank: with EC2? the fact I feel it's a bad hack :|
[16:03:35] <lu_zero> (I'm trying to figure out that leak so I was hoping that would trigger it...)
[16:05:25] <kierank> Honoome, ec2's great
[16:05:31] <kierank> for some things
[16:06:33] <mru> like wasting time
[16:09:06] <Honoome> definitely for wasting time
[16:09:30] <kierank> well theres nowhere else that will let you just fire up 1000 servers to do your bidding
[16:09:49] <Honoome> kierank: sure, if you're enough with a stock server
[16:09:57] <Honoome> when you're setting up something custom's a mess
[16:10:10] <kierank> the image upload thing is a bit awkward
[16:10:13] <Honoome> the eu zone errors out more often than not
[16:10:29] <Honoome> the only modern linux distro supported seems to be ubuntu
[16:10:41] <Honoome> but the doc does not correspond then because ubuntu (obviously) have no root
[16:11:36] <Honoome> you cannot start up s system with a device pre-connected…
[16:11:41] * elenril looks around for volunteers to apply his patch
[16:12:13] <kshishkov> elenril: try BBB, he has to perfrect his commit messages anyway
[16:15:23] <snatches> everyone, thank you for at least helping me tackle my alpha channel requests.  It would seem that VP6A is my only hope at the moment
[16:16:03] <snatches> There is no VP6A encoder, is that correct?  only a decoder?
[16:16:22] <kshishkov> there is but not in FFmpeg
[16:16:29] <_av500_> or obi wan
[16:16:46] <merbzt> :)
[16:17:06] <snatches> kshishkov: is it a matter of funding a developer to create an encoder?
[16:17:31] <Honoome> kierank: and the support software is even better! I'm trying to use rudy that does most of the work I'm needing… the problem being “private key file not found” … point it to the right file “key already exists”
[16:17:33] <kshishkov> no
[16:17:48] * KotH wonders why anyone would want to use an encoder for a format that has been proved to be worse than other available formats that are already available for free
[16:18:21] <twnqx> beacuse... no alpha channel in h264? :P
[16:18:30] * kshishkov forgets about his MSVideo1 encoder again
[16:18:45] <merbzt> snatches: buying flix would be cheaper
[16:18:48] <lu_zero> twnqx: and?
[16:19:18] <twnqx> if someone now really wants an alpha channel in his video he has to resort to some otherwise inferior codec
[16:20:20] <snatches> twnqx: that is exactly my situation.  I don't want to go with vp6a, but to use ffmpeg that seems to be what I have to do
[16:20:50] <lu_zero> flash does support alpha just on vp6 anyway...
[16:21:31] <twnqx> uhhh i broke my ffmpeg :X
[16:21:49] <twnqx> uh. and more.
[16:21:52] <BBB> DonDiego, I fixed it, didn't I?
[16:22:07] <BBB> elenril, which patch?
[16:22:14] * BBB seriously needs to start using git
[16:22:19] <KotH> BBB: btw: did you get your website for ffmtech?
[16:22:36] <BBB> KotH, I'm waiting for you to give me login credentials
[16:22:41] <KotH> ARGH
[16:22:43] <KotH> damn...
[16:22:45] <KotH> sorrry!
[16:22:47] <KotH> ^^'
[16:22:59] * KotH blames root for being lazy
[16:23:00] <BBB> that's ok :)
[16:23:03] <Honoome> lu_zero: feel like playing with genshi? :P
[16:23:15] <KotH> BBB: i'll try to have a look at it this evening
[16:23:19] <DonDiego> BBB: git does not write commit messages for you
[16:23:49] <merbzt> DonDiego: but it does, at least my version of git
[16:23:54] <merbzt> or I as drunk
[16:23:58] <merbzt> *was
[16:24:04] <snatches> this is one of the more entertaining channels I've been on.  I may have to grab some popcorn and just watch
[16:24:14] <DonDiego> haha
[16:24:15] <twnqx> >_>
[16:24:56] <_av500_> qoutes...
[16:25:01] <merbzt> snatches: we are not only just crazy, we are brilliantly crazy
[16:26:01] <BBB> dondiego: git allows me to have multiple changesets in a tree
[16:26:21] <BBB> dondiego: believe me, I have lots of random crap in my tree and I can't commit small changes for other people just like that :(
[16:26:26] <BBB> painful
[16:26:31] <elenril> BBB: thread set lavf ident string globally
[16:26:33] <snatches> well, I'm hoping the brilliance, no matter how crazy, rubs off on me a little.  my business seems to be going more and more towards streaming video and I need to get all the info I can to make sure I can service my clients
[16:26:43] <Kovensky> git gui is p. useful to select chunks to commit
[16:26:53] <Kovensky> there's also git format-patch :3
[16:26:55] <BBB> elenril, need topic title
[16:27:21] * siretart notices that mobile internet in train isn't exactly reliable…
[16:27:23] <elenril> BBB: that's it
[16:27:28] <BBB> oh
[16:27:30] <BBB> let me see
[16:27:33] <BBB> was it approved?
[16:27:35] <Honoome> siretart: still better than in planes ;)
[16:27:37] <elenril> yes
[16:27:46] <mru> and spaceships
[16:28:04] <BBB> elenril, was the asf patch applied?
[16:28:06] <kshishkov> good trains have own Internet though. Like X2 or X40
[16:28:09] <DonDiego> BBB: how does that prevent you from writing useless commit messages?
[16:28:22] <DonDiego> IOW, how is this related to what i said in any way?
[16:28:29] * elenril thought git creates commit messages too
[16:28:41] <elenril> by the power of its awesomeness
[16:28:45] <BBB> dondiego: it wasn't related, that's what I meant to say
[16:28:49] <siretart> Honoome: oh, my last experience with an delta domestic flight wasn't bad at all. at least they had a pretty reliable dns service :-)
[16:28:52] <BBB> dondiego: but I fixed the commit msg already :)
[16:29:02] <BBB> elenril: ok, hold on then
[16:29:15] * elenril holds on
[16:29:19] * Kovensky wonders if being unable to edit commit messages is a blocker in git's adoption
[16:29:20] <DonDiego> yes, but i hadn't seen the change yet
[16:29:31] <DonDiego> Kovensky: for me, it definitely is
[16:29:43] <BBB> DonDiego, is the new one ok?
[16:29:54] <DonDiego> yes
[16:29:55] <Kovensky> DonDiego: well, you CAN edit commit messages
[16:30:01] <DonDiego> Kovensky: nope
[16:30:04] <Kovensky> it will just break everyone else's history if you push
[16:30:15] <DonDiego> exactly --> useless
[16:30:39] <DonDiego> BBB: please train yourself on not writing pointless commit messages in the first place
[16:30:46] <BBB> dondiego: ok
[16:30:47] <elenril> you can do it like kernel people
[16:30:58] <Kovensky> the kernel way is the Right Way
[16:31:06] <merbzt> DonDiego: everyone know you shouldn't mess with the history
[16:31:13] <DonDiego> yes
[16:31:22] <kshishkov> Kovensky: we don't have spare Linus
[16:31:23] <BBB> elenril, any suggested commit msg?
[16:31:27] <KotH> merbzt: history is written by the winners
[16:31:28] <merbzt> you will disrupt the space time continuum
[16:31:30] <elenril> BBB: it's in the patch
[16:31:33] <BBB> oh I see
[16:31:44] * BBB tries to compile
[16:31:50] <kshishkov> merbzt: guess what's called a country with constantly changing past?
[16:32:02] <Honoome> Italy?
[16:32:03] <merbzt> kshishkov: Ukraine ?
[16:32:06] * elenril <3 git-format-patch
[16:32:09] <kshishkov> Soviet Union
[16:32:16] <Kovensky> elenril: s/-//
[16:32:25] <Kovensky> elenril: git-commands have been removed since 1.6 :P
[16:32:31] <kshishkov> Honoome: from what I know you have not got a country till 1871 or so
[16:32:34] <KotH> Kovensky: INGSOC!
[16:32:45] <Kovensky> BofH: what
[16:32:49] <elenril> Kovensky: http://tvtropes.org/pmwiki/pmwiki.php/Main/EntirelyMissingThePoint
[16:33:05] <Kovensky> elenril: http://tvtropes.org/pmwiki/pmwiki.php/Main/SpellMyNameWithAnS
[16:33:15] <elenril> err
[16:33:15] <Honoome> kshishkov: which is exactly why they keep on saying that our history is Roman/Celtic/Barbaric/WhateverSuitsThemThisTime
[16:33:16] <CIA-34> ffmpeg: rbultje * r21850 /trunk/libavformat/ (avi.c mp3.c metadata.c utils.c avienc.c metadata.h):
[16:33:16] <CIA-34> ffmpeg: Set lavf identification string globally in av_write_header(), rather
[16:33:16] <CIA-34> ffmpeg: than inside the muxers. Remove special handling of "encoder" tags from
[16:33:16] <CIA-34> ffmpeg: AVI and MP3 muxers.
[16:33:16] <CIA-34> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>.
[16:33:26] <KotH> er.. Kovensky, kshishkov: please change your nicks in a way that the first letters are different... thanks
[16:33:35] <kshishkov> Honoome: Etruskian :P
[16:33:42] <elenril> BBB: thanks
[16:33:44] <BBB> anything else I can help with?
[16:33:47] <kshishkov> KotH: begin with yourself
[16:33:55] <Kovensky> KotH: or just type two letters before hitting tab? :P
[16:34:07] <KotH> kshishkov: nah.. i hardly ever type my own nick, so no problem there :)
[16:34:17] <elenril> no, that's all for now
[16:34:21] <KotH> Kovensky: that's *effort*
[16:35:57] <mru> /rename KotH BofH
[16:36:03] <kshishkov> KotH: just don't answer one of us. That's less effort for everyone
[16:36:07] <elenril> KotH: and you're calling _me_ lazy
[16:36:16] <elenril> mru++
[16:36:35] <mru> hey, it worked
[16:36:38] <BofH> bah!
[16:36:43] <BofH> this nick is already taken!
[16:36:51] <elenril> :/
[16:36:53] * KotH blames mru 
[16:37:01] * mru blames BofH
[16:37:02] <KotH> elenril: ofc.. you are lazy
[16:37:46] <elenril> that's politically incorrect
[16:37:59] * elenril is motivation impaired
[16:38:14] <KotH> ADHD?
[16:38:27] <KotH> or just ADD?
[16:38:37] <mru> MUL
[16:38:59] <mru> SDHC
[16:39:19] <KotH> waht was it? IAIAO?
[16:39:22] <elenril> http://en.wikipedia.org/wiki/Secure_Digital#SDHC ?
[16:39:22] <kshishkov> RLWINM
[16:41:01] <mru> EIEIO?
[16:41:23] <kshishkov> what's that?
[16:41:34] <mru> a ppc instruction
[16:41:47] <mru> http://en.wikipedia.org/wiki/EIEIO
[16:43:11] <kshishkov> hmm
[17:26:09] <BBB> libavcodec/x86/dsputil_mmx.c:726: error: can't find a register in class ?GENERAL_REGS? while reloading ?asm?
[17:26:20] <BBB> who added that function (transpose4x4)?
[17:26:21] <kshishkov> well done, GCC!
[17:26:35] <kshishkov> it should be very old
[17:26:42] <kshishkov> svn/git blame is your friend
[17:27:24] <BBB> I can't compile it anymore :(
[17:28:14] * kshishkov thanks himself for using PowerPC
[17:31:21] <mru> we should move the code to yasm
[17:31:32] <kshishkov> good gsoc task?
[17:32:11] <Dark_Shikari> Yes
[17:32:13] <Dark_Shikari> absolutely absolutely yes
[17:32:16] <Dark_Shikari> holy shit yes
[17:32:18] <Dark_Shikari> do it
[17:32:22] <Dark_Shikari> fund it
[17:32:23] <Dark_Shikari> etc
[17:32:58] <kshishkov> next thing - make yasm part of FFmpeg to prevent external dependency ;)
[17:33:34] <mru> ffasm
[17:34:32] <kshishkov> good thing too
[17:34:53] <J_Darnley> Then what? ffcc?
[17:35:08] <kshishkov> excellent idea!
[17:35:14] <mru> then ffcpu
[17:35:33] <elenril> ffkernel?
[17:35:41] <mru> no, that's ffos
[17:36:53] <kshishkov> we need other ffutils for ffos
[17:37:09] <kshishkov> running on FFcpu
[17:38:26] <Dark_Shikari> ffcpu for cpu detection? =p
[17:39:42] <BBB> I'll buy beer for whoever fixes these issues forever and ever after
[17:39:56] <BBB> I keep having GENERAL_REGS compilation errors whenever someone touches the mmx files
[17:40:27] <Dark_Shikari> make it a soc project
[17:41:11] <Compn> heh
[17:41:28] <elenril> wouldn't that be a gcc soc project?
[17:41:48] <Compn> for all the amount of complaining about gcc... one could hack up tcc enough to just compile ffmpeg, then include it internally, make gcc compile tcc and tcc compile ffmpeg ;)
[17:42:28] <Kovensky> <+elenril> wouldn't that be a gcc soc project? <-- no
[17:42:29] <Compn> i mean, whats one more wheel?
[17:42:33] * elenril heard clang/llvm is NotBad
[17:42:33] <Kovensky> porting all the asm to yasm would fix that problem
[17:42:36] <Kovensky> no gcc, no problem
[17:42:57] <Kovensky> * elenril heard clang/llvm is NotBad <-- so did I, but atm it miscompiles ffmpeg
[17:43:06] * Kovensky is actually building a new clang right now
[17:43:21] <elenril> yeah, because it doesn't support asm or something
[17:46:07] <Andrius> when talking about clang, it's not "it doesn't support", it's "it doesn't support yet"
[17:46:25] <Andrius> unless you're talking about some horrible gcc extention
[17:46:34] <mru> and with gcc it's "it no longer supports"
[17:57:13] <astrange> transpose4x4 failure is because it doesn't add -mdynamic-no-pic
[17:57:56] <astrange> i meant to reply to that thread again. though in practice it'd probably end up with commiting the fix and then finding out if openbsd broke later
[17:58:03] <astrange> (was it openbsd? i can't remember the problem anymore)
[17:58:58] <kshishkov> and you'll still have broken Apple compiler I think
[18:00:04] * kshishkov wants x86* buried
[18:00:42] <astrange> apple gcc 4.0 is broken but not 4.2
[18:01:13] <peloverde> apple gas is still broken
[18:02:32] <BBB> kshishkov, you sound like one of those people that thinks maemo or moblin is going to b the next iphone killer :-p
[18:02:59] <kshishkov> BBB: no, I'm firm believer in people stupidity
[18:03:32] <Dark_Shikari> unsigned comparisons are amazing.  I just cut a loop's size by half by abusing unsigned casts
[18:04:04] <Kovensky> BBB: maemo merged with moblin IIRC
[18:04:14] <Kovensky> or it was some other random merge but one of those two were involved
[18:04:19] <BBB> Kovensky, that's why I mention it :-p
[18:04:33] <Dark_Shikari> if( x < 0 || (y >= 0 && y < x ) x = y; ---> if( (unsigned)y < (unsigned)x ) x = y;
[18:04:36] <Dark_Shikari> magic
[18:04:59] <kshishkov> employed in lavc for, say, bounds detection
[18:05:04] <Dark_Shikari> yup
[18:09:04] <Compn> Dark_Shikari : yeah, but until you optimize by half a cpu cycle ....
[18:09:35] <peloverde> Is there any chance of GCC's uninitialized warnings ever being not retarded?
[18:09:43] <mru> no
[18:10:26] <Dark_Shikari> no
[18:10:26] <astrange> there seems to have been a failed soc project about that
[18:10:29] <astrange> http://gcc.gnu.org/wiki/Better_Uninitialized_Warnings
[18:10:36] <Dark_Shikari> ll
[18:10:37] <peloverde> Why did they even bother adding it when it spits out so many false positives
[18:10:38] <Dark_Shikari> *lol
[18:10:44] <Dark_Shikari> peloverde: it _is_ useful
[18:10:48] <Dark_Shikari> the problem is there's no way to shut it up
[18:10:50] <kshishkov> is there _not failing_ GCC project?
[18:10:53] <astrange> clang just moves it into their "static analysis" option but the warning is just as bad
[18:12:02] <peloverde> I don't think it's ever caught a real bug for me, and to shut it up i have to initializers that just slow things down
[18:13:31] <Kovensky> kshishkov: weight-p
[18:13:37] <Kovensky> oh, gcc
[18:13:39] <Kovensky> I read taht as gsoc
[18:13:44] <Kovensky> that*
[18:20:20] <CIA-34> ffmpeg: rbultje * r21851 /trunk/libavformat/rtp_asf.c:
[18:20:20] <CIA-34> ffmpeg: Don't return 0 if buffer setup failed. That signals the RTSP demuxer that
[18:20:20] <CIA-34> ffmpeg: the packet was filled in, leading to virtually random behaviour in the
[18:20:20] <CIA-34> ffmpeg: decoder later on. Instead, return a negative value.
[18:22:05] <BBB> shit that's a bad one
[18:22:08] * BBB hides in shame
[18:22:10] <BBB> let me revert that
[18:22:28] <BBB> that whole code seems broken anyway
[18:24:13] <kshishkov> <CIA-34> ffmpeg: rbultje * r21852 /trunk/libavformat (3 files): revert RTP completely, it's broken anyway
[18:25:54] <CIA-34> ffmpeg: rbultje * r21852 /trunk/libavformat/rtp_asf.c: Revert r21851.
[18:26:02] * BBB kicks kshishkov 
[18:26:09] <BBB> I actually thought that was real for a second
[18:26:28] <kshishkov> <CIA-666> ouch!
[18:26:45] <Dark_Shikari> lol
[18:27:28] <Dark_Shikari> <CIA-34> ffmpeg: darkshikari * r21853 /trunk/libavformat (21 files): revert RTP completely, it sucks anyway
[19:16:05] <peloverde> What's going on with FATE these days? Is all that yellow still from the character set issues?
[19:16:30] <mru> no, this is some other vague breakage
[19:16:50] <peloverde> Is anybody working on it?
[19:17:06] <mru> some say the references need updating
[19:17:32] <peloverde> Isn't the point of FATE so we can track down exactly where things broke?
[19:17:55] <mru> we know what broke it
[19:18:10] <mru> it was some change related to -t handling
[19:18:21] <mru> some files now get one frame less than they used to
[19:18:39] <mru> go badger mike to update the refs
[19:18:46] <peloverde> So either the change is correct and we need to update the test specs or the change is wrong and we need to revert?
[19:19:06] <mru> or both
[19:20:38] <peloverde> I count both as the former
[19:21:36] <BBB> is url_open_dyn_packet_buf() broken?
[19:22:00] <kshishkov> who uses it beside you?
[19:22:03] <BBB> I get the weirdest output, where the data is preceeded by a 4-byte integer consisting of the max_packet_size value I fed it
[19:22:17] <BBB> url_open_dyn_buf() works just fine
[19:22:24] <peloverde> Some of the videos are coming out significantly shorter
[19:22:27] <peloverde> like pva
[19:22:49] <kshishkov> BBB: maybe you don't pass an AVPacket pointer to it?
[19:23:22] <kshishkov> since output lookslike AVPacket contents
[19:24:27] <BBB> I think it is intended
[19:24:35] <BBB> the code very intentionally writes the packet size in there
[19:24:41] <BBB> no idea how this ever worked
[19:24:44] <BBB> maybe it didn't
[19:24:53] <kshishkov> what code uses it?
[19:25:10] <kshishkov> for example, nothing uses SHA-1
[19:26:55] <BBB> rtsp
[19:27:04] <BBB> I think problem is fixed now
[19:27:39] <CIA-34> ffmpeg: rbultje * r21853 /trunk/libavformat/rtp_asf.c:
[19:27:39] <CIA-34> ffmpeg: Fix two problems (no idea how this ever worked):
[19:27:39] <CIA-34> ffmpeg: - the return value of url_open_dyn_*buf() is 0 on success, so using
[19:27:39] <CIA-34> ffmpeg:  if (!(res = url_open_dyn_*buf())) return res; is not going to work
[19:27:39] <CIA-34> ffmpeg: - url_open_dyn_packet_buf actually writes the max_packet_size before
[19:27:39] <CIA-34> ffmpeg:  each piece of data. Feeding this to the ASF demuxer will never work.
[19:27:39] <CIA-34> ffmpeg:  Therefore, use url_open_dyn_buf() instead.
[19:31:57] <Dark_Shikari> mru: does ffmpeg have proper 16 byte alignment macros for arm?
[19:32:14] <kshishkov> yes
[19:33:42] <Dark_Shikari> k
[19:33:47] <Dark_Shikari> kshishkov: you're getting a patch review
[19:35:37] <kshishkov> thanks
[19:38:22] <mru> Dark_Shikari: what do you mean?
[19:39:44] <Dark_Shikari> I meant that it allocates 15 extra bytes on stack
[19:39:48] <Dark_Shikari> and does a &~15 with the pointer
[19:39:49] <Dark_Shikari> and all that
[19:40:00] <mru> I have a patch for that
[19:40:04] <mru> it was bikeshedded
[19:40:09] <Dark_Shikari> .... it's still not in?
[19:40:21] <Dark_Shikari> that's pathetic
[19:41:10] * Kovensky remembers something about apple's gcc not respecting ARM's ABI that demands alignment for smth
[19:41:32] <mru> arm abi requires 8-byte aligned stack on external function calls
[19:41:36] <mru> apple ignores that
[19:41:40] <kshishkov> Apple's GCC respects something?
[19:41:47] <Dark_Shikari> steve jobs
[19:41:59] <mru> no arm compiler can provide 16-byte alignment on stack
[19:42:27] <kshishkov> Dark_Shikari: Apple history shows that they will get rid of him at first opportunity
[19:43:39] <Dark_Shikari> mru: x264 has it though ;)
[19:44:29] <mru> I know
[19:44:38] <mru> we discussed it here back then
[19:45:33] <Dark_Shikari> kshishkov: review sent
[19:48:19] <Yuvi> mru: llvm svn can kinda, it lost the stack pointer when I tried it with ffmpeg though
[19:48:33] <kshishkov> Dark_Shikari: got it
[19:48:45] * kshishkov pauses "Yes, Minister" episode to read mail
[19:49:22] <Dark_Shikari> also, wow, bink is really simple
[19:49:29] <Dark_Shikari> like, everything in it actually makes sense as far as I can see
[19:49:31] * Kovensky has spent the past 8 hours waiting for his vm to compile llvm+clang
[19:49:33] <Dark_Shikari> every single mode is done as simple as possible
[19:49:50] <Dark_Shikari> it's like what would happen if you gave On2 some sense
[19:51:48] <kshishkov> Kovensky: make it swappy
[19:52:06] * Kovensky is still waiting for it to finish compiling
[19:52:09] <kshishkov> answering your question - get_bits(0) does not work on x86
[19:52:19] <Kovensky> it's on tools/clang/lib/Frontend now
[19:52:30] <Dark_Shikari> kshishkov: ok
[19:52:32] <Dark_Shikari> one more note
[19:52:35] <Dark_Shikari> that I didn't note in that message
[19:52:35] <kshishkov> Kovensky: that way it will take even longer. And if you could run that VM on different arch...
[19:52:41] <Dark_Shikari> if you make that 8x8->16x16 DSP function as I said, you can remove a ton of code
[19:52:43] <Kovensky> lol
[19:52:47] <Dark_Shikari> i.e. the entire if(scaled) section
[19:52:55] <Dark_Shikari> since you just do an 8x8 decode and, if(scaled), convert to 16x16
[19:53:01] <mru> get_bits(0) does a >>32
[19:53:04] <mru> which is undefined
[19:53:13] <Kovensky> kshishkov: vmware server 2's defaults is to allow swapping
[19:54:49] <kshishkov> Kovensky: not allow but really make it use swap instead of RAM
[19:55:30] <Kovensky> http://www.houseofsixten.com/hcstaff/?p=1351
[19:55:49] <mru> buy more ram
[19:56:23] <kshishkov> mru: his goal is to make it compile longer
[19:56:41] * kshishkov remembers the times when computers had "Turbo" button
[19:57:20] <kierank> kshishkov: was that last month in .ua ;)
[19:58:16] <kshishkov> kierank: no, they all gone around 2000 or a few years later
[19:58:35] <kshishkov> not after 2005 at least
[19:58:50] <Kovensky> * kshishkov remembers the times when computers had "Turbo" button <-- mine switched between 20/40 MHz
[19:58:55] <Kovensky> or at least that's what the display said
[19:58:55] <Kovensky> :>
[19:59:18] <mru> my current computer has a speed dial on the front
[19:59:20] <mru> for the fan
[19:59:27] <mru> and water pump
[20:00:23] * Kovensky thinks C++ + g++ explain a lot of the slowness on llvm's compilation
[20:00:43] <peloverde> >>32 works fine if you specify -fdo-what-i-mean-not-what-i-say
[20:00:45] <kshishkov> huh? compiling C compiler with g++?
[20:00:55] <astrange> llvm is written in c++
[20:01:20] <kshishkov> so I guessed
[20:01:26] <Kovensky> llvm[4]: Compiling LLVMConventionsChecker.cpp for Debug build
[20:01:26] <Kovensky> llvm[4]: Compiling MallocChecker.cpp for Debug build
[20:01:27] <kshishkov> why not Lisp?
[20:02:21] <astrange> http://pastebin.com/m2dd06ce9 "addl $0, %esi"?
[20:03:00] <kshishkov> it's faster than cmp?
[20:10:52] <mru> Dark_Shikari: aligned stack macros re-posted
[20:14:07] <jez9999> BBB: hey... could you check in the patch for issue 1740?
[20:15:31] <kshishkov> jez9999: have you provided patch approval, ID card and filled form 26-stroke-B ?
[20:15:42] <jez9999> yup
[20:15:53] <jez9999> papers are correct
[20:16:43] <mru> and the $10k in a brown bag?
[20:16:59] <mru> ah, "papers"... I see
[20:18:39] <CIA-34> ffmpeg: stefano * r21854 /trunk/libavutil/ (pixdesc.h pixdesc.c):
[20:18:39] <CIA-34> ffmpeg: Move read_line() and write_line() definition from pixdesc.h to
[20:18:39] <CIA-34> ffmpeg: pixdesc.c, which are now not anymore marked as static inline.
[20:18:39] <CIA-34> ffmpeg: Fix the inclusion of the private header intreadwrite.h in the public
[20:18:39] <CIA-34> ffmpeg: header pixdesc.h.
[20:57:02] <Dark_Shikari> I should patch review more often
[20:57:04] <Dark_Shikari> take some load off michael
[20:57:13] <Dark_Shikari> it's a good way to make it look like I'm doing something without actually doing work
[21:02:04] <elenril> or you could fix remuxing h264 from matroska
[21:02:06] * elenril hides
[21:25:23] <Dark_Shikari> for int8_t ref[2]
[21:25:24] <Dark_Shikari> if( (M16( ref ) & 0x8080) == 0x8080 )
[21:25:33] <Dark_Shikari> why is this not the same as if( ref[0] < 0 && ref[1] < 0 ) ?
[21:25:39] <Dark_Shikari> where M16() is a uint16_t-reading macro.
[21:28:47] <mru> hmm
[21:29:04] <mru> ah, weird whitespace around your ()
[21:29:07] <mru> that's got to be it
[21:30:36] <Dark_Shikari> lol
[21:32:32] <astrange> it looks ok to me, debug it
[21:33:06] <peloverde> Is ff_imdct_half supposed to be able to work with the same input and output?
[21:36:45] <Dark_Shikari> astrange: er, that's weird.  when I compiled it again it fixed itself.
[21:37:19] <Dark_Shikari> ok, now that I have that structure
[21:37:25] <Dark_Shikari> what's a better way to do ref[0]&&ref[1]?
[21:37:30] <Dark_Shikari> i.e. if(ref[0]&&ref[1])
[21:37:34] <Dark_Shikari> given that we can now do an M16()
[21:39:09] <astrange> r = M16(ref); if (r & 0xFF00) +
[21:39:12] <astrange> oops
[21:39:22] <astrange> r = M16(ref); if ((r & 0xFF00) + (r + 0xFE))
[21:39:33] <Dark_Shikari> I doubt that's faster...
[21:39:37] <astrange> + 0xFF
[21:39:40] <astrange> yeah, it's kind of lame
[21:39:50] <Dark_Shikari> it's annoying, you can easily do || butnot &&
[21:45:19] <Dark_Shikari> hmm, can the < 0 double-check be done in one instruction?
[21:45:24] <Dark_Shikari> I guess not without simd
[22:01:07] <BBB> did any students come in yet for the summer of code?
[22:02:14] <astrange> someone new came to ask about h264 decoder tuning, didn't say if he was a student
[22:02:24] <astrange> i haven't heard anyone ask about it specifically
[22:02:37] <BBB> hmmm... need to advertise more :)
[22:39:36] <CIA-34> ffmpeg: stefano * r21855 /trunk/ffplay.c:
[22:39:36] <CIA-34> ffmpeg: Rename the "enc" variable, which refers to the AVCodecContext of a
[22:39:36] <CIA-34> ffmpeg: decoder, to "avctx".
[22:39:36] <CIA-34> ffmpeg: See the thread:
[22:39:36] <CIA-34> ffmpeg: Subject: [FFmpeg-devel] [PATCH] enc is not a good name for a decoder context
[22:39:37] <CIA-34> ffmpeg: Date: Mon, 28 Dec 2009 22:56:25 +0100
[22:45:05] <peloverde> hurray for satisfying another required SBR "optimization" that actually makes the code 1% slower
[22:45:24] <Dark_Shikari> what's that?
[22:45:36] <peloverde> eliminating qmf_filter_scratch from sbr_qmf_synthesis
[22:45:56] <peloverde> I've lost nearly 20% from the "optimizations" requested during review
[22:46:02] <peloverde> it's kind of ridiculous
[22:46:27] <Dark_Shikari> it does make sense if the optimizations allow DSPutil stuff
[22:46:28] <Dark_Shikari> e.g. more SIMD
[22:46:43] <peloverde> some of them do
[22:46:51] <peloverde> some of them don't
[22:47:16] <Dark_Shikari> why not say that they made it slower?
[22:47:42] <peloverde> because I don't want to argue, i want to land SBR so I can finish and land PS so I can pay rent and buy things
[22:47:57] <peloverde> I'm paid for PS, SBR is just a roadblock on the way
[22:48:10] <peloverde> I can fix it later when I have more free time
[22:48:25] <Dark_Shikari> lol
[22:48:29] <Dark_Shikari> how much are you getting for PS?
[22:48:37] <peloverde> 2000 Eur
[22:49:40] <Dark_Shikari> .... that's it?
[22:49:46] <Dark_Shikari> I thought it would be more work than that
[22:50:16] <peloverde> PS is fairly straight forward
[22:50:39] <Dark_Shikari> hmm, I guess.
[22:50:48] <Dark_Shikari> I'm just surprised you wouldn't be able to squeeze more for that feature
[22:52:55] <BBB> lucky guy whoever contracted him for that :)
[22:53:03] <BBB> but peloverde, thanks for doing sbr :)
[22:53:17] <CIA-34> ffmpeg: rbultje * r21856 /trunk/libavformat/ (rtpdec.h rtsp.c rtpdec.c):
[22:53:17] <CIA-34> ffmpeg: When using RTP-over-UDP, send dummy packets during stream setup, similar to
[22:53:17] <CIA-34> ffmpeg: what e.g. RealPlayer does. This allows proper port forwarding setup in NAT-
[22:53:17] <CIA-34> ffmpeg: based environments.
[22:53:17] <CIA-34> ffmpeg: Patch by Martin Storsj? <$firstname at $firstname dot st>.
[22:53:57] <Dark_Shikari> BBB: indeed
[22:54:43] <Honoome> oh fantastic now I start getting fingerprint collision
[22:54:50] <astrange> you could leave out the ones that aren't faster and leave their patches as small tasks
[22:54:51] <Honoome> one has to love ec2 to actually wish to work with that stuff
[23:00:55] <CIA-34> ffmpeg: rbultje * r21857 /trunk/libavformat/ (rtpdec.h rtpdec.c):
[23:00:55] <CIA-34> ffmpeg: Remove first_rtcp_ntp_time. This is used to prevent overflow of the timestamp,
[23:00:55] <CIA-34> ffmpeg: but doesn't actually do that. What's worse, it creates timestamp adjustments
[23:00:55] <CIA-34> ffmpeg: that are different per stream within a session, leading to a/v sync issues.
[23:00:55] <CIA-34> ffmpeg: See discussion in thread "[FFmpeg-devel] rtp streaming x264+audio issues (and
[23:00:55] <CIA-34> ffmpeg: some ideas to fix them)". Patch suggested by Luca Abeni <lucabe72 email it>.
[23:02:50] * BBB just played his first rtsp/wmavoice strea
[23:05:08] <CIA-34> ffmpeg: siretart * r21858 /branches/ (0.5 0.5/doc/ffmpeg-doc.texi):
[23:05:08] <CIA-34> ffmpeg: misc. manpage updates, fixes LP: #501729, Debian: #570050
[23:05:08] <CIA-34> ffmpeg: Update ffmpeg documentation regarding metadata setting. -title,
[23:05:08] <CIA-34> ffmpeg: -author, -copyright, -track, -album, and -year options have been
[23:05:08] <CIA-34> ffmpeg: dropped in favor of -metadata.
[23:05:08] <CIA-34> ffmpeg: Add an explanation and complete the metadata usage example.
[23:05:09] <CIA-34> ffmpeg: backported revisions r19285, r19287 and r19320 by stefano.
[23:15:18] <peloverde> Also why does PS live in subpart 8?
[23:16:59] <mru> not enough subparts otherwise
[23:17:59] <astrange> peloverde: you attached the simd patch instead of the sbr one
[23:18:15] <peloverde> today is not my day
[23:19:20] <peloverde> thanks
[23:44:00] <CIA-34> ffmpeg: michael * r21859 /trunk/libavcodec/h264_cabac.c:
[23:44:00] <CIA-34> ffmpeg: 2x faster ff_h264_init_cabac_states(), 4k cpu cycles less.
[23:44:00] <CIA-34> ffmpeg: Sadly this is just per slice so the speedup with normal files should be negligible.
[23:45:09] <Dark_Shikari> negligable.... ehehehheeh he hasn't seen our 20-mb-per-slice files ;)
[23:46:18] <janneg> or he just doesn't consider them normal
[23:46:24] <astrange> peloverde: the loop 'while (k <= sbr->n_lim)' has a stray ; at the end, my gcc warns new_bw may be uninitialized in sbr_chirp (fixed with av_uninit or a default switch case)
[23:46:41] <astrange> peloverde: no other complaints. ...except ffplay plays everything at half speed
[23:49:29] * mru wants to kill someone
[23:49:49] <Dark_Shikari> janneg: of course
[23:50:40] * Honoome hands some Amazon sysadmins to mru
[23:51:06] <mru> any autohell devs in sight?
[23:51:11] <mru> they'd better hide fast
[23:52:02] <Honoome> mru: uhm may I help somehow?
[23:52:18] * Honoome is no autohell developer, but is an autohell supporter
[23:52:19] <mru> configure.ac:26: error: Please use exactly Autoconf 2.59 instead of 2.63.
[23:52:23] <Honoome> …
[23:52:26] <Honoome> no that's not autohell developers
[23:52:29] <mru> configure.in:11: error: Autoconf version 2.60 or higher is required
[23:52:37] <Honoome> taht's definitely the project being stupid, what project is that?
[23:52:41] <mru> newlib
[23:52:49] <Honoome> ouch :|
[23:53:04] <Honoome> redhat/ex-cygnus… I think autotools people hate them as much as you do
[23:53:07] <mru> all I want to do is add one small file...
[23:53:32] <Honoome> mru: newlib, gcc, use a bastardised autotools buildsystem… which is much worse than autotools :/
[23:53:47] <mru> any idea how to "fix" it?
[23:54:41] <Honoome> I'm afraid, not… the very fact that it has two configure.(ac|in) files with different extension says that the whole thing is screwed :(
[23:54:56] <mru> different subdirs
[23:55:06] <Honoome> yeah I guessed that
[23:55:11] <Honoome> latest version in gentoo is from 2007 o_o
[23:56:11] <Kovensky> I don't hate autotools but I sure hate libtool <_<
[23:56:41] * Kovensky is workarounding at least three different libtool bugs, two of which are considered features
[23:57:08] <Kovensky> "two of which"... I wonder if that even makes sense lol
[23:57:41] <mru> perfect sense it makes
[23:58:11] <Honoome> really, I don't dislike autotools because I have seen much worse stuff
[23:58:33] * Kovensky remembers the dreaded cmake build system that was in ffms2
[23:58:33] <Honoome> but the autotools devs should get their shit together and have a *single* tool, not autoconf+automake+libtool with _slightly_ different ideas on how to do stuff =_=
[23:58:37] <mru> I dislike bad things, even if worse things exist
[23:58:51] <mru> and wildly incompatible versions
[23:58:58] <Honoome> that as well
[23:59:02] <mru> and of course each fucking package depends on a different version
[23:59:17] <Honoome> why should they have multi-level incompatibilities one with the other? just make it a single fucking project that follows a single idea :|