[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/pic... 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/qua... [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/matroskap... [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.