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

[irc at mansr.com]

[00:17:37] <peloverde> Is there a penalty for using an SSE memory operand twice vs putting it in a register then using it twice?
[00:19:43] <Dark_Shikari> yes, there will be two loads
[00:19:44] <Dark_Shikari> HOWEVER
[00:19:47] <Dark_Shikari> here's a critical thing to note
[00:20:02] <Dark_Shikari> memory loads are _FREE_ as long as the load unit isn't saturated
[00:20:18] <Dark_Shikari> so if you aren't load bottlenecked, and you need another register, it can be beneficial to repeatedly reload a value
[00:20:37] <Dark_Shikari> in general, avoid it if you can, but if you can't avoid it, it's rarely a big deal in anything but load-bottlenecked code
[00:20:39] <peloverde> that's pretty much the case that I think I'm in
[02:37:27] <Dark_Shikari> they see me trollan' http://x264dev.multimedia.cx/?p=317
[02:40:35] <Yuvi> Dark_Shikari: dirac does have some spatial AQ
[02:41:04] <Yuvi> in that you can divide each subband into blocks, each with a different quant
[02:47:44] <Yuvi> (it actually caused a schism in the format, with newer schro following the written spec there more closely, making an incompatible bitstream from what libdirac does)
[02:57:42] <Dark_Shikari> lol
[02:57:50] <Dark_Shikari> oh, you can divide subbands to get spatial AQ?
[02:57:57] <Dark_Shikari> I'll have to fix that then
[02:58:07] <Yuvi> yeah, it's also how it handles clumps of 0 coeffs
[02:58:15] <Yuvi> instead of doing RLE like snow
[02:59:04] <Dark_Shikari> how much can it subdivide it into blocks?
[02:59:33] <Yuvi> completely arbitrary, you could have a subblock per coeff
[03:00:36] <Dark_Shikari> ok, fixed the post
[03:00:47] <Dark_Shikari> does dirac have anything like AQ to leverage that?
[03:01:05] <Dark_Shikari> how does it use it?
[03:02:28] <Yuvi> schro doesn't do anything useful with it, libdirac doesn't enable it by default
[03:02:44] <Yuvi> don't know if libdirac does anything useful when you enable it
[03:26:52] <Yuvi> http://diracvideo.org/git?p=dirac-research.git;a=blob;f=libdirac_encoder/picture_compress.cpp;h=0efdf54e562643c0b308d37a03fe49941ef03540;hb=HEAD#l647 looks like libdirac only considers it in the entropy coder
[03:27:32] <Dark_Shikari> ah.
[03:30:22] <pengvado> what do you call it when you use a wavelet/pyramid/mipmap to merge two images without any visible edge in between? i.e. let each image feature peter out on it's own length scale.
[03:34:06] <Dark_Shikari> explain further?
[03:34:37] <Yuvi> or actually it doesn't consider it at all http://diracvideo.org/git?p=dirac-research.git;a=blob;f=libdirac_encoder/quant_chooser.cpp;h=16ffcb3bd43d8fbaac49770384a0561b6fd02dc5;hb=HEAD#l62
[03:35:00] <pengvado> say I have a photo of an apple and another photo of an orange. I want to construct an image that's the apple on the left, the orange on the right, and you can't see a seam in the middle.
[03:35:44] <ohsix> hm i've seen a few papers about that but i dont know if it really has a single or any name
[03:36:01] <Dark_Shikari> pengvado: ah.  that.
[03:47:10] <CIA-92> ffmpeg: michael * r22085 /trunk/libavcodec/h264.h: Split *_type setting up, 4 cpu cycles faster.
[04:10:36] <CIA-92> ffmpeg: michael * r22086 /trunk/libavcodec/h264.h: Merge h->slice_table[left_xy[0/1] ] checks, 4 cpu cycles speedup
[08:17:09] <_av500_> &win 3
[08:17:49] <kshishkov> perl expression?
[08:18:16] <ohsix> /win changes your window in a few irc clients
[08:18:27] <kshishkov> ah
[08:20:07] <_av500_> kshishkov: wrong kezmap :)
[08:20:21] <kshishkov> now too
[08:20:31] <_av500_> zes
[08:21:00] * kshishkov wonders why Germans need US keymap anyway with their "qwertz" and slash=shift+7
[08:22:03] <_av500_> i am on an usb kbd hooked to an a5 running android ssh client...
[08:23:01] <kshishkov> wonderful
[08:23:10] <_av500_> zes!
[08:23:22] * kshishkov wants Swedish USB keyboard though
[08:23:44] * _av500_ declares wrong kezmap daz...
[08:24:45] * elenril wonders what mushrooms were people who made qwertz smoking
[08:25:06] <kshishkov> elenril: ask French about "azerty" first
[08:25:31] <elenril> heh
[08:25:36] * elenril has a french craptop
[08:26:11] <elenril> it has azerty layout printed on it, but i use qwerty
[08:26:52] <elenril> hilarity ensues when anyone else tries to use it
[08:27:05] <ohsix> theres an old tale about qwerty being designed to avoid typewriter jams
[08:28:55] <_av500_> elenril: same here, got a french s10...
[08:29:37] <elenril> avi doesn't support chapters, right
[08:30:02] <_av500_> not afaik
[08:30:10] <_av500_> ask divx tough
[08:30:22] <_av500_> thez added dvd stzle menus and subs
[08:30:36] <_av500_> before they switched to h264 and mkv
[08:31:05] <kshishkov> elenril: national layouts were selected for their letter frequency (theoretically). And they differ between languages
[08:31:25] * elenril thinks it's bs
[08:31:49] <elenril> i don't think there was a good reason to just switch y and z
[08:32:36] <elenril> except to screw with everyone, m$ style
[08:34:05] <kshishkov> could be
[08:34:28] <kierank> like secam
[08:35:00] * kshishkov wonders why he has good German accent and had chosen mail address starting with "qwertz" once but does not know German nor has German ancestors or relatives
[08:35:53] <kshishkov> kierank: secam is actually the simplest colour scheme of them all, so it was used only in underdeveloped countries - France and its (former) colonies and USSR
[08:36:06] <kierank> no it was done for french protectionism
[08:36:16] <kierank> and to annoy british people who'd bought tapes from abroad
[08:36:24] <kshishkov> they invented SCART for that
[08:36:58] <kshishkov> and Britain was outdated as well
[08:37:25] <kierank> the chroma was incompatible with pal iirc
[08:37:33] <kshishkov> of course
[08:38:33] * kshishkov still lives in mixed PAL-SECAM country
[08:38:57] <kshishkov> the only good thing is that I don't watch TV anymore
[08:39:01] <kierank> is there going to be a digital switchover?
[08:39:22] <kshishkov> not in this century I fear
[08:40:01] <ohsix> isn't it dvb over there?
[08:40:03] <kierank> or are you yet to have 405 line to 625 line?
[08:40:33] <kshishkov> no
[08:42:32] <kshishkov> ohsix: you'd be surprised what thing we are lacking
[08:43:07] <pJok> mornings
[08:43:24] <ohsix> probably; but i thought that other side of the world went with dvb and for some reason we did atsc
[08:43:41] <kshishkov> goda morgnar
[09:28:50] <siretart> DonDiego: hi there
[09:28:55] <DonDiego> hoi
[09:29:18] <DonDiego> what's the release status?
[09:29:24] <siretart> did you read my mail about the release?
[09:29:30] <DonDiego> where?
[09:29:44] <siretart> do you have a few minutes time, let's talk about that on phone
[09:29:46] <thresh> any ffserver gurus (#ffmpeg is sleeping i think :() http://dumpz.org/17252/ ?
[09:30:53] <siretart> TTBOMK, I think the only left issue is the RELEASEVERSION #define in avcodec.h
[09:31:03] <siretart> other than that, I think we're ready for 0.5.1
[09:31:20] <kshishkov> thresh: try throwing out VideoBitRate
[09:31:36] <kshishkov> or quantizers
[09:33:08] <thresh> is ffserver maintained and/or usable anyway, should I just tell my users to use vlc? :)
[09:33:42] <thresh> almost the same, but now i have only one output stream and one underflow error
[09:33:45] <astrange> bcouderier(iererer?) maintains ffserver
[09:34:44] <kshishkov> astrange: a lot of people tried to maintain FFserver and failed
[09:58:27] <DonDiego> people of #ffmpeg-devel ...
[09:58:33] <DonDiego> hear me out
[09:58:53] * kshishkov lends his ears
[09:59:03] <DonDiego> do you know of any issues that need fixing for 0.5.1?
[09:59:19] <DonDiego> siretart and myself wish to push this out RSN
[09:59:48] <DonDiego> so speak up now or be silent forever :)
[10:00:46] <kshishkov> じーーーーーん
[10:02:35] <CIA-92> ffmpeg: siretart * r22087 /branches/0.5/libavcodec/avcodec.h:
[10:02:35] <CIA-92> ffmpeg: bump LIBAVCODEC_VERSION_MICRO for addition of the lock manager API
[10:02:35] <CIA-92> ffmpeg: As discussed with Diego, we'll go for bumping micro in 0.5 and will
[10:02:35] <CIA-92> ffmpeg: consider adding a RELEASEVERSION macro for trunk and 0.6 seperatly
[10:11:47] <CIA-92> ffmpeg: diego * r22088 /trunk/MAINTAINERS: sort() names in PGP/GPG fingerprint list
[10:11:48] <CIA-92> ffmpeg: siretart * r22089 /trunk/MAINTAINERS: add myself to gpg fingerprint list
[10:17:34] <CIA-92> ffmpeg: siretart * r22090 /branches/ (0.5/MAINTAINERS 0.5):
[10:17:34] <CIA-92> ffmpeg: add myself to gpg fingerprint list
[10:17:34] <CIA-92> ffmpeg: backport r22089 by siretart
[11:27:18] <DonDiego> mru: have you seen all these ea audio failures for the offbeat archs?
[11:27:23] <DonDiego> on fate i mean
[11:57:49] * kshishkov tries to resist replying "help needed in understanding ut video encoder/decoder" with "if you don't know Japanese and need docs to understand codec then you're no FFmpeg developer"
[12:07:44] <elenril> kshishkov: no need to resist it, give in to the dark side
[12:08:55] <[1]kierank> i'm almost certain that guy is trying to add the binary codec to ffmpeg
[12:09:19] <kshishkov> or copypaste sources in whole
[12:13:51] <CIA-92> ffmpeg: kostya * r22091 /trunk/libavcodec/ (ivi_common.h ivi_common.c): Make it clear that ff_ivi_init_static_vlc() does not need arguments
[12:19:05] <DonDiego> this reminds me of -Wstrict-prototypes
[12:19:21] <DonDiego> unfortunately it seems to trip up with function pointers
[12:24:43] <kshishkov> well, "void func()" always seemed to me as "I don't care about arguments completely"
[12:27:34] <DonDiego> still it's wrong :)
[12:27:54] <kshishkov> nah, been here since K&R
[12:29:40] <DonDiego> () denotes variable number of arguments, you need (void) to denote no arguments, see the C standard
[12:33:03] <DonDiego> geez, all those h.264 warnings are incredibly annoying..
[12:33:14] <kshishkov> so turn them off ;)
[12:33:24] <CIA-92> ffmpeg: kostya * r22092 /trunk/libavcodec/ (indeo5.c ivi_common.h ivi_common.c):
[12:33:24] <CIA-92> ffmpeg: Encapsulate VLC information needed for decoding blocks and macroblocks in
[12:33:24] <CIA-92> ffmpeg: Indeo 5 into single structure IVIHuffTab and factorize code using it.
[12:33:24] <CIA-92> ffmpeg: Based on patch by Maxim (max_pole at German GMX)
[12:35:14] <DonDiego> kshishkov: that, sisyphus work, you elimate one, michael adds two new ones..
[12:35:47] <kshishkov> DonDiego: I have an easy solution - optimize H.264 by yourself, so Michael won't have to work on it
[12:36:38] <DonDiego> done
[12:36:50] <DonDiego> if it weren't for me, michael would not be working on h.264..
[12:37:27] <kshishkov> you've donated yours K-III for his primary development machine, haven't you?
[12:38:35] <DonDiego> no, i'm working on it right now
[12:38:38] <DonDiego>     PayloadContext *(*open) ();
[12:38:56] <DonDiego> libavformat/rtpdec.h:143
[12:39:10] <DonDiego> what's wrong with that line?
[12:39:11] <DonDiego> rtpdec.h:143: warning: function declaration isn’t a prototype
[12:39:29] <DonDiego> this is the warning it generates with -Wstrict-prototypes
[12:39:41] <kshishkov> does not like functors, eh?
[12:46:26] <DonDiego> moin stefano
[12:46:47] <DonDiego> saste: defaults.c:26: warning: no previous prototype for ‘avfilter_default_free_video_buffer’
[12:46:51] <DonDiego> :)
[13:05:29] <saste> DonDiego: i'll try to have a look at it
[13:06:13] <saste> and BTW the list of warnings is growing longer
[13:06:20] <DonDiego> yes :-(
[13:06:35] <DonDiego> the sad thing is that most are trivial to fix
[13:06:52] <DonDiego> and our devs are just lazy/careless about them..
[13:07:03] <saste> i have a patch for implementing a less verbose compilation
[13:07:24] <saste> of the kind gcc blah blah -> [CC] module.o
[13:07:25] <DonDiego> of course -Wmissing-prototypes introduced new warnings..
[13:07:53] <DonDiego> i never understood what was so great about terse builds..
[13:07:58] <saste> i wonder if all those warnings are avoidable...
[13:08:21] <saste> with terse build is easier to spot warning in the noise of the compilation commands
[13:08:39] <DonDiego> colorgcc
[13:08:51] <DonDiego> also, you should actively watch out for warnings..
[13:09:03] <saste> that doesn't always work
[13:09:29] <saste> i usually compile within emacs which already has facilities for displaying in a different color the warnings
[13:09:48] <saste> yet if the compilation output is huge it is harder to spot new warnings
[13:12:51] <Kovensky> just -Wall -Wextra -pedantic
[13:12:52] <Kovensky> :D
[13:13:09] <Kovensky> maybe with -Werror :P
[13:13:56] <DonDiego> stop trolling
[13:17:35] * Kovensky actually compiles his own stuff with those flags (minus -Werror)
[13:17:51] <DonDiego> ok, i take it back ;)
[13:18:03] * DonDiego compiles with -Werror at work
[13:41:48] <mru> DonDiego: PayloadContext *(*open) (); is missing an argument list
[13:42:18] <mru> that's pointer to function taking unspecified args returning pointer to PayloadContext
[13:44:17] <DonDiego> PayloadContext *(*open) (void);
[13:44:25] <DonDiego> that would be the correct variant then?
[13:44:30] <mru> probably
[13:44:34] <mru> hopefully
[13:45:01] <DonDiego> i'll try to dig out another example, that one compiles with (void)
[13:45:09] <DonDiego> there was some other that caused me grief..
[14:08:58] <CIA-92> ffmpeg: kostya * r22093 /trunk/libavcodec/ivi_dsp.c:
[14:08:58] <CIA-92> ffmpeg: Strides in Indeo 5 reconstruction filter should be signed,
[14:08:58] <CIA-92> ffmpeg: this way it works on 64-bit archs too.
[14:08:58] <CIA-92> ffmpeg: Patch by Jind?ich Makovi?ka ($lastname without last letter and h??ek, gmail)
[15:26:21] <CIA-92> ffmpeg: mru * r22094 /trunk/common.mak: Stop make deleting intermediate files (ffmpeg.o and friends)
[15:47:27] <j-b> Vitor1001: is this NSV leak related to https://trac.videolan.org/vlc/ticket/2995 ?
[16:11:05] <kshishkov> j-b: you can verify it by checking whether VP6 in AVI and VP6 in .flv leak
[16:12:41] <j-b> I will check
[16:12:51] <j-b> normal samples don't leak that much
[16:12:54] <j-b> just that one
[16:13:19] <j-b> which is the only bug we have wrt to VP6 (in more than VP6 interlaced)
[16:26:13] <Dark_Shikari> "not that much" is still a leak
[16:26:55] <j-b> good morning Dark_Shikari
[16:27:19] <kshishkov> Dark_Shikari: definition varies - in Norway they had a significant part of lake leaked into tunnel, in Netherlands they are afraid of any leaks
[16:41:58] <roozhou> hi, does anybody know why stream copy of mp3 from flv to other container fails if ffmpeg not compiled with libmp3lame
[16:42:13] <Dark_Shikari> lol oops
[16:43:09] <roozhou> i am trying to build a demuxer/muxer only ffmpeg, but i found it is not working without a lot of decoders and even encoders
[16:43:42] <Dark_Shikari> I think it might require some parsers...
[16:44:11] <roozhou> that make sense only for decoders
[16:44:31] <Dark_Shikari> but to remux you may need to get information from the video stream
[16:44:36] <Dark_Shikari> thus a parser
[16:44:56] <roozhou> but why encoders are required?
[16:45:07] <mru> Dark_Shikari: what are typical keyframe intervals nowadays?
[16:45:15] <Dark_Shikari> for what
[16:45:23] <Dark_Shikari> roozhou: shouldn't be
[16:45:26] <mru> normal things
[16:45:39] <mru> not your fancy keyframeless encoding
[16:45:39] <Dark_Shikari> what is "normal"
[16:45:42] <Dark_Shikari> broadcast television?
[16:45:44] <Dark_Shikari> blu-ray disks?
[16:45:48] <Dark_Shikari> MKV rips?
[16:45:54] <Dark_Shikari> flash video streams/
[16:46:13] <mru> bcast is ~1s, I know that
[16:46:20] <mru> what do mkv rips use?
[16:46:29] <mru> typically
[16:46:40] <Dark_Shikari> default x264
[16:46:41] <Dark_Shikari> 10 seconds
[16:53:59] <_av500_> we use 1s for tv recordings
[16:54:27] <twnqx`> i use 1s for .mkv rips :]
[16:54:46] <kshishkov> YouTube used 300 frames for simplicity
[16:54:48] <mru> twnqx`: do a lot of seeking in your pr0n?
[16:55:04] <twnqx`> s/pron/hentai
[16:55:25] <_av500_> kshishkov: 300 is simple?
[16:55:28] <twnqx`> and it's more like "no, i don't... but in the rare occasion i want to i'm annoyed by too long jumps"
[16:55:51] <kshishkov> _av500_: well, if it also had bitrate of 300kbps...
[16:56:18] <_av500_> kshishkov: not with theora :)
[16:57:55] <kshishkov> _av500_: http://multimedia.cx/eggs/youtubes-lucky-number/
[16:58:38] <_av500_> lol
[16:58:40] <_av500_> nice
[16:58:54] <_av500_> I guess they use 72o these days
[16:59:09] <_av500_> o->0
[16:59:34] <kshishkov> they seem to offer different versions
[17:01:01] <_av500_> yes, &fmt=xx
[17:01:16] <Kovensky> warning: variable 'mf' might be clobbered by 'longjmp' or 'vfork' <-- o_O
[17:01:40] <mru> Kovensky: where?
[17:01:55] <mru> don't tell me we're using either of those
[17:01:58] <Kovensky> not in ffmpeg, but I fail to understand the warning (-Wextra)
[17:02:13] <mru> are you using longjmp or vfork?
[17:02:35] <kshishkov> maybe it's just a general warning?
[17:02:40] <Kovensky> it seems there is one single longjmp call
[17:03:01] <mru> kill it
[17:03:05] <mru> longjmp is evil
[17:03:05] <_av500_> frak, this train has no pwr sockets...
[17:03:23] <Kovensky> heh
[17:03:31] <mru> not as bad as the underground train in stockholm that was without brakes this week
[17:03:32] <Kovensky> it seems that this code abuses sj / lj for exceptions <_<
[17:03:41] <mru> yes, that's what exceptions are
[17:03:47] <Kovensky>     if (setjmp(mf->jb)) // something evil happened while reindexing
[17:03:47] <Kovensky>       continue;
[17:03:50] <mru> ergo exceptions are evil
[17:04:09] <Kovensky> not my code though, and I don't really understand it to fix that
[17:04:16] <_av500_> mru: then you will like bionic, it does not support them :)
[17:05:47] <kshishkov> mru: there were some runaway cars on Finnish railroads that ended checking in into Helsinki railroad station hotel several weeks ago
[17:06:05] <_av500_> but then it is used to run java that does...
[17:06:27] <_av500_> kshishkov: hah, we dont get that kind of service here...
[17:07:22] * _av500_ watches batt time go single digit :(
[17:07:48] <kshishkov> _av500_: good luck try finding power outlet in any train here
[17:08:19] <Kovensky> warning: 'ui' may be used uninitialized in this function
[17:08:21] <Kovensky> unsigned ui = (unsigned)readUInt(mf,(unsigned)len);
[17:08:22] <Kovensky> :S
[17:08:43] * Kovensky pets _av500_
[17:08:50] <kshishkov> what's the stuff you're smo^H^H^Hcompiling?
[17:09:21] <mru> Kovensky: error: too many casts
[17:09:21] <Kovensky> Haali's matroska parser
[17:09:32] <Kovensky> mru: lol
[17:09:51] <_av500_> back on phone...
[17:10:10] <kshishkov> _av500_: where are you?
[17:10:38] <_av500_> fra to muc
[17:11:09] <kshishkov> both are a bit away from you usual place, aren't they?
[17:11:14] <kshishkov> *your
[17:11:17] <_av500_> on ice
[17:11:26] <mru> Kovensky: in readFloat()?
[17:11:31] <_av500_> no. fra is near home
[17:11:33] <Kovensky> mru: yes
[17:11:50] <_av500_> muc is near snow
[17:15:10] <kshishkov> "on ice" as in "intercity express" or as "sliding over the frozen river"? "near snow" means "not too far from the place where Michael lives" or something else?
[17:16:21] <mru> Kovensky: if we're looking at the same code I don't see how that could be used uninitialised
[17:17:36] <_av500_> kshishkov: ice train going to munich then zillertal tomorrow
[17:17:41] <Kovensky> mru: me neither
[17:17:49] <Kovensky> and yes, same code
[17:18:09] <mru> might not be the same code
[17:18:16] <mru> where did you get it?
[17:19:09] <Kovensky> http://code.google.com/p/ffmpegsource/source/browse/trunk/src/core/matroskaparser.c
[17:20:31] <mru> which line is the warning on?
[17:20:49] <mru> 804?
[17:20:54] <mru> no
[17:21:02] <mru> 779
[17:21:40] <Kovensky> 763 also has a warning saying that f.v is being used uninitialized
[17:21:41] <mru> all that longjmping is probably confusing gcc
[17:22:35] <Kovensky> heh
[17:22:40] <Kovensky> c++ programmers are scary <_<
[17:22:51] <mru> that is how goto should not be used
[17:24:22] <Kovensky> that code also has some cool stuff like comparing (int > unsigned long long)
[17:24:44] <mru> that code is ugly
[17:24:52] <elenril> why do you use it anyway. just use matroskadec in lavf =p
[17:24:55] <TheFluff>  // bubble sort the cues and fuck the losers that write unordered cues
[17:25:03] <TheFluff> my favorite comment in i
[17:25:03] <TheFluff> t
[17:25:09] <Kovensky> lol TheFluff
[17:25:11] <twnqx`> wait, C++ and setjmp/longjmp for exception handling?
[17:25:18] <twnqx`> now that's weird :S
[17:25:19] <TheFluff> it's written in c
[17:25:23] <Kovensky> btw, I have some local changes to that file, I'll send you them later
[17:25:29] <TheFluff> but the guy who wrote it is probably more of a c++ programmer
[17:25:36] <TheFluff> Kovensky: what do they do
[17:25:43] <Kovensky> fix warnings
[17:25:47] <TheFluff> rejected
[17:25:48] <Kovensky> mostly changing ints to ulonglongs
[17:25:52] <Kovensky> :P
[17:26:18] <TheFluff> that is, rejected unless you can prove without a doubt you didn't break anything
[17:26:36] <TheFluff> that code is full of very clever things the implications of which are not always easily forseeable
[17:27:28] <Kovensky> two of the hunks are just initializing vars that were uninitialized
[17:27:44] <Kovensky> those should be OK
[17:28:27] <TheFluff> probably
[17:29:09] <mru> dirty hacks != very clever
[17:29:47] <mru> a clever hack is something which is non-obvious at first sight, yet obviously works when looked at more carefully
[17:30:09] <mru> something that just happens to do the right thing while nobody knows why is just sloppy
[17:30:13] <Kovensky> TheFluff: want a CIA bot in #darkhold btw
[17:30:18] <TheFluff> no
[17:30:23] <Kovensky> ic
[17:30:30] <Kovensky> I made the one in my channel track ffms too
[17:31:28] <TheFluff> that's fine but #darkhold is not a ffms development channel
[17:32:16] <Kovensky> TheFluff: I also removed the IsWritingApp function, it's only used on #if 0 code and said code is an avimuxgui hack
[17:32:48] <TheFluff> that's ok I guess
[17:36:26] <janneg> _av500_: I started a couple of hours ago to render on KotH's machine with 8G
[17:36:41] <_av500_> nice
[17:37:12] <_av500_> why not ask on ml for resources?
[17:37:28] <_av500_> sm ppl might have spare mips
[17:37:47] <kshishkov> wanna my Gdium?
[17:38:15] <_av500_> for the 6x qcif wall?
[17:39:12] <kshishkov> why not?
[17:40:10] <_av500_> kshishkov: talk to janneg :-)
[17:40:26] <janneg> http://www.jannau.net/bbb_videowall/
[17:41:10] * kshishkov has used Blender only on PocketPC (that's XScale 400MHz and 64MB RAM for you)
[17:42:23] * janneg smells OOM during loading the data files
[17:42:36] <Kovensky> out of mana?
[17:43:31] * drv casts Innervate
[18:06:56] <Vitor1001> j-b: looks related to the VP6 leak on the same thread
[18:07:22] <j-b> Vitor1001: ok, cool.
[18:19:13] <kshishkov> j-b: please remind me since when having memory leaks is cool (not in M$)
[18:20:07] <j-b> kshishkov: knowing that someone is tackling an issue is cool :D
[18:20:32] <j-b> isn't locating an issue half the work?
[18:20:44] <kshishkov> yes, sometimes it's even more
[18:21:29] <elenril> kshishkov: you didn't know? memleaks are edgy and cool since java
[18:22:35] <kshishkov> elenril: yes, since you can't fix them even in theory
[18:23:09] <Kovensky> remove memory; no memory, no leak
[18:23:31] <kshishkov> that's too stalinistic
[19:58:26] * elenril wonders if any muxer can write per-stream metadata
[19:58:58] <kshishkov> of course not
[19:59:48] <elenril> it seems matroskaenc can
[19:59:50] <janneg> language seems to work
[19:59:51] <elenril> at least title
[21:14:11] <CIA-92> ffmpeg: reimar * r22095 /trunk/libavcodec/ (avcodec.h utils.c):
[21:14:11] <CIA-92> ffmpeg: Fix avcodec_align_dimensions to return values suitably aligned for FLV decoding
[21:14:11] <CIA-92> ffmpeg: with SSE and add a avcodec_align_dimensions2 taht returns the stride alignment
[21:14:11] <CIA-92> ffmpeg: requirements independently from doing the width/height padding.