Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

February 2010

1 participants
28 discussions

IRC log for 2010-02-27
by irc＠mansr.com 28 Feb '10

28 Feb '10

[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/pi… 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/qu… [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/matroska… [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.

1 0

IRC log for 2010-02-26
by irc＠mansr.com 27 Feb '10

27 Feb '10

[00:09:17] <CIA-92> ffmpeg: michael * r22066 /trunk/libavcodec/h264_mvpred.h: [00:09:17] <CIA-92> ffmpeg: Simplify code in mv_pred. [00:09:17] <CIA-92> ffmpeg: Not benchmarked as this is petty much just code removial. [00:10:53] * DonDiego looks at CIA [00:11:23] <DonDiego> i'm kinda proud of trolling michael into picking up work on the h.264 decoder [00:11:25] <CIA-92> ffmpeg: michael * r22067 /trunk/libavcodec/h264.h: Remove unneeded line of code from the neighbor setting code in h264. [00:11:26] <DonDiego> :) [00:11:45] <DonDiego> there he goes again [00:12:12] <DonDiego> one of those days my trusty old K6-III shall be able to decode the cursed cathedral without framedrops [00:12:18] * DonDiego waves at michael [00:12:26] <DonDiego> hey there old bugger [00:12:26] <DonDiego> :) [00:12:48] <ohsix> did he ever say what kind of computers he had at his disposal? [00:13:18] <DonDiego> P3 500 at some point, dunno what it is now [00:13:25] <DonDiego> old notebook [00:13:34] <DonDiego> but i think he now has an amd64 machine [00:13:46] <mru> he must have something 64-bit [00:13:49] <DonDiego> btw, i called myself a troll up ther [00:13:50] <DonDiego> e [00:13:59] <DonDiego> so ohsix is free to do it as well now [00:14:01] <mru> he broke all 32-bit builds earlier [00:14:14] <mru> different kind of troll [00:14:20] <ohsix> there are kinds? [00:14:36] <ohsix> is it good or bad kinds or something else [00:14:48] <ohsix> diego kind of explained a "good kind" to some extent [00:16:53] <Kovensky> http://www.cracked.com/funny-2724-trolls/ <-- 6 types of trolls [00:44:27] <mru> "I love cruft! [00:44:30] <mru> " -- Monty [00:44:35] <mru> http://lists.xiph.org/pipermail/vorbis-dev/1999-November/008821.html [00:46:09] <peloverde> And I just thought he was becoming obstinate lately [00:48:00] <DonDiego> obstinate -- learn a new word every day.. [00:48:28] <DonDiego> i'm trying hard to find monty's famous ass hat flame.. [00:48:31] <DonDiego> hmm.. [00:49:50] <ohsix> what about brusk? [00:51:06] <mru> you mean brusque [00:51:12] <ohsix> possibly [00:51:37] <ohsix> it says its the same, hur [00:51:41] <ohsix> probably uk eng vs. us eng [00:52:16] <CIA-92> ffmpeg: michael * r22068 /trunk/libavcodec/avcodec.h: Clarify ref_index. [00:52:56] <ohsix> i still use behaviour instead of the dum way though; but not for much else [00:53:36] <mru> spelling should be consistent [00:54:04] <ohsix> i drop the u when theres other our words :< [00:54:07] <DonDiego> http://lists.mplayerhq.hu/pipermail/mplayer-dev-eng/2007-November/054865.ht… [00:54:22] <DonDiego> "Fine. I give up. [00:54:22] <DonDiego> There are plenty of things about the design worth arguing about... but [00:54:22] <DonDiego> you guys are more worried about the color of the mudflaps on this [00:54:22] <DonDiego> dumptruck. You're rejecting considered decisions out of hand with [00:54:22] <DonDiego> vague, irrelevant dogma. I've seen two legitimate bugs brought up so [00:54:24] <DonDiego> far in a mountain of "WAAAH! WE DON'T LIKE YOUR INDEEEEENT." [00:54:27] <DonDiego> I have the only mplayer/mencoder on earth that can always dump WMV2 [00:54:30] <DonDiego> and WMV3 without losing sync. I just needed it for me. I thought it [00:54:32] <DonDiego> would be nice to submit it for all your users who have been asking for [00:54:34] <DonDiego> this for years. But it just ceased being worth it. [00:54:37] <DonDiego> Patch retracted. You can all go fuck yourselves. Life is too short [00:54:40] <DonDiego> for this asshattery. [00:54:42] <DonDiego> Monty [00:54:44] <DonDiego> " [00:54:47] <DonDiego> sorry [00:54:50] <DonDiego> i just had to quote it in full ;) [00:54:58] <kierank> --> #ffmpeg-trolls [00:55:01] <kierank> ;) [00:55:55] <mru> pot, kettle... [00:57:20] <mru> speaking of frame start/end: http://lists.xiph.org/pipermail/vorbis-dev/1999-November/008792.html [01:02:08] <ShadowJK> DonDiego, is this h264 spree adding up to any measurable overall gains since he started? :-) [01:02:19] <janneg> sigh, the additional 2G RAM were just good enough for 30 additional frames of scenes/01_intro/01.blend [01:02:38] <ShadowJK> It's obviously constantly getting faster and faster, curious about the "big picture" though [01:03:15] <janneg> ShadowJK: yes, it was already 15% faster in january [01:03:35] <ShadowJK> compared to when? [01:03:54] <mru> december [01:04:41] <janneg> r21156 vs r21328 [01:05:12] <janneg> r21156 was just before micheal started [01:05:18] * iive tries does new build. [01:05:48] <ShadowJK> oh wow, that's amazing [01:26:21] <DonDiego> <xiphmont_> Vorbis still stands up nicely. Theora, OTOH, is a a bit embarrassing. [01:26:25] <DonDiego> * dalias tries to be polite about theora.. [01:26:27] <DonDiego> <xiphmont_> rather, it's a bit embarrassing until you look at the code, then it's alot embarrassing. [01:26:30] <DonDiego> <xiphmont_> and that's 70% 'really fucking stupid encoder, really On2, be ashamed' and 40% 'format [01:26:33] <DonDiego> design flaws'. It's so bad it adds up to 110%. [01:26:36] <DonDiego> <xiphmont_> I plan to help Theora limp along not too embarrassingly until it can be replaced for [01:26:39] <DonDiego> real-- possibly 2-4 years. [01:26:41] <DonDiego> <xiphmont_> Theora is actually fixable tho. The amount of low-hanging fruit is staggering. [01:26:44] <DonDiego> <xiphmont_> I mean, an entropy backend that results in *more* bits being written than went in? It's [01:26:47] <DonDiego> just... wow. [01:26:50] <DonDiego> SCNR [01:26:52] <DonDiego> more monty quotes :) [01:27:21] <mru> that's a classic [01:30:57] <DonDiego> definitely [01:31:06] <iive> i'm sure you full quite them, so the search engines could index this text :) nice catch. [01:33:47] <ohsix> monty is the guy that was on the vp8 thread? [01:34:35] <astrange> they're already in multimedia wiki quotes [01:36:16] <DonDiego> i just added it [01:36:24] <DonDiego> i couldn't believe it was missing [01:36:39] <DonDiego> the ml quote i mean, not monty on irc [01:37:04] <DonDiego> ohsix: yes, monty is christopher "monty" montgomery from xiph [01:39:05] <CIA-92> ffmpeg: michael * r22069 /trunk/libavcodec/h264.h: Remove useless check of the 2 left MBs of a pair being in the same slice. [01:42:47] <mru> but hey, he has (had?) some good opinions too: http://lists.xiph.org/pipermail/vorbis-dev/2000-September/010088.html [01:45:37] <ohsix> even a busted clock is right twice a day [01:45:52] <mru> but what about a clock that runs backwards? [01:46:24] <ohsix> if its the same form factor of clock that only that aphorism works for, wether it goes backwards or forwards ... since its broke, is moot [01:48:40] <janneg> mru: depends on the speed it runs [01:48:50] <mru> -1 speed [01:49:23] <mru> and the answer is 4 [01:51:10] <ohsix> oh, if it wasn't broken, huhhuuh i get it, nice [01:54:29] <mru> "Most people would rather die than think, and most people do." -- Bertrand Russell [02:03:37] * justlooking wonders if this clock is a quarts clock, how much space does it have for time as it's relative , is it traveling at near light speed, and is it near a black hole! sleeps now. [02:07:32] <DonDiego> http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/com… [02:07:35] <DonDiego> SCNR ;) [02:07:52] <DonDiego> man, i have been procrastinating at work today.. [02:11:01] <peloverde> damn I hate C's constant rules [02:13:32] <peloverde> There is far to much crap that the compiler should know at compile time but isn't required to [02:13:55] <peloverde> so I have to fall back to the stupid preprocessor [02:16:27] <ohsix> what is it this time? [02:17:49] <peloverde> had a static const array and needed to size another array based on the first arrays largest (last) value [02:17:58] <ohsix> ah [02:21:25] <kierank> i wonder if it's possible to use hpet to make the timing of rtp output packets dvb compatible [02:23:02] <ohsix> what does it mean to be compatible, just higher resolution? you can get something like a 14mhz counter and programmable wakeups from most machines with hpet support [02:24:08] <kierank> someone told me there's lots of rules about how the timing between each packets [02:24:29] <kierank> packet* [02:25:10] <ohsix> as marked or in their actual delivery? it can get you more accurate timestamps but you could also just derive them as sent i think [02:25:35] <kierank> the actual rate that the program sends them out [02:25:49] <kierank> apparently a lot of programs/hardware encoders send them out in bursts [02:36:35] <DonDiego> bah [02:36:40] <DonDiego> silvia closed comments.. [02:37:19] <[1]kierank> lol [02:54:53] <CIA-92> ffmpeg: michael * r22070 /trunk/libavcodec/h264.h: [02:54:53] <CIA-92> ffmpeg: Remove 3 mv_cache zeroing instructions that zeroed the right side. [02:54:53] <CIA-92> ffmpeg: This seems unneeded as nothing seems to ever set it to non zero values. [03:28:40] <CIA-92> ffmpeg: michael * r22071 /trunk/libavcodec/ (h264.c h264.h): Move init of right side of ref_cache from fill_caches() to init_the_darn_decoder(). [03:29:04] <Dark_Shikari> LOL [03:42:24] <DonDiego> gnite [04:01:52] <MrNaz_yma> if anyone can add me to roundup i'll help with bug testing as much as i can [04:26:42] <peloverde> Are there negative repercussions to setting frame_size to zero in AVCodec init()? [04:26:59] <mru> why would you do that? [04:27:12] <mru> is the demuxer being dishonest? [04:27:16] <peloverde> yes [04:27:23] <peloverde> just like with sample_rate [04:28:41] <peloverde> It's the whole backwards compatible HE-AAC thing [04:29:21] <mru> so why zero? [04:29:30] <mru> why not the actual frame size? [04:29:39] <mru> otoh zero should be fine [04:29:47] <peloverde> because we don't know until we decode the first frame [04:29:47] <mru> what does vorbis do? [04:29:56] <mru> it has variable-size frames anyway [04:30:44] <peloverde> avccontext->frame_size = FFMIN(vc->blocksize[0], vc->blocksize[1]) >> 2; [04:30:44] <pengvado> vorbis sets frame_size to the smaller of the possible sizes [04:31:10] <peloverde> I'm trying to figure out what libfaad does but I can't seem to find any code to deal with it [04:31:11] <mru> hmm [04:31:30] <astrange> the frame_size field as defined for mov should be 0 for vorbis, i hope the muxer does that [04:31:31] <mru> imo any app should be prepared to deal with a zero [04:31:52] <mru> zero would simply mean unknown [04:32:17] <peloverde> the thing is try_decode_frame sets the frame size, but then when the codec is reopened it gets clobbered [04:32:37] <peloverde> something similar happened with sample_rate in ffplay [04:33:07] <peloverde> I'm installing libfaad to see what happens [04:33:21] <peloverde> sigh, I thought the whole point of this was not needing libfaad [04:33:24] <mru> my apps mostly ignore the avctx from lavf [04:33:35] <mru> only copy out the bare essentials into a fresh one [04:34:11] <peloverde> the problem is that ffplay hardly considers anything essential [04:34:23] <peloverde> then gets pissy when things aren't inited [04:34:43] <mru> ffplay is rubbish [04:35:09] <peloverde> yes but ffplay is our go to sample code [04:35:17] <peloverde> so people blindly copy the ffplay rubish [04:35:22] <mru> I'd never look at ffplay as a reference [04:36:14] <peloverde> we really should fix ffplay because so that people can [04:36:21] <peloverde> and by we I mean someone else :) [04:36:32] * mru ducks for cover [04:36:35] <astrange> av500's patch worked for me [04:36:52] <astrange> aurally anyway [04:37:09] <peloverde> av500's patch as useful as it is, just papers over the real issue [04:53:32] <peloverde> Does ffplay have a way to force a decoder? [05:09:05] <peloverde> dammit, I forgot that faad just assumes SBR based on LC sample rate [05:16:53] <j0sh> i have a question re: h264 [05:17:26] <j0sh> intra blocks can only be 16x16, am i correct? [05:19:32] <j0sh> if so, why is IS_INTRA also checked for 8x8 blocks in the code for direct prediction? [05:19:53] <mru> because there are 8x8 intra blocks [05:20:05] <j0sh> ok thanks [05:20:38] <j0sh> what about for 16x8 or 8x16? [06:25:40] <thresh> moroning [06:29:07] <kshishkov> here it's been idioting since yesterday [06:30:31] <thresh> since 10 years, i'd say :p [06:32:06] <kshishkov> well, at least you have nice figurehead for president [06:32:41] <thresh> :) [06:39:38] <ohsix> whats idioting? [06:40:13] <kshishkov> virtually everything, exceptions are not worth mentioning [06:42:07] <ohsix> oh, i thought you were talking about an election or something [06:43:26] <kshishkov> well, there was presidental inauguration yesterday [07:31:02] <byteme`> kshishkov: I keep thinking of an AK-47 when I read your nick [07:31:18] <kshishkov> why? [07:31:53] <byteme`> Somehow your nick is reminding me of 'Kalashnikov' [07:32:26] <kshishkov> well, if you scramble some middle letters and throw some 'a's then yes [07:32:27] <kierank> lol [07:32:32] <mru> sssshhh, it's a secret [07:33:29] <kshishkov> mru: du vet ju att jag Ã€lskar skovel [07:33:38] <byteme`> heh [07:34:23] <mru> ah yes, the shkovel [07:35:16] <kshishkov> not everybody got shotgun and raised floor [07:35:40] <elenril> morning [07:35:49] <kshishkov> got morgon [07:35:53] <elenril> does anybody think ffmpeg should copy metadata and chapters by default? [07:36:57] <kshishkov> byteme`: in any case, it's mostly the fact you don't know much about Russian names (which is OK outside certain parts of Asia). [07:37:11] <kshishkov> elenril: could be, yes [07:37:30] <byteme`> kshishkov: yeah I'm american... so I know next to nothing about Russian names [07:37:55] <byteme`> though, you might be impressed that I've actually been out of the US. [07:38:21] <byteme`> I've been to the UK, Australia, and the Phillipines [07:38:22] <kshishkov> Canada or Mexica? [07:38:30] <kshishkov> ah [07:38:34] <byteme`> I've been to Mexico as well [07:38:55] * mru thought he'd say texas [07:39:02] <kshishkov> and I've been only to homeland and Ukraine [07:39:03] <byteme`> lol [07:39:14] <astrange> texas is the most US part of the US [07:39:23] <astrange> elenril: yes [07:39:27] <byteme`> kshishkov: you live in Russia? [07:39:35] <kshishkov> astrange: not for the last two years [07:39:47] <kshishkov> byteme`: no, never been there either. Nor want to. [07:40:21] <byteme`> I have a friend that immigrated to the US from Georgia [07:40:33] <thresh> georgia is not exactly a country [07:41:05] <kshishkov> it's both country and state [07:41:12] <byteme`> it has it's own flag and constitution? [07:41:48] <thresh> yeah, but a tie-chewing killer instead of a president [07:42:16] <kshishkov> thresh: you listen too much to Georgian propaganda [07:44:36] <byteme`> I've wanted to go to that region but haven't had the courage to do it [07:44:59] * thresh plans to go to caucasus this summer [07:45:06] <av500> elenril: why not? [07:45:52] <kshishkov> byteme`: I'd advise against it. [07:46:07] <thresh> for an american it would be nice in Georgia [07:46:49] <byteme`> I'm not sure how Americans are viewed in that region... probably not very good [07:46:57] <kshishkov> thresh: yes, how many people know English there? [07:47:22] <mru> in america? not many... [07:47:32] <kshishkov> byteme`: it's feud there, so neither Russians nor even local people are liked there very much [07:47:54] <byteme`> yeah Russian invasion? [07:48:01] <thresh> haha "invasion" [07:49:15] <elenril> av500: because it only really works with one infile and one outfile [07:49:28] <byteme`> I acutally don't know much about the conflict. American media doesn't report the conflict very often. I have to actually watch news from Europe or the Middle East to get current events ( or read internet news ) [07:49:46] <av500> elenril: sounds to me like the 95% use case [07:49:51] <byteme`> anyway, sorry for being offtopic [07:49:53] <byteme`> :) [07:50:08] <kshishkov> byteme`: I'd say it was a clash of imperial ambitions from the both sides, so don't mind it [07:51:00] <kierank> europe's got bigger problems anyway [07:52:07] <byteme`> kshishkov: The conflict is unfortunate :( [07:52:21] <av500> elenril: doing 1:N copy to me makes sense to preserve as much meta info as was present in the source file [07:52:33] <av500> doing M:N I'd say peopl know what they are doing... [07:53:05] <av500> (err, M:N, no pun intended....) [07:55:11] <kshishkov> av500: well, shortening "Big Buck Bunny" with Ronald around is much more hilarious [07:55:53] <av500> kshishkov: agree, I hate it when I can't tab complete that long abbreviation... [08:56:43] <CIA-92> ffmpeg: benoit * r22072 /trunk/libavcodec/avcodec.h: Fix typos in ref_index documentation. [09:14:30] <CIA-92> ffmpeg: michael * r22073 /trunk/libavcodec/h264.h: [09:14:30] <CIA-92> ffmpeg: Simplify code to set cbp_* [09:14:30] <CIA-92> ffmpeg: this seems 1 cpu cycle slower even though we practically just remove code. [09:14:30] <CIA-92> ffmpeg: Speed loss seems caused by the merge of if(left_type), iam commiting this [09:14:30] <CIA-92> ffmpeg: anyway as i cant imagine this to be anything but compiler messup. [09:40:07] * av500 does not like how tightly lavf and lavc are tied together [09:41:27] <kshishkov> no, it's lavf tied to lavc, lavc is rather free [09:41:38] <av500> right [09:43:13] <kshishkov> what can you suggest then? [09:45:01] <av500> demuxer: demuxes [09:47:23] <kshishkov> yes, and muxer: dances [09:49:43] <merbzt> can I generate a vararg call in C [09:49:50] <phaidros> guys I am still struggling with ffmpeg and capturing from alsa, docs seems quite outdated in that part, examples over the internet are not working, one little example: [09:49:55] <lu_zero> merbzt: like? [09:50:18] <kshishkov> merbzt: look at av_log definition [09:50:41] <phaidros> using: "arecord -Dplughw:1,0 -c 2 -r 44100 -f CD | aplay" for capturing and playing is ok, putting ffmpeg in between like this: [09:50:51] <phaidros> arecord -Dplughw:1,0 -c 2 -r 44100 -f CD | ffmpeg -ab 256000 -ac 2 -i - -acodec adpcm_ima_wav - | aplay [09:50:57] <phaidros> doesnt work. [09:51:00] <av500> merbzt: iirc there was some implementation specific bit around how varargs are actually implemented, so it might not be protable [09:51:14] <av500> phaidros: #ffmpeg? [09:51:40] <phaidros> av500: yeah, I am always getting pointed to the docs, which are not talking bout that part. [09:51:44] <kshishkov> av500: (s)printf call in libc [09:52:13] <merbzt> lu_zero: if a struct has an int array and with n values, I want to send all the args to another vararg function [09:52:22] <phaidros> av500: thanx, so I ll give up on ffmpeg for now as streaming solution. anyways, thanks for suggesting codecs yesterday. [09:52:23] <kshishkov> phaidros: you forgot to specify input and output type (format and codec) [09:52:34] <phaidros> rly? hmm [09:52:42] <av500> phaidros: sure give up [09:53:12] <kshishkov> merbzt: maybe you'll need to create va_list [09:53:45] <phaidros> kshishkov: input type for pipe? output type for pipe? [09:54:07] * KotH thinks that phaidros should go to #ffmpeg as suggested [09:54:10] <lu_zero> the function to pass out the stuff would have a ... argument [09:54:21] <lu_zero> and then you'll use a va_list to feed it [09:54:30] <av500> merbzt: http://bytes.com/topic/c/answers/218657-creating-va_list [09:54:38] <phaidros> KotH: thx [09:55:09] <av500> kshishkov: thats where the non-portable kicksin iirc [09:55:34] <av500> KotH: why did you not just let him give up? [09:57:02] <kshishkov> av500: see "rickrolling" [09:57:50] <KotH> av500: i believe in the good and just in people [09:58:29] <kshishkov> KotH: but you don't look an idiot. So I gather you're lying! [09:58:43] <KotH> lol [09:58:50] <KotH> kshishkov: dont judge people by their looks ;) [09:59:20] <kshishkov> KotH: I don't judge them at all until they've acted a bit [10:00:56] * KotH does not act, he just types [10:01:15] <kshishkov> typing is an action as well [10:03:25] <KotH> asädlfjaü0fjadfansdfüoaishdfaüsdfnhasdlfkna [10:03:34] * KotH just acted in an irrational way [10:04:15] <kshishkov> KotH just donated some umlauts to this IRC channel [10:04:57] * elenril thinks BofH should start using UTF-8 [10:06:03] <kshishkov> elenril: doesn't he? [10:06:44] * elenril doesn't think so [10:07:22] <kshishkov> ãªã [10:07:52] <kshishkov> jag ser tyska bokstav, det mÃ¥ste bli UTF-8 [10:11:21] * KotH is characterset challenged [10:13:21] <elenril> KotH: /set recode_out_default_charset utf-8 =p [10:20:07] <KotH> elenril: this replaces all non-iso8859-1 characters with ?, which is not as i'd like it [10:20:28] <elenril> /set term_charset utf-8? [10:20:37] <elenril> +get a sane terminal [10:21:23] <KotH> that' needs more work than you'd think [10:21:45] <KotH> it's easier for me to let you cope with my latin1 [10:21:47] <KotH> ;) [10:22:20] <elenril> orly [10:22:27] <twnqx> 'morning [10:22:51] * Kovensky has a script that kicks anyone that outputs non-UTF-8 on channels he has +o [10:23:09] <twnqx> evil kov! [10:23:11] <Kovensky> inb4 "that's UTF8ism!" [10:23:16] <Kovensky> hi twnqx [10:23:51] <KotH> that's rassism! [10:24:38] <Kovensky> =p [10:24:50] <Kovensky> and hurf @ vmwares (lack of) ability to keep track of time [10:25:00] <elenril> why vmware [10:25:02] <Kovensky> my VM's clock has skewed 12h behind the computer clock [10:25:05] <twnqx> normal [10:25:16] * elenril reinstalling windoze in his virtualbox atm [10:25:29] <Kovensky> elenril: because I don't need any GUI (or CLI) with vmserver; I can just set it up to automatically start up the VM [10:25:43] <Kovensky> and then I just ssh to it when it finishes booting ._. [10:26:05] <elenril> isn't vmware evil proprietary software? [10:27:57] * byteme` likes kvm [10:30:27] <twnqx> errr what [10:31:14] <KotH> someone, most likely elenril, stole all your pings [10:31:28] <twnqx> no i mean... [10:31:38] <twnqx> <-- twnqx has quit (Ping timeout: 240 seconds) i saw my own ping timeout? [10:32:10] <av500> near death experience [10:32:18] <twnqx> heh [10:32:31] <twnqx> and i hate sitting in airports with the plane being late >_> [10:33:25] <twnqx> Kovensky, did you answer my last question? :X [10:35:24] <av500> twnqx: if the plane was early, there would be no point sitting at all, no? [10:35:57] <byteme`> sitting on the plane is the hard part imo [10:36:25] <pross-au> twnqx: depends if there is free alcohol [10:36:44] <pross-au> (and not having to drive at your destination) [10:37:01] <av500> pross-au: bring an eski... [10:37:17] <twnqx> i'll have to drive [10:37:19] <twnqx> but... well. [10:37:27] <twnqx> first i'll have to catch my connecting flight... [10:37:39] <twnqx> plane change margin went from 1:10 to 0:40 already :S [10:40:29] <byteme`> delta has free alcohol on all international flights. :) [10:40:52] <twnqx> lufthansa too [10:41:01] <twnqx> but it's the national leg that's late [10:42:01] <pross-au> urgh delta sounds american [10:43:16] <bilboed-tp> byteme`, errrr... no it doesn't [10:43:43] <bilboed-tp> except for the *one* you get with your meal [10:43:57] <byteme`> I could be thinking of united airlines [10:44:03] <bilboed-tp> same [10:44:16] <byteme`> I went to australia last year and drank free [10:44:23] <bilboed-tp> Qantas ? :) [10:44:29] <byteme`> united or delta [10:44:32] <byteme`> forget which one [10:44:43] <bilboed-tp> sure, maybe on the 16 hour flights they make an exception :) [10:44:49] <KotH> air lines went down the drean after the us attacked iraq [10:45:03] <KotH> food sucks, drinks suck, service sucks [10:45:03] <twnqx> nah [10:45:07] * KotH blames the US [10:45:26] <kshishkov> KotH: ever tried Ukrainian airlines? [10:45:29] <bilboed-tp> the US carriers were already crap before that :) [10:45:35] <twnqx> well ok, with a high frequent traveler status and european/arabien airlines milage may vary :P [10:45:42] <twnqx> arabian* [10:45:43] <pross-au> i remember delta having good sized economy seating [10:46:27] <kshishkov> there are only two good places [10:46:37] <byteme`> bilboed-tp: I just checked the website, united offers free drinks when traveling to australia or europe [10:46:57] <av500> 1) offer free drinks [10:47:03] <av500> 2) charge for toilets [10:47:06] <av500> 3) ... [10:47:20] <kshishkov> byteme`: so they are suggesting you have to be drunk to fly there? [10:47:25] <byteme`> heh [10:47:50] <byteme`> kshishkov: I think they'd like people to be a bit medicated for a 17 hour flight [10:48:13] <pross-au> free drinks on trips to australia are completely understandable. [10:48:37] <pross-au> just preparing you for the local conditions [10:48:41] <twnqx> lufthansa offers beer on national flights :S [10:48:54] <kshishkov> French airlines should offer wine then [10:48:58] <av500> but not Hefeweizen :( [10:49:17] <twnqx> dunno, refuse to fly with klm/air france again [10:49:19] <pross-au> twnqx: same here on Qantas Domestic after 3~4 pm free grog [10:52:32] <twnqx> yey boarding [10:57:38] <CIA-92> ffmpeg: siretart * r22074 /branches/ (0.5 0.5/libavcodec/huffyuv.c): [10:57:38] <CIA-92> ffmpeg: Make sure we dont read over the end. [10:57:38] <CIA-92> ffmpeg: Fixes issue1237. [10:57:38] <CIA-92> ffmpeg: backport r19322 by michael [11:52:09] <CIA-92> ffmpeg: pross * r22075 /trunk/MAINTAINERS: Add myself as maintainer of the bink demuxer and bink audio decoder [13:16:48] <MrNaz_out> how do i get a login name for roundup? i can help with ffserver [13:16:58] <kshishkov> register [13:17:13] <MrNaz_out> i get the error "you do not have permission to register the user class" [13:17:25] <MrNaz_out> and no, i'm not registering with the username as "class" :P [13:18:06] <KotH> are you using "user"? [13:18:07] <kshishkov> find lu_zero here and complain to him [13:18:10] <KotH> SCNR ;) [13:18:29] <MrNaz_out> heh no i'm trying to register with my nick [13:18:55] <lu_zero> uh? [13:19:09] <MrNaz_out> "mrnaz' [13:19:21] <MrNaz_out> uh? [13:19:23] <MrNaz_out> ? [13:20:15] <lu_zero> MrNaz_out: I just joined [13:20:20] <lu_zero> tell me everything ^^' [13:21:34] <MrNaz_out> i click register, i enter "mrnaz" as the username, enter my password twice and my email address... when i click Register, I get the message: "You do not have permission to register the user class. [13:21:35] <MrNaz_out> " [13:21:41] <MrNaz_out> unless i'm already registered or something... [13:22:28] <MrNaz_out> i tried password reset, but both my username and email address are unknown [13:22:41] <lu_zero> O_O [13:22:44] <lu_zero> let me see [13:22:51] * KotH guesses bad karma [13:23:11] <MrNaz_out> KotH but i always get modded up on slashdot [13:23:27] <KotH> MrNaz_out: that's where you accumulate your bad karma! :) [13:23:38] <MrNaz_out> http://slashdot.org/~MrNaz/comments see? :P [13:24:02] <kshishkov> we seem not to care about /. much [13:24:08] <lu_zero> damn! [13:24:16] <kshishkov> (only as a source of cheap laughs) [13:26:03] <lu_zero> sigh [13:27:04] * kshishkov smells some roundup issue [13:27:07] <av500> lu_zero: hack or hang? [13:28:09] * Kovensky suggests trac and runs away [13:28:32] * av500 trac's Kovensky [13:29:32] <MrNaz_out> lu_zero you want to register for me? maybe my IP or subnet is banned for spamming or something [13:40:11] <lu_zero> MrNaz_out: I'm trying to figure out what's wrong [13:40:22] <lu_zero> meanwhile [13:40:29] <lu_zero> mrnaz is the username you want? [13:40:44] <lu_zero> which is the email you'd like to have? [13:40:57] <av500> spam! [13:44:26] <lu_zero> _maybe_ I fixed it [13:44:50] <lu_zero> they changed the permission needed to register from create user to register user [13:45:46] <kshishkov> renamed or added? it can be fun doing registation without creating actual user [13:46:25] <lu_zero> sigh [13:46:31] <lu_zero> let me see... [13:46:42] <lu_zero> just changing it breaks [13:49:53] <lu_zero> MrNaz: try again [13:50:55] <lu_zero> it works now [13:52:42] <MrNaz_out> worked... thanks [13:52:44] <MrNaz_out> what was wrong ? [13:53:24] <kshishkov> new permission name and old DB obviously [13:55:14] <lu_zero> new api and older schema... [14:19:09] <kshishkov> heh, Michael admits that H.264 is now quantum scale where it's impossible to benchmark separate part without seriously affecting its speed and produced code [14:33:16] <CIA-92> ffmpeg: siretart * r22076 /branches/ (0.5 0.5/libavcodec/vorbis.c 0.5/libavcodec/vp3.c): (log message trimmed) [14:33:16] <CIA-92> ffmpeg: fix the remaining ogv segfaults from issue 1240. [14:33:16] <CIA-92> ffmpeg: First commit: [14:33:16] <CIA-92> ffmpeg: Make decode_init fail if the huffman tables are invalid and thus init_vlc fails. [14:33:16] <CIA-92> ffmpeg: Otherwise this will crash during decoding because the vlc tables are NULL. [14:33:17] <CIA-92> ffmpeg: Partially fixes ogv/smclock.ogv.1.101.ogv from issue 1240. [14:33:18] <CIA-92> ffmpeg: backport r19355 by reimar [14:47:12] <CIA-92> ffmpeg: benoit * r22077 /trunk/ffmpeg.c: [14:47:12] <CIA-92> ffmpeg: Prevent overflow of start_time + recording_time. [14:47:12] <CIA-92> ffmpeg: Patch by Francesco Cosoleto gmail($name) [15:03:48] <CIA-92> ffmpeg: michael * r22078 /trunk/libavcodec/h264.h: [15:03:48] <CIA-92> ffmpeg: Remove some useless operations from the code setting left_cbp. [15:03:48] <CIA-92> ffmpeg: maybe 0.5 cpu cycles faster [15:06:01] <janneg> kshishkov: ^^^ [15:08:45] <janneg> it's already over 20% faster compared to r21156 [15:08:57] <mru> :-) [15:09:09] <Dark_Shikari> is there a way to find out at what file offset a difference between two files occurs? [15:09:18] <mru> cmp [15:09:45] <Dark_Shikari> it prints chars/lines, not bytes [15:10:11] <mru> LC_ALL=C cmp [15:10:27] <Dark_Shikari> no effect [15:10:39] <mru> and chars != bytes? [15:10:41] <Dark_Shikari> I guess I can just ignore lines [15:10:49] <Dark_Shikari> next: to find at what frame in the file this is :/ [15:11:00] <mru> heh [15:11:23] <mru> you need to write a parser that dumps out the syntax elements in text form [15:11:28] <Dark_Shikari> we already have that [15:11:30] <Dark_Shikari> JM tracedec [15:11:52] <mru> well, use it [15:12:04] <Dark_Shikari> well, for 352x288, it occurs on byte 16822384 of raw yuv [15:12:22] <mru> division... [15:12:26] <Dark_Shikari> frame 110 or 111 or so [15:12:43] <Dark_Shikari> yup, frame 110. [15:18:39] <andoma> Dark_Shikari: i made some app a while ago that compare raw yuv frames and printed which macroblock the error occured in [15:18:43] <andoma> and deltas, etc [15:18:48] <Dark_Shikari> Oh, nice [15:19:00] <andoma> but i've no idea where it is :) [15:19:02] <Dark_Shikari> lol [15:19:09] <andoma> it floated on tha ffmpeg-dev mailing list for a while [15:19:17] <andoma> i'll make a quick check [15:19:23] <Dark_Shikari> well elecard's yuv tool can sorta do that [15:19:26] <Dark_Shikari> it's not automated enough though [15:19:28] <mru> andoma: does it also print which C function the error is in? [15:19:34] <Dark_Shikari> lol [15:19:37] <andoma> mru: yes if you pass -v [15:19:50] <av500> mru: it does not propose NEON replacement, code? bah [15:21:39] <andoma> Dark_Shikari: http://www.olebyn.nu/~andoma/yuvcmp.c [15:21:55] * BBB holy shits [15:22:20] <Dark_Shikari> nice, thx [15:22:28] <BBB> I was in a taxi last night in the midst of a snow blizzard, that's pretty darn scary [15:22:55] <andoma> totally undocumented, but i'll guess you figure it out, it's like ./a.out a.raw b.raw 1920 1080 [15:23:32] <andoma> and 'pixelcmp' or 'blockdump' as extra option, i've no idea what they do anymore though :) [15:25:59] <kshishkov> BBB: here it may be pretty scary to take a taxi [15:26:17] <mru> in paris it's impossible to take a taxi [15:26:25] <av500> mru: you have to know how :) [15:26:40] <mru> be a cab driver? [15:27:00] <CIA-92> ffmpeg: michael * r22079 /trunk/libavcodec/h264.h: [15:27:00] <CIA-92> ffmpeg: Only load the topleft mv/ref when the topright is unavailable. [15:27:00] <CIA-92> ffmpeg: 8 cpu cycles faster. [15:27:06] <av500> mru: last cab driver managed to hit another cab... [15:27:15] <av500> slowly enough luckily [15:27:16] <kshishkov> I've heard that shouting at French in Russian helps with anything [15:29:06] <kshishkov> guess where the word "bistro" come from? [15:29:56] <mru> hmm, bistro wars? [15:30:18] <kshishkov> no, from Russian word for "quickly [do it]" [15:30:36] <kshishkov> learnt by French in the beginning of XIX century [15:31:17] <av500> "...However, this etymology is not accepted by several French linguists as there is, surprisingly, no occurrence of this word until the end of the 19th century.[1][2][3]" [15:31:49] <kshishkov> any reason to believe them? [15:32:15] <mru> english got it from french in early 20th century apparently [15:32:16] * av500 only believes fflinguists [15:32:29] <kshishkov> mru: Swedish too [15:33:09] <av500> if the russians got it from the swedish, it will create an endless loop [15:33:21] <kshishkov> no, it's of Slavic origin [15:33:56] <kshishkov> but it may be a bit puzzling why certain West Ukrainian short sausage is called "gurka" [15:34:13] <mru> from swedish of course [15:34:21] <kshishkov> javisst! [15:34:29] <mru> hardly anything to do with the gherkas [15:34:58] <mru> or gurkha, as some would spell it [15:35:00] <mru> or ghurka [15:35:05] <mru> they can't make up their minds [15:35:16] <kshishkov> no, they simply can't pronounce it [15:35:50] <merbzt> Chinese patches [15:36:13] <merbzt> and a potentially good one also [15:36:50] <kshishkov> better fix gcc though [15:37:13] <mru> yes [15:37:22] <mru> that's likely to give worse code on other machines [15:38:15] <merbzt> unpossible [15:39:05] <kshishkov> mru: go to farm and test ;) [15:42:18] <mru> one insn worse on alpha [15:43:32] <Dark_Shikari> nobody cares about alpha [15:43:37] <Dark_Shikari> ARM matters, x86 matters [15:43:40] <Dark_Shikari> PPC _maybe_ matters [15:43:40] <MrNaz_out> Dark_Shikari i have questiosn for you@ [15:43:41] <Dark_Shikari> alpha? lol [15:43:42] <MrNaz_out> ! [15:43:44] <Dark_Shikari> ask then [15:43:45] <mru> alpha is first in alphabetical order [15:43:50] <Dark_Shikari> lol [15:44:07] <mru> I have a script that compiles bits of code with a dozen compilers [15:45:59] <mru> one insn less on arm due to gcc nonsense [15:46:10] <mru> probably same execution time on modern cpus though [15:46:15] <mru> due to dual-issue [15:46:21] <Dark_Shikari> if all else is the same, faster on x86 is better [15:47:06] <MrNaz_out> video archiving... i'm outputting from premiere, into uncompressed avi and i'm trying to find a solution for archiving... i've investigated h.264 lossless and got 35mbits, which is acceptible... however that's 720x576... when i switch to using HD the bitrate will be unacceptibly high... do you ahve any suggestions? [15:47:13] <mru> one worse on avr32 [15:47:19] <Dark_Shikari> MrNaz_out: don't use lossless then [15:47:25] <lu_zero> mru: what are you doing? [15:47:25] <mru> looks better on bfin [15:47:53] <mru> ia64 looks horrible both ways [15:47:58] <mru> I can't make heads or tails of ia64 asm [15:48:06] <MrNaz_out> Dark_Shikari the video is interlaced... is there a good way to archive interlaced footage using lossy compression ? [15:48:14] <kshishkov> mru: neither can Intel [15:48:18] <Dark_Shikari> MrNaz_out: x264, crf 10? [15:48:46] <Dark_Shikari> qpmin 0 [15:49:37] <lu_zero> .... [15:49:39] <MrNaz_out> will that be safe for interlaced content? and whats the story with -ilme ? [15:49:41] <mru> one insn worse on mips [15:50:17] <kshishkov> lu_zero: he's testing small H.264 optimization proposed on ML [15:50:19] <mru> guess we don't care too much about cpus with expensive shifts [15:50:40] <CIA-92> ffmpeg: siretart * r22080 /branches/ (0.5/libavformat/asfdec.c 0.5): [15:50:41] <CIA-92> ffmpeg: Avoid divisions by 0 in the ASF demuxer if packet_size is not valid. [15:50:41] <CIA-92> ffmpeg: r19330 by reimar [15:50:42] <lu_zero> let me dig the ml [15:50:44] <Dark_Shikari> MrNaz_out: --interlaced [15:50:57] <MrNaz_out> aah [15:51:15] <MrNaz_out> will --interlaced help when using h.264 lossless? [15:51:34] <MrNaz_out> (oh i just realized that i'm asking all this in the wrong channel... switching) [15:51:42] <Dark_Shikari> MrNaz_out: yes [15:52:12] <mru> 4 insns worse on sh4 [15:52:18] <av500> sh4 is dead [15:52:33] <kshishkov> and we don't care about it which is more important [15:52:35] <mru> yes, but apparenly I have a compiler... [15:52:44] <mru> x86 looks better for sure [15:53:01] <mru> we could add a special case to gcc for this :-) [15:53:04] <mru> not very hard [15:53:05] <Dark_Shikari> lol [15:53:14] <Dark_Shikari> like that #ifdef ARM stuff in coreavc [15:53:26] <mru> coreavc has too much ifdef [15:53:30] <mru> most of them dead too [15:53:45] <Dark_Shikari> :/ yeah [16:07:52] <MrNaz_out> who is rbultje [16:08:11] <kshishkov> Ronald Bultje, should be obvious [16:08:26] <MrNaz_out> as in.. what's is irc nick [16:08:30] <kshishkov> BBB [16:08:36] <MrNaz_out> ta [16:09:54] <av500> janneg: any more luck with BBB ? [16:11:42] <janneg> av500: I can now render frames I couldn't before but slowly. currently 50 minutes per frame [16:11:57] <av500> wow [16:12:35] <av500> we might start saving to get the real BBB over here from NY... [16:12:59] <janneg> and there are still frames which gets OOM-killed with 6G [16:13:14] <BBB> av500, huh? [16:13:33] <av500> janneg: leave those to mru [16:16:22] <kshishkov> BBB: you should've chosen nick which is not an abbreviation of some movie av500 and janneg talk about [16:23:03] <CIA-92> ffmpeg: mstorsjo * r22081 /trunk/libavformat/rtspenc.c: [16:23:03] <CIA-92> ffmpeg: RTSP muxer: Use a local copy of the AVPacket for sending to the chained muxer [16:23:03] <CIA-92> ffmpeg: This way, we avoid overwriting stream_index in the user's AVPacket [16:23:03] <CIA-92> ffmpeg: with a nonsense value. [16:25:02] <janneg> av500: sure but if want it finished before linuxtag we'll need at least another quadcore. ETA at my current average speed 28 weeks but only 14 weeks left [16:26:10] <av500> janneg: I am full afk next week, but once back I can look into setting that QC up [16:26:17] <av500> and render some stuff on the I7 [16:26:41] <merbzt> av500: what are you rendering ? [16:26:44] <merbzt> BBB ? [16:26:56] <janneg> and 70 weeks with 50 minutes per frame [16:27:17] <janneg> merbzt: yes, BBB at 2700x1440 for the videowall [16:27:37] <Dark_Shikari> lol [16:27:39] <janneg> lol [16:28:20] <av500> you mean video_BBB_2700_1440.mkv? [16:28:35] <_BBB_> that doesn't work :) [16:28:41] <av500> dman [16:28:54] <kshishkov> merbzt: sounds reasonable, rendering me may not fit into that resolution [16:29:04] <lu_zero> _BBB_: ping [16:29:35] <KotH> janneg: if you need a machine for distributed rendering, let me know [16:29:55] <_BBB_> lu_zero, yes [16:31:38] <av500> KotH: yes [16:31:57] <_BBB_> lu_zero, hm, you mean pause before teardown is "normal"? [16:32:01] <_BBB_> I thought it was kind of weird [16:32:32] <KotH> av500: ? [16:33:08] <KotH> av500: ah.. [16:33:17] <KotH> av500, janneg: how much computing power do you need? [16:33:49] <janneg> KotH: we need every machine with more than 4G we can get [16:33:55] <KotH> hmm.. [16:34:06] * KotH has a dual core xeon hat home.. dunno how fast it is [16:34:15] <av500> KotH: mem is the issue [16:34:16] <KotH> havent even unpackaged it, because i had no use [16:34:20] <KotH> 4G [16:34:25] <av500> not enuf :( [16:34:31] <KotH> how much does it need? [16:34:47] <av500> [17:12] <janneg> and there are still frames which gets OOM-killed with 6G [16:35:26] <lu_zero> _BBB_: teardown should just invalidate the rtsp session and reset the rtsp state machine [16:35:42] <janneg> 6G seems to to be mostly fine, I doubt we need more than 12G [16:35:43] <lu_zero> usually a teardown follow a disconnect from the transport layer [16:36:14] <lu_zero> so most of the time on teardown the server will just stop rtp streams and such [16:36:18] <lu_zero> but [16:36:56] <lu_zero> you might have some implementation behave differently and still being on spec [16:37:01] <KotH> janneg, av500: hmpf.. i would need to buy new 2G dimms [16:37:19] <KotH> the machine is fully equiped with 4*1G [16:38:13] <av500> KotH: :( [16:38:23] <KotH> janneg, av500: do we have a sponsor? :) [16:38:24] <av500> my QC has 2x2, I'd buy 2x2 more for it [16:39:13] <_BBB_> lu_zero, hm... ok, I didn't expect that, I thought teardown was just the end-of-it-all [16:39:22] <lu_zero> you might have [16:40:01] <av500> KotH: the QC here has not enuf ram anyway, I guess corp will pay for more [16:40:17] <lu_zero> usually you do not [16:41:22] <lu_zero> it's just to be safe [16:41:41] <lu_zero> TEARDOWN is supposed to free all the resources [16:41:49] <lu_zero> so it _should_ be the end of everything [16:42:21] <lu_zero> but it's nicer to issue a pause (stop) before [16:42:38] <KotH> av500: can you can manage to get 160EUR from somewhere, i'd buy the ram and put the machine online :) [16:42:40] <_BBB_> ok, I see [16:42:51] * lu_zero is re-checking [16:43:37] <av500> KotH: I can try to win a local snowboard race next week... [16:44:42] <lu_zero> http://pastie.org/844372 [16:45:39] <lu_zero> the section seem to make the current code fine as well [16:45:52] <KotH> hmm... dont we have some money in ffmtech already? [16:46:16] <kshishkov> maybe not yet [16:48:23] * elenril pokes Honoome_ [16:49:45] <KotH> av500, janneg: anyways. if you want a machine with xeon 3065 x2.3 and 4G ram, let me know [16:49:58] <KotH> av500, janneg: if you find 160EUR for the ram, then too ;) [16:50:32] <Dark_Shikari> this is amazing [16:50:33] <Dark_Shikari> http://www.youtube.com/watch?v=sRYPEBEGIcY [16:50:37] <Dark_Shikari> intel ad for the core i7 in japan [16:50:38] <Dark_Shikari> "8 threads" [16:50:42] <mru> janneg: would another c2q 4G help at all? [16:51:13] <kshishkov> Dark_Shikari: their ad "your office - your plantation" was better [16:52:11] <janneg> I'm currently looking if there's a easy and fast way to estimate how much RAM a frame needs [16:52:37] <kshishkov> +infinity? [16:53:22] <kshishkov> or maybe f(size) = size*N + M [16:53:57] <kshishkov> or num_of_polygons*N + M + size*N [16:54:20] <av500> (..)^random_large_number [17:03:38] <KotH> strange... my server at hetzner has amd 64 X2 Dual Core Processor 5600+, but reports 1GHz [17:03:51] * KotH thinks there is something fishy going on at hetzner [17:04:09] <kshishkov> frequency control in action? [17:04:11] <janneg> KotH: cpufreq? [17:04:17] <kshishkov> or simply VM? [17:04:18] <KotH> none installed [17:04:21] <KotH> root server [17:04:29] <KotH> so, "my" machine [17:04:47] <KotH> could be that they underclock the cpu to save power [17:05:54] <janneg> KotH: in /proc/cpuinfo? run cpuburn for each core and look again [17:11:38] <mru> janneg: I can put a c2q/4G online if it'll help [17:11:58] <av500> put more ram online too [17:12:10] <mru> don't have more [17:12:22] <mru> and I don't want to bog down the i7 with rendering [17:12:23] <av500> beg, steal, borrow [17:12:27] * DonDiego wants a pony [17:12:37] * av500 wants a steak sandwich [17:12:48] <mru> DonDiego: gimme that ram and I'll render you one [17:12:58] <kshishkov> av500: ask DonDiego when he gets a pony [17:13:03] * KotH notes, cpuinfo is not static [17:13:11] <wbs> lu_zero: (martin here, hi) - regarding pause/teardown in rtsp, should I wait for the reply to pause before proceeding with teardown (using ff_rtsp_send_cmd), or just fire away pause, teardown (using ff_rtsp_send_cmd_async as I do now), then close the connection? [17:13:12] <av500> kshishkov: my daughter will cry [17:13:13] <mru> DonDiego: not "render you a pony" as a wizard might of course [17:13:15] * KotH notes further, that he has cpufreq active but didnt know it [17:14:03] <kshishkov> av500: don't slaughter her pony then [17:15:03] <KotH> janneg: another 2.8GHz amd 64 dual core with 4G ram, if you can use that [17:15:19] <mru> av500: fork it first, then she can keep it _and_ you get your sandwich [17:16:49] <KotH> janneg: and that one with a 100Mbps network connection, so you could transfere the data fast too :) [17:17:20] <av500> we still have a light ram issue [17:19:25] <KotH> yeah.. [17:19:45] <KotH> as i said, find a sponsor, i get the ram and you'll get a machine just for yourself [17:23:34] <KotH> av500, janneg: i can borrow 8G from a friend [17:23:46] <KotH> av500, janneg: so you can get a machine if you want [17:24:01] <av500> KotH: \\\ooo//// [17:24:28] * kshishkov records that sign as "The Great Cthulhu is awakened" [17:24:59] <elenril> fhtagn! [17:38:31] <KotH> av500, janneg: i get the ram tomorrow, maybe i'll have the time to set up the machine on sunday, maybe not [17:38:53] <av500> ok, as said, I am awol for 1w [17:39:11] <av500> then I will try to get more mem here and setup a login [17:45:32] <janneg> KotH: great. ping me if you're ready. thanks [18:00:34] <mru> I'm bringing my machine up just in case [18:08:41] * KotH wonders where he put that machine anyways [18:08:58] <KotH> and what name shall i give it? [18:12:28] <kshishkov> bbbch obviously [18:13:22] <CIA-92> ffmpeg: vitor * r22082 /trunk/libavcodec/eatgv.c: [18:13:23] <CIA-92> ffmpeg: Do not read beyond end of input in EA-TGV. This should avoid FATE test #362 [18:13:23] <CIA-92> ffmpeg: result depending on uninitialized data. [18:13:23] <CIA-92> ffmpeg: FATE result may change for this test. [18:13:44] <KotH> hmm... stupid question: i have to perform a%b, b is a power of 2, but can be anything between 8 and 512, is there anyway that i can tell gcc to not do a modulo operation, but optimize it? [18:14:12] <KotH> short of coding this by hand [18:14:18] <KotH> (which would probably slower) [18:14:27] <mru> b==1<<x, x==3..9? [18:14:38] <KotH> yes [18:14:53] <mru> a & ((1<<b)-1) [18:14:55] <kshishkov> gcc can't take hints anyway [18:15:07] <KotH> mru: thanks! [18:15:22] <mru> know your power of 2 maths [18:15:49] <KotH> mru: uhmm... shouldnt that be b<<1 ? [18:15:59] <mru> no [18:16:07] <mru> 1<<b == pow(2, b) [18:16:22] <mru> b<<1 == b*2 [18:17:17] <KotH> and why do i need 2^b ? :) [18:17:44] <mru> I'm stupid [18:17:47] <mru> a & (b-1) [18:50:56] <CIA-92> ffmpeg: fenrir * r22083 /trunk/libavcodec/dca.c: [18:50:56] <CIA-92> ffmpeg: Fixed a segfault in the DCA decoder with corrupted streams. [18:50:56] <CIA-92> ffmpeg: It happens when the number of channels defined by DCAContext:acmod is lower [18:50:56] <CIA-92> ffmpeg: than DCAContext:prim_channels. In this case, dca_subsubframe() will call [18:50:56] <CIA-92> ffmpeg: qmf_32_subbands() using s->channel_order_tab[] entries equal to -1. [19:21:53] <j-b> Anyone with a 6.1 vorbis file? [19:24:39] <peloverde> j-b, rob added support for the new vorbis surround stuff so my guess is he might [19:25:16] <j-b> peloverde: his mail speak about 7.1 one, not about 6.1 one [19:25:42] <peloverde> "New channel layouts have been added to the Vorbis spec [1] for 6.1 and 7.1 channels. Attached is a patch for adding such support to the FFmpeg decoder." [19:26:12] * Kovensky wonders how many compliant 5.1 files are around [19:26:13] <j-b> yes, and then speaks about the 8.ogg from monty [19:26:27] <Kovensky> I remember downloading a fansub that used 5.1 vorbis but had the channel layout completely wrong in ffmpeg [19:26:33] <Kovensky> but it was right in corevorbis [19:26:40] <peloverde> why do none of the caf samples have codec names attached [19:26:44] <Kovensky> guess which decoder the encoder insisted in using [19:33:05] <peloverde> Can we run ffprobe over the samples archive and dump that to some sort of database to try to catalog it better? [19:34:17] <mru> feel free [19:35:14] <_av500_> peloverde: so the simple solution finds no love? (wrt heaac) [19:35:26] <peloverde> I understand why the old samples are a mess but I don't understand why the new ones are equally worthless [19:35:34] <mru> _av500_: love don't come easy... [19:35:46] <_av500_> mru: I know [19:36:20] <peloverde> _av500_, your update patch probably makes the most sense [19:36:49] <peloverde> having to check each demuxer manually (which is what I'm doing now) is a huge pain in the ass [19:36:56] <_av500_> as we open the codec twice already, no use to throw the data away [19:37:24] <mru> codec-specific hacks in every demuxer is silly idea [19:37:36] <_av500_> ack [19:37:48] <_av500_> codec-agnostic ftw [19:38:02] <peloverde> I agree [19:38:30] <_av500_> now, lets find KotH and a pizza hut... :) [19:43:13] <janneg> mru: the 4G machine is useful as long as there are frames which can be rendered with 4G. I'm hacking the job generation scripts used for their renderfarm [19:48:08] <peloverde> And for reasons mysterious to me ffplay doesn't appear to be working on my system [19:48:46] <_BBB_> http://web.mit.edu/xiphmont/Public/theora/demo.html <- I guess they know after all :) [19:49:29] <wbs> _BBB_: hi :-) [19:50:35] <Kovensky> _BBB_: oh you [19:54:12] <peloverde> Is there a reason why ffplay would refuse to play audio and refuse to exit? [19:54:32] <Kovensky> refuse to exit? o_O [19:55:07] <peloverde> I can sit there and tap q or escape or hit the wm close button and it just sits there [19:55:20] <peloverde> frozen and refusing to do anything [19:55:36] <_BBB_> Kovensky, huh? [19:55:48] <_BBB_> wbs: oh, hi martin :) [19:56:06] <_BBB_> wbs: svn account holders get ops here, not sure how to ask for it but you're a svn holder after all :) [19:56:36] <wbs> _BBB_: ooh :-) [19:57:01] <Kovensky> <@_BBB_> Kovensky, huh? <-- that way you prevent us from using tab complete to talk about BBB :( [19:57:03] <_av500_> peloverde: I have that when somebody else has the soundcard [19:57:14] <wbs> _BBB_: thought it was finally time to enter this channel too, to perhaps speed up some discussions, if needed :-) [19:57:14] <_BBB_> Kovensky, indeed1 [19:57:29] <_BBB_> Kovensky, you have no idea how noisy it gets when you guys are working on that video [19:57:32] <peloverde> _av500_, that was my thought.... it really should try to handle the situation more gracefully [19:57:46] <Kovensky> wbs: all developers should be here, actually [19:57:48] <Kovensky> http://www.codinghorror.com/blog/2008/11/is-email-efail.html [19:58:16] <_av500_> peloverde: I already once tried to debug it, but then it looked like SDL totally trashed gdb... [19:59:12] <Kovensky> _av500_: there are instructions in the SDL FAQ on how to make it not hijack gdb [19:59:27] <_av500_> ah, thx [19:59:46] <_av500_> I did not assume such malice... :) [19:59:54] <Kovensky> heh :) [20:03:09] <Kovensky> _av500_: SDL_INIT_NOPARACHUTE <-- OR it with the flags given to SDL_Init [20:03:17] <Kovensky> accidentally found it on mplayer's configure.log lol [20:03:26] <_BBB_> wbs: so about that url_concat() patch, there's the thing that it sort of induces you to require two buffers [20:03:43] <_BBB_> wbs: because you'll never, ever use the hostname just by itself, it's part of a larger thing [20:03:49] <DonDiego> _BBB_: the channel overlords can instruct chanserv to give op permanently [20:03:58] <DonDiego> me and mans for example :) [20:04:08] <_BBB_> oh, our overlord is here :) [20:04:11] <Kovensky> /mode #ffmpeg-devel +o wbs [20:04:13] <Kovensky> also works [20:04:14] <Kovensky> :) [20:04:23] <Kovensky> even if only until he leaves the channel lol [20:04:41] <DonDiego> wbs: you have not registered.. [20:04:47] <wbs> Kovensky: perhaps, yes - mail is a bit easier as long as one doesn't have all that much continuous time to commit [20:05:00] <_BBB_> wbs: I'm not saying that you need to make it like url_concat(target, size, proto, auth, host, port, path);, but I guess you see what I mean, right? [20:05:14] <_BBB_> wbs: also, don't use url_concat() on uninitialized memory, I have bad experience with that :) [20:05:22] <_BBB_> I mean, av_strlcat() [20:05:23] <_BBB_> sorry [20:05:24] * Kovensky finds mailing lists too unconvenient [20:05:53] <wbs> DonDiego: hmm, I registered with nickserv after joining, should I perhaps disconnect/part or something? [20:06:08] <_BBB_> /cycle [20:06:29] <wbs> \o/ [20:06:35] <DonDiego> welcome aboard :) [20:06:36] <Kovensky> /o\ [20:06:54] <wbs> thanks :-) [20:08:10] * _BBB_ wonders if he should reply to the list for archiving purposes [20:08:43] <wbs> well, I guess we can take the initial discussion here at least and the summarize the points on the list [20:08:53] <_BBB_> I guess [20:09:05] <Kovensky> isn't the IRC discussion archived now? :) [20:09:10] <Kovensky> big brother is watching, etc [20:09:35] <wbs> _BBB_: yeah, mostly we've gotten the url components from url_split earlier, but the url assembly code is a bit different in each case, so I'm not sure about a fullblown "assemble these components into a url" function [20:09:46] <_BBB_> so what I don't like about your patch is that it induces behaviour like this: char buf[..]; url_concat(buf, sizeof(buf), "some host"); snprintf(url, "tcp://%s:%d/%s", buf, etc); [20:09:50] <_BBB_> I don't like the temporary buf [20:10:17] <wbs> yeah, that's one issue indeed [20:10:35] <wbs> that's the reason for the other suggestions I had, but they're not pretty either [20:10:53] <_BBB_> since it's not speed-critical, maybe a fullblown function is OK [20:10:58] <_BBB_> at least it'll do the correct thing [20:11:06] <_BBB_> unless it's speed-critical [20:11:08] <_BBB_> which I doubt [20:11:34] <wbs> I highly doubt it's speed critical, too, the string will probably be passed blindly into getaddrinfo at some point anyway [20:12:17] <wbs> so you're suggesting a fullblown "assemble these things into an url" function? the problem with that is that there's quite a bit of individual cases out there [20:12:34] <_BBB_> url_split() exists and works... should be OK, I guess [20:12:45] <_BBB_> but I agree it'll be big and probably a bit ugly [20:13:08] <wbs> e.g. the Host: string in http, it needs to be of the form [123::1]:80, so that's a special case compared to building the tcp://[123::1]:80/ url [20:14:19] <_BBB_> really? host needs to be []-enclosed also? [20:14:25] <_BBB_> (in the HTTP header you mean, right?) [20:14:28] <wbs> yeah [20:14:46] <wbs> otherwise, if contacting an ipv6-vhost, how could the server parse out what's part of the ip and what's the port? [20:15:24] <wbs> e.g. Host: [123::456:789]:8080, without [] it's completely ambiguous [20:15:46] <_BBB_> good question [20:15:48] <_BBB_> ok [20:15:50] <_BBB_> hmm... [20:15:52] <_BBB_> hmm... [20:15:58] <_BBB_> and again hmm... [20:16:03] <Rathann> no, without [] it's not a valid host:port pair [20:17:58] <DonDiego> ##### MESSAGE TO MICHAEL ##### [20:18:09] <DonDiego> the cursed cathedral sample is broken.. [20:18:46] <Kovensky> </##### MESSAGE TO MICHAEL #####> [20:19:37] <kierank> needs more xml metadata [20:19:56] <kierank> <message type="communication" to="michael" from="dondiego" about="cathedral"> [20:21:33] <Kovensky> --- [20:21:35] <Kovensky> message: [20:21:38] <Kovensky> to: michael [20:21:41] <Kovensky> from: dondiego [20:21:45] <Kovensky> about: cathedral [20:21:50] <Kovensky> - IT BORKEN [20:21:54] <Kovensky> ... [20:22:26] <_av500_> would DonDiego forget the "."? [20:22:48] <Kovensky> no, '...' is the YAML EOF marker [20:23:22] <_BBB_> wbs: ok, I don't have an off-hand solution but again, if you can somehow get rid of the temp buffer, I'd greatly appreciate it [20:23:31] <kierank> actually my message fails because i didn't specify a schema [20:23:44] <Kovensky> lulz [20:23:47] * Kovensky <3 yaml [20:24:04] <_BBB_> wbs: worst-case, it's ok for me to make the function return [ip::ip]:port if proto == NULL (for HTTP purposes) [20:26:58] <wbs> _BBB_: after revisiting the code, we mostly have cases of tcp://%s:%d, and a few special cases with the http host header, an proto://host:port/path url in rtmp, and then the rtp://host:port?localport=%d&ttl=%d in rtsp... so I guess it would be quite simple to cover them all with such a function [20:30:35] <DonDiego> hrmpf [20:30:47] <DonDiego> the cathedral sample works with ffplay.. [20:31:16] <KotH> av500: i'm here [20:31:24] <KotH> av500: but pizza hut isnt ;) [20:35:12] <wbs> _BBB_: so, what about function signature like this: void url_join(const char* proto, const char* host, int port, const char* fmt, ...); [20:35:53] <_BBB_> what is fmt? [20:36:13] <wbs> a normal printf format for the rest of the url [20:36:36] <wbs> in rtsp, there's some ?localport=%d&ttl=%d that otherwise needs a temp buffer [20:37:29] <_BBB_> isn't var_args a portability nightmare? [20:38:24] <wbs> libavutil/avstring.c already uses them, don't know if it's confined to that place only or if it's used freely at other places too [20:38:44] <_BBB_> no, you're right, if it's used then it's ok [20:38:51] <_BBB_> if you add good doxy I guess it's OK [20:39:50] <wbs> ok, I'll give it a shot. with this change, the modifications to the individual protocols become very non-intrusive [20:53:05] <_BBB_> I like that [20:57:31] <KotH> janneg: what do you need to have installed? [21:01:46] <_BBB_> wbs: I sent a summary to the list [21:03:18] <wbs> _BBB_: great, thanks [21:03:46] <wbs> _BBB_: regarding having this as a non-public function, in what header should it be added? are there any libavformat "global" headers that aren't installed? [21:07:47] <janneg> KotH: only blender [21:17:31] <_BBB_> wbs: I suppose if I say "where-ever url_split() is", that's not the right answer? [21:18:53] <wbs> _BBB_: yeah, that'd be my first choice, too, but it's in avformat.h, and everything there is public/exported, right? [21:19:15] <_BBB_> url_split() isn't... [21:19:35] <_BBB_> well, since michael reads IRC log anyway: [21:19:44] <_BBB_> add it there and wait for him to say that it should be in a new header [21:19:50] <_BBB_> and let's take it from there [21:20:21] <wbs> ooh, there's an HAVE_AV_CONFIG_H section in avformat.h - then I guess it's ok to put it there [21:40:07] <ShadowJK> BBB, i don't know how anyone can read the intermixed drivel and actual content in one day batches like that :) [21:46:10] <_av500_> /tools/ircdigest? [21:47:33] <DonDiego> i tend to agree, reading irc logs can be a huge waste of time [21:47:37] <DonDiego> just like irc ;) [21:51:35] <KotH> lol [21:55:11] * KotH is an idiot [21:55:26] <DonDiego> we know, we know.. [21:55:28] <DonDiego> *sigh* [21:55:30] <DonDiego> ;-p [21:55:33] * KotH used a x86 install cd instead of an x86_64 [21:55:39] <DonDiego> lol [21:55:43] <DonDiego> k, gtg, cu [22:01:28] <ShadowJK> KotH, I've done that, but that was just because I didn't want to wait a week for the amd64 dvd to download :) [22:03:16] <Yuvi> hm, avformat_seek_file is still considered under construction [22:03:49] <Yuvi> did gstreamer / whoever else ever come up with actual suggestions / gripes? [22:03:54] <KotH> ShadowJK: well, in this case it's an issue [22:04:01] <KotH> ShadowJK: as i need a 64bit system [22:04:38] <ShadowJK> how old is this debian etch anyway [22:04:40] <peloverde> Why am I getting 403s on some of the samples? [22:04:42] <ShadowJK> i think that's what I'm running on it [22:05:01] <KotH> peloverde: which ones? [22:05:16] <peloverde> asian-commercials-are-weird.flv [22:05:28] <KotH> too many downloads [22:05:35] <KotH> use ftp with developer login [22:07:03] <astrange> oh, i still need to complain that there's no public index-reading function [22:10:23] <wbs> BBB: there, sent a new mail with the new function, and an example of converting all the protocol code to use it [22:12:55] <KotH> astrange: send script [22:32:47] <KotH> http://www.brainblog.to/item/2010/01/der-super-hacker [22:38:23] <andoma> KotH: that guy is awesome! [22:43:33] <janneg> KotH: lol [22:45:25] * janneg still wonders why windows resolves http://google.com [22:46:35] <CIA-92> ffmpeg: michael * r22084 /trunk/libavcodec/h264_cabac.c: [22:46:35] <CIA-92> ffmpeg: Optimize (amvd>2)+(amvd>32), about 1 cpu cycles faster. [22:46:35] <CIA-92> ffmpeg: patch by Zhou Zongyi @ zhouzy () os punkt pku dot edu speck cn [22:46:43] <KotH> prolly because there are too many windows admins who think the protocol is part of the hostname [22:48:04] <janneg> broken dns a.k.a. sitefinder could be another reason [22:48:17] <Kovensky> is that still about that hacker that says tracert shows you the IPs of the computers accessing google? [22:48:22] <Kovensky> well, "hacker" [22:48:32] <janneg> yes [22:48:50] <Kovensky> lulz [22:48:51] <andoma> perfect hire [22:48:59] <Kovensky> I saw that on larry oysterman's blag [22:49:17] <Kovensky> he said the guy owned him a new monitor because he spat coffee on his lol [22:55:17] <KotH> janneg: is there a minimal version of blender you need, or is debian/outdated ok? [22:58:01] <janneg> yes, it's sitefinder. 24.28.193.9 is allocated to roadrunner and not google [22:58:27] <janneg> KotH: no idea. I use the latest 2.49b [22:58:48] <KotH> janneg: hmm.. ok. i'll put debian/testing on [23:00:03] <janneg> ok, 2.46 might be too old, testing has the 2.49b [23:01:09] <KotH> janneg: i'll install gcc&co too, so you can compile anything you need or dislike ;) [23:02:50] <janneg> shouldn't be necessary, blender, vim, ssh and rsync should be enough [23:06:07] <Kovensky> debian/stale :) [23:06:08] * Kovensky ducks [23:52:44] <KotH> night boys

1 0

IRC log for 2010-02-25
by irc＠mansr.com 26 Feb '10

26 Feb '10

[00:05:55] <CIA-92> ffmpeg: stefano * r22045 /trunk/ffprobe.c: [00:05:55] <CIA-92> ffmpeg: Cosmetics: replace "filename" to "arg" for the name of the argument of [00:05:55] <CIA-92> ffmpeg: opt_input_file(). More consistent and more clear, as "filename" can be [00:05:55] <CIA-92> ffmpeg: easily confused with the global "input_filename". [00:07:40] <janneg> 2G DDR2 modules, but I'm primarily annoyed that I haven't bought some 9 months ago [00:08:04] <janneg> or at least replaced the broken one [00:17:33] <CIA-92> ffmpeg: stefano * r22046 /trunk/ffprobe.c: [00:17:34] <CIA-92> ffmpeg: 10l: add prefix "TAG:" to the metadata tags key showed for each stream. [00:17:34] <CIA-92> ffmpeg: This is consistent with the metadata displaying in show_format() and [00:17:34] <CIA-92> ffmpeg: with the documentation. [00:27:34] <janneg> hmm, I'm looking at a script for tile rendering [01:09:18] <janneg> I render only a quarted of the image and memory consumption hasn't decreased much and rendering seems to be as slow as before [01:10:38] <Dark_Shikari> I would doubt memory consumption would go down much with tile rendering [01:10:41] <Dark_Shikari> you still have to consider the whole scene [01:14:53] <Kovensky> http://www.codinghorror.com/blog/2008/11/is-email-efail.html [01:15:42] <Kovensky> and yes, memory consumption won't go down; you're only skipping the rendering of off-camera objects but they're still there [01:20:09] <janneg> rendering objects will obviously consume memory too [01:20:40] <iive> janneg: can you explain this a little bit more [01:21:12] <mru> I reckon most of the memory is used for the scene representation [01:21:22] <mru> most of the cpu time is probably spent in rendering though [01:22:05] <iive> so, even if you render 320x200, you'd still need that amount of ram. [01:23:41] <janneg> if I interpret the memory usage stats and stage descriptions correctly the scene representation is usually around 1-1.5G [02:11:45] <mru> I finally figured out why gcc is silly about registers [02:11:58] <mru> there's a file in the gcc source called rtlanal.c [02:18:30] <DonDiego> ##something##-not-a-lawyer [02:19:14] <mru> rtl = register transfer language [02:19:38] <mru> it's what the machine descriptions are written in [02:22:39] <DonDiego> btw [02:23:06] <DonDiego> i managed to troll the xiph folks on their home turf.. [02:23:12] <DonDiego> didn't even want to.. [02:23:15] <DonDiego> :) [02:23:24] <mru> how? [02:24:26] <DonDiego> http://blog.gingertech.net/2010/02/20/googles-challenges-of-freeing-vp8/ [02:24:36] <DonDiego> i called ogg deeply flawed [02:25:04] <DonDiego> i could use some help dispelling the myths they keep spreading.. [02:28:53] <Dark_Shikari> use mru's post [02:29:09] <mru> it's not all-encompassing [02:29:17] <Yuvi> he thinks codec-specific timestamps are a feature [02:29:17] <mru> only talks about timestamps [02:29:17] <Yuvi> not [02:29:47] <Yuvi> i.e. that everything mru points out are good things [02:30:02] <mru> lol [02:30:13] <DonDiego> i already used mru's post [02:30:24] <DonDiego> we really have a problem here [02:30:27] <mru> I need to write a new one [02:30:33] <DonDiego> they should not be left with the last word [02:30:46] <mru> but writing a good, scathing post takes time [02:31:00] <DonDiego> we need to be way more visible with good technical criticism [02:31:30] <Yuvi> I really should start a blog / get a domain, but I can't think of a good name [02:31:30] <DonDiego> "The third big thing Diego (and the mplayer community in general) hate is the intentional, conscious decision to allow a codec to define how to parse granule positions for that codec’s stream. Granpos parsing thus requires a call into the codec." [02:31:47] <DonDiego> "The practical consequence: When an Ogg file contains a stream for which a user doesn’t have the codec installed…. they can’t decode the stream! *gasp* Wait… how is that different from any other system?" [02:32:06] <mru> have I mentioned that I dislike the silly names they give everything? [02:32:10] <mru> "granule" wtf? [02:32:19] <mru> "sample" please [02:32:27] <DonDiego> am i deeply mistaken or does this prohibit remuxing? [02:32:41] <Yuvi> with other containers, you either don't have to add *any* code to the demuxer to handle nearly any new codecs, (avi, nut, mov) or very little (mkv, mpg, mp4) [02:33:02] <DonDiego> Yuvi: ask mike for a blog on multimedia.cx [02:34:08] <DonDiego> Yuvi: also, your work is very important: it's a much better to be able to say "yes, we hate the stuff, but of course we have top-notch support nonetheless" [02:35:50] <mru> monty is on edge, nice work DonDiego [02:36:04] <DonDiego> haha :) [02:36:14] <DonDiego> as i said, please back me up [02:36:38] <DonDiego> we need to show that it's not just for the sake of trolling [02:38:23] <peloverde> DonDiego, There are patents on the MP4 container [02:38:32] <mru> that's just crazy [02:38:41] <mru> it's apple quicktime ffs [02:38:42] <peloverde> but my guess is that they are on fancy new (read unnecessary) features [02:38:44] <DonDiego> apparently, but i didn't know that [02:38:47] <mru> old as the hills [02:38:53] <peloverde> MOV itself is old as dirt and [02:39:22] <mru> the -14 format really has everything you need [02:39:31] <mru> and it's quite simple too [02:39:55] <peloverde> I would define something simple on top of -12 [02:40:13] <mru> simpler than -14? [02:40:22] <peloverde> yes [02:40:25] <peloverde> -14 is a superset of -12 [02:40:33] <Dark_Shikari> DonDiego: the point is that they're looking from a completely different perspective [02:40:35] <mru> I know [02:40:38] <Dark_Shikari> they're acting as if developers don't matter [02:40:42] <mru> but -12 lacks a few bits [02:41:05] <peloverde> -12 lacks a few bits, but that crowd is going to piss and moan that -14 costs a few CHF [02:41:18] <DonDiego> Dark_Shikari: good point, yes, but false of course [02:41:31] <peloverde> anything missing can be re-adapted from qtff which is also free [02:41:40] <Dark_Shikari> just use mkv [02:41:42] <Dark_Shikari> seriously [02:41:44] <Dark_Shikari> it's already free [02:41:46] <Dark_Shikari> it's more popular than ogg [02:41:49] <Dark_Shikari> it's better than ogg in every way [02:41:56] <mru> mkv is a bit over-complicated [02:41:58] <peloverde> yes mkv is also acceptable [02:42:03] <Dark_Shikari> mru: but xiph love overcomplicated [02:42:05] <mru> but it's not utterly horrible like ogg [02:42:08] <DonDiego> mkv is supported in a lot of hardware [02:42:09] <peloverde> for dev purposes I kind of like mov [02:42:13] <Dark_Shikari> and mkv also has buzzword compliance [02:42:14] <Dark_Shikari> XML! [02:42:30] <mru> even though it has fuck all to do with xml [02:42:44] <peloverde> mov is basically human readable [02:43:14] <CIA-92> ffmpeg: michael * r22047 /trunk/libavcodec/ (h264.c h264.h): Keep mvd_table values of only 2 mb rows. [02:43:27] <peloverde> either way, mov or isom i don't really care [02:44:36] <Dark_Shikari> we need to pick something already free, already widely used, and promote it [02:44:39] <Dark_Shikari> let's make it mkv. [02:44:58] <peloverde> If you are trying to build consensus (which it doesn't seem like they are) choosing a mov/isom derivative might get a few points of approval from apple [02:45:08] <Dark_Shikari> Nobody will agree on a new container format. [02:45:12] <kierank> and it works in flash [02:45:26] <Dark_Shikari> The purpose of this promotion is to step on Xiph [02:45:31] <DonDiego> oh, mike is posting.. [02:45:35] <Dark_Shikari> it doesn't have to be something apple would like [02:45:43] <Dark_Shikari> it has to be something better than what xiph offers [02:46:03] <Yuvi> wonder how much stuff nut works in (heh) [02:46:14] <Yuvi> probably not gstreamer [02:46:16] <Dark_Shikari> so seriously, someone make a post outlining all the reasons that ogg sucks [02:46:22] <Dark_Shikari> and tell people to use mkv [02:46:26] <Dark_Shikari> because it's more widely used, more widely supported [02:46:28] <Dark_Shikari> and better [02:46:40] <Dark_Shikari> and free. [02:47:07] <saintdev> <Dark_Shikari> XML! <-- EBML! [02:47:30] <saintdev> *ML, it must be good... [02:48:15] <saintdev> Dark_Shikari: your blog seems to get a lot of attention ;) [02:48:25] <Dark_Shikari> I'm not enough of an expert to write about why ogg sucks. [02:49:27] <astrange> mkv doesn't need faststarting so it's probably easier to use than mov [02:50:00] <Dark_Shikari> it also has commercial support (unlike ogg) [02:50:07] <Dark_Shikari> i.e. you can get support from corecodec [02:52:02] <DonDiego> mru: you do notice that everyone is looking at you, don't you? [02:52:04] <DonDiego> :) [02:52:45] <saintd3v> and like a car-crash, i can't look away [02:52:49] <saintd3v> :p [02:53:39] <astrange> hmm, mkvmerging a random ogg (3m long vorbis track) made it a little smaller [02:53:52] <astrange> wonder if it takes less disk reads to do a random seek [02:54:13] <Yuvi> yeah, ogg has the highest overhead of any container other than .ts [02:55:08] <mru> but unlike ts the overhead doesn't bring any advantages [03:03:58] <DonDiego> monty claims otherwise [03:04:09] <mru> well, he would... [03:04:42] <DonDiego> well, we need to set him straight [03:04:59] <DonDiego> i already did for the infamous youtube comparison from gregory maxwell [03:05:37] <Dark_Shikari> DonDiego: you'd actually be slightly surprised at the situation [03:05:47] <Dark_Shikari> apparently the theora devs are very worried because people are dubbing them liars and cheats [03:06:06] <Dark_Shikari> in large part due to the legions of idiots who follow xiph [03:06:22] <DonDiego> yeah [03:06:28] <DonDiego> the devs know the limitations [03:06:31] <mru> but they _are_ liars and cheats [03:06:33] <Dark_Shikari> and they want people to stop posting about how theora will beat h264 [03:06:44] <Dark_Shikari> of course it's partially their fault... [03:06:55] <Dark_Shikari> the point being that lies catch up with people [03:09:30] <DonDiego> who told you that? [03:09:59] <peloverde> Ask them if they are willing to renounce and reject lying supporter Mozilla? [03:10:59] <DonDiego> what? [03:11:23] <Dark_Shikari> who told what [03:11:33] <peloverde> mozilla has gotten caught with their hand in the bad comparison cookie jar multiple times [03:11:49] <Dark_Shikari> they don't seem to be willing to do it [03:11:55] <Dark_Shikari> which means I think people will rightfully blame them for it [03:14:32] <DonDiego> you guys are talking in riddles right now.. [03:14:43] <peloverde> I also wish someone would ask Mozilla if their former high profile developers Hyatt, Hixie, and Goodger want to "Hurt the web" [03:15:05] <peloverde> I wish someone would take their retarded frame to its logical conclusion [03:15:06] <ohsix> i'm hurting the web right now [03:16:09] <Dark_Shikari> DonDiego: a theora dev told me to bonk on the head anyone who claimed that theora was nearly as good, as good, or better than h264 [03:16:13] <Dark_Shikari> because it made them look like liars [03:16:58] <DonDiego> peloverde: where are these guys now? [03:17:17] <DonDiego> well, i talked to a webkit dev at fosdem [03:17:46] <DonDiego> alp toker [03:17:55] <peloverde> alp was pretty cool [03:17:58] <DonDiego> he ported webkit to firefox [03:18:16] <DonDiego> i.e. firefox with webkit as rendering engine [03:18:20] <mru> and theora to mono [03:18:24] <peloverde> Hixie and goodger are at google [03:18:36] <peloverde> hyatt is at apple [03:18:42] <DonDiego> i.e. faster and more standards-compliant rendering [03:18:47] <DonDiego> all firefox extensions [03:18:49] <DonDiego> perfect [03:19:18] <peloverde> well i'm sure there are a few extensions that depend on -moz CSS attributes [03:19:33] <DonDiego> mru: yeah, but that was "just for kicks" as he said, no particular reason or political agenda [03:19:33] <kierank> DonDiego, can you download that? [03:19:48] <kierank> it would be firefox without being sluggish as hell [03:20:03] <ohsix> anyone seriously and critically assessing this stuff will know all they need to know after they commit their own time; theres really nothing that needs to be constantly and doggedly defended, overstating your case is bad [03:20:10] <peloverde> some of firefox's issues are from the way they use SQLite [03:20:11] <DonDiego> no, he was paranoid to release it, fearing a backlash from the firefox people :-( [03:20:40] <DonDiego> ohsix: i agree, but our case is not sufficiently stated [03:20:52] <DonDiego> we need to be more visible with our technical arguments [03:21:10] <DonDiego> we should explain *once* why ogg is bad and not on a mailing list [03:21:49] <ohsix> anyone thats actually doing a technical review will find information wherever it is [03:21:58] <Dark_Shikari> ok, so mru [03:22:00] <Dark_Shikari> 1) write the blog post [03:22:08] <Dark_Shikari> 2) put a huge disclaimer at the top for idiots explaining what ogg is and isn't [03:22:11] <Dark_Shikari> i.e. ogg is not vorbis [03:22:12] <Dark_Shikari> ogg is not theora [03:22:13] <Dark_Shikari> ogg is ogg [03:23:18] <ohsix> peloverde: are you referring to sqlites use of fdatasync or ? [03:23:38] <peloverde> I'm referring to the fsync issue [03:24:03] <ohsix> ic, i thought they sorted that ages ago when they finally admitted it was real [03:24:06] <Yuvi> btw, I'll have a blog up at blog.yuvie.net soon, maybe I'll do a post on ogg problems [03:24:40] <peloverde> They made it better, but I'm pretty sure it's not all fixed [03:25:05] <peloverde> Last I checked firefox performed a lot worse than chromium for me when the disk was under load [03:25:23] <ohsix> hm, keen, only problem i've had with ff on lunix is that theres no nanojit for x86_64 in release builds yet [03:27:53] <DonDiego> Yuvi: do that.. [03:28:11] <DonDiego> Yuvi: also, how is your theora branch coming along? [03:28:52] <Yuvi> I wanted mike's comments on reworking the coeff decode, that's the most significant change I'm making and most further ones depend on it [03:29:01] <Yuvi> so I'll ping that later [03:29:22] <DonDiego> ping mike in private, iirc he does not follow the lists much [03:31:38] <astrange> i have to rewrite the vp3 patch in -mt, so [03:31:49] <astrange> i'd rather not merge until you commit that, otherwise i have to do it again again [03:34:12] <Dark_Shikari> yeah, the sooner that commit goes in the better [03:34:18] <Dark_Shikari> once the trees are fully merged I can start trying some optimizations [03:34:50] <astrange> that's merging the other way, not ready for that yet [03:35:11] <astrange> but i blew away most of the cosmetic stuff in the todo last week, so now i'm working on the important stuff [03:35:37] <Dark_Shikari> I meant for yuvi [03:38:52] <DonDiego> Yuvi: i think you should ask mike if he is ok with you taking over vp3/theora maintenance [03:38:57] <Dark_Shikari> agreed. [03:39:10] <DonDiego> my guess is that he will be ok with it [03:41:07] <DonDiego> Yuvi: another thing: have you compared performance with the binary vp3 decoder? [03:41:25] <DonDiego> i tested waaaay back and the vp3 binary used to be considerably faster [03:41:36] <DonDiego> but this was years ago... [03:47:11] <ohsix> why are wavelets a deadend? [03:48:01] <Yuvi> DonDiego: nope, it might be faster on ppc only because it has more altivec, but even then I'd be surprised [03:48:17] <Yuvi> I've heard libtheora was significantly faster [03:50:33] <DonDiego> i tested on x86 back then [03:50:43] <DonDiego> there is no ppc binary for vp3 iirc [03:50:59] <Yuvi> guess it was only a quicktime component [03:54:40] <ohsix> re: this vp8 thing and the ensuing comments; arguments from authority are weak on their face, and that other guy has sober and rational in spades [03:56:46] <peloverde> who is making the argument from authority? [03:59:54] <pengvado> ohsix: because wavelets make everything else harder. if the transform doesn't have well-defined edges, then you don't have places at which to switch coding modes. [04:00:28] <Dark_Shikari> ohsix: a few reasons [04:00:33] <Dark_Shikari> 1) nobody has found a good way to do intra coding [04:00:38] <Dark_Shikari> 2) nobody has found a good way to do variable partition size [04:00:44] <Dark_Shikari> 3) nobody has found a good way to make the transform's artifacts not look like shit [04:00:50] <Dark_Shikari> 4) nobody has found a good way to do spatial adaptive quantization [04:01:34] <mru> 1-4) nobody has found a way to make it work [04:01:43] <pengvado> actually, I don't think there's anything hard about spatial adaptive quantization in wavelets. [04:01:50] <Dark_Shikari> how would you do it? [04:01:57] <Dark_Shikari> how would you assign a differnet quantizer to each 8x8 block [04:02:00] <Dark_Shikari> if the wavelets were 128x128? [04:02:45] <pengvado> each wavelet coef has a position and a radius. if it's smaller than 8x8, take the qp from the one colocated block. if larger, take the average of all blocks it overlaps. [04:03:37] <Dark_Shikari> hmm. that could work. [04:03:43] <Dark_Shikari> weighted average, even better [04:04:11] <ohsix> pengvado: ah, thanks [04:04:25] <Dark_Shikari> ok, so 1-3), but not 4). [04:04:29] <ohsix> i was thinking of other uses than basic codec principle stuff [04:05:00] <pengvado> what other uses? [04:05:01] <ohsix> and cheers in explaining it in terms of wavelet properties that are relevant ;] [04:05:30] <pengvado> overcomplete wavelets for denoising? [04:05:46] <ohsix> motion estimation? dunno; multiresolution stuff for coder parameters [04:06:02] <Dark_Shikari> wavelets don't help you for multiresolution [04:06:11] <Dark_Shikari> only in intra coding, not in inter coding [04:09:27] <ohsix> this is all under the premise that "the multimedia commumity" considers wavelets a "dead end" ;] [04:11:56] <peloverde> Even in audio and still images wavelets have largely failed to deliver [04:12:25] <CIA-92> ffmpeg: michael * r22048 /trunk/libavcodec/ (h264.c h264.h): [04:12:25] <CIA-92> ffmpeg: Cut the size of mvd_table by yet another factor of 2. [04:12:25] <CIA-92> ffmpeg: The code read/write code itself was 1 cycle faster, overall its [04:12:25] <CIA-92> ffmpeg: likely more due to cache effects [04:13:14] <ohsix> but its not a foregone conclusion; that could change at any point in the future [04:14:57] <ohsix> anyways i'd just like to see the arguments to be more cogent if theres always going to be a rallying cry when some new blog posts comes out; i feel bad for some of these statements, i know some aren't from english speakers, or people subject to some concerns of the other commenters, but an argument from authority is always a fallacy [04:16:11] <peloverde> It could change in the future but historically people have proposed wavelet based solutions as saviors over and over again only to fall flat [04:16:50] <peloverde> At this point wavelets-as-a-magical technique has lost any credibility and wavelet based solutions need to stand on their own merits [04:17:20] <mru> the wavelet craze caught on after fractal compression had gone nowhere [04:17:23] <ohsix> and the people that may chime in to support someone they trust in experience here or withing the project; the "support" undermines any argument they could make, at least in support for another post; these other entities dont have the same trust & experience to these same people, the arguments have to be clean and technical [04:19:55] <pengvado> I agree with "the multimedia commumity considers wavelets a dead end", to a sufficient extent that when I flatly declare wavelets to be not worthwhile, I expect to only occasionally find people who are both interested in the technical details and not already know why wavelets suck. [04:20:28] <ohsix> hey fractal compression could make a comeback [04:20:30] <peloverde> then wavelet proponents need to make a "clean and technical argument" why a their new wavelet based codec will be more successful than conventional codecs, and if they just repeat the same argument as their forebears they need to explain why they will cross whatever hurdles their forebears failed to do so, until then wavelets will remain a buzzword that failed to deliver [04:20:53] <ohsix> yea they do need to make the argument [04:21:32] <pengvado> "even in audio"? what reason is there to expect wavelets to be any more appropriate to audio? [04:21:54] <ohsix> you can do doppler really easy and cheap with wavelets in simulations [04:21:57] <mru> fractal compression seemed fine, until it was discovered that the test image they were using was one of the mandelbrot set [04:22:21] <ohsix> along with other generation thingies that are well to do with multiresolution source samples [04:22:43] <peloverde> pengvado, T/F flexibility is one the biggest problems in hard to code audio samples [04:23:23] <peloverde> sharp attacks are basically very specific localization in time [04:23:29] <ohsix> one project i read the paper to used wavelets and vibrational modes to generate close to physically accurate sounds for virtual objects being struck/sounded in arbitrary configuration [04:24:45] <peloverde> So if you implement them say the way the AAC TF model does with the EIGHT_SHORT_SEQUENCE, diving up your frame into smaller windows, you wind up smearing everything else in frequency [04:25:51] <peloverde> In addition we aren't coding noisy residuals or doing intra prediction [04:26:50] <ohsix> oh boy i was reading pengvado and peloverde as the same person [04:27:31] <pengvado> oh, what's the status of prediction in audio coding? blue-sky research? everyone's given up? or what [04:27:53] <ohsix> pengvado: some readers might not even know what he's hinting at when he mentions wavelets, and might derail the thread _into_ that wavelet discussion [04:28:24] <peloverde> AAC introduced a main predictor that was a disaster for a variety of spec specific reasons [04:28:31] <peloverde> like mandatory use of half floats [04:28:47] <peloverde> or mandatory emulation of half floats [04:29:28] <peloverde> and in general it was very computationally intensive even with full floats [04:30:05] <peloverde> so it was more efficient just to not use it and dump more effort into a good scalefactor search [04:30:20] <ohsix> someone with a fetish for wavelets might do something interesting in the future with them; but you can pretty much write them off until they're appropriate, not even worth mentioning in that context imo [04:30:53] <peloverde> MPEG-4 introduced another predictor (the LTP) which was much simpler [04:31:30] <peloverde> I don't know what that one didn't take off, presumably it wasn't worthwhile as well [04:31:50] <peloverde> main predictor breaks frame accurate seeking, I presume LTP does as well [04:31:55] <peloverde> (I haven't touched LTP at all) [04:32:15] <peloverde> (At some point I plan on implementing it for libfaad2 compatibility) [04:32:37] <ohsix> i'm learning things, thanks chaps; this beats the blog post pileon any day [04:33:03] <peloverde> SBR also breaks frame accurate seeking but in a way that degrades nicely [04:33:16] <peloverde> In many ways SBR is actually an INTRA predictor [04:33:36] <peloverde> you are coding the HF in terms of the LF [04:34:12] <Yuvi> > interleave is a fairly recent feature in MKV [04:34:19] <Yuvi> there was such a thing as non-interleaved mkv? [04:35:05] <ohsix> you can just put stuff in arbitrary chunks, no? [04:35:06] <peloverde> I don't know what's going on in USAC these days [04:35:19] <ohsix> thats how fonts and stuff are embedded in mkv [04:35:20] <peloverde> I'd really like to see the current WD to see what they are up to [04:35:29] <Yuvi> ohsix: those don't have timestamps [04:35:36] <peloverde> things should be settling down by now [04:36:05] <ohsix> ah [04:37:16] <peloverde> In general USAC is a bit of a frankenstein codec the way MPEG-4 Audio with Scalability was envisioned except even more closely coupled so I wonder if their will be any sane subprofiles [04:39:18] <Dark_Shikari> ohsix: there's no real bias against wavelets; if someone proposed a reasonable way to solve any of wavelet coding's main problems, I think people would be very interested [04:39:49] <Dark_Shikari> people are biased against solutions that _don't_ claim to solve any of these [04:40:00] <Yuvi> then again, some people still think tarkin is the next-gen xiph codec [04:40:11] <Dark_Shikari> lol tarkin [04:41:11] <ohsix> i didn't mean to suggest bias; just appropriateness when you're trying to plead a technical case [04:42:04] <Dark_Shikari> I think there's significant benefit to be had in some of the MC ideas that have come from wavelet research [04:42:09] <Dark_Shikari> obmc/grid MC [04:42:23] <Dark_Shikari> and ds's idea, of arbitrary motion vector partitions [04:42:36] <Dark_Shikari> where you start with the whole frame, and split it into arbitrary rectangles step by step [04:42:42] <Dark_Shikari> allowing partitions to start and end on any boundary [04:50:47] <Dark_Shikari> since michael is reading the irc [04:50:53] <Dark_Shikari> thanks for that idea you just committed. I'm porting it to x264. [04:53:13] <Dark_Shikari> hmm I wonder if it's possible to port his ringbuffer model for cabac mvds... [04:56:43] <peloverde> that reminds me that there is some circular buffer stuff in SBR that I've been putting off [05:05:04] <pengvado> course it is. nnz too. [05:15:16] <Dark_Shikari> would need one per thread for sliced threads [05:15:20] <Dark_Shikari> like intra border backup [07:02:27] <Yuvi> hm, it seems like only aurel's mkv demuxers can handle unknown cluster sizes... [07:03:28] <kshishkov> excuse it for being robust [07:07:46] <Yuvi> http://userpages.umbc.edu/~dconrad1/streamed.mkv <- does that play for anyone outside of ffplay or mplayer? [07:10:05] <astrange> not in perian, mkvinfo, divx 7 player, coreplayer [07:10:11] <Dark_Shikari> haali? [07:10:33] <astrange> the last two hung so maybe they'll wake up [07:32:18] <KotH> moin [07:33:41] <astrange> never did wake up [07:34:02] <kshishkov> never in your life? [07:35:40] <Yuvi> not surprising, guess I'll just write one block per cluster [07:35:46] <Dark_Shikari> Yuvi: what are you writing? [07:36:08] <Yuvi> Dark_Shikari: making lavf's matroska muxer work better when streaming / piping [07:36:12] <Dark_Shikari> ah. [07:36:21] <Dark_Shikari> maybe you can write index support for x264's afterwards? ;) [07:36:27] <Dark_Shikari> or wait, Haali said he had that half done [07:36:55] <Yuvi> (since one of ogg's "strengths" is streaming) [07:37:07] <Dark_Shikari> lol [07:37:17] <Dark_Shikari> yeah, mkv _should_ work fine streaming [07:37:21] <Dark_Shikari> but a lot of existing implementations don't :/ [07:37:40] <Yuvi> like, all of them [07:37:43] <Dark_Shikari> Yeah [07:38:21] <astrange> mkvinfo thinks it has |+ (Unknown element: DummyElement; ID: 0xff size: 4152553056) [07:38:33] <Yuvi> yeah, dunno why [07:39:04] <Yuvi> it's valid, the only difference there between a non-streamed is that it uses the special unknown size [07:39:57] <Yuvi> which mkvinfo recognizes for the segment... [07:40:22] <Yuvi> vlc and gstreamer don't work (no surprise on the latter) [07:41:26] <Dark_Shikari> fix ffmpeg, fix vlc [07:41:31] <Dark_Shikari> then bitch at gstreamer for not supporting it [07:41:36] <Dark_Shikari> ;) [07:41:56] <Yuvi> didn't work with haali either I think [07:42:07] <Yuvi> ffmpeg already works fine [07:43:01] <Dark_Shikari> yell at haali [08:14:11] <siretart`> morning [08:20:04] <siretart`> ramiro: I've seen your request on -cvlslog, I'm still thinking about it [08:20:15] <siretart`> request for comment [08:25:49] <av500> Yuvi: it plays fine here :) [09:10:26] <CIA-92> ffmpeg: benoit * r22049 /trunk/libavformat/asf.c: [09:10:26] <CIA-92> ffmpeg: asf: add more entries to metadata conv table. [09:10:27] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail com [09:11:29] <CIA-92> ffmpeg: benoit * r22050 /trunk/libavformat/asf.c: [09:11:29] <CIA-92> ffmpeg: asf: indent. [09:11:29] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail com [09:44:05] <twnqx> i wonder if it's a good idea to map author to artist... what happens if you actually *mean* author? [09:45:01] <Dark_Shikari> and what about album artist vs song artist? [09:45:19] <Dark_Shikari> I have hundreds if not thousands of songs where album artist != song artist [09:45:45] <twnqx> dunno, id3v2 can handle that [09:46:07] <elenril> twnqx: there is no generic tag named author [09:46:28] <twnqx> but there should be! [09:46:43] <elenril> send patches [09:46:47] <twnqx> heh [09:46:50] * elenril doesn't see much point in having it [09:46:53] <twnqx> only if you fix mp4/mov [09:46:55] <elenril> Dark_Shikari: what about it? [09:47:14] <elenril> we have both album_artist and artist [09:47:50] <Dark_Shikari> oh, we do? guess that works. [09:47:55] <av500> Dark_Shikari: there is "WM/AlbumArtist" and "Author" in asf [09:47:58] <Dark_Shikari> good for comiket stuff. [09:49:10] <av500> elenril: btw, WM/TrackNumber is 1 based, WM/Track is 0 based :) [09:49:22] <av500> do we handle that? [09:49:31] <elenril> should we? [09:50:29] <av500> I think so, Track 1 is could come out as 0 or 1 if not [09:51:40] <av500> btw, could CIA-92 output clickable links into the SVN/GIT here? [09:52:12] <Dark_Shikari> svn web interface is down [09:52:20] <av500> git is up [09:52:53] <elenril> av500: send patches ;) [09:53:01] <av500> elenril: :) [09:53:11] * elenril already wasted too much time on asf [09:53:16] <av500> I might, I also have asf chapters rotting here [09:53:38] <elenril> asf supports chapters? [09:53:51] <elenril> funny i'm just adding chapters copying to ffmpeg [09:54:20] <av500> elenril: well, they call it markers, but in principle the same, you get a time and a name [09:54:36] <av500> I will clean up the patch... [09:54:45] <elenril> twnqx: btw in what situation would it make sense to have an 'author' and 'artist' tags [10:00:04] <twnqx> audio books, maybe [10:00:21] * elenril <3 how git can automagically detect patches applied upstream and skip them when rebasing [10:00:34] <twnqx> operas, where the actors are as important [10:06:20] * elenril would rather use performer/writer tags in these cases [10:12:11] <Dark_Shikari> siretart`: we picked a god-damn good revision didn't we. I just found yet another regression.... in r1449. [10:13:34] <twnqx> :S [10:27:07] * KotH thinks that more scientific publications should be written in german [10:28:23] <av500> auf jeden Fall! [10:29:01] * elenril thinks german is evil [10:29:42] * av500 performs 3v1l l4ugh [10:32:16] <KotH> Grundlagen der kombinatorischen Logik. American Journal of Mathematics [10:32:22] <KotH> somehow, i like the sound of that :) [11:03:15] <kshishkov> KotH: you had the time when most scientific publications were in German - before WWI [11:17:42] <KotH> kshishkov: before ww2 actually [11:17:47] <KotH> kshishkov: and some time after it too [11:18:06] <kshishkov> I doubt it a bit [11:18:06] <av500> I guess a lot of rocket science papers in german after ww2 :) [11:18:16] <av500> (for internal use only) [11:18:44] <kshishkov> av500: nah, rocket scientists were divided between USA and USSR [11:18:49] <KotH> math papers were written mostly in german until 50s [11:19:03] <av500> kshishkov: thats what I meant actually :) [11:21:39] * KotH wonders whether one should start a journal that is written in iotic [11:22:17] <kshishkov> with the shortest Greek letter only? [11:23:54] <KotH> en.wikipedia.org/wiki/Iotic [11:24:33] <kshishkov> Sindarin is more traditional [11:27:48] <KotH> but can you discuss the relativity theory in sindarin? [11:28:08] <kshishkov> merbzt: vet du hur många kostar bananer i Sverige? [11:28:26] <kshishkov> can you discuss it any other language than math? [11:28:48] * kshishkov thinks German language is good only for philosophical discussions [11:43:06] <siretart`> Dark_Shikari: :-) [12:14:46] <lu_zero> hi [12:15:05] <lu_zero> roundup is being moved to wsgi [12:15:21] <lu_zero> hopefully that should make it faster [12:37:31] <siretart`> hi Diego! [12:45:56] <elenril> when adding new options to ffmpeg.c i only have to document it in doc/ffmpeg.1, right? [12:46:35] <siretart`> if you expect users to find them, that might be a good idea [12:52:24] <CIA-92> ffmpeg: michael * r22051 /trunk/libavcodec/h264.h: unroll tiny and trivial loop. Same speed but clearer. [13:08:42] <lu_zero> sigh [13:08:51] <lu_zero> ok, I give up =_= [13:09:04] <lu_zero> wsgi+roundup -> KaBoom [13:09:31] <lu_zero> it's too underdocumented to have it working w/out trying with a from scratch test [13:28:16] <KotH> wgsi? [13:28:41] <kshishkov> wery shaky gateway interface, I suppose [13:29:40] <phaidros> hi [13:30:19] <kshishkov> KotH: why this channel topic cantains nothing about ignoring greetings? [13:30:28] <phaidros> :D [13:31:01] <phaidros> just wanted to ask if ffmpeg has any fixed point audio encoders aboard [13:31:43] <phaidros> (asked before in #ffmpeg, but I believe here is the way better place to ask taht) [13:31:53] <kshishkov> yes, aLaw/uLaw [13:32:29] <kshishkov> and G.726 [13:32:41] <phaidros> kshishkov: are they suitable for music? [13:33:05] <kshishkov> not very much [13:33:13] <av500> adpcm? [13:33:44] <kshishkov> ADPCM does not use floats in any representation [13:34:21] <phaidros> hm, looking for any possiblity to make live streaming possible from a non-fpu plattform [13:34:42] <Kovensky> libtremor? [13:34:54] <kshishkov> Kovensky: it's for decoding only IIRC [13:35:09] <Kovensky> ic [13:35:15] <Kovensky> I thought they ported the whole thing [13:35:50] <kshishkov> xiph.org mainpage: "Tremor: Fixed-point decoder" [13:35:53] <phaidros> ack [13:36:02] <phaidros> just cralwed through there .. [13:36:10] <phaidros> well, there is a codec from xiph - celt - which is fixed point, but stll very much in development [13:36:23] <Kovensky> celt is also optimized for voice [13:36:28] <Kovensky> so it won't work for music [13:36:28] <phaidros> irks [13:36:47] <phaidros> darn. so, no way for doin such a thing? [13:36:57] <kshishkov> sonic may work [13:37:13] <Kovensky> wavpack? :) [13:37:31] <kshishkov> that too [13:37:38] <phaidros> ok, I'll give it a shot [13:38:01] <av500> phaidros: IMA adpcm gives you 1:4 compression at almost 0 cpu [13:38:03] <phaidros> so, basically, I could encode it on the device, deliver it to ffserver and there re-encode? [13:38:18] <phaidros> av500: kay, so I'll try that first :) [13:38:25] <av500> if you can live with ~300kbit/s audio, it is not bad [13:38:47] <phaidros> fair enouhg for almost all state of the art internet use cases [13:38:56] <Kovensky> wavpack OTOH is the slowest audio compressor I've touched... but I use it on highest settings lol [13:39:50] <kshishkov> Kovensky: that means you've touched nothing else, I think. Flac compressor is pretty slow IMO. And APE... [13:40:09] <Kovensky> reference flac encoder is p. fast, even on highest [13:40:15] <Kovensky> ffmpeg with -use-lpc 8 however is SLOOOOW [13:40:43] <lu_zero> ok [13:40:46] <Kovensky> and I never used ape ._. [13:40:53] <lu_zero> roundup had been fixed and updated [13:40:55] <kshishkov> but better than official Flac encoder nevertheless [13:41:10] <lu_zero> please try it a bit and report back if something isn't working as should [13:41:13] <kshishkov> lu_zero: you forgot to say for which time [13:41:19] <Kovensky> I have got higher bitrates with -compression_level 12 -use_lpc 8 than with just -compression_level 12 [13:41:31] <lu_zero> kshishkov: which time? [13:41:52] <kshishkov> lu_zero: like "roundup had been fixed and updated for the fifth time" [13:42:19] <kshishkov> Not found: roundup/ffmpeg/ [13:44:23] <lu_zero> kshishkov: switched to be saner... [13:44:29] <lu_zero> roundup.ffmpeg.org [13:44:36] <lu_zero> now I'll put a redirect [13:49:11] <lu_zero> kshishkov: I added a redirect [13:49:23] <lu_zero> so older urls will be still valid [13:49:30] <kshishkov> seems to be slow but works [13:49:30] <kshishkov> thanks, I'm too lazy to update bookmark [13:49:41] <lu_zero> please test that as well [13:49:43] <lu_zero> ^^ [13:50:37] * lu_zero checks who is messing up with the server [13:50:48] <kshishkov> lol, it redirects to ffmpeg.roundup.org [13:51:36] <kshishkov> lu_zero: in my experience it's usually women and janitors who mess with servers [13:54:13] <lu_zero> meh [13:54:27] <Compn> what? no managers ? [13:54:42] <Compn> 'if we turn this off at night, we can save money!' [13:55:04] <lu_zero> fixing the typo... [13:55:28] <kshishkov> no, it's usually janitors "_everything_ should be turned off at night" [13:55:53] <kshishkov> managers issue a policy which can be ignored [13:57:18] <phaidros> av500: which of the adpcm variants do you think is ok ? [13:57:28] <av500> we use 4bit IMA adpcm [13:57:36] <phaidros> k [13:57:39] <lu_zero> seems working [13:57:41] <kshishkov> almost everybody uses it [13:57:58] <phaidros> ok [13:58:07] <kshishkov> lu_zero: yes, it seems so [13:58:11] <phaidros> this one then: adpcm_ima_dk4 [13:58:58] <kshishkov> lu_zero: except that it inserts second slash in URL after host name [13:59:14] <kshishkov> phaidros: it's nonstandard [13:59:45] <phaidros> kshishkov: puh, ok, still got to get familiar with ffmpeg, never used it before *duck* [14:00:13] <kshishkov> phaidros: funny you mention that, it's Duck ADPCM actually [14:00:24] <phaidros> :D [14:01:19] <kshishkov> use adpcm_ima_wav [14:01:29] <phaidros> ok [14:01:39] * kshishkov still has to fix that issue with adpcm_ima_qt [14:03:08] <phaidros> phew, your man page is huge. [14:03:20] <kshishkov> good [14:03:28] <CIA-92> ffmpeg: michael * r22052 /trunk/libavcodec/ (h264.c h264.h): [14:03:28] <CIA-92> ffmpeg: Store intra4x4_pred_mode per row only. [14:03:28] <CIA-92> ffmpeg: about 5 cpu cycles slower in the local code but should be overall faster [14:03:28] <CIA-92> ffmpeg: due to reduced cache use. (my sample though has too few intra4x4 blocks [14:03:28] <CIA-92> ffmpeg: for this to be meassureable easily either way) [14:03:44] <phaidros> no clue, how to find quickly the comand line to capture from line-in and stream to remote server .. it'll take some time :) [14:04:00] <kshishkov> ask at #ffmpeg [14:07:28] <lu_zero> kshishkov: ok [14:24:00] <phaidros> hm, where do I find out which settings a certain codec accepts? eg. adpcm_ima_wav which bandwidths etc .. [14:24:51] <av500> bandwidth? [14:24:55] <kshishkov> it's fixed [14:25:06] <av500> it is a fixed 1:4 reduction [14:25:16] <av500> a 4bit codec, so 16bit gets encoded to 4bits [14:25:50] <phaidros> ok [14:27:06] <CIA-92> ffmpeg: michael * r22053 /trunk/libavcodec/ (h264.c h264.h): [14:27:06] <CIA-92> ffmpeg: Reorder intra4x4_pred_mode so that we can read/write 4 values at once. [14:27:06] <CIA-92> ffmpeg: 3-7 cpu cycles faster [14:29:45] <janneg> memtest86 with more than 4G is annoying, is there a memtest86_64? [14:29:54] <kshishkov> could be [14:30:42] <kshishkov> memtest86+ for example [14:31:41] <av500> janneg: hmm my q8800 box has only 4g too :( [14:32:26] <janneg> av500: my phenom has now 6G [14:32:31] <kshishkov> my four boxes have 3G [14:32:37] <kshishkov> total [14:33:19] <janneg> I guess that means kshishkov can't help rendering Big Bug Bunny [14:33:39] <av500> janneg: the qvga version maybe [14:33:57] * kshishkov can dedicate his SheevaPlug for that when he's not transcoding h264 to something less CPU-hungry [14:34:05] <Kovensky> rendering it smaller doesn't save much ram, it saves a lot of cpu though [14:34:10] <av500> kshishkov: to libaa? [14:34:37] <kshishkov> av500: mpeg2 [14:35:25] <BBB> lol @ libaa [14:35:27] <janneg> fuck, errors [14:36:04] <kshishkov> BBB: if you make TMV encoder, it'll become reality [14:38:35] <janneg> Kovensky: yes, the tiled renderer failed also with OOM [14:41:41] <ramiro> siretart`: ok, thanks for letting me know. it seemed to me all release-related discussion was going to /dev/null. [14:43:34] <BBB> kshishkov, no [14:43:39] <BBB> kshishkov, I'd rather do VP8 or so [14:43:46] <BBB> at least then I learn something useful and fundable [14:43:54] <kshishkov> I doubt so [14:44:06] <kshishkov> and VQ is pretty powerful stuff [14:44:39] <siretart`> ramiro: no, they are not. I am just increadibly busy this week, but fortunately, my paper deadline was extended by two weeks. this means I was able to finish testing the libx264 patch and therefore committed it [14:45:16] <siretart`> ramiro: currently I have a debian bug reopened with a number of security issues that I need to verify, then I think the RELEASENUMBER thing is the last blocker for 0.5.1 [14:47:18] <BBB> ramiro, shall I handle conceiva? [14:54:42] <mru> Yuvi: your mkv file works fine on the archos tablet [14:54:57] <av500> mru: yes :) [14:55:22] <CIA-92> ffmpeg: michael * r22054 /trunk/libavcodec/h264.h: Simplify intra4x4_pred_mode_cache init. [15:04:41] <janneg> memtest86+ is indeed faster but still not native 64bit. at least the new memory seems to be fine [15:13:17] <BBB> dondiego: any opinions on what to do with conceiva? do you agree with carl eugen? [15:28:46] <CIA-92> ffmpeg: michael * r22055 /trunk/libavcodec/h264.h: [15:28:46] <CIA-92> ffmpeg: Store data in direct_table interleaved. [15:28:46] <CIA-92> ffmpeg: seems 20cpu cycles faster [15:30:01] <CIA-92> ffmpeg: michael * r22056 /trunk/libavcodec/h264.c: Dont allocate direct_table 8 times too large. [15:31:12] <DonDiego> BBB: looks *very* suspicious [15:31:26] <DonDiego> i haven't followed the details [15:31:49] <DonDiego> we could give them the benefit of the doubt and ask them what they were thinking [15:32:05] <DonDiego> but it might well be just a case to hand over to the lawyers.. [15:34:38] <DonDiego> maybe ping them one more time and give them the benefit of the doubt [15:45:29] <BBB> ok [15:45:31] <BBB> I'll try it then [15:45:44] <mru> Yuvi: and now my mkv demux handles that file too [15:46:10] <mru> I hadn't bothered to add simpleblock before [15:46:19] <mru> about time I did though, those files are getting common [15:47:21] <DonDiego> "your" demux? [15:47:23] <DonDiego> tcvp? [15:47:28] <mru> yes [15:47:39] <mru> archos uses that demux btw [15:48:00] <DonDiego> go figure.. [15:48:01] <mru> av500 added the 2 lines for simpleblock himself [15:48:01] * KotH senses some evil influence at archos [15:48:13] <av500> mru: I did [15:48:22] <DonDiego> mru: ogg blog post pending :) [15:48:28] <mru> I didn't realise it was _that_ easy to do [15:48:29] <av500> and I even offered you patches [15:49:02] <mru> you wanted things in return [15:49:13] <av500> it compiling, yes [15:49:28] <mru> it does compile, after a fashion [15:49:40] <av500> I dont follow fashions [15:50:04] <mru> neither do I anymore [15:50:13] <mru> the makefiles need rewriting [15:50:27] <mru> fortunately that's mostly a matter of rewriting the script that writes them [15:53:04] <av500> whatever you like, if it results in a configure file in the end [15:53:20] <KotH> apropos configure file, what about ffconf? [15:53:26] <mru> it's related [15:53:44] <av500> KotH: before we do ffcc? [15:54:01] * KotH wouldnt mind an ffcc [15:54:22] <av500> we need it for ffcpu.... [15:54:22] * KotH wonders whether mn could be pestered enough to start it [15:54:39] <KotH> ffcpu is more difficult, because that would require ffhdl too [15:54:54] <av500> and ffphysics [15:55:08] <mru> phphysics? [15:55:10] <KotH> ffphysics is easy, just c&p from the next textbook ;) [15:55:36] <kshishkov> just show me local opensource semiconductor fab [15:55:48] <av500> fffab [15:56:20] <kshishkov> ok, just tell me when I can move to FFearth in FFuniverse [15:58:18] <KotH> kshishkov: you dont want an oss fab [15:58:25] <av500> no, you have to stay in ogg/country, I am sorry [15:58:40] <KotH> kshishkov: even if all OSS fanatics chipped in, it would be way too expensive [15:58:57] <KotH> and you'd need people who are engineering types, not religious, to get it working [16:00:42] <kshishkov> well, if can choose from Theora-style fab and FFmpeg-style fab you know what I choose ;) [16:01:33] <mru> gates arranged in hilbert order? [16:01:56] * kshishkov prefers dragon curve x 4 [16:18:59] <janneg> has anyone started working on broadcom crystal hd decoder support? [16:19:14] <kshishkov> talking or developing? [16:19:34] <av500> talking to pets and plant ok, but to chips? [16:19:38] <janneg> developing. talking is cheap [16:20:02] <kshishkov> av500: what is bus for? [16:20:35] <janneg> electro shocks [16:20:54] <av500> bus? [16:21:07] <kshishkov> PCI, 1-wire, whatever [16:23:03] <janneg> memory seems to be okay now after reseting BIOS settings [16:25:45] <ramiro> BBB: yes, thank you. [16:32:23] <DonDiego> ramiro: about conceiva_ [16:32:23] <DonDiego> ? [16:32:32] <mru> deceiva... [16:32:48] <Compn> janneg : doubt it, someone offered some money for such a thing on -devel [16:33:00] <Compn> so if anyone wanted to take that job, he/she should reply to that message [16:39:12] <CIA-92> ffmpeg: benoit * r22057 /trunk/libavformat/asfdec.c: [16:39:12] <CIA-92> ffmpeg: asfdec: don't strip the "WM/" prefix, this should be done during conversion. [16:39:12] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas gmail com [16:40:26] <BBB> benoit-, can you apply his other 2 also? [16:40:32] <BBB> (thanks!) [16:44:15] <benoit-> BBB: I'm in the process of doing it [16:46:53] <BBB> benoit-, thanks! [16:47:20] <BBB> (otherwise he'd ask me to do it later today :) ) [16:48:30] <benoit-> :) [16:48:50] <kshishkov> you can ignore this like all others did [16:51:20] <CIA-92> ffmpeg: benoit * r22058 /trunk/libavformat/asfenc.c: [16:51:20] <CIA-92> ffmpeg: asfenc: simplify writing of comment header. [16:51:20] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas gmail com [16:54:42] <benoit-> kshishkov: when I can, I prefer when there are not a hundred approved patches lying around [16:55:14] * mru just wishes michael would unbreak the build [16:57:42] <av500> mru: I just had an excoworker ask me to help unbreak it :) [17:00:52] <CIA-92> ffmpeg: benoit * r22059 /trunk/libavformat/asfenc.c: [17:00:52] <CIA-92> ffmpeg: asfenc: write tags in proper UTF-16. [17:00:52] <CIA-92> ffmpeg: Patch by Anton Khirnov wyskas gmail com [17:16:29] <ramiro> Yuvi: http://ffmpeg.arrozcru.org/forum/viewtopic.php?f=8&t=1299 [17:16:39] <ramiro> Yuvi: I don't know if it makes any sense. Just reporting. [17:38:13] <mru> http://pastebin.ca/1810424 [17:39:13] <av500> mru: nice [17:39:20] <av500> saves you all the base13 stuff [17:45:47] <janneg> 42 [18:35:09] <_av500_> janneg: lol @ the eye scene :) [18:37:04] <_av500_> is there a reason ff is capped at 2kx2k? [18:37:33] <_av500_> that's so 00s [18:37:59] <mru> who's capped? [18:38:11] <janneg> xv with my intel GMA3100 is capped to 2k^2 [18:38:25] <kshishkov> overlays are always capped [18:38:27] <mru> my nvidia seems a bit unhappy too [18:38:52] <_av500_> mru: swScaler: Compile-time maximum width is 2048 change VOF/VOFW and recompile [18:38:56] <kshishkov> BTW, what's with internal swscale buffer limiting width to some constant? [18:38:57] <janneg> -vo gl2 works [18:39:23] <mru> _av500_: there's a compile-time limit for performance reasons [18:39:42] <mru> increasing it also slows things down, at least on some systems [18:39:48] <mru> and >2k is kinda rare [18:39:50] <CIA-92> ffmpeg: michael * r22060 /trunk/libavcodec/svq3.c: [18:39:50] <CIA-92> ffmpeg: fix compilation, sorry ive not checked cvslog for a while :((( [18:39:50] <CIA-92> ffmpeg: svq3 decoder does not work yet though but i didnt want to keep compilation [18:39:50] <CIA-92> ffmpeg: broken longer [18:39:53] <kshishkov> since it's swscaler there are also legacy problems [18:40:12] <kshishkov> mru: for movies only, that's why FFmpeg is not ImageMagick replacement yet [18:42:38] <CIA-92> ffmpeg: michael * r22061 /trunk/libavcodec/svq3.c: [18:42:38] <CIA-92> ffmpeg: svq3 now in working condition, at least vissually, ill let fate tell us [18:42:38] <CIA-92> ffmpeg: if the checksums match [18:44:05] <mru> kshishkov: true [18:44:54] <kshishkov> could be good to have some fallback solution for huge images [18:44:54] * Dark_Shikari points to coreavc's 2048 compile-time limit [18:45:15] <kshishkov> BTW, 4x4 Binks can't be scaled too [18:46:17] <Dark_Shikari> lol [18:46:34] <kshishkov> you can try it [18:47:22] <kshishkov> http://samples.mplayerhq.hu/game-formats/bink/thps4/Snd0a3a2ad4.dee [18:49:45] <elenril> o_0 so many patches applied and i didn't have to do anything [18:50:16] <kshishkov> try doing something bigger next time [18:50:23] <elenril> :effort: [18:50:37] <elenril> and i'd have to know c/how to program for that [18:50:42] * kshishkov has started with REing simple decoders [18:51:22] <janneg> elenril: the time machine is already finished? [18:54:41] <kshishkov> machine for extending time should be ebough [19:07:56] <phaidros> kshishkov: I prefer pausing time [19:10:43] * kshishkov has lost his time remote controller [19:15:09] <BBB> elenril, during my first programming, I kept wondering why sprintf(); did take a variable number of arguments but gtk_button_set_label() did not... point being, programming can be learned [19:15:31] <BBB> I kept trying to compile gtk_button_set_label(button, "%s", some_argument); [19:15:36] <BBB> it did not work :-( [19:17:12] * kshishkov had his first programming under DOS [19:21:41] <phaidros> av500: streaming kindof with adpcm_ima_wav runs, gets served ass ogg on ffserver, but no data coming through [19:22:52] <phaidros> does anything here look suspicious? ffmpeg -f alsa -ar 16000 -ac 2 -i hw:0,0 -acodec adpcm_ima_wav http://some.host:8090/feed1.ffm [19:23:45] <kshishkov> maybe it expects some video too? [19:23:58] * kshishkov does not know ffserver [19:37:54] <Yuvi> mru: av500: nice [19:38:15] <Yuvi> turns out vlc will work if you add a fake cluster of size 0 at the beginning [19:38:15] <Yuvi> but [19:38:21] <Yuvi> that doesn't fix anything else [19:38:47] <Yuvi> ramiro: vlc and mplayer really need to learn to seek in indexless files :/ [19:38:48] <Yuvi> I'll fix that though [19:39:48] <CIA-92> ffmpeg: stefano * r22062 /trunk/doc/faq.texi: Replace not anymore valid syntax "-title X" with "-metadata title=X". [19:40:05] <mru> Yuvi: I didn't try seeking [19:40:42] <Yuvi> I don't expect seeking to work with unknown cluster sizes [19:41:01] <Yuvi> that'd require a linear scan from where you are [19:51:36] <DonDiego> j-b: what does vlc use for vorbis decoding? [19:51:48] <DonDiego> j-b: ffvorbis is faster than libvorbis.. [19:52:06] <j-b> it has both [19:52:26] <DonDiego> what is the preferred one? [19:52:32] <j-b> but I believe libvorbis is still the prefered one [19:52:59] <j-b> confirmed [19:53:17] <j-b> but more and more packager are not packaging the vorbis module anymore [19:54:50] <DonDiego> what about switching to ffvorbis? [19:54:51] <DonDiego> :) [19:54:56] <DonDiego> as i said, it's faster.. [19:55:15] <mru> and not xiph-encumbered [19:55:25] <DonDiego> haha :) [19:55:27] <j-b> well, what is clear, is that it won't happen now, before 1.1 [19:55:37] <DonDiego> oh, no hurry [19:55:42] <j-b> but it will come [19:55:43] <DonDiego> but what do you think about the idea? [19:55:50] <kshishkov> VLC 1.1 or FFmpeg 1.1? [19:55:54] <CIA-92> ffmpeg: stefano * r22063 /trunk/ (doc/libavfilter.texi libavfilter/Makefile tools/graph2dot.c): [19:55:54] <CIA-92> ffmpeg: Add the graph2dot tools and document it. [19:55:54] <CIA-92> ffmpeg: Also link avfiltergraph.o and graphparser.o against libavfilter, as it [19:55:54] <CIA-92> ffmpeg: uses them. [19:56:10] <j-b> especially since fenrir fixed a few issues in the avcodec module for vorbis/theora [19:56:14] <j-b> lately [19:56:17] <mru> kshishkov: 1.1 is when we've conquered the moon too [19:56:22] <j-b> kshishkov: VLC 1.1.0 is in feature freeze [19:56:56] <j-b> the thing is I am not so sure about vorbis 5.1 and 7.1 in both decoders [19:57:12] <DonDiego> do you have samples? [19:57:33] <peloverde> I thought superdump took care of taht for ffvorbis [19:58:05] <j-b> problem is not ffvorbis, it is likely to be our module calling ffvorbis [19:58:13] <j-b> that might screw the audio channels [19:58:45] <Yuvi> didn't they change the spec as to the channel mapping? [19:58:53] <Compn> downsampling ? [19:59:23] <j-b> Yuvi: yeah, but I didn't follow it [19:59:41] <j-b> mru: the problem is not really vorbis. Problem is ogg and theora [19:59:49] <Yuvi> hehe [19:59:57] <mru> vorbis is also full of flaws [20:00:31] <peloverde> vorbis's flaws (at least the ones i know of) are largely fixable with a few minor changes, a vorbis 1.1 if you will [20:00:38] <ohsix> lets not forget x86's flaws, we need to start at the root fo the problem and throw it all out [20:01:42] <mru> peloverde: yes, they're mostly fixable [20:01:51] <ohsix> then again, leakage increases with smaller geometry transistors; you dont have leakage problems with abacusii' [20:03:00] <Yuvi> grr I hate trying to figure out which of the dozen gstreamer packages has the module I'm looking for randomly shoved in [20:03:06] <j-b> mru: like all codecs [20:03:24] <j-b> mru: but vorbis has less flaws than ogg, if I could compare [20:04:05] <ohsix> Yuvi: huhu and they move around too :> [20:05:04] <mru> the silliest thing in vorbis is that it can't be correctly decoded if not stored in ogg [20:05:20] <Yuvi> this is only the third time I've tried, and I wasn't convinced I found the right module the first two times [20:05:37] <Yuvi> (after looking through several thousand lines of boilerplate) [20:06:02] <peloverde> mru: What about vorbis in mkv? [20:06:13] <ohsix> theres a toplevel file that says whats in each but i dont remember what it was [20:06:26] <peloverde> or are you saying it's not real vorbis because the screw with the header packets? [20:06:57] <mru> peloverde: nothing in the vorbis setup data tells how many samples to discard from the start of the first frame [20:07:22] <peloverde> shouldn't that be container specific data anyway [20:07:23] <mru> you're supposed to divine that by comparing the number of actual output samples with the end timestamp from the ogg container [20:07:39] <mru> so you can't output a single sample until you've decoded the entire first page actually [20:08:06] <peloverde> I see that more as an ogg flaw than a vorbis flaw [20:08:20] <mru> huh? [20:08:22] <mru> it's both [20:08:32] <peloverde> For AAC the codec doesn't tell you how many samples to discard, you are suppsoed to get it from the contaienr editlist [20:08:40] <mru> a piece of required informatino is not specified by the codec [20:08:53] <mru> then aac as the same flaw [20:09:07] <ohsix> required for what; doing something a certain way? its different but it doesn't mean its wrong [20:09:46] <mru> any codec with incomplete setup data is broken imo [20:10:36] <peloverde> It seems simpler for the container to specify a consistent way to do it for all codecs than for each codec to come up with it's own scheme [20:10:52] <ohsix> their deal is like; they split something thats normally in one layer into 3, like how stuff can be put in mpeg-ts being split into 2 layers; so the same junk can be used in several use cases while at least the 3 layers are the same [20:11:41] <ohsix> raw bitstreams for some scenarios will be completely useless; they're supposed to have the other thing on top for that usage [20:12:35] <peloverde> In the context of AAC you can't even playback a raw bitstream without sending side information to the decoder manually [20:12:42] <mru> having a setup blob to be communicated out of band is fine [20:12:58] <mru> relying on external framing is fine too [20:13:19] <mru> anything beyond that is questionable [20:13:46] <ohsix> its just my understanding; i'm indifferent, it makes some assumptions that you can nearly never hold for commercial bits you might want to include in the container, but it also assumes all the open bits can be available [20:14:03] <peloverde> I think relaying on external editlists is fine as well [20:14:11] <mru> I don't [20:14:16] <mru> few containers have them [20:14:18] <ohsix> its viral in some sense that you need to care that vorbis is in a basic stream :> [20:14:38] <ohsix> don't those help with editing stuff in the containers? [20:15:15] <ohsix> like for vorbis you can cleanly put partial pages into a stream, which are really whole pages, but the edit point can cross them partially [20:18:24] <ohsix> it seems to me they might be trying to solve too many problems at once, but it also keeps you from picking possibly something proprietary "for purpose" for some specific usage scenario that their same project doesn't cover [20:18:56] <ohsix> like it might all be well and good to use these native formats until you need to stream it to the web; then you have to pick something outside & suited for that [20:20:27] <ohsix> mpeg does the same sort of thing except they have tons of standards and will fill behind or offer something else to cover the parts missing when something new comes out, and the other guys basically had to bootstrap themselves somehow [20:21:30] <mru> the mpeg video codecs are entirely self-contained [20:21:59] <ohsix> yea but for different usage scenarios you stay in their ecosystem [20:22:10] <mru> I don't get your point [20:22:15] <mru> or even that you have one [20:22:37] <ohsix> any sort of usable alternate solution would have to have some complete ecosystem to draw from for any solution, instead of going to another one (mpeg) to furnish their use-case [20:23:00] <mru> I don't understand what you're trying to say [20:23:15] <mru> vorbis and aac rely on an obscure container field to be decoded correctly [20:23:41] <DonDiego> maybe we should create that vorbis 1.1 :) [20:23:47] <peloverde> Editlists are hardly obscure [20:24:04] <mru> they are obscure if a minority of containers have them [20:24:06] <DonDiego> trolling at its perfection :) [20:24:17] <mru> and they're needlessly complicated for the job [20:24:31] <mru> a single small integer is all you need to specify [20:24:41] <peloverde> Two small integers [20:24:51] <mru> two? [20:25:15] <peloverde> extra samples at the begining and extra samples at the end [20:25:24] <mru> ok then [20:25:25] <mru> two [20:25:29] <mru> hardly a big deal [20:25:34] <mru> edit lists are much more complicated [20:25:53] <ohsix> i'm just trying to elaborate on why they do things differently; they needed to provide their own ecosystetm with a least cost approach, and that makes the thing more complex than it needs to be to account for every case, but they dont have the luxury of having other bits to bring in _for_ every possible use case, and i'm talking about ogg, not vorbis in particular [20:26:14] <mru> ohsix: you are not making any sense whatsoever [20:26:15] <peloverde> because things like chapers may also dump you mid frame? [20:26:19] <DonDiego> there was no need for them to invent their own container [20:26:38] <DonDiego> there were plenty of general-purpose ones around [20:26:52] <peloverde> What does the ogg approach solve that they couldn't have done with the mov approach or the mkv approach? [20:26:58] <ohsix> DonDiego: yea there was, they needed to create an alternate and feasible ecosystem [20:27:24] <mru> DonDiego: do you understand what he's blathering about? [20:27:39] <ohsix> some people dont think you can just pick the best bits from wherever they're available; there are technical and legal reasons that might be involved [20:27:48] <DonDiego> not for containers [20:28:07] <DonDiego> legal issues exist for codecs [20:28:17] <Yuvi> DonDiego: unfortunately, back when vorbis was first created, the only general-purpose containers were avi and mov [20:28:24] <DonDiego> but for containers the motivation was NIH, nothing more, nothing less [20:28:26] <ohsix> so what do you have if you have all the codecs and stuff free; but then you shove it into a container of someone elses purview? [20:28:33] <Yuvi> the former can't handle vorbis at all [20:28:33] <DonDiego> so? [20:28:42] <DonDiego> ohsix: yes [20:29:06] <Yuvi> the latter won't ever have a complete parser outside of classic quicktime [20:29:12] <DonDiego> you also store it on filesystems you did not write [20:29:19] <ohsix> that doesn't sit right; you should be able to do things within their ecosystem and without proprietary bits [20:29:32] <DonDiego> and stream it over protocols you don't control [20:29:50] <Dark_Shikari> duh, we need an ogg filesystem [20:29:53] <DonDiego> there is nothing proprietary about avi or mov or other containers [20:29:59] <Dark_Shikari> great idea. we'll have no index, of course [20:30:07] <Dark_Shikari> you'll have to binary search the disk to find any file [20:30:14] <Yuvi> Dark_Shikari: they were talking about adding a gzipped index [20:30:17] <Dark_Shikari> Yuvi: yeah I know [20:30:25] <Dark_Shikari> they were also talking about Tarkin [20:30:31] <Yuvi> hehe [20:30:31] <Dark_Shikari> xiph likes to talk about things. [20:30:42] <Yuvi> and multithreading libtheora! [20:30:46] <BBB> Dark_Shikari, I saw a "discussion" on mozillazine, was that you? [20:30:56] <Dark_Shikari> I don't post there [20:31:07] <ohsix> you are leaving the ecosystem if you are looking for a 3rd party container format; you should be able to do that, fine. but the internal bits in the ecosystem should still exist [20:31:21] <peloverde> And now that mov is 20 years old, why do they stick with ogg? [20:31:27] <DonDiego> you also use a third-party compiler [20:31:28] <Dark_Shikari> BBB: I assume you saw my blawg though [20:31:46] <BBB> let me see [20:31:51] <ohsix> DonDiego: you aren't trolling a blog post here :< [20:31:51] <DonDiego> there is no need to reinvent existing wheels (badly) [20:32:04] <DonDiego> you are the troll [20:32:17] <Dark_Shikari> BBB: it got linked on HN, reddit, daring fireball, and a few dozen more [20:32:21] <ohsix> DonDiego: the compiler is not part of the usage of the software, it is not part of the "media" ecosystem, the problems the software purports to solve [20:32:34] <ohsix> DonDiego: you are mistaken, you keep bringing up strawmen arguments [20:32:41] <DonDiego> ogg does not solve any problem at all [20:33:01] <DonDiego> and i'm not bringing up any straw men (feel free to point them out) [20:33:01] <ohsix> ogg is something in their ecosystem; for their formats to be in; that solves their problem [20:33:01] <peloverde> ohsix: simply what was the problem that ogg solved that mov did not? [20:33:03] <Dark_Shikari> ohsix: why is the container part of the usage of the software, but the protocl is not? [20:33:06] <Dark_Shikari> *protocol [20:33:08] <Dark_Shikari> explain. [20:33:20] <BBB> Dark_Shikari, I never read any of those [20:33:23] <DonDiego> there is no need to create an ecosystem [20:33:23] <BBB> but interesting read [20:33:28] * BBB should make a planet FFmpeg [20:33:30] <DonDiego> there is a need to create free codecs [20:33:35] <ohsix> DonDiego: strawmen: 12:31 <@DonDiego:#ffmpeg-devel> you also use a third-party compiler [20:33:37] <peloverde> ohsix: They also didn't invent PCM but they have no problem with that in their ecosystem [20:33:54] <peloverde> they didn't invent FLAC but they welcomed that into their ecosystem [20:33:55] <Yuvi> peloverde: branding! [20:33:57] <DonDiego> those codecs can go in whatever container [20:34:09] <ohsix> btw, the point of the starwman is to argue over the strawman, and that is exactly what is occuring with these kinds of digressions [20:34:15] <Dark_Shikari> ohsix: you have yet to answer my question [20:34:21] <peloverde> or mine? [20:34:23] <Dark_Shikari> Why is the container part of the ecosystem, but the protocol is not? [20:34:28] <ohsix> DonDiego: there is a need to create a reasonable and alternate ecosystem [20:34:32] <Dark_Shikari> Why are PCM and FLAC allowed in their ecosystem? [20:34:35] <Dark_Shikari> They didn't make them. [20:34:43] <ohsix> you might say theres no point to the exercise at all if there isn't [20:34:46] <DonDiego> alternative containers are reasonable [20:34:48] <Dark_Shikari> If you cannot answer these questions, we will assume you are trolling. [20:34:55] <DonDiego> so there is no need to recreate them [20:35:03] <Yuvi> did they settle on a way to put pcm in ogg? I thought that was left as an incomplete draft [20:35:11] <DonDiego> i fully understand the need to write vorbis and theora [20:35:35] <DonDiego> unlike what other people claim i *never* questioned it [20:35:52] <mru> Dark_Shikari: flac has an obnoxious raw format so that was acceptable to them [20:35:55] <Dark_Shikari> mru: lol [20:36:03] <peloverde> I agree vorbis serves a need, theora serves a need... poorly [20:36:04] <DonDiego> of course you will want to have free sw implementations for containers [20:36:11] <DonDiego> but these already existed [20:36:33] <ohsix> Dark_Shikari/peloverde: you guys aren't trolling, DonDiego does this on the blog posts and threads and its counterproductive; its not even a discussion that should be had or have any energy wasted on, and he does so unconvincingly and in a manner that undermines whatever point he might have [20:36:45] <Dark_Shikari> ohsix: But you still haven't answered our questions. [20:36:54] <Dark_Shikari> I don't care about diego [20:36:58] <Dark_Shikari> You haven't answered our questions. [20:37:02] <Dark_Shikari> You're dodging them. [20:37:26] <DonDiego> ohsix: which blog posts and threads? [20:37:36] <ohsix> no, i'm simply talking to one person, you cant insert yoursel finto a conversation and just demand things if you want to be taken seriously [20:37:51] <Dark_Shikari> um [20:37:51] <mru> dude, this is irc... [20:37:52] <Dark_Shikari> this is IRC [20:37:54] <Dark_Shikari> lol [20:38:00] <Dark_Shikari> "talking to one person" "IRC channel" [20:38:04] <DonDiego> lol [20:38:07] <Dark_Shikari> If you want to talk to one person, feel free to take it to a PM [20:38:08] <ohsix> peloverde: poorly or not its a separate conversation :> [20:38:10] <DonDiego> ok, i'll ask the questions then [20:38:10] <Dark_Shikari> Do you want to talk to one person? [20:38:27] <Dark_Shikari> I could evacuate you from this channel then ;) [20:38:32] <DonDiego> ohsix: what is in ogg that is not available elsewhere? [20:38:35] <Dark_Shikari> then you could talk directly to one person ;) [20:39:04] <ohsix> as to peloverde asking about MOV, it was besides my own point about the alternate software ecosystem, so it as factually offtopic (though apparently i'm not making my point well) [20:39:33] <ohsix> a dogpile is not an effective rhetorical tool btw, if you had points; they are lost on me [20:39:37] <DonDiego> there is no need to create a complete alternate universe [20:39:40] <ohsix> and probably any unbiased reader [20:39:54] <ohsix> DonDiego: that is an opinion [20:40:07] <DonDiego> lol [20:40:07] <ohsix> which i actually agree with [20:40:20] <DonDiego> what was your point again then? [20:40:25] <BBB> it's NIH... we all suffer from it [20:40:25] <ohsix> but that is not the rationale behind having an alternate ecosystem, which also has merit [20:40:26] <BBB> so do they [20:40:28] <BBB> let's leave it [20:40:48] <DonDiego> and which blog posts and threads do you refer to? [20:41:05] <ohsix> DonDiego: you have no interest in understanding whatever point i could have possibly been making for the last half hour; asking me to repeat it is a strawman, my "posts" as it were are still there [20:41:24] <DonDiego> i have interest in understanding [20:41:29] <DonDiego> however, you do not answer questions [20:41:43] <DonDiego> how do you expect anybody to understand this way? [20:42:01] <ohsix> again, you essentially haven't asked an on topic question that i have not addressed according to the point i was trying to make originally [20:42:09] <DonDiego> also, i'm not asking you to repeat: i'm asking for specifics [20:42:30] <DonDiego> let me see... [20:42:40] <iive> ohsix: you have addressed the question, but diego haven't understood it. try again. [20:42:44] <ohsix> i want you to be more effective in trying to express your viewpoints; the only reason i _care_ is that you spend a lot of time just flaming people [20:42:46] <DonDiego> 21:40 <@DonDiego> and which blog posts and threads do you refer to? [20:43:09] <ohsix> for the sake of argument, all of them; you know that is another logical fallacy right [20:43:29] <DonDiego> no, i want to know what you have read and what you are referring to [20:43:37] <DonDiego> why can't you answer a simple question? [20:43:58] <DonDiego> i want you to be more effective in getting whatever point you have across [20:44:05] <DonDiego> so far you are failing miserably [20:44:24] <DonDiego> i'm still talking to you because i'm interested to hear those points [20:44:43] <ohsix> the way you may have asked that is "why dont you answer my questions in the manner i want you to", i'm being extremely clear what i'm trying to address with the way you are communicating _right now_ [20:45:04] <ohsix> you are badgering me and trying to force your point by mass of force [20:45:10] <DonDiego> nonsense [20:45:20] <ohsix> "why aren't you answering my questions" is the only real question you have [20:45:29] <Yuvi> anyone know when microsoft first released asf? [20:45:36] <DonDiego> i repeat: what threads and blog posts? [20:45:55] <DonDiego> you refuse to give any details [20:46:01] <Dark_Shikari> OK, let's have a summary here. Ogg was useful at the time because neither AVI or MOV could stream. DonDiego is being way overzealous. ohsix is being an utter jackass troll as usual and completely ignoring every question he can't answer. Both people should be kicked for a short period of time to cool down. [20:46:05] <ohsix> point of fact; had i answered any question you would have missed it; and imo, you have already; so at least to this one unbiased observer your rhetorical style has failed to convince [20:46:30] <DonDiego> do you think any person will accept a criticism of the type "you are behaving wrongly, change" without any further details? [20:46:36] <ohsix> i'm not hot man, let me say again that i'm just worried that the way DonDiego communicates undermines his own cause and points [20:46:45] <Dark_Shikari> ohsix: and the way you communicate doesn't? [20:46:52] <Dark_Shikari> seriously, holy shit, you come off as a jackass with every phrase [20:46:56] <Dark_Shikari> you attack your opponent's method of arguing [20:47:01] <Dark_Shikari> instead of attacking his actual point [20:47:01] <ohsix> i'm being extremely clear [20:47:10] <Dark_Shikari> you don't answer any questions anybody asks of you [20:47:14] <Dark_Shikari> you are a waste of air. [20:47:15] <DonDiego> i disagree, you are not clear [20:47:24] <DonDiego> i'm tryint to understand you and i fail [20:47:26] <Dark_Shikari> But I think this has gone on too long. [20:47:30] <Dark_Shikari> both of you need a break. [20:47:39] <ohsix> you have a point there; except i am answering questions, but with the reams of comments you are expecting me to field; and with nobody giving my comments even due consideration, you have to agree that its tough to keep up [20:48:03] <DonDiego> stop complaining, get back on topic [20:48:19] <ohsix> i'm actually assessing everything people have to say, but inbetween the time a question is posed and an answer is expected is less than 2 lines, or i'm "not answering questions" [20:48:24] <DonDiego> if you want to change my style you will have to be more specific [20:48:40] <Dark_Shikari> can you two take this to a PM? [20:48:45] <DonDiego> we have heard you [20:48:46] <DonDiego> stop complaining, get back on topic [20:48:49] <ohsix> i'm being extremely _pedantic_ in every manner which your rhetorical style falls flat to an unbiased observer [20:49:30] <DonDiego> well, that settles it [20:49:37] <Dark_Shikari> I think you should have been kicked too. [20:49:39] <Dark_Shikari> you are not helping. [20:49:59] <DonDiego> i was trying to stay on topic [20:50:10] <DonDiego> and not flaming him harder than any of you [20:50:10] <Dark_Shikari> staying on topic would be /ignore ing ohsix [20:50:23] <DonDiego> you are right there [20:50:43] <DonDiego> but everybody else would have earned a kick that way.. [20:50:56] <mru> I was talking about the aac and vorbis needing unusual container features, when he started blathering about ecosystems [20:51:09] <DonDiego> right [20:51:31] <mru> I wasn't even talking about ogg [20:51:46] <iive> is this ohsix from xiph ? [20:52:15] <Dark_Shikari> it's like that south park episode [20:52:18] <Dark_Shikari> "this is what xiph actually believes" [20:52:50] <mru> we should commission them do an episode [21:08:15] <Compn> oh i missed flamewar [21:09:38] <mru> not a good one [21:10:38] <Dark_Shikari> let's start a good one then [21:10:43] <Dark_Shikari> MKV is better than MP4. Start now., [21:13:24] <mru> an mkv demuxer is actually easier to write [21:13:36] <mru> but it could have been better [21:15:21] <elenril> Dark_Shikari: is mp4 superior to mkv in anything? [21:15:55] <Kovensky> the only benefit I see in mp4 is that it has broader hardware support, but that's an implementation artifact, not a design advantage [21:15:58] <Compn> someone suggested to use mov up there any no one called him on it ? [21:16:27] <Compn> peloverde said that heh [21:16:58] <peloverde> I said that because mov was well established when vorbis was first publically released [21:17:28] <peloverde> mkv didn't exist until the end of 2002 [21:17:29] <mru> mov is horrible [21:17:40] <mru> mp4 is the non-horrible core of mov [21:17:58] <Yuvi> elenril: mp4 has precise timestamps, mkv forces a single timebase for the entire file and you can't accurately represent most timebases in mkv's scheme anyway [21:18:21] <Compn> arguing containers isnt very productive anyways [21:18:29] <mru> and don't forget the 3 different ways of packing frames in a block [21:18:30] <Compn> how did you guys let michael break svn ? :P [21:18:46] <Compn> shouldnt fate send svn breakages to -devel ? [21:18:53] <Compn> was that a requested feature or did we ignore that ? [21:19:19] <Compn> 'danger' 'danger' 'svn is broken! in rXXXXX' [21:19:47] <Kovensky> danger, will robinson! [21:19:53] <Kovensky> er, michael! [21:20:46] <Kovensky> Yuvi: mkv supports nanosecond timing [21:21:03] <mru> Kovensky: so? [21:21:11] <Kovensky> ... dunno [21:21:26] <mru> if my timebase is 1000000+1/3 ns, that still won't do it [21:21:36] <Yuvi> Kovensky: it doesn't support a timebase of say 1001/30000 [21:21:57] <mru> supporting arbitrary fractions is easy [21:21:59] <BBB> all mkv movies that I've seen are rips from another source [21:22:01] <mru> and covers everything [21:22:04] <BBB> be that mp4, dvd or something else [21:22:10] <mru> I've never seen 10*pi fps [21:22:20] <BBB> mkv will never be superior if its source suffers from all these deficits that it's said to try to fix [21:22:38] <BBB> </flame> [21:23:06] <mru> mkv, like so many other things, aims too high [21:23:11] <mru> it's trying to be all at once [21:23:38] <mru> it should at least define common subsets [21:24:13] <mru> so you know which parts can safely be skipped in an implementation [21:24:47] <mru> and if possible make files play back sensibly when fancy features are ignored [21:24:56] <mru> not the case with chapters for instance [21:25:05] <mru> since they can be specify a non-linear playback sequence [21:25:08] <mru> for no good reason [21:25:26] <Kovensky> there is a good reason: because we can [21:25:28] * Kovensky ducks [21:25:44] <_av500_> mru: Yuvi: no we do not seek in mkv if no index [21:26:01] <Kovensky> o_O [21:26:49] <_av500_> as we come from deep embedded with little mem and a small window into a large file on a possibly slow mass storage device [21:27:01] <_av500_> so, no index, no seek [21:28:13] <CIA-92> libswscale: stefano * r30729 /trunk/libswscale/yuv2rgb.c: Apply consistency nit. [21:28:13] <CIA-92> libswscale: stefano * r30730 /trunk/libswscale/utils.c: Remove pointless empty line. [21:28:20] <_av500_> wrt flame, wasnt ogg all about having 0.002% overhead? [21:28:53] <Yuvi> nah, it has more overhead than anything other than ts [21:29:07] <Yuvi> nut was about lowest possible overhead though [21:29:11] <Yuvi> partly [21:30:01] <_av500_> lowest overhead: mandate fixed sized a and v frames and strict 1:1 interleaving :) [21:30:08] <Dark_Shikari> that's high overhead [21:30:10] <Dark_Shikari> it requires padding [21:30:17] <Dark_Shikari> it just moves the overhead. [21:30:27] <_av500_> the container comes clean :) [21:31:02] <_av500_> crossbreed raw YUV and WAV/PCM :) [21:31:29] <iive> nut doesn't mandate fixed size a/v frames. [21:31:39] <_av500_> iive: no, that was my proposal :) [21:32:04] <iive> anyway, mp4 subtitle support is kind of troublesome. [21:32:11] <iive> mkv is better at that. [21:33:05] <mru> iive: there's nothing in mp4 that makes subtitles inherently hard [21:33:32] <iive> mkv supports external segments. many think of this as disadvantage. [21:33:58] <mru> it's a whole new can of worms [21:34:09] <mru> and mp4 can do such nonsense too [21:34:13] * _av500_ does not support that and has yet to hear a complaint [21:34:42] <iive> _av500_: just join #mplayer. [21:34:53] <_av500_> :) [21:35:15] <elenril> iive: it's worse than that [21:35:25] <elenril> matroska has three different kinds of linking [21:35:50] <Yuvi> external segments are a bit easier to support in mp4/mov because the main file indexes everything, you only need to treat the additional files as different data sources [21:35:55] <elenril> everybody uses ordered chapters, but still... [21:36:02] <mru> matroska's motto: there are 3 ways to do it [21:36:25] * _av500_ likes the "broken index, divide all by 10000000" ones [21:36:38] <iive> mru: tell me more about the subtitles. formats etc. [21:36:40] <mru> Yuvi: yeah, external files are just instead of mdat blocks [21:36:54] <iive> btw, does mp4 support fourcc or llong codec descriptions? [21:41:43] <iive> _av500_: btw, about the fixed size frames... ogg already does that! [21:42:34] <janneg> libcrystalhd is ugly and C++ [21:42:52] <mru> is that from bcm? [21:43:07] <mru> bcm can't write software [21:43:21] <mru> and they use visual sourcesafe [21:43:31] <_av500_> mru: add marvell, nxp, ti... [21:43:32] <janneg> yes [21:43:48] <mru> _av500_: very few hw companies can do sw [21:43:57] <mru> intel are actually good at it [21:44:06] <mru> and they can do good hardware too [21:44:24] <_av500_> they will rule the pc business then one day... [21:44:38] <mru> x86 instruction set aside, their cpus are pretty damn good [21:44:42] <janneg> CamelCase of more than 7 words make my eyes bleed [21:44:51] <mru> of course the best bits were stolen from DEC [21:44:58] <_av500_> CamelCaseCaravan [21:45:25] <mru> do you know where CamelCaseCameFrom? [21:45:38] <_av500_> hell? [21:46:47] <_av500_> NoIDontKnowWhereItCameFromButIWishItWentBackThere [21:47:25] <Kovensky> CamelCaseIsActuallyConsideredGoodStyleInPopAndCuteLanguagesLikeJava [21:47:33] <drv> from_somebody_without_underscore_keys? [21:47:51] <_av500_> pwzstrAndTookStupidHungarianWithIt [21:48:29] <Kovensky> _av500_: pwsz* [21:48:42] <Kovensky> actually, lpwsz [21:48:46] <_av500_> Kovensky: I got carried away... [21:48:51] <Kovensky> :) [21:49:28] <_av500_> pwszZeroTerminatedWideStringPointer ftw [21:49:34] <Kovensky> I still facepalm when I remember Chen saying "How do I know he didn't double-null-terminate that string? Because his variable is pszVar, not pszzVar." [21:49:55] <mru> apparently some old xerox machine had no _ on the keyboard so people were forced to invent workarounds [21:50:08] <_av500_> double null for extra safety? [21:50:12] <mru> becausecamelcaseisstilleasiertoreadthannothing [21:50:21] <Dark_Shikari> Kovensky: Cheeeeeeeeeeeeeeeeeeeeeeeeeen! [21:50:24] <Kovensky> _av500_: no, cheap way to get string arrays [21:50:28] <Kovensky> Dark_Shikari: oh you [21:50:40] <_av500_> pszzzzzzzzzzzzEmptyString? [21:50:43] <Kovensky> _av500_: string1\0string2\0string3\0\0 [21:50:54] * _av500_ cries [21:50:59] <mru> that's not a string array, that's a string list [21:51:12] <mru> and not unreasonable in some situations [21:51:28] <_av500_> Kovensky: without tripple null, how do you fit edit lists and externals? [21:51:39] <mru> 2d arrays [21:52:05] <mru> s00\0s01\0\0s10\0s11\0\0\0 [21:52:39] * _av500_ writes xml to n-null terminated string converter [21:53:02] <Kovensky> .k _av500_ no: xml [21:53:09] <Kovensky> :> [21:53:41] * _av500_ writes ogg to n-null terminated string converter~ [21:53:47] <Kovensky> D: [21:53:58] * Kovensky throws eggs at _av500_ [21:54:04] <Kovensky> egg > ogg [21:54:08] * mru writes xml2ogg xslt [21:54:24] <_av500_> Kovensky: for what definition of >? [21:54:27] * Kovensky 's head asplodes [21:54:56] <Kovensky> _av500_: test -gt [21:55:11] * _av500_ proposes punycode for metadata tags instead [21:55:43] <_av500_> artist: Bjrk-lol [21:56:03] <Kovensky> wat [21:56:19] <_av500_> artist: Mns-ftw [22:09:26] <saste> are you guys using git for committing stuff to ffmpeg? [22:09:37] <saste> my working copy is getting messier and messier every day [22:09:49] <saste> and I feel the need to start to work with branches [22:10:00] <mru> many of us use git [22:10:00] <saste> the last time I did and attempt with git I gave up [22:10:07] <mru> git svn clone svn://... [22:10:22] <mru> it'll take a while to clone but then you'll love it [22:10:27] <saste> because I failed to find some way to work with stack of patches [22:10:39] <saste> yep I already did that :-) [22:11:02] <saste> well I mean it is safe enough to *commit* using git2svn and what is it ... [22:11:05] <saste> I suppose so [22:11:21] <mru> sure [22:11:36] <saste> I'm pretty used to how quilt works [22:11:44] <mru> just prepare the commits you want to send in a branch and git svn dcommit [22:11:56] <saste> ok [22:12:13] <saste> what about guilt / st-git [22:12:18] <mru> never used [22:12:23] <mru> git branches work fine for me [22:12:49] <DonDiego> saste: you should register your nick [22:13:37] <mru> he did [22:13:42] <mru> he just hasn't identified [22:14:26] <mru> and you should use irssi, not xchat :-) [22:14:26] <saste> give me some mintue... [22:14:47] <mru> does xchat support sign-on scripts? [22:15:08] <saste> the first I tried ... I was tempted to irc from emacs but then my emacs session is messed up enough [22:15:29] <saste> mru: maybe [22:15:46] <mru> there are a few emacs irc clients [22:15:55] <saste> but as you know i'm quite an irc newbee and not very motivated into mastering it (no time) [22:15:56] <Rathann> mru: yes it does [22:17:00] <Rathann> mru: put "LOAD -e path/yourscript" (path is relative to $HOME) in connect command [22:17:44] <Rathann> but if you just want to identify with nickserv, it has direct support for that too [22:18:19] <mru> Rathann: I don't care about xchat, saste seems to be using it [22:18:39] <Rathann> saste: ^ [22:22:19] <saste> Rathann: thanks I'll try that later [22:23:03] <peloverde> Dark_Shikari, is psyrd on by default? [22:23:26] <Dark_Shikari> yes [22:23:33] <Dark_Shikari> as are a lot of other psy things [22:24:01] <peloverde> Just curious because I was lookign at this comparison: http://keyj.s2000.ws/?p=356 [22:24:19] <Dark_Shikari> some stupid psnr thing? [22:24:45] <peloverde> SSIM [22:24:57] <Dark_Shikari> x264 should use --tune ssim for that [22:25:03] <peloverde> I agree [22:25:19] <peloverde> but even so, x264 still manages to destroy everything [22:25:36] <astrange> the ffmpeg2/4 encodes are missing chroma me [22:25:40] <mru> how'd they manage to push theora so high? [22:25:49] <mru> it should be much closer to mpeg2 [22:25:53] <Dark_Shikari> mru: they added AQ [22:26:10] <Dark_Shikari> AQ is like magic for SSIM [22:26:12] <astrange> and scplx_mask, though that was never really effective [22:26:44] <mru> lavc mpeg2 encoder can do really well if you tune it right [22:26:52] <mru> and very, very poorly with bad (aka default) settings [22:27:03] <Dark_Shikari> mru: it doesn't have vaq [22:28:20] <Yuvi> I wonder how they managed to get dirac to be faster than x264 at any preset faster than placebo [22:28:48] <Yuvi> even using schro [22:28:52] <astrange> lavc mpeg2 has really bad blocking... [22:29:02] <peloverde> yeah [22:29:02] <Dark_Shikari> lavc mpeg2 just sort of sucks [22:29:06] <Dark_Shikari> no psy optimizations [22:29:43] <peloverde> How does QuEnc compare to lavc mpeg-2 these days? [22:29:51] <Dark_Shikari> hcenc is the best iirc [22:29:56] <peloverde> yes [22:30:02] <peloverde> but quenc is a fork of lavc [22:30:03] <Dark_Shikari> it's written in fortran [22:30:08] <Dark_Shikari> (lol) [22:30:54] <mru> whatever the likes of bbc use is pretty good [22:31:04] <Dark_Shikari> >bbc [22:31:05] <Dark_Shikari> >good [22:31:07] <Dark_Shikari> have you SEEN their TV lately? [22:31:13] <mru> no [22:31:37] <mru> I've only watched the odd program on iplayer [22:31:43] <mru> and that's a different story entirely [22:32:17] <mru> but works and is easier than hunting stuff down on tpb [22:32:35] <Yuvi> trellis 2 I guess [23:07:26] <kierank> back in the mpeg-2 sd days anything involving scrolling graphics lead to massive blocks [23:08:31] <mru> shouldn't simple scrolling be _trivial_ to code? [23:08:38] <mru> if MVs are long enough [23:08:54] <mru> i.e. theora is out [23:08:59] <kierank> lol [23:10:38] <Yuvi> as long as they move a multiple of subpel I guess [23:11:00] <mru> how would they *not* do that? [23:25:56] <iive> mru: bruteforce ME [23:27:09] <mru> unless an idiot made the animation, motion would be in integral pixels [23:27:32] <mru> anything else would look horrible [23:28:43] <CIA-92> ffmpeg: mru * r22064 /trunk/common.mak: [23:28:43] <CIA-92> ffmpeg: Disable suffix rules [23:28:43] <CIA-92> ffmpeg: Most of the make builtin rules, which we do not need, are suffix rules, [23:28:44] <CIA-92> ffmpeg: and we use only new-style pattern rules. Disabling suffix rules saves [23:28:44] <CIA-92> ffmpeg: some time when building on slow systems. [23:28:50] <iive> in these days, animation was made on film, like everything else. [23:29:26] <mru> I thought he was talking about scrolling stock tickers and the like [23:29:38] <mru> computer-rendered all the way [23:31:03] <iive> graphics [23:31:37] <mru> if it's on a raster display, it's graphics [23:31:47] <mru> as opposed to a text-only display [23:32:17] <iive> well, sharp edges and big uniform areas are hard for some algorithms.that relay on gradual improvement when getting closer to correct values. [23:33:21] <mru> if there's an exact match for MC to work on there shouldn't be many problems [23:33:30] <mru> as long as you spend enough bits on the keyframes [23:34:03] <iive> it would be problem is how to find the exact match [23:34:19] <mru> oh god, is this the day of idiots on this channel? [23:35:28] <ohsix> i presume you mean me; thanks again [23:35:32] <mru> Dark_Shikari: btw, speaking of AQ... has anyone experimented with using multiple quant matrixes and switching per MB? [23:35:35] <iive> do you know how ME works? [23:35:35] <ohsix> classy :) [23:36:05] <iive> ohsix: btw, what is the url od diego's blog? [23:36:11] <iive> od/of [23:36:20] <mru> he doesn't have one afaik [23:36:23] <ohsix> no idea, didn't know he had one [23:36:34] <mru> the troll was talking about comments on other blogs [23:37:20] <ohsix> who? what [23:37:37] <ohsix> i'm getting the distinct feeling of passive aggressive behavior where even aggressive behavior isn't warranted [23:37:58] <mru> ohsix: you accused DonDiego of trolling in blog comments [23:38:01] <Dark_Shikari> mru: scrolling text is a bitch for algorithms without qpel [23:38:13] <mru> ohsix: you refused to provide a reference [23:38:28] <mru> Dark_Shikari: even with full-pel scrolling? [23:38:37] <Dark_Shikari> That rarely happens [23:38:47] <Dark_Shikari> most scrolling is not fullpel [23:38:48] <ohsix> mru: i did not, thanks for knowing all the facts before casting aspersions yo [23:39:03] <ohsix> if you have anything thats not a personal attack i'll still look at it as such [23:39:58] <mru> 20:36 < ohsix> Dark_Shikari/peloverde: you guys aren't trolling, DonDiego does this on the blog posts and threads and its counterproductive [23:40:02] <mru> so there [23:40:30] <ohsix> yea [23:40:40] <ohsix> you still dont know whats going on; so drop it please [23:40:45] <Dark_Shikari> mru: with quant matrix per qp: theora supports that [23:40:49] <ohsix> i understand that you might not like me personally, but that is off topic [23:40:51] <Dark_Shikari> every QP has a custom quant matrix [23:40:54] <Dark_Shikari> that's how QPs are _defined_ [23:41:00] <Dark_Shikari> so the quantizer scaling is arbitrary [23:41:03] <mru> ohsix: you're a big, fat, lying troll, that's what's going on [23:41:23] <Dark_Shikari> however, IMO, in the general case, CQMs are not very useful because most of their effect (if not more) can be performed via rounding differently [23:42:09] <mru> oh, I thought the qp values were just scaling the same matrix differently or something [23:42:59] <mru> I haven't looked at those things in detail since before ffh264 supported cqm [23:43:26] <DonDiego> mru: leave ohsix be, we've had enough for tonight [23:43:42] <mru> mpeg2 certainly has only one matrix each for intra and inter frames [23:44:20] <mru> begone [23:44:29] <Dark_Shikari> mru: it differs between theora and h264 [23:44:32] <Dark_Shikari> in theora, every QP defines a CQM [23:44:37] <Dark_Shikari> in h264, every QP scales the CQM [23:44:46] <mru> oh, so I wasn't entirely mistaken... [23:44:47] <Dark_Shikari> thus theora is more flexible--but since it only allows 3 QPs per frame, it sorta sucks imo [23:44:54] <mru> yeah [23:45:00] <Dark_Shikari> if the two were combined, it woudl be very powerful [23:45:03] <Dark_Shikari> well, if someone had an idea of what to do with it [23:45:14] <mru> that's what I meant [23:45:32] <CIA-92> ffmpeg: michael * r22065 /trunk/libavcodec/ (6 files): [23:45:32] <CIA-92> ffmpeg: Get rid of mb2b8_xy and b8_stride, change arrays organized based on b8_stride to [23:45:32] <CIA-92> ffmpeg: ones based on mb_stride in h264. [23:45:32] <CIA-92> ffmpeg: about 20 cpu cycles faster overall per MB [23:46:17] <iive> actually 2, inter/intra luma/chroma, indeed, not per qp [23:46:27] <Dark_Shikari> and one per chroma plane [23:46:30] <Dark_Shikari> you can differ between U and V iirc [23:46:38] <iive> mpeg2 i mean.

1 0

IRC log for 2010-02-24
by irc＠mansr.com 25 Feb '10

25 Feb '10

[00:35:29] <felipec> it looks like H.263 and H.264 parsers are doing half the job (not really updating the fields they parse): http://article.gmane.org/gmane.comp.video.ffmpeg.devel/104777 [00:40:13] <felipec> are there bitstream regression tests for H.263, H.264 and MPEG-4? if so, where are the streams? [00:40:26] <Dark_Shikari> there are tons of regression tests for the decoders [00:41:29] <felipec> Dark_Shikari: cool, that's what I thought :) but I can't seem to find the data [00:41:40] <Dark_Shikari> http://fate.multimedia.cx/ [00:42:06] <Dark_Shikari> http://www.mediafire.com/download.php?mi2zjoynymi has 90 megs of regression test files [00:46:46] <felipec> Dark_Shikari: thanks [00:46:52] <felipec> downloading [00:46:58] <Dark_Shikari> note there are no hashes with them. [00:47:07] <Dark_Shikari> You can generate the hashes by using JM and hashing the output YUV files. [00:49:30] <felipec> Dark_Shikari: JM? [00:49:35] <Dark_Shikari> the official reference decoder [00:49:48] <Dark_Shikari> though you're not testing the decoder [00:49:53] <Dark_Shikari> so you probably don't need the hashes [00:50:46] <felipec> Dark_Shikari: well, I want to test the parsers... so testing the decoders would be a good start [00:51:11] <Dark_Shikari> the decoders are tested automatically by fate [00:52:38] <felipec> Dark_Shikari: yeah, but if I modify the parser and fate finds out that the decoder is broken, that would help :) [01:09:59] <J_Darnley> If I wanted to get a commit reverted, should I discuss as a reply on -cvslog or on -devel? [01:12:33] <Dark_Shikari> cvslog [01:13:47] <Kovensky> >cvs [01:17:56] <J_Darnley> okay, thanks [01:38:35] <troy_s> Anyone know why I keep getting "libavformat/allformats.c:175: error: ‘CONFIG_RTSP_MUXER’ undeclared (first use in this function)" errors with SVN? [01:38:52] <mru> make config [01:39:26] <troy_s> mru: Then make alone I assume? [01:39:37] <mru> yes [01:39:46] <mru> make config reruns configure with same flags as last time [01:39:53] <troy_s> mru: You are terrific sir. Thank you kindly. [01:40:10] <troy_s> mru: So every svn up I need to follow with a make config correct? [01:40:34] <mru> only when new stuff is added to config.h [01:41:25] <Honoome> mru: does make -j14 config all work? :P [01:41:43] <mru> not sure [01:42:02] <mru> probably not [01:42:33] <mru> there's no dependency between config and other stuff [01:43:44] <ohsix> is that the same target thats run when maintainer mode is enabled and the build files need to be regenerated? [01:43:59] <mru> eh? [01:44:04] * ShadowJK is starting to suspect the bottleneck for screencapture is in x11grab rather than the video codecs [01:44:04] <mru> this ain't autohell, dude [01:44:51] <ramiro> ShadowJK: what does profiling say? [01:45:33] <Honoome> (forced) maintainer mode is one of the worst features in autotools [01:45:46] <ramiro> I still don't know what maintainer mode is... [01:47:31] <Honoome> ramiro: basically it adds rules so that changing any of the “original” files (Makefile.am, configure.ac) rebuilds the involved autotools “automagically” and eventually re-run ./configure [01:47:50] <mru> including cryptic failure at the end [01:48:25] <Honoome> unfortunately this breaks in a looot of cases [01:48:35] <Honoome> not only it might very well fail to rebuild anything if the autotools aren't available [01:48:35] <Honoome> sometimes it tries to rebuild with a slightly-different version of autotools because distributions package different versions [01:48:41] <ramiro> Honoome: ah, so that's why when I type make it configures again... [01:48:47] <Honoome> other times it fails because the versions don't match [01:49:23] <Honoome> and finally, since autotools developers can't work their shit together, and every distribution has its own wrapper to support multiple automake (and autoconf) versions, they can even rebuild the stuff with *totally different* versions [01:49:29] <Honoome> ramiro: yeppers [01:50:20] <Kovensky> the best thing is when an upstream package comes with a broken configure script [01:50:45] <Honoome> Kovensky: don't get me started [01:50:49] <Yuvi> my favorite use of autotools is mozilla's [01:50:51] <Honoome> I could start ranting now and finish next week [01:50:52] <Kovensky> < Honoome> (forced) maintainer mode is one of the worst features in autotools <-- it is forced? D: [01:50:56] <Kovensky> I thought only autogen enabled that [01:51:12] <Honoome> Yuvi: NOOOOOOOOO >_< please don't even name that one! it's real autoshit! It's still based on autoconf 2.13!! >_< [01:51:22] <Yuvi> Honoome: hehe [01:51:26] <Kovensky> lol [01:51:35] * Kovensky maintains an autotools-based build system ._. [01:51:47] <ramiro> Kovensky: what for? [01:51:52] <Honoome> Kovensky: uhm see here's the catch: a long time ago, it wasn't available; then they added AM_MAINTAINER_MODE that _allowed_ it optionally [01:51:53] <Kovensky> ffms2 [01:52:18] <ramiro> Kovensky: you're an ffms2 developer too? [01:52:20] <Honoome> then they decided that it was too variable, and made it _the default_ without any way to disable it *unless* you call AM_MAINTAINER_MODE, which then adds you the *option* to turn it off [01:52:42] <Kovensky> ramiro: not really, I just do build system stuff [01:52:55] <Kovensky> Honoome: ._. [01:53:03] <Honoome> Kovensky: I started writing this ;) http://www.flameeyes.eu/autotools-mythbuster/index.html I actually think autotools can work fine… but upstream sucks at getting their shit together [01:53:04] <ramiro> Kovensky: last time I tried ffms2 it was cmake, why do you do autotools-based stuff? [01:53:20] <mru> Honoome: upstream sucks, and all the users suck [01:53:21] <Kovensky> ramiro: because the cmake stuff was very broken [01:53:37] <Dark_Shikari> ramiro: they swapped away from cmake [01:53:39] <mru> cmake is _more_ broken than autohell [01:53:58] <Honoome> mru: most of… not all of it… and it's still better than half the custom build systems out there, or those based on scons, imake, cmake, … [01:53:59] <Kovensky> the best part of cmake is option passing [01:54:01] <Kovensky> there is none [01:54:03] <ramiro> Dark_Shikari, Kovensky: oh, nice choise. going from cmake to autotools =) [01:54:08] <Kovensky> unless you use a variable [01:54:18] <Kovensky> -D VARIABLE_NAME:type=value [01:54:30] <Kovensky> and there is no way to know what are the variables without reading source [01:54:33] <Honoome> cmake had the chance to learn about the mistakes about autotools usage both up- and down- stream and get it right [01:54:44] <Honoome> they didn't do that :| [01:54:54] <ohsix> configure scripts are generated files; usually only generated for disttribution, you're supposed to bootstrap it yourself if its from source control [01:55:06] <Dark_Shikari> ramiro: I'm not an ffms dev >_ [01:55:09] <ramiro> ohsix: not in FFmpeg... [01:55:39] <Honoome> I'm curious to see what Nokia will do with their buildsystem instead… not that I'd like to depend on Qt… but it might get some people re-think about cmake if they do it right [01:55:46] <ramiro> Dark_Shikari: but you're a strong supported... You should point them away from those bad choices... [01:55:53] <ramiro> s/supported/supporter/ [01:56:04] <Kovensky> ohsix: I committed the generated configure script and stuff because I didn't want to hear from MSYS users ._. [01:56:08] <ohsix> ramiro: he was talking about "broken" configure scripts [01:56:11] <Dark_Shikari> ramiro: configure is better than cmake [01:56:12] * Honoome is a build system otaku, if somebody didn't notice [01:56:16] <Dark_Shikari> if it works, it works [01:56:17] <Kovensky> MSYS is USELESS for almost everything [01:56:32] <Dark_Shikari> ramiro: here's the most important thing [01:56:35] <Dark_Shikari> WINDOWS DOES NOT HAVE PKG-CONFIG. [01:56:37] <ramiro> Kovensky: what? how's that? [01:56:38] <Dark_Shikari> aka you are fucked [01:56:48] <ohsix> Kovensky: heh; then you could just preconfigure it for msys and export a tree with config.h and templated files already configured [01:57:02] <ramiro> Dark_Shikari: pkg-config works on Windows... I've used it before. [01:57:17] <CIA-92> ffmpeg: michael * r22012 /trunk/libavcodec/h264.h: Remove unused variable. Seems i forgot to commit this. [01:57:18] * mru must dust off the mips/irix machine one day [01:57:48] <Dark_Shikari> ramiro: it works [01:57:51] <Dark_Shikari> but nobody has it installed [01:57:59] <ramiro> hmmm. so you install it? [01:58:22] <CIA-92> ffmpeg: michael * r22013 /trunk/libavcodec/h264.h: Replace /2 by faster >>1 as the mvd values are now all positive. [01:58:24] <ramiro> I admit it was a pain though [01:58:33] <Kovensky> yes, at least gtk has precompiled pkg-config packages that work fine on msys [02:00:20] <ohsix> you can always put a pkg-config at the front of your path that emulates it :> [02:00:24] <mru> autoconf isn't a terrible _idea_ [02:00:43] <mru> it's just that they made every mistake possible in the implementation [02:01:27] <ohsix> they were trying to write their sendmail.cf and they ended up with a configuration management tool [02:01:36] <mru> ohsix: on linux I've put a pkg-config at the front of the path that removes all the broken flags [02:02:07] <ohsix> heh word; i've done the same, once it calls out to any app like that you can easily fudge it if you need to; which is nice to be able to do [02:02:21] <Honoome> mru: which broken flags? [02:02:35] <mru> like -L/usr/lib when cross-compiling [02:02:56] <Honoome> blah that stuff is a bad one, we really should have $CHOST-prefixed pkg-config scripts for the cross-compile [02:03:07] <ramiro> mru: what about the sysroot option for pkg-config? [02:03:12] <mru> doesn't work [02:03:16] <ramiro> at all? [02:03:41] <mru> nope [02:04:20] <Honoome> ramiro: I think there's a pkg-config bug on bugs.fd.o : “pkg-config is broken for cross-compile” [02:04:31] <mru> I have to first twiddle the environment to point at the cross-root [02:04:39] <mru> then I filter the output through sed "s!\$-[IL]\$\$/lib\\|/usr\$!\\1${ROOT}\\2!" [02:04:43] <ohsix> that kind of idea is kind of leaky Honoome; you have the same problem you do int he first place, its hard to slot software in, it makes building single trees with all supported software easy though [02:05:31] <ohsix> pc files are generally configured like the .h.in files for paths and stuff and maybe some extra cflags [02:05:38] <mru> then I have a pageful of autoconf cache variable overrides [02:05:40] <Honoome> ohsix: hm? what do you mean? you got arm-linux-pkg-config that looks for stuff in /usr/arm-linux-pkg-config/lib/pkgconfig rather than /usr/lib/pkgconfig [02:05:59] <Kovensky> < Honoome> blah that stuff is a bad one, we really should have $CHOST-prefixed pkg-config scripts for the cross-compile <-- yes, autotools checks for that when on cross-compile mode [02:06:01] <mru> Honoome: that's not where my cross-root is [02:06:05] <Kovensky> and that's also how x264 does it [02:06:11] <Honoome> mru: or whatever else you configure it to :) [02:06:11] <mru> I have about a dozen differnt cross-roots [02:06:19] <mru> many of them the same platform [02:06:23] <Kovensky> I have a patch on my own mplayer tree that also uses $CHOST-pkg-config, and a patch for ffmpeg's configure that I've been too lazy to send to ML [02:06:24] <mru> but very different configurations [02:06:25] <Honoome> mru: you have PKG_CONFIG_PATH to look stuff up ;) [02:06:39] <mru> yes, I twiddle that one in my wrapper script [02:06:47] <mru> but it still spits out -L/usr/lib [02:07:00] <mru> and then libtool puts -L/usr/lib back [02:07:09] <mru> so I have to wrap the compiler in a script to filter it out again [02:07:11] <Kovensky> PKG_CONFIG_PATH doesn't make it ignore the default path [02:07:33] <Kovensky> ./configure --with-pc-path=/usr/local/i686-mingw32/lib/pkgconfig --enable-indirect-deps --program-prefix=i686-mingw32- [02:07:40] <Kovensky> ^ the line I used to build my pkg-config [02:08:05] <mru> that's too rigid [02:08:27] <Kovensky> that's ofc not the main pkg-config, but the one that is used when cross-compiling [02:08:42] <mru> as I said, I have about a dozen cross-roots [02:08:50] <mru> some use the same tool prefix [02:09:03] <Kovensky> it is a problem if they use the same prefix [02:09:09] <Honoome> mru: yeah I know quite a few problems… one of the problems is with .la files, and another is with gentoo's insistance on using stupid ldscripts for /usr/lib/libfoo.so instead of not adding it at all if the library is in /lib :( [02:09:18] <mru> I delete .la files [02:09:28] <Kovensky> libtool is FUCKING ANNOYING <_< [02:09:36] <ohsix> heh yea libtool is annoying [02:09:49] <Kovensky> I had to workaround like 3 windows bugs in libtool in the build system [02:09:52] <mru> so far I've found two things that broke from deleting .la files [02:09:58] <Kovensky> all very well known bugs that are either WONTFIX or just plain stupid [02:10:04] <mru> imagemagick and librep [02:11:38] <Kovensky> well, bed time ._. [02:11:40] * Kovensky is off [02:14:52] <Honoome> mru: and libtool's own macros =_= [02:15:18] <mru> yeah, of course [02:15:57] <mru> but my system is happy with no other .la files than libltdl.la in /usr/lib [02:16:48] <mru> imagemagick uses some misguided dynamic loader for various components [02:17:18] <ohsix> one thing that bugs me is packages that use autoconf but basically build only one place, or they dont support any of the compiler versions or linkers the scripts do; so its just as fragile and much more noisy than a nieve build script which you can always force if push comes to shove [02:17:21] <mru> and somehow it fails if the .la files for those are deleted [02:19:16] <ohsix> naive :< [02:20:03] <ohsix> it would be way cool if there was something less messy that would let you do the same sort of stuff with host triplets and platform configuration [02:20:32] <Honoome> ohsix: would be nicer already of people learnt not to just use autoscan [02:20:43] <Honoome> or stopped testing for 20 functions when they use only two [02:20:50] <Honoome> and don't even provide replacement, but just fail anyway if they are missing [02:21:06] <Honoome> and started using non-recursive automake [02:21:08] <ohsix> same idea though [02:21:25] <mru> or checking for fortran, c++, and ada when they only need c [02:21:27] <ohsix> the breakage anyways; might as well not even start [02:21:34] <Honoome> mru: that's an old libtool bug [02:21:34] <mru> and FAILING if one is missing [02:21:40] <Honoome> it's fixed if you use libtool 2 [02:22:13] <ohsix> mru: doesn't that work right if you use AM_PROG_CC? [02:22:21] <ohsix> right/as expected [02:22:24] <mru> don't know [02:22:34] <mru> I've just been annoyed by packages failing to build for no reason [02:22:40] <Honoome> it's old libtool bugs [02:22:46] <ohsix> i remember seeing that a few times but it was fromd efaults when stuff was omitted [02:22:48] <Honoome> pre-1.5, it checked and failed if C++ compiler wasn't found [02:23:04] <Honoome> for 1.5 it still checked C++ and Fortran but didn't die [02:23:13] <Honoome> 2.x does not check for C++ or Fortran by default [02:23:29] <Honoome> [and caused quite a bit of trouble as quite a few packages used C++ and never used AC_PROG_CXX =_=] [02:23:48] <mru> I was getting to that part [02:23:51] <Honoome> problem is you have to get upstream to release tarballs using *updated autotools chains* rather than the crappy stuff that comes with RHEL5 [02:23:57] <mru> that upgrading any piece of that crap breaks everything [02:24:22] <Honoome> one more reason why they should stop pretending they are standalone projects and just make it *one fucking big project* [02:24:51] <Honoome> remove the redundancies, reduce the code, possibly get to pre-define special routes… [02:25:16] <Honoome> and the other thing that needs to die is gnulib [02:25:28] <Honoome> nice idea when you first look at it, a nasty can of worms when you actually see it used [02:26:08] <mru> gnulib? [02:26:54] <Honoome> mru: replacement functions for stuff that is not supported by older C libraries and similar [02:29:10] <Honoome> mru: there, I posted a draft I had laying around for a while: http://blog.flameeyes.eu/2010/02/24/reinventing-lots-of-little-wheels [02:49:31] * Honoome wonders if mru is trying to save his kittens from being killed by the gnulib users [06:13:50] <elenril> J_Darnley: why do you want to revert that patch? [06:14:04] <elenril> /morning/ [06:14:54] <kshishkov> (is it?) [06:15:46] <CIA-92> ffmpeg: ramiro * r22014 /trunk/ffprobe.c: FFprobe: take only one input file. [06:15:58] * elenril thinks it is [06:16:32] <kshishkov> any hard evidence? [06:17:03] <elenril> CTCP TIME reply from kshishkov: Wed Feb 24 08:16:03 2010 [06:17:03] <mru> birds are singing [06:17:41] <kshishkov> mru: birds are coughing [06:18:07] <kshishkov> elenril: looks like morning has nothing in common with time of day on IRC [06:18:31] <elenril> ofc it does [06:18:42] <elenril> morning is when i say it's morning [06:18:52] <byteme`> Hi I'm a computer science student. Looking to join an OSS project and contribute [06:19:48] <kshishkov> send a patch, it's a good gesture [06:20:17] <kshishkov> elenril: ok, you said so on your own free will. I'll take a note. [06:20:18] <elenril> if there's someone active enough to apply it =p [06:20:35] <elenril> btw <insert usual question here> [06:21:01] <Dark_Shikari> byteme`: both x264 and ffmpeg are good targets for contributions ;) [06:21:09] <Dark_Shikari> the most important thing is: [06:21:17] <Dark_Shikari> 1) figure out how things work, preferably by asking questions until you do [06:21:28] <Dark_Shikari> 2) there are no stupid questions, only stupid people [06:21:43] <Dark_Shikari> 3) start small. find something little you want to do first. [06:22:01] <kshishkov> elenril: told you, wait for benoit-. Or give me the reference to the thread where that patch is (and was okayed) [06:22:55] <byteme`> Dark_Shikari: okay. [06:23:15] <elenril> kshishkov: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083341.html [06:23:59] <elenril> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083590.html [06:24:17] <Dark_Shikari> byteme`: it also depends what you want to do and are interested in, of course [06:24:23] <byteme`> Dark_Shikari: Currently, I've been looking at the 'small tasks' page on the wiki to get some ideas on contributions. The LZW encoder being extended to support GIF sounds interesting [06:24:34] <Dark_Shikari> I'd probably divide tasks into the following: [06:24:39] <elenril> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083705.html [06:24:43] <Dark_Shikari> 1) deep magic fun encoder stuff [06:24:48] <Dark_Shikari> 2) black magic assembly stuff [06:24:56] <Dark_Shikari> 3) decoder stuff [06:24:58] <Dark_Shikari> 4) muxer/demuxer stuff [06:25:12] <Dark_Shikari> 5) bugfixing (a little of everything) [06:25:42] <Dark_Shikari> notably the main difference between encoding and decoding being that in decoding it's a 1-dimensional problem: all you care about is efficiency, basically, since there's only one right way to do it. [06:25:51] <Dark_Shikari> in encoding, it's a 2-D problem: you have to do it fast, and well. [06:26:18] <mru> just use a space-filling hilbert curve, problem solved [06:26:59] <Dark_Shikari> lol [06:26:59] <byteme`> Porting missing decoders/demuxers from other projects seems interesting as well [06:27:08] <byteme`> I'm not sure if I'm advanced enough to handle writing an encoder yet. [06:27:10] <Dark_Shikari> yeah, though they have to be lgpl-compatible [06:27:14] <Dark_Shikari> well, WRITING an encoder is hard [06:27:19] <Dark_Shikari> but jumping into an existing encoder is much easier [06:27:26] <Dark_Shikari> you can blackbox everything scary and poke at one little thing [06:27:31] <Dark_Shikari> also, have you thought of summer of code? [06:27:37] <kshishkov> elenril: ok, I ignored most of those links [06:27:54] * elenril expected as much =p [06:28:00] <CIA-92> ffmpeg: kostya * r22015 /trunk/libavformat/ (nut.c nut.h nutenc.c nutdec.c): [06:28:00] <CIA-92> ffmpeg: Introduce metadata conversion table for NUT encoder. [06:28:00] <CIA-92> ffmpeg: Patch by Anton Khirnov (wyskas, do no evil mail) [06:28:00] <CIA-92> ffmpeg: Thread "[PATCH] nut metadata conversion table" [06:28:23] <elenril> o_0 thanks [06:28:24] <byteme`> Dark_Shikari: haven't thought about it. This is my first attempt at trying to join an OSS project. [06:29:35] <elenril> actually it's not just muxer, the table applies to demuxer too [06:30:03] <mru> (join byteme` (match-attr 'oss (get-projects))) [06:30:12] <Dark_Shikari> lol [06:30:23] <Dark_Shikari> Haskell > lisp [06:30:36] <byteme`> I'm looking at the SoC wiki page... lots of interseting projects attempted/completed the last few years [06:30:37] * mru is hacking gcc rtl atm [06:30:47] <Dark_Shikari> byteme`: here's a paste from an email to a student that asked me a few questions a while back [06:30:51] <Dark_Shikari> http://pastebin.com/59qGQj7D [06:31:03] <Dark_Shikari> I think it's a bit relevant here. [06:31:15] <thresh> moroning [06:31:35] <kshishkov> elenril: corrected. Wait another month for other patches to apply or ask you know who [06:31:37] * kierank can vouch for what Dark_Shikari said [06:31:54] <Dark_Shikari> also, kierank is one of those guys who played the "ask questions for 3 weeks until he understood everything" game [06:32:16] <byteme`> Dark_Shikari: that email is very inspiring [06:32:16] <kshishkov> Dark_Shikari: writing encoder is easy, the hard stuff is to make it perform well [06:32:33] <Dark_Shikari> indeed. [06:32:39] <mru> writing bitstream formatter is easy [06:32:43] <Dark_Shikari> though writing the framework for a big encoder can be scary [06:32:45] <mru> figuring out what to feed it is hard [06:33:01] <byteme`> I'm actually a junior right now. [06:33:12] <Dark_Shikari> which university? [06:33:19] <byteme`> I don't particularly find my classes that difficult so hopefully I can find something challenging in a project [06:33:24] <byteme`> Regis University [06:33:46] <mru> staying connected can be enough of a challenge at times [06:34:05] <mru> comcast... [06:34:07] <byteme`> hmmmm nice irc client crash... [06:34:13] <Dark_Shikari> lol [06:34:16] <Dark_Shikari> 14:33 <@mru> staying connected can be enough of a challenge at times [06:34:18] <kierank> mru: it's comcastic [06:34:29] <pJok> mornings [06:34:36] <byteme`> Anyway, I go to Regis University [06:34:43] <mru> where's that? [06:34:48] <byteme`> it's not a well known school, but the only school I could get into [06:34:50] <Dark_Shikari> http://en.wikipedia.org/wiki/Regis_University [06:34:56] <byteme`> It's a private university in Colorado [06:35:06] <Dark_Shikari> started by the jesuits. doesn't sound too bad, the jesuits were pretty awesome. [06:35:49] * elenril wonders how does git-svn react to svn prop changes [06:36:02] <mru> it doesn't [06:36:04] <kshishkov> compare to http://en.wikipedia.org/wiki/Kharkiv_Polytechnical_Institute [06:36:24] <byteme`> After I graduate, I'm going to apply for graduate MSCS at University of Colorado at Boulder or possibly Colorado State University Masters in CompSci [06:36:34] <Dark_Shikari> kshishkov: LOL at the comments people are stuffing in the article [06:36:40] <Dark_Shikari> National Technical University "Kharkiv Polytechnical Institute" is one of the oldest technical universities in Ukraine and one of the finest in eastern and southern Europe. {Wishful thinking, check the ratings.} [06:36:41] <kierank> lol [06:37:00] * Dark_Shikari has http://en.wikipedia.org/wiki/Harvey_Mudd_College [06:37:25] <kshishkov> Dark_Shikari: well, finest = easy to get in, very hard to get thrown out [06:37:30] <Dark_Shikari> LOL [06:37:48] <byteme`> Anyway my name is Jeff, nice to meet you all :) [06:38:38] <byteme`> Dark_Shikari: I sent myself a copy of that email you posted so I can refer to it for inspiration [06:38:46] <Dark_Shikari> if you like encoder stuff, might want to drop by #x264 + #x264dev as well [06:38:53] <Dark_Shikari> byteme`: I can send you the whole email, it has a lot of info on SoC and similar [06:39:04] <byteme`> sure [06:39:06] <Dark_Shikari> email? [06:39:12] <byteme`> want me to pm it? [06:39:26] <byteme`> jeff2321(a)gmail.com [06:39:35] <Dark_Shikari> sent [06:39:40] <byteme`> thanks man :) [06:39:42] <kshishkov> spam to follow [06:39:56] <Dark_Shikari> lol [06:39:58] <byteme`> I've had that email for a long time [06:40:01] <Dark_Shikari> it's true, this channel is publicly logged [06:40:05] <byteme`> it gets spammed anyway [06:40:06] <Dark_Shikari> not like anyone cares [06:40:10] <Dark_Shikari> everyone gets massive spam these days [06:40:15] <Dark_Shikari> good thing for gmail's amazing spam filter. [06:40:27] <kierank> i get weird spam after being in x264 git [06:40:36] <kierank> about lists of hospitals [06:40:50] <Dark_Shikari> lol [06:41:15] <mru> kierank: be in x264 too long and you'll need 'em [06:41:30] * kshishkov has an alternative address "kostya.forjunk" but it gets spam only once a week [06:41:33] <byteme`> another idea I had was a new gui for vlc [06:41:55] <byteme`> but perhaps people like the gui the way it is [06:42:40] * kshishkov prefers default MPlayer gui [06:43:05] <kierank> as long it as it's not obnoxious like powerdvd or totalmedia theatre [06:43:08] <elenril> weren't you saying you don't use mplayer? [06:43:13] * mru watches it mostly in md5 [06:43:23] <byteme`> well I was thinking a different gui for htpc deployments [06:43:33] <Dark_Shikari> we call that mythtv [06:43:36] <kshishkov> elenril: FFplay lacks good video output [06:43:40] <mru> and xbmc [06:43:41] <Dark_Shikari> or xbmc [06:43:48] <mru> xor? [06:44:01] <kshishkov> elenril: but if that's fixed, I'll gladly drop MPlayer [06:45:19] <kierank> Dark_Shikari: also, *only* 1/5th of x264 [06:45:20] <Dark_Shikari> dropping mplayer is a bad idea, it might break when it hits the floor [06:45:30] <Dark_Shikari> kierank: I think LOC wise that's not unreasonable [06:45:43] <kierank> i would have thought it was more [06:45:50] <benoit-> good morning [06:45:55] <benoit-> (or whatever) [06:46:01] * elenril thinks mplayer doesn't die when it's dropped [06:46:25] <kshishkov> Dark_Shikari: no, it's all parts tightly hacked together [06:46:45] <kshishkov> the only way to break it is to make it use only public APIs for all libs [06:46:50] <Dark_Shikari> kierank: think of all the parts that I have mostly not touched [06:46:54] <Dark_Shikari> encoder.c, set.c, VLC tables [06:46:55] <Dark_Shikari> powerpc asm [06:46:56] <kshishkov> benoit-: your patch monkey skills are needed [06:46:58] <Dark_Shikari> sparc asm [06:47:08] <Dark_Shikari> lots of C implementations of DSP functions [06:47:11] <Dark_Shikari> which nobody will ever modify ever [06:47:51] <benoit-> kshishkov: well, my coding skills are needed too here... [06:48:16] <benoit-> I have no time to test things enough before checking code in; so I prefer not checking in [06:48:48] <kshishkov> benoit-: where you are going to apply those skills? [06:50:13] <benoit-> kshishkov: at my workplace [06:50:30] <benoit-> (sorry, my sentence was unclear) [06:50:45] <kshishkov> benoit-: ok, tell that to elenril [06:51:14] * elenril bashes head against wall ;) [06:52:01] <benoit-> kshishkov: I saw that yesterday [06:52:34] <benoit-> elenril: ping some of your patches that need to be applied; I'll see if I find some time to do it this morning [06:59:15] <elenril> done [07:05:17] <byteme`> Dark_Shikari: looks like you are in Australia. I visited Sydney last year -- should an amazing place. [07:05:23] <byteme`> s/should/such/ [07:05:38] <kshishkov> wrong [07:06:13] <kshishkov> it's just his proxy has an Australian domain name [07:06:20] <Dark_Shikari> byteme`: nope [07:06:25] <Dark_Shikari> my remote shell has an AU domain [07:06:28] <byteme`> oh [07:06:31] <Dark_Shikari> it's based on michigan or so [07:06:32] <byteme`> hehe :)P [07:06:33] <Dark_Shikari> Harvey Mudd is in Claremont, CA [07:06:59] <byteme`> is it good to use a shell to access irc? [07:07:05] <byteme`> hmmm [07:07:05] <kshishkov> yes [07:07:16] <Dark_Shikari> extremely good [07:07:17] <Dark_Shikari> 1) you never log off [07:07:20] <Dark_Shikari> 2) you never miss anything [07:07:24] <byteme`> I've got one... let me switch to it [07:07:26] <Dark_Shikari> 3) when you get on in the morning, you can see what you missed [07:07:33] <Dark_Shikari> 4) you get to use irssi, the IRC client of the future! [07:07:42] <byteme`> I'll just put irssi in a screen [07:07:50] <kierank> #4 is why i haven't asked checkers for a bnc [07:07:52] <kshishkov> 5) you are not restricted by stupid filtering rules of the local machine [07:08:06] <Dark_Shikari> 6) you can access your IRC from anywhere [07:08:08] <Dark_Shikari> so not only do you not miss anything [07:08:13] <Dark_Shikari> but you can "not miss anything" from anywhere [07:09:00] <byteme`> comcast tends to go down late at night [07:09:10] <byteme`> which is another problem [07:09:29] <kshishkov> well, saying "comcast" is enough [07:09:47] <Dark_Shikari> lol [07:09:51] <byteme`> there we go [07:09:52] <Dark_Shikari> that's another reason to use a remote shell [07:09:55] <kierank> comcast engineering at the higher level is supposedly very good [07:10:03] <Dark_Shikari> comcast was even worse for me [07:10:04] <kierank> and they're making an effort with things like ipv6 and dnssec [07:10:04] <Dark_Shikari> here's how bad it was [07:10:12] <Dark_Shikari> you connect to IRC, and it SPAMMED YOU WITH RST PACKETS [07:10:14] <Dark_Shikari> disconnecting you completely [07:10:21] <Dark_Shikari> I had to use a remote shell over an encrypted connection [07:10:23] <Dark_Shikari> to even access IRC [07:10:28] <Dark_Shikari> anything else would RST-dump me [07:10:32] <Dark_Shikari> last I tried, they still did this [07:10:44] <Dark_Shikari> it even RST dumped me if I connected to IRC via telnet, manually, by typing in commands [07:10:46] <kierank> maybe it was an anti-botnet feature [07:10:54] <byteme`> wow [07:10:56] <elenril> at least freenode supports ssl now [07:10:56] <thresh> OMG, RST packets, cant resist them! [07:11:24] <byteme`> I'm going to yell at my friend that works at comcast then [07:11:37] <byteme`> he's a senior network guy at comcast here in colorado [07:11:43] <Dark_Shikari> byteme`: it might no longer be true [07:11:46] <Dark_Shikari> I don't use comcast myself [07:11:48] <Dark_Shikari> I use a university connection [07:12:05] <Dark_Shikari> I wouldn't harass him until I go back home for the summer and confirm it again ;) [07:12:15] <kierank> everyone should use linksys, the worlds largest isp [07:12:17] <Dark_Shikari> I mean, I really hate when people bug report things that I fixed 6 months ago [07:12:22] <Dark_Shikari> so I don't do it to anyone else either [07:12:26] <Dark_Shikari> kierank: +1 [07:12:32] <kierank> 100% reliable [07:12:33] <byteme`> I usually give him crap anyway :) [07:12:38] <byteme`> just beause he works at comcast [07:12:41] <kshishkov> here we mostly stuck with D-link, it seems [07:12:52] <Dark_Shikari> I like my uni connection [07:12:57] <Dark_Shikari> 1gbit down, limited to 100mb by wires [07:13:14] <Dark_Shikari> couple-millisecond ping to many places on the west coast [07:13:22] <byteme`> my comcast line has better bandwidth than my university [07:13:23] <Dark_Shikari> .... and slower upload than a comcast connection. [07:13:24] <kierank> I plugged into the lan at cern once [07:13:27] * kshishkov cannot say anything about his uni connection as it's well-hidden from students [07:13:40] <elenril> why slow upload? [07:13:46] <kshishkov> kierank: and then HL happened? [07:14:06] * elenril has 100mb/100mb on uni connection [07:14:08] <kierank> the guy was giving a presentation about the european academic networks and their superior capacity and I said yeah because all those torrents need their bandwidth [07:14:19] <kierank> screw the lhc data [07:14:20] <byteme`> haha [07:15:24] <Dark_Shikari> if I can't download a 1080p movie faster than I can watch it [07:15:27] <Dark_Shikari> the connection is too slow. [07:16:14] <kierank> do you not have usage limits? [07:16:18] <Dark_Shikari> nope [07:16:30] <Dark_Shikari> heavily limited upload, 500kbps only [07:16:32] <kshishkov> Dark_Shikari: try that with raw 1080p movies [07:16:33] <Dark_Shikari> but unlimited DL [07:16:38] <Dark_Shikari> kshishkov: I did, big buck bunny [07:17:14] <Dark_Shikari> the funny thing is our internet is so fast that you can get to the top of the usage chart in about 2 hours [07:17:33] <kshishkov> here upload is not so limited [07:17:42] <kshishkov> if you know that download is 1mbps [07:31:52] <CIA-92> ffmpeg: benoit * r22016 /trunk/libavformat/asfdec.c: [07:31:52] <CIA-92> ffmpeg: asfdec: only unicode tags must have even length. [07:31:52] <CIA-92> ffmpeg: Patch from: Anton Khirnov wyskas gmail [07:33:07] <CIA-92> ffmpeg: benoit * r22017 /trunk/libavformat/asfdec.c: [07:33:07] <CIA-92> ffmpeg: asfdec: fix a memleak. [07:33:07] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail [07:33:36] <kshishkov> hmm, too many elenril patches applied this month [07:33:56] * elenril stabs kshishkov [07:33:59] <elenril> benoit-: thanks [07:34:07] <CIA-92> ffmpeg: benoit * r22018 /trunk/libavformat/asfdec.c: [07:34:07] <CIA-92> ffmpeg: asfdec: add a debug message about skipped tags. [07:34:07] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail [07:35:01] <CIA-92> ffmpeg: benoit * r22019 /trunk/libavformat/asfdec.c: [07:35:02] <CIA-92> ffmpeg: asfdec: skip byte array tags. [07:35:02] <CIA-92> ffmpeg: Patch from Anton Khirnov wyskas gmail [07:38:31] <benoit-> elenril: I thought you had more than this four ones, didn't you ? [07:39:17] <elenril> yes, there's one trivial documentation patch (mention that metadata tags are UTF-8) [07:39:53] <elenril> and patches in "asf - read/write metadata as UTF-16", but i'm yet to decipher which ones are OK'ed [07:46:29] * elenril goes to school, bbl [08:28:52] * av500 sets this as new browser homepage: http://bijint.com/en/ [08:35:32] <superdump> av500: ? [08:35:43] <superdump> is that just a girl holding up a sign saying the time on it? [08:35:49] <superdump> that updates every minute [08:36:29] <av500> yes [08:37:12] <av500> I guess ffmpeg devs will prefer the http://bijint.com/jp/ version though [08:37:23] <benoit-> meaning that you interrupt what you're doing every minute to be sure not to lose one pic ? [08:37:25] <byteme`> that url doesn't even render in my browser [08:37:36] <benoit-> BTW, hi Rob [08:38:59] <Dark_Shikari> superdump: lol [08:39:17] <superdump> hey benoit- [08:39:20] <Dark_Shikari> they really went through and had her hold up every single one? [08:39:38] <superdump> it's a different girl now [08:39:49] <superdump> maybe they just stood in a city and asked someone to hold the sign [08:39:55] * av500 waits for the android app, his mobile carrier rejoices [08:40:01] <Dark_Shikari> looks the same to me [08:40:11] <Dark_Shikari> oh wait, you're right [08:40:23] <thresh> :) [08:40:36] <av500> and you even get to know her blood type! [08:40:40] <Dark_Shikari> this is japan [08:40:44] <Dark_Shikari> blood type is more important than your age [08:40:48] <kierank> ? [08:41:03] <Dark_Shikari> http://en.wikipedia.org/wiki/Blood_types_in_Japanese_culture [08:42:04] <kierank> i can safely say that doesn't match [08:43:53] <KotH> there are about a dozen girls [08:44:09] <andoma> KotH: you have watched all night? [08:44:15] <KotH> and yes, they took quite a few fotos :) [08:44:21] <KotH> andoma: nah.. [08:44:25] <andoma> :) [08:44:34] <KotH> andoma: i had it open a whole weekend ;) [08:45:39] <KotH> Dark_Shikari: erhmm... bloodtype is like zodiac signs in european culture [08:45:54] <KotH> Dark_Shikari: people do ask about it, but nobody really believes... [08:46:03] <Dark_Shikari> KotH: of course [08:46:16] <Dark_Shikari> but EVERYTHING has blood types [08:46:23] <Dark_Shikari> like holy shit they put blood types next to every anime character [08:46:31] <Dark_Shikari> in america we don't put zodiac signs next to each TV show character [08:46:46] <Dark_Shikari> (nor in europe) [08:46:48] <KotH> american fail, then [08:46:50] <KotH> ;) [08:47:13] <av500> well, bart simpson is a virgin, no? [08:48:04] <peloverde_> blood types are fairly common on american TV but not for creepy japanese reasons, we just have too many medical shows [08:48:39] <KotH> lol [08:49:09] * KotH thinks that usians are way more creepy than japanese [08:49:17] <av500> like cell phone reception, matching blood is never there when you need it [08:49:30] * thresh doesnt even know his blood type [08:49:52] <KotH> thresh: you'll die a horrible death! [08:50:21] * av500 has cold blood [08:50:41] <Dark_Shikari> peloverde_: It's lupus! [08:51:25] <superdump> lol [08:51:41] <superdump> necrotising fasciitis [08:51:56] <superdump> auto-immune disease! :o [08:56:49] <Dark_Shikari> interesting, that site only lets you access the current image [08:56:52] <Dark_Shikari> you get 403 on any other image [08:57:05] <av500> you get a few back [08:57:54] <Dark_Shikari> ah [08:58:06] <Dark_Shikari> still, must require some smart rotating http server script [08:58:48] <av500> there is user timezone to take into account, no? [08:59:24] <Dark_Shikari> yeah it must do that too [08:59:29] <Dark_Shikari> or maybe it only allows a few minutes per hour [08:59:53] <av500> no [08:59:54] <Dark_Shikari> it could parse the time in the user GET [09:08:57] <av500> Dark_Shikari: http://forum.archosfans.com/viewtopic.php?p=206352#p206352 [09:09:48] <Dark_Shikari> :) [09:37:59] <twnqx> interesting blog article, Dark_Shikari [09:38:22] <twnqx> and interesting comments on it as well [09:38:41] <Dark_Shikari> superdump: http://bijint.com/jp/pages/iphone/bisei.html [09:38:43] <Dark_Shikari> they have an iphone app [09:39:40] <superdump> well i don't particularly want it [09:39:46] <Dark_Shikari> I know, I'm just pointing it out ;) [09:39:53] <Dark_Shikari> thought it was funny [09:39:53] <superdump> i was just wondering what the point of it was [09:39:55] <superdump> :) [09:40:16] * av500 wonders why they dont have an anime version.... [09:40:38] <av500> oops: http://bijint.com/jp/pages/iphone/pixiv.html [09:40:44] <DonDiego> twnqx: what blog post? [09:40:58] <av500> DonDiego: http://x264dev.multimedia.cx/?p=292 [09:41:03] <twnqx> the one from two days ago [09:41:32] <av500> twnqx: thats a clear description :) [09:41:44] <twnqx> you posted the link already :P [09:41:52] <twnqx> "The best choice will always be a deeply patent-encumbered format until someone gets rid of software patents" [09:42:14] <Dark_Shikari> aka "screw the US, you guys suck" [09:42:17] <twnqx> isn't it more like "the best ideas are sadly patended, and other ideas just are too inferior"? [09:42:26] <Dark_Shikari> no, more like "good ideas will always be patented" [09:42:35] <twnqx> hm [09:42:40] <Yuvi> Dark_Shikari: you're included, you haven't moved yet :P [09:42:53] <Dark_Shikari> Yuvi: self-deprecation is allowed [09:43:16] <peloverde> If it's a US vs elsewhere thing then why are so many german patents listed in the mpeg-la list? [09:43:37] <av500> peloverde: h264 cost money in .eu too [09:43:39] <Dark_Shikari> peloverde: hardware is separate [09:43:45] <Dark_Shikari> EU prohibits patents on computer programs [09:43:48] <Dark_Shikari> this does not apply to hardware [09:43:53] <Dark_Shikari> it also probably doesn't apply to computers distributed with software [09:44:00] <Dark_Shikari> so for example, VLC should be fine [09:44:04] <Dark_Shikari> but if I sell a computer with VLC on it, it may not be fine [09:44:12] <Dark_Shikari> and if I sell an ipod with a hardware decoder, it's definitely not fine [09:44:22] <Dark_Shikari> but it's much more _reasonable_, because if you sell hardware, you can afford to pay licensing fees [09:44:25] <av500> ipod with sw decoder is also not fine [09:44:26] <Dark_Shikari> while software has zero duplication cost [09:44:40] <Dark_Shikari> and thus it's not reasonable to expect all distributors of software to be able to pay [09:44:47] <Dark_Shikari> it's still not optimal, but a far better option than what's in the US. [09:44:54] <av500> and it is not reasonable to go after e.g. vlc [09:45:15] <Dark_Shikari> mpeg-la are pretty smart. they don't want to make enemies of open source, it's biting the hand that feeds them [09:45:40] <av500> right [09:45:54] <Dark_Shikari> smarter than adobe ;) [09:50:48] <twnqx> so it would be possible to sell a hardware with a h264 license, but no h264 application installed, and it would still cover any app that a user might want to install? [09:51:01] <Dark_Shikari> Probably. [09:51:04] <Dark_Shikari> You'd probably have to ask mpeg-la. [09:51:17] <twnqx> and fraunhofer et al for mp3, etc >_> [09:51:45] <twnqx> is alac patented? [09:52:49] <Dark_Shikari> fraunhofer is much more annoying than mpeg-la [09:52:53] <Dark_Shikari> same with via licensing and aac [09:53:18] <av500> dont forget sisvel for mp3, most annoying [09:54:21] <peloverde> I don't understand why people even bother with mp3 anymore, the format is retarded and the licensing is a mess [09:54:37] <Dark_Shikari> flash doesn't support vorbis [09:54:40] <Dark_Shikari> there are no good open source aac encoders [09:54:44] <Dark_Shikari> libmp3lame is better than libfaac and ffaac [09:54:49] <av500> peloverde: ??? [09:54:58] <Dark_Shikari> and aac is no better than mp3 licensing wise [09:54:59] <peloverde> nero is gratis [09:55:04] <Dark_Shikari> no it isn't! [09:55:08] <Dark_Shikari> nero is non-commercial only [09:55:19] <peloverde> They will sell you a commercial license [09:55:26] <Dark_Shikari> In theory [09:55:35] <Dark_Shikari> but a lot of people want free software solutions [09:55:52] <Dark_Shikari> now stop being lazy and work on the aac encoder! :) [09:56:11] <peloverde> All these people who want free software solutions seem unwilling to pay [09:57:37] <Dark_Shikari> Well, nobody's paying for x264, and we seem to be doing fine. [09:58:00] <peloverde> I thought you were pulling down reasonable money to work on x264 [09:58:09] <Dark_Shikari> yes, but not for any quality-related stuff [09:58:12] <Dark_Shikari> mostly for niche features [09:58:29] <Dark_Shikari> like low latency, bitrate reconfig, etc [09:58:36] <av500> most users cannot judge quality anyway... [09:58:44] <Dark_Shikari> Making x264 Good (TM) came for free. mostly [09:58:50] <Dark_Shikari> AQ was paid for, but that's about it [09:59:02] <Dark_Shikari> AQ came because Avail Media was annoyed at grass in football games looking awful [09:59:13] <av500> --nice-grass [10:00:04] <Dark_Shikari> and it's not really as much money as I'd like anyways :/ [10:00:54] <Dark_Shikari> seriously though, you can't get money by doing nothing and promising work when the money comes [10:01:32] <peloverde> yes but i'm getting money for decoding [10:01:39] <peloverde> so why bother with the encoder [10:02:32] <Dark_Shikari> because this is free software. money is the icing, not the cake. [10:03:39] <peloverde> Says the man working for corecodec and selling non-free licenses to is program [10:03:53] <Dark_Shikari> working for them? I wrote asm for them over a summer [10:03:55] <Dark_Shikari> that was about it [10:04:00] <Dark_Shikari> and I said THIS is free software [10:04:03] <Dark_Shikari> coreavc is not free software [10:04:06] <Dark_Shikari> therefore, the same rules don't apply [10:04:27] <Dark_Shikari> working on free software doesn't preclude working on other things too. [10:06:35] <Dark_Shikari> but when you're working on free software, sitting around whining and refusing to work on X because nobody will give you money is simply stupid. [10:07:07] <pross-au> Q: to support seeking in bink, i need to know the audio PTS of the frame being seeked to. the only way to caclulate the PTS, is to process first 4 bytes of each prior frame. This involves a lot of seeking, especially for big files. Any ideas how i can implement this neatly? [10:07:07] <Dark_Shikari> it's fine to admit that X isn't your thing, and that you're not interested. But in that case we better find someone else to do it. [10:07:33] <Dark_Shikari> pross-au: well, good thing bink files aren't usually very long... [10:08:03] <peloverde> If somebody wants to work on the AAC encoder, they are more than welcome to [10:08:04] <pross-au> Dark_Shikari: the diablo cutscenes are huge man [10:08:09] <Dark_Shikari> they're like 5 minutes [10:08:41] <pross-au> 7! [10:08:47] <Dark_Shikari> lol [10:08:54] <Dark_Shikari> and they're like, sub-SD [10:09:13] <pross-au> But Patent Free [10:09:20] <av500> Dark_Shikari: but one day utube will switch to bink-HD, we better be prepared [10:09:51] <pross-au> Quality, Patent-Encumbered or Fast. Pick two. [10:10:07] <Dark_Shikari> you mean patent-free [10:10:12] <Dark_Shikari> you mixed that one up. [10:10:24] <av500> pross-au: I pick Quality and Fast :) [10:10:31] <Dark_Shikari> lol [10:10:35] <pross-au> Dark_Shikari: arh crap [10:10:42] <pross-au> You know what i mean [10:10:44] <Dark_Shikari> I don't think that works well either [10:10:49] <Dark_Shikari> what's patent-free, quality, but not fast? [10:10:52] <Dark_Shikari> certainly not dirac [10:10:57] <av500> raw YUV [10:10:57] <Dark_Shikari> that's patent-free, not quality, not fast [10:11:01] <Dark_Shikari> lol [10:11:08] <Dark_Shikari> But raw YUV is fast. [10:11:21] <merbzt1> quality is awesome [10:11:45] <av500> merbzt1: some of it could use a blocking filter though [10:12:08] <av500> inb4 xkcd [10:35:22] <pross-au> Seeking in bink videos looks ugly [10:36:07] <Dark_Shikari> they do have keyframes though right? [10:44:57] * Kovensky wonders about flac seeking [10:45:12] <elenril> Kovensky: patches welcome ;) [10:45:30] <Kovensky> :P [10:45:48] <av500> flac cannot seek? [10:45:51] * elenril wonders how to handle -ss when copying chapters [10:45:54] <elenril> av500: no [10:45:55] <Kovensky> I already spent like 2 hours yesterday adding TTA support to mplayer's mkv demuxer, and that was with libavformat copypasta [10:45:58] <Kovensky> lol [10:46:00] <Kovensky> av500: no, it can't seek OR tell [10:46:24] <elenril> Justin said it was on his todo list [10:46:38] <av500> hmm, it seeks here nicely [10:46:52] <Kovensky> * elenril wonders how to handle -ss when copying chapters <-- the same way mkvmerge does: shift chapters [10:46:58] <Kovensky> av500: mplayer? try -demuxer lavf :) [10:47:10] <av500> Kovensky: no, my own player/demuxer [10:47:25] <Kovensky> o [10:47:28] <elenril> Kovensky: well obviously [10:47:52] <elenril> but ffmpeg just parses -ss argument when handling -i and then throws it away [10:48:22] <elenril> so this will require some :effort: [10:48:43] <elenril> or a brain, but those are hard to get lately [10:52:13] <pross-au> Dark_Shikari: yeah it has them, but kshishkov is part of 'equality for frame-types' movement. [10:52:21] <pross-au> so all frames are treated as KEY [10:52:58] * elenril always thought kshishkov was evil [10:55:13] * av500 thought no key frames at all was the new rage these days... [10:56:54] <elenril> only for 1337 formats liek x264 [10:57:09] <CIA-92> ffmpeg: cehoyos * r22020 /trunk/ (libavformat/mpegtsenc.c tests/ref/lavf/ts): [10:57:09] <CIA-92> ffmpeg: Correctly increment continuity_counter in PCR packets. [10:57:09] <CIA-92> ffmpeg: Patch by Yann Coupin, yann.coupin+ffmpeg gmail [11:02:12] <Kovensky> elenril: you forgot the . [11:02:40] <elenril> lol [11:04:12] * elenril lols@http://kovensky.project357.com/stats/ffmpeg-devel.html [11:04:45] <kshishkov> pross-au: you have LSB in seektable offsets to tell you whether that's keyframe or not [11:04:49] <elenril> most used words: michael [11:06:11] <pross-au> I am yet to find a sample file that has LSB set [11:06:26] <kshishkov> there is - for the first frame [11:06:31] <pross-au> Yeah [11:07:21] <pross-au> seeking is a pain kshishkov, because we need to calculate audio pts (and that involves seeking) [11:07:32] <av500> Kovensky: you have to ignore "_" when making the stats [11:07:33] <kshishkov> the rest is obviously treatead as P-frames [11:07:45] <Dark_Shikari> lol bink [11:07:55] <kshishkov> pross-au: what about quick and dirty approximation as frame number * constant ? [11:07:59] <Kovensky> av500: lol [11:08:07] <Kovensky> av500: pisg is p. dumb :/ [11:08:13] <pross-au> That trick cross my mind kshishkov [11:11:33] <kshishkov> at least for video you have to decode whole frame to tell whether it's real P-frame or not, so seeking may be not worth bothering [11:12:52] <pross-au> So the LSB 'keyframe' flag does not always mary up with the Bink Video content [11:13:07] <kshishkov> it is [11:13:23] <pross-au> that's an incomplete sentence kshishkov [11:13:38] <kshishkov> it is not :) [11:13:45] <pross-au> it does not! [11:14:01] <kshishkov> your time is over [11:14:08] <pross-au> True [11:14:33] <kshishkov> another 5 minutes cost ten quid [11:14:51] <pross-au> i dont think seeking to an 'estimated by constant' audio pts is going to work [11:15:07] <kshishkov> true, some frames lack audio [11:15:12] <pross-au> the audio is not distributed evenly across the file. audio gets lumped at the beginning [11:15:32] <pross-au> of course, we will fix that with the FFmpeg Bink A/V encoder right? [11:16:27] <kshishkov> right [11:16:33] <kshishkov> draft Dark_Shikari [11:18:04] <kshishkov> I think that simply seeking to the beginning in Bink files should be enough [11:19:19] <pross-au> kshishkov: ok [11:25:42] <kshishkov> I'm uploading BIKb sample with sound for you [11:26:04] <kshishkov> it does not play audio well either [11:28:52] <kshishkov> pross-au: incoming/bink/NWCLOGO.BIK [11:29:50] <J_Darnley> elenril: was the email not clear enough? [11:30:50] <pross-au> Oh cool [11:31:25] <CIA-92> ffmpeg: pross * r22021 /trunk/libavformat/bink.c: set AVINDEX_KEYFRAME correctly for bink [11:33:17] <pross-au> kshishkov: which game? [11:33:28] <kshishkov> silly question [11:33:55] <kshishkov> the same for which you have that demo with BIKb files [11:34:07] <pross-au> searching 'NWCLOGO.BIK' via Bing.com yields nothing [11:34:10] <kshishkov> (how many games by New World Computing you know anyway?) [11:34:21] <pross-au> Zero [11:34:24] <pross-au> Haha [11:34:25] <kshishkov> search at Bink.com [11:35:25] <kshishkov> it was in single video archive along with other Binks and Smackers [11:35:29] <pross-au> in your expedition, did you find any other bink versions? [11:35:45] <kshishkov> not much [11:35:54] <kshishkov> all seems to play fine [11:36:07] <pross-au> No 'a' [11:36:09] <kshishkov> though there is one BIKh sample with minor artifacts [11:36:15] <kshishkov> not at all [11:37:17] <kshishkov> theoretically if someone could sort that list of games using Bink by year... [11:39:51] <Dark_Shikari> that would be a long list [11:40:05] <pross-au> its published on their website Dark_Shikari [11:40:30] <pross-au> one would need to scrape it, and then run some queries on mobygames [11:43:56] <byteme`> hmm [11:44:21] <CIA-92> ffmpeg: pross * r22022 /trunk/libavformat/bink.c: low-complexity Bink file seeking [11:44:58] <kshishkov> < CIA-92> ffmpeg: pross * r22023 /trunk/libavformat/bink.c: HEv1 Bink file seeking [11:45:39] <pross-au> HEv1? [11:45:58] <kshishkov> yes, "low-complexity" makes me think of AAC [11:46:10] <pross-au> we'll i have a complex version working, but its ugly [11:47:20] <pross-au> it seeks through the file at read_header() time. so... need to write a 'index cache' type thing for it [11:49:09] <kshishkov> nah, it won't work fine with Bink Streaming Server [11:51:48] <pross-au> Bwahaha [11:52:34] <CIA-92> ffmpeg: pross * r22023 /trunk/libavcodec/mmvideo.c: it is not necessary to display the decoder name, as av_log() automatically prints the context [11:53:16] <pross-au> ^^^^ there's about 100 instances like this through libavcodec [11:53:27] <kshishkov> mostly for old codecs [11:53:38] <pross-au> correct [11:53:51] <pross-au> 'classics' [11:53:55] <kshishkov> someone should update them a bit [11:54:21] <pross-au> Update? How? [11:54:23] <kshishkov> do you consider Mike as a living classic since many of those are his creation? [11:55:10] <kshishkov> update = use new features like bytestream, rewrite messages, throw out useless checks, whatever [11:58:08] <pross-au> It will happen when the supply of interesting new codecs drys up. [11:58:23] <kshishkov> heh [11:58:47] <pross-au> Think peak oil :D [11:58:51] <pross-au> Peak Codec :D [12:00:26] <merbzt1> :) [12:00:40] <merbzt1> I think we have reached it [12:01:08] <merbzt1> what interesting stuff is left ? [12:01:18] <kshishkov> Windows Media stuff [12:01:20] <merbzt1> wmalossless, indeo4 [12:01:22] <kshishkov> voice codecs [12:01:29] <byteme`> voip codecs? [12:01:29] <merbzt1> g72* [12:01:31] <kshishkov> screen codecs [12:01:34] <pross-au> Bink is comparable to the oil underneath an antarctica. Its a long way to go, for very little... [12:01:59] <kshishkov> pross-au: then BIKb is an oil on Mars [12:02:13] <pross-au> Indeed [12:02:35] <byteme`> g729 would be nice but it's heavily patented [12:03:18] <av500> so? [12:03:29] <Compn> there are still a bunch of codecs to go :) [12:03:32] <kshishkov> some people may want Apple Indermediate and ProRes codecs [12:03:44] <Compn> we havent run out yet [12:03:50] <pross-au> Compn <- Climate Change Skeptic [12:03:53] <kshishkov> too bad [12:04:05] <byteme`> av500: doesn't that present an issue? ( I'm really new to media formats when it comes to legal licensing issues ) [12:04:25] <merbzt1> byteme`: for us it doesn't matter [12:04:34] <kshishkov> byteme`: our position on patents in expressed in your nickname [12:04:40] <byteme`> haha [12:04:45] <byteme`> cool :) [12:07:54] <av500> byteme`: it is not illegal to write source code for patented stuff [12:08:53] <byteme`> good to know. I really need to read up more on licensing before I speak about it again :) [12:10:35] <byteme`> av500: so lets just say I was a genius and implemented a G729 encoder from the patent spec... would some US company try and sue me for submitting an encoder patch to the ffmpeg devel mailing list? [12:10:51] <kshishkov> no [12:11:04] <byteme`> ok [12:14:57] <Dark_Shikari> byteme`: patents apply to use [12:15:01] <Dark_Shikari> not to writing code [12:15:07] <Dark_Shikari> code is a description of an implementation, not an implementation [12:15:19] <kshishkov> especially when there's standard [12:15:24] <Dark_Shikari> of course [12:15:28] <Dark_Shikari> since the standard itself is basically code [12:15:59] <Dark_Shikari> if a company uses a G729 encoder in ffmpeg, they may (depending on the country) need to pay license fees [12:16:02] <Dark_Shikari> but it's their responsibility, not ours [12:16:23] <Dark_Shikari> no open source project in history has ever gotten a patent lawsuit, AFAIK. [12:17:03] <Dark_Shikari> there's been dmca stuff and similar (e.g. threats over rtmpdump), but patent lawsuits are always aimed at users (primarily companies), if at all. [12:17:22] <byteme`> that is good to know :) [12:17:26] <Dark_Shikari> users/distributors [12:17:46] <Dark_Shikari> ffmpeg policy is basically "we don't give a fuck about patents, the US is a crappy country anyways" [12:18:01] <byteme`> haha [12:18:18] <byteme`> yeah I don't like how there are 20 million lawyers these days [12:18:37] <byteme`> I read an article that says you have a 1 and 4 chance of getting sued in your lifetime [12:18:45] <byteme`> if you live in the US [12:19:34] <byteme`> that statistic increases if you start a business by another 10-15% according to the article. [12:20:20] <Dark_Shikari> hmm, that sounds a bit high. [12:20:31] <Dark_Shikari> Like maybe something from a legal office trying to promote themselves ;) [12:22:56] <byteme`> heh :) [12:30:59] <av500> byteme`: if you are a foreign country doing business in the us, chances are 500% your will get sued... [12:31:05] <av500> err, foreign company :) [12:31:23] <byteme`> I'm a poor US citizen ( college student ) [12:31:33] <av500> byteme`: you are safe (for now) [12:31:38] <byteme`> heh [12:31:45] * kshishkov is safer anyway [12:32:15] <av500> kshishkov is is safe haven [12:32:19] <av500> is in [12:32:43] <kshishkov> we have low standards compared to Australia though [13:12:26] <CIA-92> ffmpeg: kostya * r22024 /trunk/libavcodec/vc1dec.c: [13:12:26] <CIA-92> ffmpeg: ff_msmpeg4_decode_init() calls ff_h263_decode_init() which calls [13:12:26] <CIA-92> ffmpeg: MPV_common_init(), so calling both is redundant and leads to memory [13:12:26] <CIA-92> ffmpeg: leaks in WMV3/VC-1 decoder. Thus use only the first function in [13:12:26] <CIA-92> ffmpeg: WMV3/VC-1 decoder initialization. [13:12:46] <beaver> www.search2.net [13:13:00] <CIA-92> ffmpeg: michael * r22025 /trunk/libavcodec/h264_cabac.c: Replace ad-hoc fill rectangle by fill_rectangle(). [14:23:24] <DonDiego> byteme`: unfortunately people are driven by unreasonable fear when nothing more than a word from a legal context is used against them.. [14:23:46] <DonDiego> are you afraid of holding hands in public? kissing? drinking beer? [14:24:07] <DonDiego> there *are* places where you can go to prison for any of them... [14:24:23] <kshishkov> DonDiego: in US for the last thing I heard [14:25:05] <DonDiego> nobody is kept awake at night in euroope because they drink beer in public [14:25:13] <DonDiego> even though you cannot do it in the US [14:25:43] <DonDiego> but when they might infringe a us patent, suddenly they *are* kept awake at night.. [14:25:47] * DonDiego shakes his head [14:26:14] <kshishkov> DonDiego: because lawyers are US mafia [14:26:25] <DonDiego> no [14:26:33] <DonDiego> it's people being irrational [14:27:19] <Honoome> DonDiego: companies generally have a good reason for that [14:27:29] <Honoome> (they sell goods/services in the US as well) [14:27:55] <Honoome> but yeah, it's irrational for private, single people to get upset about US patents while living in a (sorta) more free side of the world [14:28:04] <Honoome> I say that sorta in context of latest Google's official blog post [14:28:34] <kshishkov> they have blog? [14:28:45] <Honoome> kshishkov: they have many blogs [14:28:50] <KotH> DonDiego: i dont think it's irrational [14:29:08] <KotH> DonDiego: us companies are known to apply us law in any other country as well [14:29:10] <Honoome> kshishkov: http://googleblog.blogspot.com/2010/02/serious-threat-to-web-in-italy.html?… [14:29:19] <KotH> DonDiego: or you get sued in the us [14:29:24] <KotH> DonDiego: just think of CERN [14:29:41] <Honoome> KotH: that applies to companies and not individuals though, doesn't it? [14:29:50] <KotH> Honoome: think of decss [14:29:58] <DonDiego> KotH: nonsense [14:30:09] <DonDiego> of course us law applies when you do business in the usa [14:30:11] <DonDiego> not before [14:30:21] <kshishkov> think of TPB [14:30:33] <Honoome> KotH: ah forgot rule number one: don't ever enter american soil [14:30:40] <mru> KotH: and CERN didn't seem to care much, did they? [14:30:54] <KotH> mru: actually they do [14:30:55] <DonDiego> kshishkov: TPB is still running ... [14:31:05] <KotH> mru: part of their coils are produced at fermilab [14:31:07] <Honoome> KotH: beside, doesn't decss have to do with DMCA and not patents? [14:31:09] <DonDiego> what happened with cern? [14:31:39] <KotH> Honoome: yes, it was a dmca claim, not patent. but it shows that even individuals can get sued [14:31:56] <Honoome> KotH: different kinds of laws though [14:32:01] <KotH> DonDiego: they got sued for "endangering the world by willfully producing black holes" [14:32:08] <Honoome> I think DMCA was classed as a criminal offense (jail sentence) but patents iirc are not [14:32:52] <kshishkov> KotH: one has to try hard to prove he is a patented idiot... [14:33:30] <DonDiego> KotH: where did individuals get sued? [14:34:00] <KotH> DonDiego: as i said, decss [14:34:10] <KotH> DonDiego: yes, i know the outcome of the whole issue [14:34:12] <kshishkov> TPB as well [14:34:28] <KotH> kshishkov: in that field, mininova too [14:34:28] <DonDiego> but you are getting things wrong [14:34:40] <DonDiego> dvd jon was sued in their *home* country [14:34:41] <Honoome> neither applied to patents [14:34:50] <DonDiego> TPB as well [14:34:57] <DonDiego> and nothing to do with patents, yes [14:35:02] <DonDiego> and this is the problem [14:35:04] <DonDiego> people [14:35:11] <DonDiego> *please* try to get a clue [14:35:20] <KotH> DonDiego: nope, the first trial was in the us [14:35:26] <kshishkov> Salem? [14:35:31] <DonDiego> patents != copyright != trademarks [14:35:31] <KotH> DonDiego: the second and third was in .nl [14:35:42] <DonDiego> KotH: what trial [14:35:51] <KotH> DonDiego: on decss [14:36:07] <DonDiego> it's not constructive to start talking about decss or TPB when the topic are patents [14:36:16] <KotH> DonDiego: i might not have a clue on legal stuff, but i follow what's happening in the world [14:36:16] <DonDiego> it only leads to one thing: more confusion [14:36:32] <DonDiego> you must differentiate between these issues [14:36:38] <KotH> DonDiego: i know that most of it is just hot air, but that does not mean that people do not have a reason to fear us companies [14:36:47] <DonDiego> fsk [14:36:50] <DonDiego> fsck [14:36:57] * KotH checks DonDiegos harddisks [14:37:00] <DonDiego> stop spreading FUD already [14:37:46] <kshishkov> KotH: actually patents unlike copyright are local, i.e. valid only in one country. You can do what you want outside it and won't get sued. [14:37:50] * KotH spreads chocolate instead [14:37:59] <KotH> kshishkov: not true [14:38:00] <DonDiego> *local* laws is what you have to take into account [14:38:07] <KotH> kshishkov: there are a lot of countries with patent treaties [14:38:29] <kshishkov> KotH: still that requires patent issued there [14:38:31] <KotH> kshishkov: ie, if you get sued over a patent in country A, that has effects in country B too [14:38:38] <DonDiego> that makes them *local* patents [14:38:41] <mru> I'll enforce yours if you enforce mine? [14:38:48] <KotH> mru: juup [14:38:49] <DonDiego> so repeat after me please: [14:39:02] <DonDiego> *local* laws is what you have to take into account [14:39:04] <KotH> mru: and all of your patents are valid here too [14:39:15] <KotH> *local* laws is what you have to take into account [14:39:23] <KotH> DonDiego: happy? ;) [14:39:41] <DonDiego> you get *stoned* for extramarital affairs in iran [14:39:44] <mru> there's only one letter difference between law and flaw... [14:39:46] <KotH> DonDiego: you know where i stand regarding patent and similar issues [14:39:47] <kshishkov> no go study Paris Convention [14:40:00] <kshishkov> mru: in practice there's even less difference [14:40:07] <DonDiego> so do people in, e.g. france, fear for their lives when they have an affair? - no [14:40:20] <mru> they fear their wives though [14:40:29] <mru> well, not in france actually [14:40:30] <kshishkov> *local* laws is what you have to take into account :) [14:40:48] <DonDiego> neither should somebody in, say, japan, fear that they might get sued for dmca infringement [14:40:59] <DonDiego> when they circumvent decss [14:41:07] <DonDiego> dmca is a US law, does not apply in japan [14:41:08] <KotH> DonDiego: actually, you do [14:41:16] <DonDiego> NOOOOOOOOOOOOOOOO [14:41:21] <KotH> DonDiego: .jp has a treaty on dmca with the us :) [14:41:43] <DonDiego> but then it becomes a LLLLLLLLOOOOOOOOOCCCCCCCCAAAAAAAAALLLLLLLL law !!!!!!!!!!!! [14:41:49] <KotH> yeah [14:41:50] <DonDiego> is that so hard to understand [14:42:07] <DonDiego> i'm harping about this because [14:42:09] <kshishkov> until ACTA comes and it all becomes *global* law [14:42:29] <DonDiego> people really do fear non-local laws that do not apply to them [14:42:38] <kshishkov> not here [14:42:42] <DonDiego> and they believe the FUD [14:42:48] <KotH> DonDiego: i do not fear the law [14:42:54] <DonDiego> and they stop living as free people [14:42:55] <KotH> DonDiego: i do fear a company sueing me [14:42:59] <KotH> DonDiego: that's a big difference [14:43:14] <DonDiego> a us company? suing you in .ch? for what? [14:43:18] <KotH> DonDiego: or as the germans put it: recht haben und recht bekommen sind zwei verschiedene dinge [14:43:22] <kshishkov> for chocolate [14:43:31] <DonDiego> WTF [14:43:39] <kshishkov> KotH: they say so in Odessa too. Really [14:43:41] <KotH> DonDiego: erhm... [14:43:42] <DonDiego> attila, please don [14:43:45] <DonDiego> 't be stupid [14:43:59] <DonDiego> of course a court can make a wrong decision [14:44:04] <KotH> DonDiego: you know which name will first pop up if someone want to take down ffmpeg or mplayer? [14:44:10] <DonDiego> but that decision will have to be based on *local* law [14:44:20] <DonDiego> mine probably [14:44:22] <DonDiego> :) [14:44:24] <KotH> DonDiego: yeah sure... and who is going to pay for my lawyer? [14:44:28] <kshishkov> KotH: reregister everything to Gerard Lantau [14:44:49] <DonDiego> we have lawyers [14:45:08] <DonDiego> they are us lawyers, so they can battle the us companies you are afraid of.. [14:45:11] * DonDiego shakes his head [14:45:15] * KotH notelement we [14:45:29] <DonDiego> sure you are element of that group [14:45:49] <DonDiego> if you worry, send them the papers already.. [14:45:51] <KotH> does the fslc handle everything around ffmpeg/mplayer? [14:45:55] <DonDiego> yes [14:46:00] <DonDiego> SFLC [14:46:08] <CIA-92> ffmpeg: ramiro * r22026 /trunk/ffplay.c: [14:46:08] <CIA-92> ffmpeg: Clear freed pointer in ffplay.c. [14:46:08] <CIA-92> ffmpeg: Fixes a crash when audio stream is cycled twice. [14:46:24] <DonDiego> but for some reason they have no reach into china [14:46:29] <KotH> DonDiego: only if they handle cases in .ch too [14:46:45] <DonDiego> ask [14:46:58] <kshishkov> DonDiego: local laws - foreign barbarians has nothing to do in CHina [14:46:59] <DonDiego> but stop spreading FUD already please [14:47:11] <DonDiego> worry about *local* laws [14:47:21] <DonDiego> and tell people to worry about *local* laws [14:47:23] <KotH> DonDiego: again [14:47:27] * av500 spreads FUDge [14:47:33] <DonDiego> this is one of those urban horror stories [14:47:36] <KotH> DonDiego: you know where i stand in issues around patents and copyright [14:47:40] <DonDiego> that people keep spreading [14:48:16] <KotH> DonDiego: and you know what i think about companies trying to demand stuff of ffmpeg/mplayer [14:48:44] <DonDiego> what i know is that you are spreading FUD here by making unqualified statements, sorry for sounding harsh [14:49:45] <KotH> hmm.. [14:49:55] <KotH> i guess it's time that we drink some tea together [14:50:57] <DonDiego> no, seriously, think about it [14:51:11] <DonDiego> this is driving me mad [14:51:25] <KotH> dont worry about that, you are quite mad already ;-> [14:52:40] <DonDiego> http://en.wikipedia.org/wiki/Urban_legend [14:52:57] <DonDiego> seriously, you are contributing to the urban legends of the multimedia hacker space [14:52:57] <KotH> DonDiego: btw: have you seen/read the new oreilly book on ip in oss? [14:53:00] <DonDiego> stop it [14:53:11] <DonDiego> spread clue, not FUD [14:53:24] <DonDiego> i saw you had it in your hand at fosdem [14:53:28] * KotH continues to spread chocolate for world peace [14:53:49] <KotH> i had a quick look at it, 99% us law in it [14:54:14] <KotH> do you know lawyers specialized in ip stuff from europe? [14:54:37] <KotH> i'd be interested to put together some text about european regulations on ip in contrast to that book [14:54:49] <DonDiego> there was one that wrote for german linux magazine [14:54:59] <KotH> hmm... right [14:55:50] <DonDiego> people read so much about us law that they end up believing it applies to them [14:55:57] <DonDiego> witness what just happened here... [14:56:32] <kshishkov> KotH: wipo.int [14:56:58] <KotH> kshishkov: the wipo isnt interested in any such text [14:57:41] <KotH> the wipo is a mostly us controlled organization that tries to enforce us ideas of copyright, unfair use and patents onto the world [14:57:58] <kshishkov> you forgot trademarks [14:58:04] <janneg> Till Jaeger from http://www.jbb.de/ has worked for Harald Welte in the gpl-violations cases [14:58:51] <janneg> http://www.jbb.de/rechtsthemen/open-source/ [14:58:56] <janneg> KotH: ^^^ [15:00:46] * KotH takes notes [15:01:07] <janneg> KotH: http://www.ifosslr.org/ifosslr might be interested in that text [15:03:44] <janneg> http://www.fsfeurope.org/ftf is probably helpfull too [15:05:47] <KotH> hmm.. interesting [15:05:49] <KotH> danke! [15:06:38] <janneg> https://lists.gpl-violations.org/mailman/listinfo/legal [15:06:57] <DonDiego> and now get informed and please stop spreading misinformation, thank you [15:07:35] <KotH> janneg: i'm not interested in subscribing yet another mailinglist i have no time to read :) [15:07:53] * KotH reads up on usb and continues spreading chocolate [15:13:26] <elenril> J_Darnley: no, i don't understand how it interferes with your patch [15:23:16] <kshishkov> wow, donated NEON code make me feel like _I_ know how write ARM assembly [15:23:57] <mru> it's not pretty [15:24:09] <mru> maybe I should just do it properly from scratch instead [15:24:16] <mru> probably quicker than fixing that stuff [15:24:38] <mru> it requires massive reformatting too [15:26:22] * KotH notes, having 67k mails in an imap folder is not very fast [15:27:07] * av500 59k in his ffmpeg imap folder [15:27:18] <av500> works for me [15:27:34] <KotH> yeah.. but it takes ages to build the cache [15:27:48] <thresh> mutt? [15:27:51] * KotH wonders why imap isnt compressed already [15:27:57] <KotH> thresh: i dont like mutt [15:28:04] <thresh> mutt is notoriously slow with imap, though [15:28:16] <KotH> nothing is fast with imap [15:28:55] <thresh> KotH: kmail is pretty much okay [15:28:57] <mru> 92k mails in my ffmpeg folder [15:29:09] <thresh> no idea how many messages i've got though, probably some tens of thousands [15:31:47] <KotH> thresh: it has a k as its first letter -> not ok [15:32:06] <KotH> and we are talking about ~700k mails [15:32:07] * thresh suspects KotH doesnt run kernel too [15:32:13] <thresh> yeah, same here, corporate stuff [15:32:24] <thresh> ah nevermind, me stupid [15:32:25] <KotH> thresh: i have a system that is completely gnome and kde free [15:32:33] <KotH> thresh: and i want it to stay like that [15:32:50] <thresh> here, have your 100 oils [15:32:55] <elenril> kde too? what do you use for pdfs? [15:33:11] <thresh> *cough* xpdf *cough* ? [15:33:18] * elenril found a good enough replacement for almost everything except okular and okteta [15:34:07] <mru> xpdf is fine [15:34:08] <elenril> xpdf fails at ui [15:34:14] <KotH> the only bloat left on my system are eterm and firefox [15:34:21] <av500> thresh: kmail as in KDE mail? [15:34:29] <thresh> yes [15:34:31] <mru> KotH: eterm? are you mad? [15:34:33] * elenril throws uzbl at KotH [15:34:39] <elenril> and urxvt [15:34:42] <KotH> mru: you should know that answer :) [15:34:49] <mru> "yes" [15:34:52] <av500> o/ JIHAD [15:35:01] <KotH> \o JIHAD! [15:35:25] <av500> thresh: then yours must be a magical one [15:36:53] <thresh> av500: could be. thunderbird was the worst one :S [15:37:30] * av500 prefers tb over kmail any day [15:37:42] * KotH learned to hate tb [15:38:02] * av500 remembers kmail when it used to *block* on reading imap folders... [15:38:23] <mru> pine ftw [15:38:38] <av500> not telnet to imap server? [15:38:51] * mru has done that too on occasion [15:38:58] <mru> openssl connect, actually [15:41:41] * mru checks dependencies of chromium [15:41:54] <Honoome> mru: they are scary scary scary [15:41:58] <mru> OMFG, dbus _and_ gconf [15:42:06] <mru> firefox it'll be then [15:44:46] * elenril thought everything requires dbus these days [15:45:40] <mru> no, not everything [15:45:52] <Honoome> elenril: but leave it to ubuntu and everything will require couchdb [15:46:02] <elenril> lol [15:46:02] <mru> only the bloated stuff needs it [15:46:27] <Honoome> now I could see the point for couchdb but… [15:46:29] <Honoome> HTTP?! really?! [15:46:58] <mru> the very concept of dbus scares me [15:48:13] * elenril runs aptitude why dbus [15:48:56] <elenril> wpasupplicant Depends libdbus-1-3 o_0 [15:49:29] <thresh> yeah, it has dbus interface to communicate with NM for instance [15:49:57] * elenril wonders why would anyone want to communicate with nm [15:52:13] <KotH> dbus' original use (namely communicating hw events to software) was good.. did it quite well actually [15:52:27] <KotH> but making a full fledged ipc system out of dbus was a big big mistake [15:52:38] <mru> I don't want my web browser talking to my dhcp client [15:52:54] <KotH> why not? [15:53:02] <mru> it has no business doing that [15:53:05] <KotH> then your webserver would know that you've lost your connectivity [15:53:12] * elenril doesn't want his webbrowser talking to anything [15:53:24] * elenril installed tomoyo specifically because of that [15:53:50] <mru> if connect() works, link is up, otherwise not [15:53:51] <mru> simple [15:54:04] <av500> elenril: she keeps you safe? http://images.google.com/images?q=tomoyo [15:54:36] <elenril> av500: sure she does http://tomoyo.sourceforge.jp/ [15:54:48] <av500> mru: dont you want your compromised webbrowser plugin to talk to your router to open up some ports? [16:04:20] * Kovensky prefers sakura [16:05:37] <twnqx> [aac @ 0x684cc0]More than one AAC RDB per ADTS frame is not implemented. Update your FFmpeg version to the newest one from SVN. If the problem still occurs, it means that your file has a [16:05:37] <twnqx> feature which has not been implemented. [16:05:39] <twnqx> :( [16:10:06] <felipec> is there a way to run fate just once with a git repo I already have? (not pull or anything) [16:10:47] <mru> if only it used pkgconfig I'm sure that would be trivial [16:17:02] <CIA-92> ffmpeg: michael * r22027 /trunk/libavcodec/h264_cabac.c: [16:17:02] <CIA-92> ffmpeg: Replace mvd>2 + mvd>32 by MIN((mvd+28)*17>>9, 2) [16:17:02] <CIA-92> ffmpeg: same speed as far as i can meassure but it might have fewer branches on some [16:17:02] <CIA-92> ffmpeg: archs. [16:17:02] <CIA-92> ffmpeg: Idea from x264 / jason [16:20:15] <J_Darnley> elenril: it looks wrong to write the same string twice into a file and it looks wrong to say that lavf is the encoder [16:22:59] <elenril> encoder is just a generic tag name, means muxer for global metadata, encoder for per-stream [16:23:19] <elenril> (and in many formats it actually is called encoder) [16:25:09] <elenril> as for writing it twice, i don't see anything really wrong with that [16:25:57] <elenril> feel free to add an exception for it though [16:26:21] <elenril> imo it's still better than adding exceptions to at least avi, id3, nut and asf muxers [16:36:24] <J_Darnley> okay then [17:42:19] <BBB> elenril, I forgot the patches, any more I should apply? [17:42:28] <BBB> elenril, and could you comment on the issue raised on cvslog? [17:43:24] <kshishkov> I think Benoit has applied his yearly quota of patches already [17:44:40] * elenril slaps kshishkov [17:44:52] <elenril> BBB: i already talked with J_Darnley about that [17:45:55] <kshishkov> elenril: if you'd started earlier you could get write account by now [17:46:03] <elenril> if you have time, i'd like to have "mention that metadata tags are UTF-8" applied [17:46:22] <elenril> and patches 01 and 06 from " asf - read/write metadata as UTF-16" [17:46:41] <elenril> kshishkov: earlier? [17:46:53] <kshishkov> yep, several years ago [17:47:12] * elenril was a n00b several years ago [17:47:23] <elenril> used windoze even [17:47:26] * kshishkov started in 2004 and got account in 2006 (after ~1.5 years) [17:48:16] * elenril can live without an account just fine as long as his patches get applied [17:53:19] * Honoome wonders where Baptiste is [17:53:35] <kshishkov> USA probably [17:53:58] <Honoome> kshishkov: more where did he disappear to as I'm waiting for you to be sure not to get Michael's rebus wrong [17:54:02] <Honoome> but on this note, I'll go fetch my coffee [17:54:57] * Kovensky goes fetch coffee too [17:55:59] <kshishkov> Kovensky: local or good one? [17:57:26] <Kovensky> whatever's on the kitchen ._. [17:57:32] <Kovensky> but it seems that we ran out of coffee [17:57:50] <kshishkov> who has ever heard of Brazilian coffee anyway? [17:58:09] <BBB> elenril, forward me the relevant msg with attachment, or some way to identify the message in my inbox [17:58:21] <BBB> elenril, lots of msgs/patches, not much time :) [17:58:37] <kshishkov> BBB: "silence elenril about this patch" should fit them all [17:59:34] <elenril> BBB: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083705.html [18:00:00] <elenril> patches 01 and 06 from http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-February/083703.html [18:02:18] <BBB> applied that first one [18:02:35] <CIA-92> ffmpeg: rbultje * r22028 /trunk/libavformat/avformat.h: [18:02:35] <CIA-92> ffmpeg: Mention that metadata tags are (unvalidated) UTF-8. [18:02:35] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [18:05:06] <BBB> they are attached as 6-1 [18:05:10] <BBB> should I apply 1-6 or 6-1? [18:05:16] <BBB> i.e. what order? [18:06:54] <CIA-92> ffmpeg: michael * r22029 /trunk/libavcodec/h264_cabac.c: [18:06:54] <CIA-92> ffmpeg: Factorize common code from the top of decode_cabac_mb_mvd() [18:06:54] <CIA-92> ffmpeg: 10-15 cpu cycles faster. [18:07:39] <Kovensky> <@kshishkov> who has ever heard of Brazilian coffee anyway? <-- there's some propaganda here that says that brazilian coffee is the best or one of the best in the world, but that everything goes to exports and we drink shitty (insert random other south american country) coffee [18:09:19] <CIA-92> ffmpeg: rbultje * r22030 /trunk/libavutil/common.h: [18:09:19] <CIA-92> ffmpeg: Add PUT_UTF16() macro. [18:09:19] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [18:10:37] <CIA-92> ffmpeg: rbultje * r22031 /trunk/libavformat/asfenc.c: [18:10:37] <CIA-92> ffmpeg: Eliminate put_str16(). [18:10:37] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [18:10:57] <elenril> BBB: 1 and 6 [18:11:13] <elenril> i'm not yet sure if the other are oked :) [18:11:17] <BBB> elenril, are you SURE that patch 3 doesn't break the demuxer? [18:11:23] <troy_s> Yuvi: Are my eyes deceiving me or did the 16-235 non stretch get pushed to main? [18:11:24] <BBB> oh! I just started applying them [18:11:25] <BBB> dude [18:11:35] <BBB> be clearer :) [18:11:53] <elenril> sorry [18:12:05] <elenril> it's probably ok though [18:12:30] <kshishkov> Kovensky: Colombian coffee seems to be better. Not that I drink any. [18:13:14] <elenril> BBB: 0003-asf-don-t-add-WM-prefix-to-all-tags.patch [18:13:17] <elenril> this one? [18:13:25] <elenril> why should it break the demuxer? [18:13:36] <BBB> because the demuxer uses that metadata conv table also [18:14:03] <BBB> michael ok'ed it [18:14:09] <BBB> I'm just asking because I'm too lazy to check [18:14:23] <BBB> and honestly, one thread per patch is better [18:14:34] <BBB> don't do this again, I can barely keep up with this... [18:14:50] <elenril> most of these don't make any sense by themselves [18:17:37] <BBB> 1-3 applied [18:17:38] <BBB> anything else? [18:17:38] <CIA-92> ffmpeg: michael * r22032 /trunk/libavcodec/h264_cabac.c: switch back to (amvd>2)+(amvd>32), its 5 cpu cycles faster now. [18:17:40] <BBB> 6? [18:17:43] <elenril> yes [18:18:08] <BBB> 4 and 5? [18:18:10] <BBB> no? [18:18:24] <CIA-92> ffmpeg: rbultje * r22033 /trunk/libavformat/ (asf.c asfenc.c): [18:18:24] <CIA-92> ffmpeg: Don't add WM prefixes to all written ASF tags. [18:18:24] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [18:18:29] <elenril> no, don't apply them yet [18:18:30] <kshishkov> not approved maybe [18:18:58] <kshishkov> elenril: I've always wanted to ask why your nickname sounds like certain cat food brand [18:19:56] <BBB> ok done [18:20:16] <elenril> kshishkov: i want to know that too [18:20:52] <CIA-92> ffmpeg: rbultje * r22034 /trunk/libavformat/asfdec.c: [18:20:52] <CIA-92> ffmpeg: Read ASF metadata as proper UTF-16 and spit it out as proper UTF-8 in our [18:20:52] <CIA-92> ffmpeg: metadata system. [18:20:52] <CIA-92> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [18:20:59] <elenril> but there are ThingsManWasNotMeantToKnow [18:21:01] <elenril> BBB: thanks [18:21:43] <kshishkov> elenril: good explanation. I'll file it into HilariousInHindsight category [18:22:21] <BBB> all applied except 4/5 [18:22:28] <BBB> please start a new thread [18:22:31] <BBB> I'm confused [18:23:01] * BBB goes for lunch [18:31:50] * kshishkov notes a good slogan "Confused? Go for lunch!" [18:35:11] * elenril goes for dinner [18:50:50] <CIA-92> ffmpeg: michael * r22035 /trunk/libavcodec/h264_cabac.c: [18:50:50] <CIA-92> ffmpeg: Calculate mvd without abs() [18:50:50] <CIA-92> ffmpeg: same speed (ask gcc why, i dont know) [18:52:16] <kshishkov> oh gcc, why? [18:55:42] <Dark_Shikari> that's _good_ [18:55:48] <Dark_Shikari> it means gcc did it well the first time ;) [18:56:07] <kshishkov> it's quantum fluctuation [19:21:53] <BBB> so that doesn't worek [19:22:42] <BBB> oops [19:23:05] * BBB hates it when stuff is behind other windows but in focus [19:23:23] * elenril <3 sloppy focus [19:23:49] <_av500_> focus follow mouse, no? [19:24:22] <_av500_> elenril: asfdec reads the ID3/TXXX tags? [19:24:37] <kshishkov> _av500_: yes, into mousehole as well [19:24:52] <elenril> av500: yes, except windows retain focus when mouse is over desktop [19:25:07] <elenril> av500: no, it doesn't [19:25:16] <BBB> _av500_, you're confused x 5 [19:25:18] <elenril> give me specs and samples and i might implement it [19:25:28] <_av500_> specs is easy [19:25:33] <BBB> _av500_, no linux here, also I barely use my mouse, and I switch virtual desktops like 10x per minute [19:25:58] <Dark_Shikari> get a bigger monitor [19:26:00] <kshishkov> fingers stuck on Alt and Tab? [19:26:05] <_av500_> elenril: use ID3/TPE1 as if it were WM/Artist [19:26:18] <_av500_> but sample I only have your broken one [19:26:29] <BBB> Dark_Shikari, laptop [19:26:35] <BBB> kshishkov, yes [19:27:16] <BBB> actually [19:27:22] * elenril has a big monitor and 10 virtual desktops [19:27:22] <BBB> I'm getting a new laptop in ~3 months [19:27:30] <BBB> should I go for a 17" or 15"? [19:27:33] <_av500_> why 3? [19:27:35] <elenril> _av500_: err why do you need it if you have no samples [19:27:36] <BBB> I'm wondering if 17" is like overkilling it [19:27:54] <kshishkov> no [19:27:57] <mru> for a laptop anything about 13" is too big [19:28:07] <_av500_> 3pounds ftw [19:28:10] <BBB> nah, I work on it all day [19:28:12] <BBB> need bigger [19:28:18] <kshishkov> 30" tablet please [19:28:30] <mru> BBB: then you need a desktop [19:28:37] * mru has 2x24" on desk [19:28:39] <_av500_> kshishkov: you use that in .ua public transport please :) [19:29:07] <kshishkov> _av500_: you use .ua public transport please [19:29:55] <_av500_> not without my 30" tablet to defend myself [19:30:26] <ohsix> just in glass a 30" tablet would weigh a ton [19:31:07] <_av500_> for small values of ton [19:31:54] <ohsix> 1 30" standard glass weight plus mechanics ton [19:32:37] <kshishkov> mechanics? [19:33:04] <ohsix> 3m and stuff has some pretty magical glass, but over a certain size you just have to make it thicker or its own lack of rigidity will imperil it [19:33:09] <kshishkov> cogwheels and levers? [19:33:34] <ohsix> and steam whistles [19:33:44] <_av500_> kshishkov: it needs a fruit crate around the glass [19:34:59] <kshishkov> ecodesign? [19:35:16] <_av500_> cupertino design [20:25:41] <BBB> mru, not portable enough [20:25:56] <BBB> mru, you forget that I work at university most of the day, and at home in the weekend [20:25:59] <BBB> don't want 2 computers [20:26:02] <BBB> or come into uni weekends [20:26:04] <BBB> so laptop [20:26:18] <mru> but you _need_ 2 computers [20:26:34] * byteme` has 2x24" as well [20:26:44] <ohsix> i ended up with a 15" i'd thought would be too small/low res; but i use it nearly 24/7 now [20:26:49] <mru> byteme`: do you have 6 virtual desktops on each too? [20:26:56] <byteme`> yes [20:26:58] <byteme`> I use fluxbox [20:27:09] <mru> xinerama or separate? [20:27:16] <byteme`> xinerama [20:27:23] <mru> separate here [20:27:27] <byteme`> had to play with the nvidia drivers a bit [20:27:27] <mru> it's fantastic [20:27:42] <ohsix> my desktop has a 2048x1152 cute lcd <3 its almost threatening after using the laptop for a while [20:27:51] <mru> it's a bit annoying that firefox refuses to run on both screens [20:28:22] * mru has a 2048x1152 too [20:28:25] <ohsix> do you use dmx or anything with the separate servers? [20:28:28] <byteme`> I'm basically at 3840x1200 [20:28:40] <mru> single server [20:28:42] <BBB> mru, why 2 computers? [20:28:44] <mru> multiple screens [20:28:47] <BBB> to work on 2 a the same time? [20:28:50] <BBB> then get 2 laptops [20:29:04] <byteme`> I may add a 3rd screen for a mac [20:29:07] <mru> BBB: laptop for portable needs and desktop for real computing [20:29:08] <byteme`> 3rd 24" [20:29:09] <ohsix> oh, ic [20:29:15] <BBB> mru, maybe, used to have it [20:29:21] <BBB> mru, but manhattan apts are small [20:29:25] <BBB> mru: so no, not for now [20:29:27] <ohsix> those samsung panels rule btw :O [20:29:36] <_av500_> BBB: get small laptop then [20:29:47] <BBB> big laptop is still small [20:29:51] <byteme`> <-- Dell 2407 LCD [20:29:56] <byteme`> they are cheap now [20:30:16] <_av500_> BBB: but desktop can render BBB while you are away :) [20:30:39] <ohsix> byteme`: heh, only because you cant really buy the one that was worth ownning anymore :O though last i looked they still had a -HC version [20:30:39] <BBB> like I said, no space [20:30:53] <BBB> manhattan apts are too expensive to waste space on a big fat desktop computer [20:31:05] <byteme`> ohsix: I got mine from ebay [20:31:56] <ohsix> you could always waste some space on an external monitor and play up portability for a smaller form factor [20:32:35] <ohsix> my 15" has a keypad and everything, i <3 its cheapness [20:34:08] <Kovensky> http://www.boingboing.net/2010/02/24/ip-alliance-says-tha.html <-- /facepalm [20:35:21] <elenril> lawl [20:35:33] <ohsix> well they have a point with all the red baiting going around [20:35:51] <ohsix> at least one nutters will take at face value ;] [20:36:31] <byteme`> for a laptop I have the Dell 1569 studio [20:37:41] <Kovensky> http://www.economist.com/business-finance/displaystory.cfm?story_id=15570585 [20:38:48] <CIA-92> ffmpeg: michael * r22036 /trunk/libavcodec/rectangle.h: Extend fill_rectangle() support for 16bit [20:39:31] <CIA-92> ffmpeg: michael * r22037 /trunk/libavutil/intreadwrite.h: AV_COPY16() & AV_ZERO16() [20:40:58] <Dark_Shikari> hmm, michael must be doing something interesting ;) [20:41:03] * Dark_Shikari guesses mvd-related [20:43:43] <j-b> did anyone worked on VP6 interlaced? [20:43:59] <CIA-92> ffmpeg: michael * r22038 /trunk/libavcodec/ (h264.c h264.h h264_cabac.c): [20:43:59] <CIA-92> ffmpeg: Change mvd_cache & mvd_table to 8bit, this is overall a bit faster [20:43:59] <CIA-92> ffmpeg: for high resolution videos. [20:43:59] <CIA-92> ffmpeg: about 20cycles faster per MB for cathederal. [20:44:34] <Kovensky> http://m.news.com/2166-12_3-10458570-71.html <-- /facepalm2 [20:44:47] <Kovensky> * Dark_Shikari guesses mvd-related <-- how did you know D: [20:51:07] <BBB> j-b: no that I've heard of [20:51:13] <BBB> I thought vp8 was the new shit anyway [20:52:07] <j-b> BBB: ok, that is what I thought. [20:53:00] <j-b> I just had a sample in my incoming [20:53:46] <elenril> w00tness, mkvenc writes AV_NOPTS as duration [20:54:15] <BBB> that's pretty cool [20:54:23] <BBB> ffmpeg-specific feature!!! [20:54:25] <elenril> isn't it [20:54:37] <BBB> I bet that only ffmpeg can decode that duration correctly [20:54:56] * elenril doesn't know about that [20:55:07] <elenril> i don't want to run ffplay as it can crash X [20:55:12] <elenril> mplayer doesn't play it [20:55:15] <BBB> lol :) [21:01:10] <Kovensky> http://blogs.gnome.org/seth/2010/02/23/i-did-the-worst-design-of-my-life-wi… [21:01:32] <mru> gnome is the worst "design" in many people's lives [21:06:43] <elenril> anyone knows where is duration set? [21:09:35] <elenril> nvm, i think i got it [21:10:22] <ohsix> heh @ the icon thing; it always sort of bothered me the way they'd stream in when you opened a menu; and it used too change the menu width too [21:12:52] <mru> does michael have a 64-bit machine? [21:13:21] <ohsix> he has babbages machine [21:13:31] <mru> 'cause he just broke all 32-bit builds [21:13:44] <elenril> w00t! [21:13:52] <mru> fate is crying [21:14:19] <_av500_> isnt 32bit really 90s... [21:15:54] <BBB> Kovensky, seth is a hero in many ways, although I often disagree with him [21:16:04] <BBB> but seth did design most of gnome2's UI stuff [21:16:07] <BBB> he really is quite good [21:16:12] <Dark_Shikari> Kovensky: psychic powers [21:16:28] <Kovensky> Dark_Shikari: oh you [21:16:31] <Kovensky> BBB: heh [21:23:25] <ohsix> i dont much mind if something like the icon thing happens as long as its evident the turnover is high; the higher it is the better the chance they have at doing novel things instead of dum things [21:23:47] <_av500_> what is the icon thing? gnome has icons now? [21:23:51] <ohsix> i'm biased though, i did hate the flow in width changw [21:24:03] <elenril> Yuvi: you're maintaining matroskaenc, right? [21:24:22] <Yuvi> elenril: yeah [21:25:58] <Compn> blah, sbr aac stream http://amber.streamguys.com:4210/ [21:26:01] <Compn> but it plays ok [21:26:05] <elenril> when transcoding with -ss, i get duration=(uint64_t)-1 [21:26:30] <elenril> Yuvi: i think the problem is that mkvmuxcontext.duration is unsigned [21:26:44] <elenril> can you look at it? [21:27:53] <Yuvi> do all pkt->pts have values? [21:27:57] <elenril> yes [21:28:02] <elenril> but soem of them are negative [21:28:57] <Yuvi> hm, negative pts will cause more problems than just duration calculation [21:29:23] <elenril> i thought negative pts are allowed [21:31:26] <janneg> Linuxtag Call for Projects: http://wiki.linuxtag.org/w/fp:Call_for_Projects [21:34:59] <byteme`> can I ask a non-ffmpeg related question? It is Linux related [21:35:28] <byteme`> actually nevermind [21:35:35] * byteme` needs to rtfm more [21:36:46] <elenril> hmm, you were right, there's more things broken than just duration [21:38:10] <janneg> and I need help rendering Big Buck Bunny. ETA 150 days at the current pace [21:38:37] <ohsix> janneg: amazon s2 [21:39:13] <kierank> you mean ec2 [21:39:37] <ohsix> yea that; but you'll beed to store it somewhere too :> [21:40:36] <janneg> ohsix: are you going to sponser 1800$? [21:41:25] <ohsix> amazon might [21:41:46] <ohsix> osuosl might too [21:44:24] <Kovensky> thresh: http://www.boingboing.net/2010/02/23/dude-in-moscow-hacks.html <-- lolrussia [21:46:38] <byteme`> did google just change the layout of their search results? [21:46:39] <byteme`> hrm [21:47:48] <thresh> Kovensky: yeah the guy's awesome [21:48:12] <thresh> there are even photos of that billboard [21:56:44] <CIA-92> ffmpeg: michael * r22039 /trunk/libavcodec/rectangle.h: Try to fix 100l compilation failure on some systems. [22:04:32] <Dark_Shikari> good job michael ;) [22:05:30] <mru> a few of the tests pass actually [22:06:00] <siretart> Dark_Shikari: I'm currently testing your proposed libx264 backport for libx264. it seems that the 'baseline' and 'main' presets won't work: http://pbot.rmdir.de/6e6695ad8137b28cbcfbc9bc71242786 [22:06:46] <CIA-92> ffmpeg: michael * r22040 /trunk/libavcodec/rectangle.h: Fix doxy and assert(). [22:07:13] <Dark_Shikari> siretart: that's not how they work [22:07:18] <Dark_Shikari> baseline, main, and high are modifier presets [22:07:23] <Dark_Shikari> -vpre hq -vpre baseline [22:07:29] <Dark_Shikari> or -vpre normal -vpre high [22:07:30] <Dark_Shikari> or whatnot [22:07:38] <Kovensky> http://www.ironicsans.com/2010/02/they_dont_make_computer_manual.html :D [22:07:43] <Dark_Shikari> If you want a better system, we just exposed libx264's presets directly in the API [22:07:50] <Dark_Shikari> and you could modify ffmpeg to use them directly [22:07:52] <siretart> oh, I see. that's not exactly clear to me after reading the manpage [22:07:59] <Dark_Shikari> of course it's not clear. it's fucking awful [22:08:05] <Dark_Shikari> you have two options: [22:08:18] <Dark_Shikari> 1) pasteeater has a patch that he submitted to the ML that replaces the presets with new ones [22:08:23] <Dark_Shikari> these new ones are equivalent (as best as possible) to the x264 presets [22:08:28] <Dark_Shikari> and have "firstpass" versions of each one [22:08:34] <Dark_Shikari> well actually that doesn't fix the baseline/high issue either :/ [22:08:41] <Dark_Shikari> 2) make a patch to use the libx264 presets [22:08:51] <Dark_Shikari> this would require an API change at a minimum [22:09:02] <Dark_Shikari> in fact it would probably require codec-specific defaults to work right :/ [22:10:03] <siretart> anyway, it seems that at least for simple invocations, your libx264 backport works fine [22:11:16] <Dark_Shikari> btw, that's how it's always worked [22:11:19] <Dark_Shikari> since the presets were created [22:12:03] <Yuvi> elenril: negative dts is fine (and works with matroska since it's ignored) [22:12:03] <Yuvi> negative pts can't be directly stored in any container afaik, and the only meaning I can think of is "start playback at this non-keyframe after decoding its dependencies" [22:12:03] <Yuvi> so I guess it can be implied from an edit list (mov/mp4), ordered chapters (mkv), or ogg skeleton, but probably very few players actually work correctly [22:14:04] <elenril> well ffmpeg obviously produces it when using -ss [22:14:10] <Yuvi> -vcodec copy? [22:14:12] <CIA-92> ffmpeg: michael * r22041 /trunk/libavcodec/rectangle.h: 3rd and hopefully last 100l fix. [22:14:12] <elenril> so this is a bug in ffmpeg? [22:14:19] <elenril> no, -vcodec libx264 [22:14:33] <Yuvi> it's a bug somewhere, not sure exactly where [22:16:46] <mru> 3rd time lucky [22:24:18] <Yuvi> elenril: from what source? [22:28:14] <elenril> mkv [22:28:25] <elenril> you can't reproduce? [22:28:31] <Yuvi> nope [22:41:07] <CIA-92> ffmpeg: siretart * r22042 /branches/0.5/ (20 files in 3 dirs): [22:41:07] <CIA-92> ffmpeg: backport libx264.c from trunk [22:41:07] <CIA-92> ffmpeg: now compiles with x264 API versions 65 up to 85 [22:41:07] <CIA-92> ffmpeg: patch prepared by darkshikari [22:42:08] <siretart> good night [22:42:12] <Dark_Shikari> \o/ [23:14:53] <janneg> http://www.jannau.net/bbb_videowall/ [23:17:22] <elenril> hmm, weird, now i can't reproduce it myself [23:19:51] <janneg> mru, _av500_: instructions and status for rendering Big Buck Bunny are here http://www.jannau.net/bbb_videowall/ [23:21:08] <peloverde> janneg, what does "complete with rendering error already in the source file" mean? [23:24:05] <janneg> peloverde: look at http://www.jannau.net/peach_2700x1440/01_intro_03_0001.png and you'll see [23:24:56] <janneg> the eyes stay at the same position [23:26:38] <peloverde> that's creepy but I'm still slightly confused about the "already in the source file" part? is it a bug in BBB itself? [23:26:52] <mru> yes, big bug bunny [23:28:10] <janneg> peloverde: it is bug in the production files from the project site and probably also on the dvd [23:29:59] <janneg> i.e. they haven't published the corresponding source files [23:32:03] <Dark_Shikari> which means it's not open source!~!11! [23:40:50] <mru> boo, closed-source bunny :-( [23:41:07] <mru> bunnies _want_ to be free! [23:43:28] <_av500_> janneg: thx, will look into it [23:49:56] <janneg> bah, the OOM killing gets annoying, could only render frame 1 of 02_rabbit/04.blend [23:52:52] <janneg> I could try to add swap but I fear that the rendering speed will decrease from very slow to 1/ludicrous spped [23:53:41] <CIA-92> ffmpeg: stefano * r22043 /trunk/libavutil/fifo.h: [23:53:41] <CIA-92> ffmpeg: Extend doxy for the src parameter of av_fifo_generic_write(). [23:53:41] <CIA-92> ffmpeg: @patchby Tomas H?rdin |tomas dot hardin at codemill dot se| [23:54:16] <iive> janneg: you may give a try to the compressed in memory swap [23:54:36] <iive> in case the data is highly redundant. [23:55:14] <_av500_> janneg: what mem do you need? [23:57:40] <CIA-92> ffmpeg: alexc * r22044 /trunk/libavcodec/aac.c: (log message trimmed) [23:57:40] <CIA-92> ffmpeg: aac: Keep decode_band_types() from eating all padding at the end of a buffer. [23:57:40] <CIA-92> ffmpeg: Due to a shortcoming in the AAC specification, if an all zero buffer is [23:57:40] <CIA-92> ffmpeg: fed to section data decoding it will never terminate. That means without [23:57:40] <CIA-92> ffmpeg: a buffer exhaustion check decode_band_types() will consume all input [23:57:41] <CIA-92> ffmpeg: buffer padding. Worse if a get_bits() implementation that returns zeros [23:57:42] <CIA-92> ffmpeg: when padding is exhausted is used, the function will never terminate.

1 0

IRC log for 2010-02-23
by irc＠mansr.com 24 Feb '10

24 Feb '10

[00:31:35] <mru> damn apple, I can't use an evil hack [00:32:27] <mru> which would be abusing bit 2 of the stack pointer [00:36:20] <BBB> DonDiego, fixed [00:36:26] * BBB goes home [00:36:40] <CIA-46> ffmpeg: rbultje * r21974 /trunk/ (7 files in 2 dirs): Prefix non-static RTSP functions with ff_. [01:08:32] <CIA-46> ffmpeg: michael * r21975 /trunk/libavcodec/h264.c: [01:08:32] <CIA-46> ffmpeg: Move extradata reading code into codec init instead of doing it [01:08:32] <CIA-46> ffmpeg: in read frame. [01:09:42] <CIA-46> ffmpeg: michael * r21976 /trunk/libavcodec/h264.c: [01:09:43] <CIA-46> ffmpeg: Try to set has_b_frames in codec init if we know everything alraedy. [01:09:43] <CIA-46> ffmpeg: This fixes some issues with the first few timestamps. [02:47:11] <astrange> Dark_Shikari: huh, i thought gnash used ffmpeg. so i did learn something from reddit [02:47:27] <mru> what do they use? [02:47:40] <astrange> installing bzr to find out [02:48:00] <astrange> probably nothing, someone in a comment called it "legally dubious" [02:48:06] <astrange> i'll have to ask if that means "not gpl3" [02:48:32] <mru> that's a fair bet on reddit [02:49:06] <Dark_Shikari> lol [02:49:36] <astrange> yeah, nothing [02:51:18] <Dark_Shikari> it was gnash devs who apparently think that a gpl flash player means that they can't play gpl-non-compliant flash files [02:57:13] <Dark_Shikari> siretart`: I'm about to push a revision with some bugfixes plus new features, they're ordered so bugfixes are first, then features [02:57:16] <Dark_Shikari> so you can pick the last bufix revision [02:57:24] <Dark_Shikari> *bugfix [02:57:31] <Dark_Shikari> After this, any further bugfixes will have to be backported. [02:57:56] <Dark_Shikari> so if you have any configure or similar patches you want in, hit me [02:58:11] <astrange> no, i looked in trunk and it has ffmpeg and gst modules... [03:06:52] <Compn> Dark_Shikari : whats this comiket music you talk of ? torrents ? [03:07:12] <Compn> comiket = japanese manga convention iirc [03:09:55] <Dark_Shikari> japanese Stuff convention [03:10:06] <Dark_Shikari> notably, amateur-only, no corporate stuff allowed [03:10:54] <Dark_Shikari> Compn: torrent is http://www.nyaatorrents.org/?page=torrentinfo&tid=113174 [03:11:04] <Dark_Shikari> " [03:11:05] <Dark_Shikari> This torrent is so large it breaks all uTorrent versions up to and including 2.0" [03:11:31] <Compn> crud [03:11:37] <Compn> my ut 1.6 wont like it then [03:12:25] <Dark_Shikari> there's the lossy version, which is "only" 109gb [03:12:41] <Dark_Shikari> most of the music isn't that good anyways, you could probably filter it down to 1/5 the size easily [03:12:49] <Dark_Shikari> but such is true of any sufficiently large collection [03:12:59] <Dark_Shikari> especially since most people don't like all genres anyways [03:13:18] <Compn> i... think i like all genres hah! [03:13:27] <Dark_Shikari> rap? [03:13:29] <Compn> even country (if its good, which is rare) [03:13:35] <Compn> yep [03:13:56] <Compn> i mostly like the rap beats, because i have trouble understanding english lyrics anyways [03:16:45] <mru> omg, ffmpeg .bss has grown to 8MB [03:16:51] <mru> that's unacceptable [03:18:04] <Dark_Shikari> for what [03:18:47] <mru> it's just unacceptable bloat [03:18:52] <mru> it was 4MB a week ago [03:19:40] <Dark_Shikari> yeah, I know [03:19:41] <Dark_Shikari> why is it so big [03:19:43] <Dark_Shikari> who fucked up [03:20:40] <mru> static VLC table_data[8192 * 16][2]; [03:20:53] <Dark_Shikari> which codec [03:20:59] <mru> indeo5 [03:21:02] <Dark_Shikari> ..... [03:21:07] <Dark_Shikari> THAT IS LARGER THAN THE L2 CACHE OF MOST CPUs [03:21:17] <Dark_Shikari> WHAT THE FUCK [03:21:20] <mru> it's larger than everything else in ffmpeg combined [03:21:32] <Dark_Shikari> kostya's fault? [03:21:39] <mru> or maxim [03:22:02] <mru> explains why everything started failing on blackfin suddenly [03:22:10] <mru> I only allocated 5MB for .bss [03:22:45] <ramiro> oh, then that's what added around 300kb to the autobuilds 7z... [03:23:13] <mru> no [03:23:16] <Dark_Shikari> bss is free [03:23:16] <mru> this is .bss [03:23:22] <Dark_Shikari> 300kb was from bink, amr-nb, etc [03:23:28] <mru> it's not free on nommu systems [03:23:59] <ramiro> hmm, right. it just jumped from one day to the other. [03:36:27] <mru> http://pastebin.ca/1806356 [03:36:44] <Dark_Shikari> what's that? [03:37:11] <mru> slashing that table size to 1/8 of the size [03:38:04] <Dark_Shikari> that's still big [03:38:16] <mru> obvious typo though [03:38:19] <Dark_Shikari> way too big [03:38:19] <Dark_Shikari> ah [03:46:43] <CIA-46> ffmpeg: mru * r21977 /trunk/libavcodec/ivi_common.c: Declare indeo VLC table storage with correct type [03:47:17] <mru> back under 5MB [05:21:11] <fizk_> hey guys, can ffplay be written to not depend on SDL? [05:21:26] <fizk_> just OpenGL [05:30:26] <astrange> yes, port mplayer libvo [05:30:40] <astrange> and ao [06:04:12] <pavel_> anybody from ffmeg devs here?? [06:04:33] <pavel_> is it better to write to devel-list or I can as questions here?? [06:05:43] <Dark_Shikari> don't ask to ask, just ask [06:32:07] <pavel_> i just email devel. [06:32:15] <pavel_> i can post it here as well. [06:32:46] <kshishkov> I believe you [06:33:20] <pavel_> i asked if anybody was alive to see my posts... anyways, I'm really late and I have to see a dentist tomorrow morning at 8am, so I need to leave in a few mins. [06:33:45] <pavel_> kshishkov: thanks you very much for believing me, [06:34:59] <kshishkov> hmm, your post misses links to samples [06:35:11] <pavel_> one of the problems was an assert that always hits in avcodec and it's related to h264 (.mov) files filmed with iphone. that was first assert in MPV_frame_start in mpegvideo.c [06:37:14] <CIA-46> ffmpeg: kostya * r21978 /trunk/libavformat/bink.c: Make Bink demuxer pass video flags to decoder [06:37:44] <kshishkov> nevertheless, I doubt that our H.264 dev has iPhone to make samples and fix that condition [06:37:53] <kshishkov> same goes for JPEG [06:40:10] <CIA-46> ffmpeg: kostya * r21979 /trunk/libavcodec/bink.c: Bink video decoder now can use extradata to detect alpha plane presence [06:40:32] <elenril> morning [06:40:50] <kshishkov> as you say [06:41:58] <astrange> r21915 plays video from a 3gs for me [06:42:06] <pavel_> http://dev5.summit-tech.ca/pavel/test.mov [06:42:29] <astrange> plays that too [06:42:52] <astrange> actually i thought asserts were off in that file [06:42:56] <pavel_> As for tandberg cam I have no idea what I can do - I think I might capture raw frames to a file, write a test and mail that.... [06:43:22] <pavel_> that file doesn't have and cannot have asserts :) It's a media file, you build has to be a debug build :) [06:43:31] <astrange> i mean mpegvideo.c [06:43:33] <pavel_> your [06:44:42] <pavel_> well, after I had these problems with jpeg, I decided to make a debug build to see if there was something. I hit that assert, amybe who ever wrote it could review the conditions and possible modify some code... [07:01:38] <CIA-46> ffmpeg: kostya * r21980 /trunk/libavcodec/bink.c: Move plane decoding code into separate function in Bink decoder [07:01:38] <CIA-46> ffmpeg: kostya * r21981 /trunk/libavcodec/bink.c: cosmetics: reindent after last commit [07:08:42] <CIA-46> ffmpeg: kostya * r21982 /trunk/libavcodec/bink.c: Decode alpha plane in Bink video [07:09:05] <Dark_Shikari> \o/ [07:09:11] <Dark_Shikari> Awesome, kshishkov ! [07:09:16] <Dark_Shikari> Any other remaining issues with the files I sent? [07:09:34] <Dark_Shikari> and any progress on the speed issue? [07:10:20] <kshishkov> two issues - speed and sound [07:10:41] <kshishkov> and Bink version 'b' [07:11:02] <Dark_Shikari> what's "b"? [07:12:04] <kshishkov> Bink versions are determined by 3rd byte of file. Currently supported files begin with "BIKf", "BIKh" and "BIKi" [07:12:23] <kshishkov> "BIKb" is an old version requiring separate decoder [07:15:44] <Dark_Shikari> how different is it? [07:15:58] <Dark_Shikari> and what about a,c,d,e? [07:16:24] <kshishkov> some principles are the same, everything else differs - bundle reading, block types, etc [07:16:55] <kshishkov> for a,c-e versions we don't have any samples [07:25:23] <Dark_Shikari> wow. [07:25:27] <Dark_Shikari> that's going to be a lot of work :/ [07:25:30] <Dark_Shikari> you have a lot of b samples? [07:26:34] <kshishkov> let's see... [07:26:48] <kshishkov> http://samples.mplayerhq.hu/game-formats/bink/bikb/ - sould be enough [07:26:50] <kshishkov> *should [07:28:37] <Dark_Shikari> what's the difference between f, h, and i? [07:28:39] <Dark_Shikari> and what's g [07:29:50] <kshishkov> never seen 'g' but it should be virtually the same [07:30:22] <superdump> ? [07:30:26] <kshishkov> 'i' has colour planes swapped and plane size before alpha and luma planes [07:30:42] <kshishkov> superdump: we are discussing Bink versions [07:30:59] <kshishkov> probably some coding methods were added for those versions [07:31:21] <kshishkov> too lazy to verify what coding methods are not present in those old versions [07:42:18] <CIA-46> ffmpeg: kostya * r21983 /trunk/libavcodec/ (indeo5.c ivi_common.c): [07:42:18] <CIA-46> ffmpeg: 10l trocadero: Indeo 5 decoder did not free custom VLCs for macroblock and [07:42:18] <CIA-46> ffmpeg: block decoding at exit, so prevent that memory leak now. [08:05:44] <CIA-46> ffmpeg: daniel * r21984 /trunk/ (configure libavcodec/Makefile): Fix svq1 encoder dependencies [08:10:52] <CIA-46> ffmpeg: daniel * r21985 /trunk/ (configure libavcodec/Makefile): Fix snow encoder dependencies [08:13:19] <CIA-46> ffmpeg: daniel * r21986 /trunk/libavcodec/Makefile: Fix gif encoder dependencies [08:16:34] <CIA-46> ffmpeg: benoit * r21987 /trunk: [08:16:34] <CIA-46> ffmpeg: Add ffprobe to ignore rules. [08:16:34] <CIA-46> ffmpeg: (spotted by Martin) [08:17:41] <pJok> mornings :) [08:17:45] <CIA-46> ffmpeg: daniel * r21988 /trunk/libavcodec/Makefile: Fix wmv2 encoder dependencies [08:18:53] <kshishkov> goda morgnar [08:19:36] <pJok> SJ gets quite a beating these days [08:22:42] <kshishkov> http://www.youtube.com/watch?v=eaXm4FGbZys [08:23:53] <KotH> trevlig morgon [08:24:52] <CIA-46> ffmpeg: daniel * r21989 /trunk/libavcodec/Makefile: Fix mpeg4video parser dependencies [08:25:04] <av500> kshishkov: not bad, at least you can arrest everybody for drunk driving :) [08:26:21] <kshishkov> av500: nah, even if drunk driver kills people it's unlikely he get arrested [08:26:25] <kshishkov> *gets [08:33:19] <CIA-46> ffmpeg: daniel * r21990 /trunk/libavcodec/Makefile: Fix h264 parser dependencies [08:37:58] <CIA-46> ffmpeg: daniel * r21991 /trunk/libavcodec/Makefile: Fix vc1 parser dependencies [08:41:35] <CIA-46> ffmpeg: daniel * r21992 /trunk/libavcodec/Makefile: Fix iff demuxer dependencies [08:41:45] <Dark_Shikari> wee dependency fixes [08:43:02] <drv> should be all done now ;) [08:43:33] <drv> (now time to sleep and wait for 80-column fanatics) [08:44:46] <kshishkov> ok, we'll tell DonDiego [08:45:11] <kshishkov> thanks for vc1 parser too [08:45:27] <drv> in my defense, the existing makefiles are consistent on line length/breaking points, so i don't think i made it any worse... [08:46:28] <drv> kshishkov: btw, any bink samples with > 2 audio tracks? [08:46:37] <drv> format seems to be able to support it, but i haven't seen any [08:46:50] <kshishkov> of course, Psychonauts samples you complained about [08:46:59] <drv> ah really, i should take a closer look then [08:47:45] <drv> hmm, those are multiple tracks but not individual tracks with more than stereo, i think [08:50:02] <drv> anyway, i doubt there are such files, but the format has a field for number of channels rather than just a mono/stereo flag, so i was just wondering [08:50:13] <drv> the encoder only supports selecting mono or stereo [08:50:32] <kshishkov> yes, but there may be many mono/stereo tracks [08:50:36] <drv> right [08:50:41] <drv> i think we support that already though [08:50:43] <kshishkov> your samples have three [08:51:22] <kshishkov> some samples from Dark_Shikari have six audio tracks [08:51:52] <kshishkov> Huh? "Use -h to get full help or, even better, run 'man ffplay'" [09:19:16] <DonDiego> drv: indeed, you messed up the line length, why? [09:19:53] <DonDiego> it's not like breaking a line is going to take you an additional hour and a half.. [09:19:55] <kshishkov> g'day, mate! [09:19:59] <DonDiego> moin [09:20:23] <pross-au> Morning [09:20:49] <kshishkov> looks like people are finally starting complaining about Bink audio. Can't tell why [09:21:10] <pross-au> That was ME [09:21:28] <kshishkov> and that "reported data size does not match output data size" message [09:21:37] <pross-au> oh? [09:21:44] <pross-au> I can fix that [09:21:47] <pross-au> the dct issue, er, no [09:22:08] <kshishkov> well, something strange happens with demuxer too [09:22:27] <pross-au> Yeah? [09:22:50] <kshishkov> yes [09:23:13] <pross-au> I need a little more detail to work on [09:23:15] <kshishkov> I believe you've seen https://roundup.ffmpeg.org/roundup/ffmpeg/issue1767 [09:24:02] <Dark_Shikari> and the fact tha tit sounds like shit [09:24:03] <pross-au> Yeah i read it. Need to go hunting for the password [09:24:04] <Dark_Shikari> *that it [09:24:31] <pross-au> DCT mismatch Dark_Shikari [09:24:42] <Dark_Shikari> needs fixing regardless [09:24:57] <Dark_Shikari> and if you really mean it's just a rounding error, I find that quite unlikely [09:25:27] <pross-au> No its more than that [09:26:05] <kshishkov> it would be nice if demuxer told duration too [09:36:37] <Dark_Shikari> god damn I've used bisect twice today now [09:36:39] <Dark_Shikari> the best git feature, ever [09:37:00] <andoma> Dark_Shikari: indeed! [09:37:51] <bilboed-tp> Dark_Shikari, you know you can have it run automatically a series of command and automatically mark revisions as good/bad ? :) [09:38:05] <Dark_Shikari> yeah I know, but that's effort [09:38:23] <bilboed-tp> true... but well worth it [09:42:41] <Dark_Shikari> oh FUCK. the bug is a fucking ARRAY OVERREAD. [09:42:59] <Dark_Shikari> I hate shit like this. [09:43:09] <Dark_Shikari> well, thank god for regression tests. [09:49:16] <twnqx> wouldn't you love java with runtime bounds checking :P [09:49:32] <kshishkov> even Pascal had that [09:50:09] <twnqx> true, but i always turned it off for performance :P [09:55:40] <elenril> DonDiego: ping [09:55:49] <DonDiego> pong [09:56:00] <DonDiego> sup? [09:56:00] <elenril> can i get svn account? [09:56:16] <DonDiego> for what? [09:56:21] <elenril> for ffmpeg [09:56:30] <DonDiego> why would you be asking me? [09:56:31] <kshishkov> for metadata in FFmpeg ;) [09:56:32] <elenril> patch monkeys are too lazy [09:56:44] <elenril> i thought you handled these things [09:56:49] <DonDiego> no [09:57:02] <DonDiego> i'm not the boss around here, i don't hand out privileges [09:57:33] <DonDiego> you're asking the janitor to get access to company premises [09:57:58] <pross-au> DonDiego: that's how it sometimes works [09:58:26] <DonDiego> your attempts at social engineering fail horribly [09:58:41] <DonDiego> it may work if the janitor can be sure the boss won't notice [09:58:46] <DonDiego> not the case here [09:58:50] <elenril> heh [09:59:02] <elenril> who should i ask then? [09:59:35] <pross-au> kshishkov: were you able to reproduce issue1767 (inconsistent bink framerate)? [09:59:56] <kshishkov> the usual way is to swamp FFmpeg-devel with useful (and accepted) patches so Michael says "give that guy an account" [10:00:25] <kshishkov> pross-au: yes, many Binks start with some slowness then speed up [10:02:51] <av500> kshishkov: with michael reading irc logs, I guess he is aware now :) [10:02:58] <pross-au> i tried both files on mplayerhq and they looked fine [10:03:17] <DonDiego> elenril: ask somebody who thinks you should get an account to ask michael if he agrees [10:03:25] <DonDiego> somebody /= DonDiego [10:03:36] <DonDiego> oh, that was haskell, let me say it in C again.. [10:03:43] <kshishkov> pross-au: it's not "looking", its subjective playing speed I think. Ask jonwil when he's able [10:03:46] <DonDiego> somebody != DonDiego [10:04:00] <pross-au> oh ok [10:04:39] <elenril> ok, does anybody here think i should get an account? :) [10:06:49] <Dark_Shikari> siretart`: 1a6d32b4 is the new target revision [10:06:57] <Dark_Shikari> this contains many new bugfixes, including for some very old bugs. [10:07:31] <Dark_Shikari> aka r1448 [10:08:06] <DonDiego> say [10:08:33] <DonDiego> somebody in that thread on reddit claims that adobe no longer forbids alternative implementations [10:08:37] <DonDiego> is that right? [10:08:55] <av500> they opened the specs [10:08:59] <Dark_Shikari> yes, quite some time ago [10:13:09] <DonDiego> last time i looked at it there was a big disclaimer at the front [10:13:22] <DonDiego> forbidding use in alternative implementations [10:13:58] <DonDiego> i know it was still the case when kostya was working on rtmp [10:13:58] <Dark_Shikari> of course it's not like it's an enforcable clause [10:15:28] <DonDiego> sure, but it's still there, isn't it? [10:15:44] <DonDiego> people are incredibly easy to scare [10:17:10] <DonDiego> "if you run this program, you are forever banned from writing email" [10:25:39] * KotH deletes all of DonDiego's email accoutns [10:27:07] <DonDiego> btw, i'm starting to think that gnash is hurting a flash reimplementation [10:27:20] <DonDiego> it's taking away mindshare and nobody else bothers working on it [10:27:53] <KotH> whats wrong with gnash? [10:27:56] <DonDiego> while at the same time not progressing anywhere... [10:28:02] <DonDiego> KotH: tried using it? [10:28:05] <av500> DonDiego: well, being open source etc, you are supposed to work on gnash, not reimplement [10:28:11] <av500> :) [10:28:18] <DonDiego> av500: there are alternatives [10:28:36] <DonDiego> swfdec and the other one [10:28:44] <DonDiego> i think gnash is based on swfdec [10:28:49] <DonDiego> i keep confusing them [10:29:01] <CIA-46> ffmpeg: pross * r21993 /trunk/libavcodec/binkaudio.c: Use reported_size to truncate final Bink Audio frame [10:29:10] * av500 knows swfdec and gnash [10:29:16] <DonDiego> KotH: i was unable to make gnash play anything and compiling stuff was terribly hard [10:30:42] <DonDiego> gameswf was the other one [10:30:51] <DonDiego> and gnash is based on gameswf [10:31:10] <av500> ffswf [10:31:42] <__gb__> lightspark starts to do things too [10:32:39] <pross-au> It uses Boost, enough said. [10:32:45] <KotH> DonDiego: nope [10:32:58] <KotH> DonDiego: i use the adobe flash player... for a good reason :) [10:33:19] <DonDiego> __gb__: what is lightspark? [10:33:30] <DonDiego> swfdec is C, not C++ ... [10:33:32] <kshishkov> KotH: is there any good reason in using Flash? [10:33:43] <av500> http://sourceforge.net/projects/lightspark/ [10:34:38] <__gb__> though windows-only at this time iirc [10:34:54] <kshishkov> also IIRC some guy managed to write Flash client purely in JavaScript [10:34:57] <__gb__> uses llvm & glsl [10:38:51] <DonDiego> C++ shit as well :-/ [10:39:15] <kshishkov> but it's designed by Danish [10:39:42] <KotH> kshishkov: yeah.. and if it's just porntube [10:41:00] <kshishkov> KotH: ahem, I'd use youtube-dl instead [10:41:36] <av500> kshishkov: that not the right solution if you decidec to spend your friday night with "browsing utube..." :) [10:41:59] <KotH> av500: it is [10:42:21] <KotH> av500: for some reason, my machine is too slow to show even the most simple flash movie [10:42:36] <KotH> av500: downloading them and playing them with mplayer works though... with less than 1% cpu usage [10:42:49] <KotH> -> mozilla+flash sucks [10:43:18] <kshishkov> av500: even streaming it with MPlayer should be better [10:43:50] <av500> KotH: guess why we used to offer to our users to play the actual FLV in our video player and not in the flash one :) [10:44:30] <DonDiego> av500: "your users"? [10:44:32] <kshishkov> av500: please send a patch so we can use ffmpeg -i youtube://jhfddf6d outfile [10:44:42] <av500> kshishkov: actually trivial [10:44:52] <av500> we do that [10:45:07] <av500> not with ffmpeg though [10:45:22] <kshishkov> I know it's trivial, but why don't we have it supported in FFmpeg yet? [10:45:49] <av500> DonDiego: Archos customers [10:46:22] <DonDiego> it's trivial? what has to be done? [10:46:45] <av500> wait a sec [10:47:18] <av500> whet http://www.youtube.com/watch?v=XXXXXXXXXXX [10:47:19] <kshishkov> 1) read page 2) extract info 3) construct URL 4) read it 5) ... 6) playing! [10:47:24] <av500> wget [10:48:28] <av500> you can even add &fmt=YY to get different formats (SD,HD...() [10:50:30] <thresh> they break the page from time to time [10:50:39] <thresh> like, every few months. [10:51:01] <av500> thresh: yep [10:51:19] <thresh> morning, btw [10:51:21] <av500> thats why we actually host the parsing script on our website, no need to update the SW :) [10:51:35] <thresh> ah, nice [11:02:42] <CIA-46> ffmpeg: pross * r21994 /trunk/libavformat/bink.c: Bink audio pts starts at 0, not reported_size [11:06:24] <CIA-46> ffmpeg: mstorsjo * r21995 /trunk/libavformat/ (rtsp.c rtsp.h): Cosmetics: reindent [11:16:08] <CIA-46> ffmpeg: pross * r21996 /trunk/libavformat/bink.c: Set video stream duration for Bink demuxer [11:16:18] <kshishkov> yay! [11:16:42] <pross-au> i have isolated the 'video goes farking slow' problem [11:16:52] <kshishkov> good [11:17:01] <pross-au> seems to be caused by excessive buffering in the files [11:17:48] <pross-au> e.g. the audio frames are cramed at the start, video packets are more-so at the end [11:36:12] <DonDiego> mru: btw, i propose adding -Wmissing-prototypes to CFLAGS [11:36:40] <Kovensky> -Wall -Wextra -pedantic? :D [11:36:55] <DonDiego> we have -Wall [11:37:06] <Kovensky> inb4 ffmpeg's compile spends more CPU time on stderr than on actually compiling [11:37:19] <Kovensky> :> [11:37:24] <DonDiego> inb4? [11:37:39] <Kovensky> "in before", internetspeak [11:40:30] <DonDiego> i don't see that sentence making any sort of sense [11:41:09] <DonDiego> what english expression does "in before" translate to? [11:42:18] <kshishkov> who said anything about English? [11:45:53] <Kovensky> DonDiego: as I said, it isn't english, it's internetish :) [11:46:28] <pross-au> 'netspeak, Kovensky, get with the programme [11:48:22] <Kovensky> DonDiego: urbandictionary is your friend: http://www.urbandictionary.com/define.php?term=inb4 / http://www.urbandictionary.com/define.php?term=in%20b4 [11:50:08] <elenril> Kovensky: http://tvtropes.org/pmwiki/pmwiki.php/Main/DontExplainTheJoke [11:50:17] <Kovensky> elenril: oic [11:50:19] <Kovensky> oh well [11:50:36] * Kovensky be late [11:50:41] <Kovensky> classes started 50 minutes ago :D [11:51:06] <Kovensky> time to do my daily 1h20m commute to college... + 1h20m to commute back <_< [11:51:15] <Kovensky> (and that's only 20km >_>) [11:51:19] <elenril> get a better college? [11:51:59] <kshishkov> or better commuter [11:52:11] <Kovensky> there are only busses here [11:52:15] <av500> or better distance [11:52:24] <Kovensky> and they're often so stuffed you can't even try to get on them [11:53:05] <Kovensky> anyway, I'm out \o [11:54:17] <Compn> carpool with some other dingus [11:54:29] <Compn> or a professor [11:54:30] <Compn> :P [11:54:37] * kshishkov has half a dozen of universities in 15 min walk [11:54:47] <pross-au> Kovensky: its a 1h15m bike ride to my work [11:55:41] <kshishkov> I thought you can go by tram [11:56:33] <pross-au> kshishkov: not to work [11:56:38] <pross-au> but we have lots of 'em [11:56:51] <pross-au> *someones* been studying AUSTRALIA :D [11:57:03] <av500> pross-au: whereabouts? [11:57:20] <pross-au> Melbournem, Victoria [11:57:21] <kshishkov> well, Melbourne has a reputation of Australian Göteborg [11:57:31] <av500> pross-au: ah, the other city :) [11:57:46] * av500 likes Melbourne better [11:58:02] <kshishkov> better than what? [11:58:08] <av500> the other city [11:58:16] <pross-au> other? [11:58:18] <av500> they have 2 of them [11:58:23] <kshishkov> you mean the one with tissue box opera? [11:58:27] <av500> yep [11:58:30] <pross-au> We have more then two my friend [11:58:38] <av500> pross-au: I know, been there := [11:58:53] <pross-au> Cool [11:59:04] <av500> I have relatives in Melbourne actually [11:59:08] * kshishkov is unlikely to get even to Serbia [11:59:25] <av500> kshishkov: you are more than welcome should you chose too :) [12:00:04] <kshishkov> av500: my Serbian is nonexistent and they had no reason to learn Russian [12:01:00] <av500> true, they rather learned english [12:01:06] <pross-au> who in their right mind would discount life australia based on our extreeme climate [12:01:11] <pross-au> *life in [12:01:31] * kshishkov points to himself [12:02:34] <av500> kshishkov: at least no ice on the roads... ;) [12:02:40] * thresh would like to melt instead of freezing [12:03:11] <kshishkov> av500: I can't think when the temperature is high [12:03:59] <av500> try watercooling [12:04:20] <kshishkov> Australia is not famous for water [12:05:04] <kshishkov> I've even heard that when their rivers have water is an extreme situation [12:05:17] <av500> yes [12:05:25] <kshishkov> (and once they cancelled boat racing because of that) [12:13:25] <pross-au> kshishkov: desal [12:13:39] <kshishkov> what's that? [12:13:58] <pross-au> salt water in one end, drinkable water out the other [12:14:13] <pross-au> kinda like a video decoder [12:14:21] <kshishkov> ah [12:14:24] <pross-au> (making sure we stay on subject) [12:14:40] <kshishkov> that's rather denoiser ;) [12:15:02] <CIA-46> ffmpeg: michael * r21997 /trunk/libavutil/fifo.c: Clarify non constness of src in av_fifo_generic_write() [13:43:33] <mru> btw, somethings wrong with vc1dec [13:43:42] <kshishkov> what? [13:43:47] <mru> it crashes on avr32 and valgrind complains [13:44:14] <kshishkov> what are those complains? [13:45:23] <mru> hmm, now it's not complaining [13:45:39] <mru> but it crashes on avr32 while freeing memory at the end [13:45:50] <mru> I'm guessing corruption somewhere [13:46:38] <kshishkov> could be [13:49:44] <mru> also leaking memory [13:50:48] <mattg> mru: apologies for the green issue before which i attributed to ARM - it's not ARM at all. infact I can replicate it on x86. [13:51:01] <mru> then it's just a broken file [13:51:52] <kshishkov> mru: I was not able to trace those leaks. Valgrind says it's from some av_mallocz() but none of av_mallocz() in vc1dec.c it seems [13:52:11] <mattg> i found that if you memset the AVFrame's data buffers each time ffmpeg asks for a new buffer (i.e. don't just throw it the old one, reset the data to 0s, and then set the age to 256*256*256*64) then x86 and arm both give the green frames i was seeing [13:52:49] <mru> kshishkov: http://pastebin.ca/1806766 [13:54:02] <mattg> mru: do you happen to know who i could speak to regarding this? i think it may be an ffmpeg bug but i haven't pinned it down yet for sure, but i'd certainly like to find it. [13:54:34] <mru> "Too many slices, increase MAX_SLICES and recompile" [13:54:52] <kshishkov> mru: I suspected that. Maybe forgot to call MPV_common_close() somewhere [13:55:18] <mru> I see an MPV_common_end() call... [13:55:30] <mru> in fact, that's where it crashes on avr32 [13:56:20] <kshishkov> that's bad and the fact I can't find a reason is even worse [13:57:19] <mattg> mru: it's nothing to do with MAX_SLICES. i upped to 32, checked that there were no more MAX_SLICES errors and can still reproduce. [13:57:36] <mru> mattg: go shout at whover encoded the file [14:22:23] <mru> http://www.4p8.com/eric.brasseur/gamma.html [14:23:17] <av500> I wanted to paste that too [14:28:30] <kshishkov> what's the morale? Smart browsers throw away noise on scaling leaving only gray background or what? [14:29:10] <twnqx> smart broser use fractal scaling! [14:29:19] <av500> I guess it would be nice to have gamma/degamma SIMD opcodes :) [14:31:15] <Kovensky> < pross-au> Kovensky: its a 1h15m bike ride to my work <-- at least you only depend on yourself, you don't have to wait until some usable bus passes by and can avoid traffic jams ._. [14:33:15] <kshishkov> av500: the funniest thing is that I'm on Mac and it uses different gamma value [14:35:48] <av500> kshishkov: I'm sure intel can make a custom CPU for the fruit company... [14:36:19] * kshishkov would like IBM to do that instead [14:36:56] <kshishkov> with all its quirks, PowerPC is better than x86. Well, almost everything is [14:39:41] <av500> kshishkov: well, now with apple making their own chips, you can rally them to make PPC.... [14:40:12] <kshishkov> they don't make desktop/server CPUs yet :( [14:47:58] <superdump> can anyone remember the oprofile macros for starting/stopping profiling in-line with C code? [14:48:28] <mru> there are such? [14:48:53] <superdump> i think so [14:49:00] <superdump> unless i'm thinking of something else [14:49:52] <superdump> i want to profile some code in an isolated manner [14:50:14] <superdump> rather than wading through piles of crap to get the information i want [15:00:07] <mru> what kind of crap? [15:00:32] <mru> you can restrict the output of opreport and opannotate to specific files or functions [15:09:40] <CIA-92> ffmpeg: michael * r21999 /trunk/ffmpeg.c: [15:09:40] <CIA-92> ffmpeg: Redesign opt_programid code. [15:09:40] <CIA-92> ffmpeg: Its now possible to also select programs per input file and there is [15:09:40] <CIA-92> ffmpeg: less code duplication. [16:13:45] <CIA-92> ffmpeg: daniel * r22000 /trunk/libavcodec/Makefile: Cosmetics: break all Makefile lines at 80 columns or less [16:22:10] <mru> kshishkov: compiler bug [16:22:19] <mru> it's adding an array index twice [16:22:25] <kshishkov> mru: hello to codesourcery? [16:22:30] <mru> atmel [16:25:49] <mru> hexedit ftw [16:25:57] <andoma> :) [16:26:27] <kshishkov> so that's how you patch compilers? [16:26:54] <mru> that's how I patch the code produced by the compiler [16:29:44] <mru> btw, is it just me are those pkgconfig trolls getting annoying? [16:30:17] <kshishkov> just think about autoconfig trolls and relax ;) [16:30:50] <mru> they are closely related [16:30:57] <mru> maybe killing one will harm the other [16:31:02] * mru loads shotgun [16:31:12] <kshishkov> and if you mean that guy who still uses French Revolutionary calendar, that is a dead giveaway [16:31:23] <kshishkov> prepare guillotine then ;) [16:31:36] <mru> which one? felipe or nicolas? [16:31:42] <av500> mru: kill them slowly, this is so much fun to read [16:31:48] <CIA-92> ffmpeg: michael * r22001 /trunk/libavformat/utils.c: [16:31:48] <CIA-92> ffmpeg: Count all frames with codec_info_nb_frames not just ones with non zero [16:31:48] <CIA-92> ffmpeg: duration. I hope this breaks nothing. Its needed for my fix of issue1156 [16:31:49] <kshishkov> Nicolas [16:32:24] <CIA-92> ffmpeg: michael * r22002 /trunk/ffmpeg.c: [16:32:24] <CIA-92> ffmpeg: Favor streams with more packets if the user did not specify what she wants. [16:32:24] <CIA-92> ffmpeg: Fixes issue1156 [16:33:09] <kshishkov> "she wants"? [16:33:24] * mru looks around for girls [16:33:41] * mru sees none [16:35:41] <kshishkov> mru: I heard there's a rule "there are no girls among FFmpeg users" [16:36:13] <mru> untrue: http://www.youtube.com/watch?v=iIalNEW-LQ8 [16:36:32] <av500> mru: you put that on F12? [16:36:52] <mru> top hit when searching yt for ffmpeg [16:37:01] <elenril> kshishkov: http://tvtropes.org/pmwiki/pmwiki.php/Main/ThereAreNoGirlsOnTheInternet [16:37:27] <kshishkov> I thought that YouTube is itself top hit for FFmpeg (alas with <noref>) [16:47:29] <CIA-92> ffmpeg: michael * r22003 /trunk/ffplay.c: Replace *_index by st_index[codec_type]. [16:50:05] <CIA-92> ffmpeg: ramiro * r22004 /trunk/libavdevice/vfwcap.c: [16:50:05] <CIA-92> ffmpeg: vfwcap: support MJPG compressed streams. [16:50:05] <CIA-92> ffmpeg: Patch by Nash Tsai <nash dot tsai at gmail dot com> [16:55:01] <CIA-92> ffmpeg: ramiro * r22005 /trunk/libavcodec/mlp_parser.c: [16:55:01] <CIA-92> ffmpeg: mlp_parser: Fix memleak. [16:55:01] <CIA-92> ffmpeg: ff_combine_frame() is called, which allocates ParseContext->buffer if needed, [16:55:01] <CIA-92> ffmpeg: so ff_parse_close() must be called to free it. [16:55:01] <CIA-92> ffmpeg: Patch by jai. [16:57:11] <CIA-92> ffmpeg: michael * r22006 /trunk/ffplay.c: replace wanted_*_stream by wanted_stream[CODEC_TYPE] [17:00:06] * elenril lols@http://mailman.videolan.org/pipermail/vlc-devel/2008-June/045064.html [17:01:18] * kshishkov likes "fix something" more [17:02:03] * av500 has kill_all_orphans() ... [17:02:27] * elenril always thought av500 was evil [17:02:48] * av500 inserts evil laughter [17:03:10] * kshishkov smiles from the dark corner [17:03:22] <av500> dark country, no? [17:03:40] <kshishkov> and very righteous too [17:03:41] <elenril> you're all evil and lazy! [17:03:49] <elenril> btw anyone wants to apply a few patches? :) [17:04:08] <kshishkov> elenril: you should've asked when benoit- was around [17:04:46] <elenril> :/ [17:10:41] <CIA-92> ffmpeg: michael * r22007 /trunk/ffplay.c: Dont modify wanted_stream. [17:14:58] <Dark_Shikari> siretart`: ping [17:15:58] <siretart`> Dark_Shikari: at work, but around [17:17:29] <Dark_Shikari> so, we have our first problem [17:17:32] <Dark_Shikari> r1448 had some stupid errors [17:17:37] <Dark_Shikari> which I fixed... in r1461 [17:17:53] <Dark_Shikari> or actually wait, let me check... [17:18:05] <Dark_Shikari> phew, we're good! none of the changes up to r1448 broke anything [17:18:16] <Dark_Shikari> nevermind then, you're good [17:18:18] <Dark_Shikari> r1448 is stable. [17:18:29] <Dark_Shikari> I guess not having big changes increases likelihood of stable :) [17:20:21] <siretart`> Dark_Shikari: I have filed [17:20:21] <siretart`> https://bugs.launchpad.net/bugs/526396 for tracking this. I'll make a [17:20:21] <siretart`> note make that r1461 instead of r1448 [17:20:37] <Dark_Shikari> er, no [17:20:42] <Dark_Shikari> keep it at r1448 [17:20:43] <Dark_Shikari> as I said [17:21:01] <Dark_Shikari> r1461 adds new features, and we're past the feature freeze ;) [17:21:14] <siretart`> ah, you have fun with confusing me. ok [17:21:19] <Dark_Shikari> I mistakenly thought r1448 had a bug [17:21:23] <Dark_Shikari> and r1461 fixed issues in r1448 [17:21:25] <Dark_Shikari> _but_ [17:21:31] <Dark_Shikari> all the issues fixed in 1461 were created after 1448 [17:21:38] <siretart`> great [17:21:48] <Dark_Shikari> 1a6d32b4a4 should be your revision. [17:36:37] <CIA-92> ffmpeg: michael * r22008 /trunk/ffplay.c: Also favor streams with more packets in ffplay. [17:37:56] <mru> "people who know how their programs work do better than those who do not", wow... such insight [17:39:18] <av500> where? [17:39:31] <mru> http://www.eis.mdx.ac.uk/research/PhDArea/saeed/paper1.pdf [17:42:40] <Dark_Shikari> lol [17:44:25] <elenril> http://xkcd.org/703/ [17:44:41] <mru> yeah, good one [17:45:59] <av500> mru: you get paid to read that paper? [17:46:09] <mru> av500: no [17:46:28] <mru> it was linked on HN [17:47:04] <av500> ah [17:47:26] * av500 reloads [17:47:34] <siretart`> HN? [17:47:40] <av500> http://news.ycombinator.com/ [17:48:08] <siretart`> ah, thnx [17:48:47] * mru doesn't often get paid to read stuff [17:48:53] <mru> that's why most of my code is write-only [17:53:55] <kshishkov> mru: not in this community [18:21:15] <janneg> lol, I found the first error in the big buck bunny sources: http://www.jannau.net/peach_2700x1440/01_intro.mkv [18:21:42] <Dark_Shikari> error? [18:22:30] <janneg> the eyes aren't moving with the body in the third scene [18:22:37] <janneg> watch the video [18:22:49] <Dark_Shikari> fix it? ;) [18:24:12] <janneg> how? [18:24:31] <kshishkov> by modifying sources and rerendering [18:24:43] <mru> or by editing the mkv with hexedit [18:25:07] <Dark_Shikari> mru: lol [18:25:09] <kshishkov> do you think he can reencode H.264 in his head? [18:25:35] <Dark_Shikari> LOL @ the eyes [18:25:38] <Dark_Shikari> lmao [18:25:43] <Dark_Shikari> how the fuck did that happen [18:26:49] <janneg> blender uses a binary format. or maybe just xml + compression [18:37:02] <janneg> downloaded the source from the peach studio backup with the same error [18:37:29] <mru> don't get the backup, get the files they used for the production render [18:37:31] <mru> ;-) [18:38:10] <kshishkov> or re-create them [18:38:11] <janneg> I don't care and I won't rerender the scene [18:41:51] <Dark_Shikari> why, because its hilarious? [18:46:41] <janneg> because it takes too much time, there seems to be no public svn repo for blender or peach and I think they deserve being ridiculed by releasing files with such error [18:47:18] <kshishkov> ever heard of Matrix? [19:05:53] <_av500_> janneg: change the eyes to ffmpeg logos [19:07:14] <FFeyes> this way? :P [19:44:58] <elenril> /nick Honoome fflameeyes [19:49:21] <Kovensky> fflames [19:49:42] <Kovensky> "/nick Honoome Shana" also works I guess [19:50:34] * elenril thinks Kovensky is confusing #ffmpeg-devel with #mplayerdev [19:50:36] * Honoome is cofnused nw [19:50:45] <Honoome> and my keyboard as well [19:51:04] <Kovensky> elenril: =p [19:51:18] <elenril> Honoome: your patch still not oked? [19:52:01] <Kovensky> Honoome: Shana from Shakugan no Shana has flame eyes [19:52:23] <Honoome> elenril: waiting for Baptiste to be sure… specially because I'm not totally sure about Michael's rebus… the only place where I see the “official” name being related to “author” is mov and 3gpp [19:52:32] <Honoome> Kovensky: never seen that, anime I assume? [19:54:40] <Kovensky> light novel / anime [19:54:42] <elenril> Honoome: michael is default maintainer, everything not listed belongs to him [19:54:44] <Kovensky> I never saw it either =p [19:58:20] * elenril wonders wtf is rpl and vqf [19:59:03] <Honoome> elenril: that much I know [19:59:36] <elenril> "Regarding Bink, a lot of games use Theora nowadays (StarCraft 2, for example)." << wut [20:00:20] <Dark_Shikari> it _is_ better than bink [20:00:39] <Dark_Shikari> gotta be honest about that =p [20:00:44] <elenril> lol [20:00:46] <_av500_> and freer [20:01:08] <j-b> Hello [20:01:10] <elenril> but a lot of games? [20:01:15] * elenril didn't see a single one [20:05:15] <peloverde> A handful of old games used VP3 [20:06:29] <peloverde> Also I haven't seen the star craft 2 cinematics but the ones from starcraft 1 were way overcompresseed [20:07:01] <kierank> maybe they got vorbis and theora confused [20:07:10] <kierank> tons of games use vorbis [20:07:16] <elenril> otoh it ran on 486's [20:07:27] <Dark_Shikari> starcraft 1 used smacker [20:08:22] <elenril> can ffmpeg play them? [20:08:33] <Dark_Shikari> yes iirc [20:11:30] <peloverde> If theora is as good as its advocates say it is, why are they be so concerned about VP8? [20:12:11] <Dark_Shikari> don't apply logic to them ;) [20:12:16] <Dark_Shikari> also, because vp8 is 50% better than h264 [20:12:17] <Dark_Shikari> obviously [20:12:33] <Yuvi> on2 says so, it must be true! [20:12:50] <elenril> does vp mean anything btw? [20:13:26] <_av500_> my initials [20:17:25] <CIA-92> libswscale: ramiro * r30722 /trunk/libswscale/swscale_template.c: Reorder buffer debug. Also print out if slice was buffered. [20:18:16] <DonDiego> mru: what about -Wmissing-prototypes? [21:01:58] <mru> DonDiego: go for it [21:04:18] <CIA-92> ffmpeg: diego * r22009 /trunk/configure: Add -Wmissing-prototypes to CFLAGS if available. [21:06:29] <peloverde> why is the uspto site so terrible? [21:06:37] <kierank> because it's government designed [21:07:07] <kierank> government designed back when citizen facing projects were treated like miltary projects [21:08:10] <mru> i.e. best kept secret [21:08:19] <mru> use google patents instead [21:29:00] <DonDiego> now let's see if the ton of warnings generated by -Wmissing-prototypes gets ignored as usual [21:45:57] <anhanguera> hi, where should i send a possible fix for memory leak in libavcodec? [21:46:15] <mru> ffmpeg-devel mailing list would be fine [21:46:41] <mru> if it's not obvious, try to describe the error and the fix as clearly as possible [21:47:18] <anhanguera> ah, hi mru. ok thanks. [21:53:20] <anhanguera> mru, actually commenting libavcodec/vc1dec.c lines 2998, 2999 will fix the leak, as h363_decode_init() is called twice. 1- directly from vc1dec.c:2998, 2- indirectly from v1dec.c:3001. anyway i will send an email abou that [21:59:30] <ramiro> anhanguera: are you brazilian? [22:01:31] <anhanguera> ramiro, no. but read about a pterosaur named anhanguera, and loved the meaning. [22:07:36] <CIA-92> ffmpeg: michael * r22010 /trunk/ffmpeg.c: Set ist->pts to something that isnt guranteed to entangle itself with stream copying b frames. [22:21:33] <mru> http://ie6funeral.com/ [22:22:56] <peloverde> meh, ie6 has been dead to me for years [22:24:05] <mru> I'm getting ~8% IE6 on my blog [22:24:22] <mru> more than any other IE version [22:24:34] <mru> maybe my stats aren't representative... [22:24:46] <Dark_Shikari> mru: I got like 2% last I looked [22:24:49] <Dark_Shikari> among all IEs [22:25:12] <mru> looking stats for all last year, I have 16% all IE [22:25:18] <mru> 7.9% IE6 [22:25:37] <mru> that's 7.9% of total [22:25:47] <Dark_Shikari> from the past 2 days, where I got ~20k hits [22:25:59] <Dark_Shikari> 30% safari, 28% firefox, 25% chrome, 8% "mozilla compatible", 4% IE [22:26:48] <mru> this month I have 10% IE [22:26:58] <mru> equally split between 6, 7, and 8 [22:27:10] <mru> 45% firefox [22:27:25] <mru> 14% chrome [22:28:04] <mru> and one hit from lynx [22:28:27] <Dark_Shikari> in the 3 weeks before my recent 20k hits [22:28:30] <Dark_Shikari> 51% firefox [22:28:32] <Dark_Shikari> 17% chrome [22:28:33] <thresh> i wonder who was that pour soul with lyns [22:28:34] <thresh> lynx [22:28:34] <Dark_Shikari> 11% IE [22:28:36] <Dark_Shikari> 10% safari [22:28:41] <Dark_Shikari> 7.5% opera [22:28:43] <mru> lynx ain't bad [22:28:52] <Dark_Shikari> I think the high Safari % of the past 2 days is because I was linked on DaringFireball [22:29:51] <mru> that reddit post gave me 33k hits in one day [22:30:01] <mru> 18k the following day [22:30:44] <Dark_Shikari> lol [22:30:46] <Dark_Shikari> reddit ftw [22:33:20] <Dark_Shikari> 06:32 < BugMaster> ramiro: while you here may be also look at this patch for ffmpeg and non mod4 rgb24 pixel-format: http://pastebin.com/pc62RxpF (don't have time and will to register for ffmpeg mail-list) [22:40:59] <ramiro> Dark_Shikari: I saw that. I'll look at it now. [23:12:44] <peloverde> Dark_Shikari, ramiro: still doesn't make up for my comment that DivX 6 is MPEG-4 ASP being downvoted to -10 [23:13:05] <Dark_Shikari> lol [23:14:14] <mru> peloverde: comment where? [23:14:27] <peloverde> reddit, twoish years ago [23:14:31] <mru> oh [23:14:38] <ramiro> peloverde: mru got similarly downvoted on reddit... [23:14:50] <ramiro> I don't know why you guys care so much about reddit. seems like a waste of time to me. [23:14:57] <mru> I don't care about reddit [23:14:57] <Dark_Shikari> same [23:15:08] <ramiro> well, but you're subscribed, and reply [23:15:12] <ramiro> that means you do care. [23:15:14] <kierank> only thing interesting about reddit is iama [23:15:24] <mru> I only subscribed so I could reply to the comments about my blog post [23:15:43] <mru> haven't touched it before or since [23:15:56] <ramiro> to "defend yourself"? [23:16:28] <mru> the discussion was a bit one-sided [23:17:00] <peloverde> reddit was also all up in arms when we started going after our violators [23:17:08] <mru> lol [23:17:53] <mru> btw, I just found this regex in my .emacs: "/ffmpeg\\.\$[^/]*\$/\$[^/]+\\(/[^/]+\$/\\)?" [23:18:32] <Kovensky> why are all the \ escaped [23:19:20] <mru> becaue they're in a string [23:19:22] <Kovensky> and why are the () escaped? o_O [23:19:47] <mru> to match a literal \ you need \\\\ [23:20:12] <mru> \\( becomes \( which is the emacs-regex grouping construct [23:20:21] <Kovensky> ic [23:20:24] * Kovensky prefers his perl regexps [23:20:41] <mru> just remember which is which [23:22:35] <Kovensky> m!/ffmpeg\.([^/]*)/([^/]+(/[^/]+)/)?! <-- slightly more readable :) [23:23:22] <mru> yes, I too slightly prefer perl regex [23:23:31] <mru> but emacs isn't written in perl [23:23:43] <Kovensky> libpcre? [23:23:57] <mru> obviously not [23:24:12] <Kovensky> :p [23:42:02] <CIA-92> ffmpeg: michael * r22011 /trunk/ffmpeg.c: Attempt to fix issue1728 and regression of issue203 [23:48:45] <j-b> ruggles?

1 0

IRC log for 2010-02-22
by irc＠mansr.com 23 Feb '10

23 Feb '10

[00:34:54] <CIA-90> ffmpeg: mru * r21952 /trunk/libavcodec/arm/ (mdct_neon.S dsputil_armv6.S): ARM: add missing preserve8 directives [00:34:55] <CIA-90> ffmpeg: mru * r21953 /trunk/libavutil/arm/bswap.h: [00:34:56] <CIA-90> ffmpeg: ARM: change argument/return type of bswap_16() to unsigned 32-bit [00:34:56] <CIA-90> ffmpeg: This avoids unnecessary masking otherwise added by the compilers. [00:34:56] <CIA-90> ffmpeg: mru * r21954 /trunk/configure: [00:34:56] <CIA-90> ffmpeg: Revert "Suppress icc warnings about unknown attributes" [00:34:56] <CIA-90> ffmpeg: This reverts r21884. Apparently people want those warnings. [00:34:57] <CIA-90> ffmpeg: michael * r21955 /trunk/libavformat/avc.c: Attempt to fix the completely random values returned by ff_avc_find_startcode(). [02:57:28] <ramiro> how should I deal with a timestamp discontinuity in an audio grabbing device? [02:57:43] <mru> what's the source of the timestamps? [02:58:09] <mru> and why is it discontinuous? [02:58:09] <ramiro> there are no timestamps. =( [02:58:37] <mru> if they don't exist, how can they be discontinuous? [02:58:39] <ramiro> it's the windows waveform api. we give the api x buffers so it may record sound in them. [02:58:53] <ramiro> if all is going right, we get the buffers back one by one, and the data is continuous [02:59:12] <ramiro> but if the buffers fill up, we lose data. [02:59:36] <ramiro> when we get a new buffer, there's no way to tell its timestamp, how much it differed from the last buffer. [02:59:37] <mru> do you know how much data you lost? [03:01:35] <ramiro> I was thinking of getting system time every time the data is lost. but that way ffmpeg is garbling up the sound. I'd expect the exact amount of delay between one and the other as silence, but that's now what I get... [03:01:44] <ramiro> that's not [03:02:15] <mru> using system time is generally not a good idea [03:02:31] <mru> do you get any indication how much you lost? [03:02:39] <mru> or just that something was lost? [03:02:55] <ramiro> no, there's no indication on how much was lost. not even an indication that something was lost. [03:03:25] <ramiro> but if we are holding all buffers, it's sure to be data loss. [03:03:27] <mru> then the best you can do is probably to pretend it doesn't happen [03:03:28] <Dark_Shikari> mru: does ARM have population count? [03:03:35] <mru> Dark_Shikari: no [03:04:15] <mru> there's a neon vector population count [03:04:31] <ramiro> there is one function to get the time and number of bytes spent recording, but that function must not be called from the callback, so it's kind of useless. [03:04:38] <mru> works only on 8-bit elements [03:05:27] <mru> Dark_Shikari: why do you ask? [03:06:28] <Dark_Shikari> random discussion on some other channel, wondering which archs had one [03:06:35] <Dark_Shikari> seems ultrasparc, alpha, cray did [03:07:02] <mru> blackfin has [03:07:19] <ohsix> doesn't v6 have a popcnt? [03:07:40] <mru> armv6? [03:08:09] <ohsix> ya [03:08:18] <mru> v5 has clz [03:08:26] <mru> I don't see a popcount anywhere [03:08:30] <ohsix> ah that might have been what i was thinking of [03:15:01] <RTFM_FTW> a number of GPUs (i.e. anything D3D11 compliant for example) offer a "population count" instruction (or something equivalent) as well [03:37:29] <ShadowJK> does v6 have clz? [03:37:43] <mru> yes [03:37:46] <mru> v5 and later [03:40:42] <mru> nothing has been removed [03:40:49] <mru> swp has been deprecated [03:41:13] <mru> in favour of new, better instructions [04:33:18] <ramiro> is there a way to instruct ffmpeg to output each channel to a different file? [04:33:43] <mru> don't think so [04:34:10] <ramiro> hmm, is there at least a way to specify that I only want one audio channel? (and not by resampling, by ignoring the others) [04:39:34] <peloverde> both of those would be useful [04:40:59] <pentanol> hello, looks weird, but here... static int rtmp_open(URLContext *s, const char *uri, int flags) uri pointer not used [04:57:12] <peloverde> Did people see the january 2010 zzuf report? [05:08:37] <troy_s> Can anyone in here tell me how to dump a still image frame from an x264 stream using rec709 instead of the implied 601? [05:08:55] <troy_s> I've tried -colorspace 4, but it still seems to be trunking the output. [05:12:13] <astrange> does the zzuf report include backtraces or just the files? [05:12:25] <troy_s> (as in the 16-235 crunch. That is what I seek to avoid and bring everything into 0-255 if at all possible) [05:14:00] <astrange> it sounds like a problem with the input, with no colorspace conversion it won't clip anything [05:14:38] <troy_s> astrange: Not the case. [05:14:46] <troy_s> astrange: I believe it is a well documented issue with swscale [05:15:14] <troy_s> astrange: In that it, in short, thrusts 601 on output (not so much 601 but more the 16-235 clamp) [05:15:58] <astrange> you can try yuvj420p, i guess. don't know if swscale implements that [05:16:00] <troy_s> astrange: I am pretty sure Dark_Shikari and Yuvi know the issue, but I am curious if there is a way for me to get a full 0-255 still image from it in some lossless format. I'd be elated if that were the case. [05:16:14] <troy_s> astrange: Sorry... explain please? [05:16:49] <pentanol> hm, I should do mux\demux stream if i needed proxying rtsp stream to rtmp? [05:17:20] <astrange> try using -pixfmt yuvj420p for input and output. but now that i think about it, that probably can't be controlled from the cli either [05:17:55] <Yuvi> it can for raw yuv [05:18:06] <astrange> pix_fmt too [05:18:33] <troy_s> Yuvi: Sorry... idiot here.. Is there a way to pull full 0-255 out of the file then? [05:19:08] <pentanol> u.e. I need convert AVFormatContext or ByteIOContext to URLContext? [05:19:28] <Yuvi> out to what? rgb or yuv? (yuv should just work unless some conversion is involved, but it might not be marked as such) [05:20:26] <troy_s> Yuvi: As in assuming I have an x264 MOV here with 0-255 defined, can I pull a still frame out of it (say PNG) with that full 0-255? [05:20:41] <troy_s> Yuvi: So yeah, YUV starting point. [05:21:28] <troy_s> Yuvi: Because I tried -colorspace 4 -i in.mp4 out.png and (probably my fault) spit out a PNG (after complaining) that is still 16-235 clamped. [05:23:03] <pentanol> copying ByteIOContext *pb; to void *priv_data; should be okay? [05:23:12] <pentanol> and work properly? [05:23:21] <troy_s> Yuvi: (And thank you for your time) [05:25:36] <pentanol> anyone? [05:26:49] <Yuvi> troy_s: try http://pastebin.ca/1805431 I think [05:27:11] <troy_s> Yuvi: Wow. [05:27:16] <troy_s> Yuvi: Is that in SVN? [05:28:31] <Yuvi> no, it didn't really work for rgb -> yuv for colorspace, and I didn't look into whether swscale had support for that [05:28:56] <troy_s> Yuvi: So going from YUV to RGB (x264 to PNG in this case) can work? [05:29:46] <Yuvi> as long as you used --fullrange (or add --color_range 2 to ffmpeg) [05:30:09] <troy_s> Yuvi: So I need to add that patch before it will work? [05:30:14] <Yuvi> yeah, I [05:30:21] <troy_s> Yuvi: Or can I svn up and have it without breaking my SVN? [05:30:31] <Yuvi> 'll ping the thread to see if it's okay to half-fix the issue ignoring rgb -> yuv [05:30:57] <troy_s> Yuvi: You rock Yuvi thank you immensely. I'd love to see some sort of workaround hack in SVN. [05:32:51] <troy_s> Yuvi: I don't suppose RGB to YUV is easily tackled without tackling the larger issue of colourspace agnostic manipulations? [05:33:27] <troy_s> Yuvi: Because in essence here we are dealing with colourspace conversion, which would imply that ffmpeg is working in a platonic colorspace and bumping out to a known paradigm, no? [05:35:06] <Yuvi> there's no internal ffmpeg colorspace, it doesn't change from the source unless doing an rgb <-> yuv conversion [05:35:34] <Yuvi> or range if going from 0-255 <-> 16-235 [05:35:39] <troy_s> Yuvi: Right... which then I guess implies a colorspace, correct? [05:36:15] <troy_s> Yuvi: So I guess the follow up question is - is there a REC709 implementation that also clamps 16-235? [05:36:18] <Yuvi> yes, and it'll be tagged wrong (or untagged) most of the time [05:36:43] <Yuvi> rec709 and 16-235 are orthogonal [05:36:55] <troy_s> Yuvi: Hrm... I tried patch -p0 < patch and it gagged. Did I miss something completely obvious? [05:37:00] <Yuvi> -p1 [05:37:07] <troy_s> Yuvi: Grok. [05:48:40] <troy_s> Yuvi: Is it possible that CONFIG_BINK_DECODER isn't defined? [05:49:43] <elenril> make clean? [05:50:28] <troy_s> elenril: Tried it. Grepp'd and didn't see it pop up other than in that file. [05:50:45] <troy_s> elenril: Reverted to 20 revisions prior and it seems fine. [06:32:51] <pentanol> kshishkov there? [06:32:58] <kshishkov> no, here [06:33:15] <jai> *slow clap* [06:33:15] <jai> ;) [06:33:41] <kshishkov> jai: you people clap with with single hand [06:33:48] <jai> O_O [06:34:17] <kshishkov> yes, and then ask everybody else how it sounds [06:36:43] <pentanol> I guess you may point me with mux\demuxing stream which comes from rtsp to rtmp... [06:37:08] <kshishkov> you need to recode it [06:39:22] <pentanol> hm, right, then rtmp accept only URLContext, also there... void *priv_data; should be data? or where? [06:40:02] <kshishkov> priv_data is private data used only by protocol handler [06:42:31] <pentanol> rtmp_write(URLContext *h, uint8_t *buf < there? buf must be for payload? [06:43:00] <kshishkov> no, RTMP protocol accepts only FLV [06:45:02] <pentanol> anyway some where should be buffer asigned for paylosd data, where it's? [06:45:13] <pentanol> assigned* [06:46:12] <kshishkov> it's not protocol worry - you feed it FLV data, it publishes it to server [06:52:46] <benoit-> good morning [06:53:38] <Dark_Shikari> kshishkov: er, but doesn't the rtmp server demux the flv file? [06:53:42] <Dark_Shikari> and present it in RTMP format? [06:54:25] <kshishkov> yes, and FFmpeg client does the same [06:54:36] <kshishkov> when publishing to RTMP server [06:54:52] <Dark_Shikari> yeah, but if we had an RTMP server [06:54:56] <Dark_Shikari> it could take input from anything in ffmpeg right? [06:55:37] <kshishkov> RTMP is tied to FLV and its codecs [06:56:20] <Dark_Shikari> it's tied to its codecs yes [06:56:25] <Dark_Shikari> but why couldn't ffmpeg turn an mp4 into rtmp? [06:57:07] <kshishkov> theoretically it can [06:57:46] <kshishkov> RTMP server should accept simple audio and video streams and mux them itself [07:13:33] <pJok> mornings [07:13:47] <kshishkov> goda morgnar [07:14:20] <pJok> kshishkov, be glad you are not in stockholm and need to get to work today [07:15:57] <kshishkov> oh yeah, you don't know what goes here [07:17:42] <pJok> they promise about half a meter of snow [07:17:50] <pJok> in southern sweden [07:18:01] <kshishkov> ours is accumulated [07:18:24] <kshishkov> so we have both mountains of snow, ice and water [07:18:51] <pJok> fun [07:18:59] <pJok> sounds like snow hell [07:19:08] <kshishkov> sounds like Ukraine [07:19:57] <kshishkov> and local street cleaning services were hired from Africa - they don't know what to do with snow and officially declared that it will melt in spring so no problem [07:20:41] <pJok> awesome [07:21:45] <kshishkov> yes [07:22:09] <pJok> and thats quite far away to hire cleaning services from... [07:22:41] <kshishkov> well, they look like Russians but judging from the way they think... [07:23:39] <kshishkov> I've heard some roofs are collapsing because of snow as well [07:23:49] <KotH> moin [07:24:07] <kshishkov> gruss dich [07:25:34] <_av500_> dobro jutro [07:25:46] <pJok> yeah, quite a lot of roofs in sweden have collapsed [07:25:47] <kshishkov> I hope it's so for you [07:26:10] <kshishkov> pJok: and we _didn't_ have heavy snowfalls here [07:27:22] <pJok> most of the heavy snow was in middle sweden [07:27:37] <_av500_> middle earth? [07:27:40] <pJok> yes [07:27:48] <pJok> midgard [07:27:54] <pJok> which is in ängelholm [07:28:08] <pJok> along with valhalla [07:28:21] * _av500_ knows sweden from blue/yellow stores [07:28:37] * kshishkov blev pÃ¥ ValhallavÃ€gen [07:30:03] * kshishkov blev pÃ¥ alla fyra svenska landsdelar ocksÃ¥ [07:30:29] <pJok> :) [07:33:22] <superdump> does anyone have 11172-2? [07:34:01] <_av500_> 11170? [07:34:13] <kshishkov> ISO 11170 [07:35:18] <superdump> http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnu… [07:35:26] <superdump> so i don't mean that? [07:35:53] <superdump> i think i do [07:35:58] <jai> superdump: http://www.neuron2.net/library/mpeg1/ [07:36:02] <jai> thats mpeg1 [07:36:03] <superdump> 11170 is about hydraulics [07:36:21] <superdump> thanks jai [07:36:23] <jai> np [07:36:26] <_av500_> superdump: so excuse lame joke [07:36:31] <astrange> btw the graphs in those files don't render in word for mac [07:36:33] <astrange> i have some pdfs [07:37:57] <jai> abiword seems to do them fine iirc [08:58:24] <pentanol> pokes kshishkov , if I haven't rtsp in Enabled protocols list, it's means I forgot live555 linking? but rtmp there... [09:23:25] <jonwil> hi [09:24:12] <jonwil> I have some video clips in Bink format that have some small issues when played back with the new Bink decoder. What should I do with these files? [09:24:33] * Dark_Shikari pings kshishkov [09:28:55] <pross-au> Hey Mr Wilson [09:31:51] <jonwil> hi [09:33:10] <jonwil> 2010 is only just begun and already FFMPEG has added a couple new codecs/formats :) [09:33:26] <jonwil> maybe 2010 will be the year that some much-wanted codecs enter FFMPEG [09:33:34] <pross-au> Like what? [09:33:38] <pross-au> EALayer3? [09:33:56] <pross-au> VP7? [09:34:04] <Dark_Shikari> WVP2 [09:34:07] <jai> VP8 ftw [09:34:08] <Dark_Shikari> is the most wanted imo [09:34:20] <Dark_Shikari> wm speech was big, but that's in now [09:34:24] <Dark_Shikari> SBR is very big and wanted [09:34:28] <pross-au> mp3pro [09:34:31] <Dark_Shikari> Dolby E will be very nice to get [09:34:35] <jai> lol mp3pro [09:35:10] <pross-au> jai: we need that for completeness [09:35:28] <jonwil> EALayer3 is my #1 most wanted IMO [09:35:31] <jai> pross-au: we can bug Vitor for that :) [09:36:11] <Dark_Shikari> we have twinvq [09:36:14] <Dark_Shikari> which was even more useless than mp3pro [09:36:26] <jonwil> what is wvp2? [09:36:36] <Dark_Shikari> it's the most common video format that we don't have [09:36:45] <Dark_Shikari> according to a few tens of millions of videos logged while I was at facebook [09:36:55] <pross-au> video camera? [09:36:58] <Dark_Shikari> it's a Windows Media format that has embedded info about slideshow stuff, etc [09:37:05] <Dark_Shikari> Windows Media Screen Video 2 or whatnot [09:37:13] <Dark_Shikari> it's used by Windows Movie Maker afaik [09:37:17] <jonwil> ok [09:37:28] <jonwil> Do we have the codec that MSN uses to send webcam data? [09:38:09] <jai> yep. its called mimic or sth [09:38:24] <Dark_Shikari> lol, mimic [09:38:34] <jonwil> Webcam support in 3rd party MSN clients would be nice :P [09:38:53] <jonwil> I am surprised that no-one bothers to support voice/video in 3rd party clients [09:39:17] <jai> surely they welcome patches [09:39:37] <merbzt> jai: can you play sitar like this guy http://www.youtube.com/watch?v=erLZ-zW9Ti4 ? [09:40:50] <jai> merbzt: not really, though i can play a bunch of beatles' songs ') [09:41:08] <merbzt> awesome :) [09:41:35] <jai> also, indian instruments are usually more expensive here [09:47:30] <pross-au> somebody mention bink benchmarking yesterday. how does it fair? [09:48:02] <CIA-90> ffmpeg: cehoyos * r21956 /trunk/libavcodec/Makefile: Fix compilation for --enable-version3 --enable-libopencore_amrwb (only). [09:48:51] * Dark_Shikari mentioned it [09:50:20] <Dark_Shikari> hmm. shit. I need to sign extend values in an simd reg. [09:50:31] <Dark_Shikari> I have X 0 Y 0 (words) [09:50:41] <Dark_Shikari> and I need to turn this into X Y (doublewords, 32-bit) [09:50:47] <Dark_Shikari> but X and Y can be signed [09:50:55] <Dark_Shikari> so the 0s need to become -1s if necessar [09:50:56] <Dark_Shikari> *necessary [09:50:58] <Dark_Shikari> what's a good way to do that [09:51:24] <Dark_Shikari> hmm, or I could use packusdw, which is sse4 only [09:51:49] <Dark_Shikari> ... but I'm using mmx. [09:51:50] <Dark_Shikari> no packusdw. [09:57:19] <kshishkov> why have some people mentioned Bink? [09:57:19] <jonwil> ok, so what do I do with these bink videos that have problems in ffmpeg? [09:57:36] <kshishkov> report to me and I'll work on that [09:57:36] <Dark_Shikari> send them to kshishkov [10:00:04] <KotH> send me chocolate [10:00:13] <KotH> swiss chocolate [10:00:28] <kshishkov> and Emmenthal? [10:02:18] <elenril> morning people [10:03:02] <jonwil> where do I send this bik file kshishkov? [10:03:55] <Kovensky> morning elenril [10:04:08] <Kovensky> KotH: would be easier if we were in .ch [10:04:14] <Kovensky> (which obviously means .chocolate) [10:04:58] <merbzt> jonwil: mplayer samples archive [10:05:40] <elenril> so the usual question -- anybody wants to apply a few patches for me? [10:06:29] <jonwil> mplayer samples archive is where? [10:06:30] <elenril> or even better -- anybody wants to give me commit rights? ;) [10:07:12] <merbzt> I'll say yes to that [10:07:20] <jonwil> also, is there any kind of size limits on samples? [10:07:37] <merbzt> 10mb ish should be ok [10:08:00] <Kovensky> the preference is that they should be just small enough to replicate the problem [10:08:14] <jonwil> well I have 3 that all show the problem, one is 3.26mb [10:08:19] <jonwil> one is 27.9mb [10:08:23] <jonwil> and one is 32.1mb [10:08:38] <jonwil> As far as I know other than this one problem with playing the first few frames too fast, they play just fine [10:09:06] <jonwil> I cant see any artifacts vs playing them in the rad game tools player [10:09:15] <jonwil> should I upload the 3.26mb one then? [10:09:32] <merbzt> upload them all [10:09:43] <Kovensky> yea, they're not scary like 10GB samples :) [10:10:05] <pross-au> hardly a 'sample' [10:10:17] <Kovensky> indeed\ [10:10:24] <jonwil> where do I upload them then? [10:10:33] <merbzt> samples.mplayerhq.hu [10:10:36] <Kovensky> incoming.mplayerhq.hu/samples IIRC [10:10:42] <Kovensky> or was it samples.mplayerhq.hu/incoming? =p [10:10:45] <Kovensky> ftp:// [10:10:51] <pross-au> jonwil: go to ffmpeg.org and READ the BUG REPORTS page... [10:11:10] <jonwil> ok, will read that [10:11:18] <pross-au> Kovensky: upload IIRC [10:13:42] <pross-au> kshishkov: i have some problematic files too [10:14:34] <KotH> Kovensky: it's not my fault that you dont live in chocolate country [10:15:15] <Kovensky> KotH: :( [10:15:31] <KotH> Kovensky: jump into the next train and come here [10:15:31] <jonwil> Definatly good job to everyone involved in cracking Bink [10:15:47] <Kovensky> >train [10:15:54] <Kovensky> :D [10:16:02] <jonwil> Just make sure all the work is legally clean so that Rad Game Tools cant sue you :P [10:16:16] <KotH> and if they sue us? [10:16:24] <pross-au> [binkvideo @ 0x95c2e60]Unknown block type 10 :D [10:16:52] <KotH> i have yet to see one company who actually sues us [10:17:00] <KotH> many have threatened us [10:17:03] <KotH> none sued [10:17:13] <jonwil> true [10:17:19] <jonwil> but RGT makes money off their codec [10:17:39] <KotH> so does On2 or any of the others [10:17:41] <_av500_> sue who? [10:17:47] <elenril> KotH [10:17:50] <pross-au> stop speculating jonwil. focus your energy on something positive [10:17:57] <elenril> he's the most evil here [10:17:59] <jonwil> :) [10:18:02] <_av500_> sue the svn server... [10:18:07] <Dark_Shikari> jonwil: so does everyone [10:18:08] * KotH kicks elenril for his lazyness [10:18:27] <Dark_Shikari> the only possible lawsuit RGT could put out is a patent lawsuit [10:18:32] <Dark_Shikari> and I don't recall that RGT is a patentmonger [10:19:05] <KotH> beside, it would be very difficult to sue based on a software patent in a country that does not recognize software patents [10:19:06] <merbzt> we can always fallback on interoperability [10:19:16] <Dark_Shikari> nobody has ever sued ffmpeg over an RE'd codec [10:19:25] <Dark_Shikari> Real has threatened anyone who _used_ ffmpeg [10:19:27] <Dark_Shikari> but they won't sue [10:19:33] <Dark_Shikari> because they know they can't, no legal basis [10:19:37] <_av500_> no sense to sue source code, you sue the users... [10:19:40] <jonwil> my wishes for FFMPEG in 2010 would be support for EALAYER3 (en and decode) and encode support for the VP6 video with EA ADPCM audio .vp6 files of Red Alert 3 [10:19:43] <Dark_Shikari> can't sue users, I mean [10:20:03] <Dark_Shikari> jonwil: why the hell would we want vp6 encode support? [10:20:05] <Dark_Shikari> it's a dead format [10:20:22] <jonwil> The reason its usefull is that Red Alert 3 uses it for video clips [10:20:26] <_av500_> vp3 + vp6 = vp9!!! [10:20:31] <jonwil> so being able to encode new video clips for RA3 mods would be nice [10:20:35] <Dark_Shikari> use on2's encoder [10:20:36] <CIA-90> ffmpeg: michael * r21957 /trunk/libavformat/utils.c: [10:20:36] <CIA-90> ffmpeg: Make sure a set r_frame_rate is not overriden by a guess. [10:20:36] <CIA-90> ffmpeg: Also make sure we dont waste time in this case with collecting timestamps. [10:20:48] <merbzt> jonwil: you can encode to vp6 via the vfw encoder [10:21:08] <jonwil> hmmm I guess so, that doesnt help with the audio though [10:21:16] <Kovensky> my wish for ffmpeg in 2010 is alpha channel support in ffvhuff and ffv1 =p [10:22:24] <jez9999> Hmm, can I get this straight: in order for ffmpeg not to complain "Compiler did not align stack variables. Libavcodec has been miscompiled", you need a bleeding-edge version of gcc. Yet, you still support gcc 2.95? [10:22:42] <jonwil> what platform? [10:22:51] <jez9999> Windows [10:22:56] <Dark_Shikari> jez9999: --disable-sse [10:23:03] <Dark_Shikari> gcc 2.9.5 is "supported" [10:23:06] <Dark_Shikari> and 4.2 is hardly "Bleeding edge" [10:23:10] <Dark_Shikari> I mean, 6 years old is not really bleeding edge [10:23:15] <pross-au> vp6 encoder... [10:23:19] <jez9999> hmm cusiour how MSYS doesnt come with it [10:23:23] <jez9999> *curious [10:23:26] <Dark_Shikari> what? msys has gcc 4.4 [10:23:38] <Dark_Shikari> unless you're using some insane ancient version [10:23:42] <jez9999> for some reason i have 3.4.5 [10:23:48] <jez9999> and i only downloaded it recently [10:23:48] <Kovensky> Dark_Shikari: "official" MSYS probably comes with lolold stuff [10:23:48] <jez9999> weird [10:24:03] <Dark_Shikari> I don't know anyone who uses 3.4 on msys [10:24:07] <Dark_Shikari> I use 3.4 on cygwin due to :lazy: [10:24:26] <jez9999> 'gcc version 3.4.5 (mingw-vista special r3) [10:25:12] <Dark_Shikari> welcome to 7 years ago [10:25:59] <merbzt> jez9999: it should be safe to run a 3.4 compiled ffmpeg, it should not crash might just run abit slower [10:26:10] <Dark_Shikari> merbzt: wrong [10:26:21] <jez9999> i dont get how i managed to download that old version in the last week :-) [10:26:23] <Dark_Shikari> movdqa on unaligned data -> CRASH [10:26:29] <Dark_Shikari> jez9999: old releases [10:27:31] <merbzt> Dark_Shikari: I know but I haven't seen a bugreport regarding that for ages [10:27:53] <merbzt> most buffers are moved to the heap [10:28:06] <jez9999> "Latest official release of GCC from the MinGW project is GCC 3.4.5. " [10:28:08] <jez9999> heh [10:28:10] <jez9999> that might explain it [10:28:26] <Dark_Shikari> jez9999: it's called a dead projects [10:28:31] <Dark_Shikari> *project [10:28:34] <Dark_Shikari> sometimes you have to update away from the dead project [10:28:51] <jez9999> what, gcc 3.4.5 or msys? [10:29:25] * jai uses tdm's builds for windows testing [10:29:42] <Kovensky> and you don't really need mingw gcc anyway [10:29:49] <Kovensky> almost everything from them has been merged back upstream [10:30:07] <jai> some people dont want to waste time building gcc [10:30:18] <Dark_Shikari> msys [10:30:28] <jai> in this case, there are decent precompiled binaries available [10:30:41] <jez9999> i had no idea msys was a dead project [10:30:47] <Dark_Shikari> well, anything still stuck on gcc 3.4 [10:30:49] <jez9999> people still recommend it for windows builds [10:30:50] <Dark_Shikari> is a dead project [10:30:52] <Dark_Shikari> whether they claim so or not [10:30:53] <Dark_Shikari> ;) [10:30:56] <jonwil> will be interesting to see what Google does with On2 VP8 now that they own it. [10:31:07] <Dark_Shikari> jonwil: probably nothing. I'm guessing they bought on2 for some patent leverage [10:31:14] <jai> eh, msys is just an environment [10:31:20] <Dark_Shikari> and yeah, that [10:31:26] <Dark_Shikari> you can update the gcc separate of the environment [10:31:27] <merbzt> Dark_Shikari: and the engineers [10:31:29] <jai> i assume you are complaining about mingw's default gcc [10:31:31] <Dark_Shikari> merbzt: that too [10:31:33] <jez9999> yup [10:31:43] <jez9999> i need an independent build of gcc? [10:31:57] <jai> either use "technology previews" from mingw or tdm's builds [10:32:22] <jonwil> some people have said that it makes sense for Google to open up VP8 as a replacement for H.264 so that they no longer need to buy H.264 licenses for YouTube and Chrome [10:32:34] <Dark_Shikari> jonwil: not useful [10:32:34] <jez9999> gnu.org recommends using Cygwin or MinGW [10:32:41] <Dark_Shikari> mobile devices [10:32:44] <Dark_Shikari> iphone, etc [10:32:58] <Dark_Shikari> youtube wants to have a single global video formats that works on everything [10:33:01] <Dark_Shikari> *format [10:33:10] <Dark_Shikari> also, they don't pay a cent for youtube [10:33:28] <Dark_Shikari> and for chrome, the price of licenses is cheaper than the price of the disks to store the duplicate copies of every single video [10:33:47] <Dark_Shikari> and "some people" aren't saying that, "FSF" is saying it . Don't talk like Fox News. [10:34:02] <jonwil> its not just FSF, others have speculated the same [10:34:03] <pross-au> who cares about open-source VP8, i want the dll first [10:34:07] <jonwil> but yeah I see the point [10:34:12] <Dark_Shikari> FSF and their mouthpieces, ok [10:34:27] <Dark_Shikari> Now, I would not be totally shocked if they _did_ [10:34:42] <Dark_Shikari> but I highly doubt they will try to switch youtube over [10:34:45] <Dark_Shikari> too expensive [10:35:12] <Dark_Shikari> then again, google is known for starting "wars" with every company on earth [10:35:26] <Dark_Shikari> and putting their fingers in everyone's pies [10:35:29] <Dark_Shikari> so who knows. [10:35:29] <jonwil> another point someone raised is that they may open it and get support for it in browsers in case the MPEGLA threatens per-view fees for H.264 [10:35:42] <Dark_Shikari> well, h264 is free until 2016 at a minimum [10:35:44] <Dark_Shikari> so that's quite far off atm [10:36:27] <pross-au> h265 will be out by then [10:36:31] <Dark_Shikari> lol [10:36:44] <pross-au> the hype will be out, at least [10:37:36] <jonwil> I wonder if we will ever see the world adopt a "free" (as in free of patents) video codec for mainstream web use [10:37:50] <Dark_Shikari> VP8 is sure as hell not free [10:38:03] <jonwil> not now it aint [10:38:07] <Dark_Shikari> no, it won't be ever [10:38:12] <Dark_Shikari> Remember when microsoft released WMV9 as VC-1? They claimed it was royalty-free etc etc [10:38:19] <Dark_Shikari> 3 months later, a dozen companies pop up claiming patents on it [10:38:24] <Dark_Shikari> 3 months later, there's a VC-1 equivalent of MPEG-LA [10:38:27] <jonwil> true [10:38:32] <Dark_Shikari> This shit happens every time. [10:38:33] <jonwil> that never occurred to me [10:38:47] <jonwil> thats why we need to keep fighting to see software patents gone [10:38:51] <Dark_Shikari> exactly [10:38:57] <Dark_Shikari> you cannot solve the problem by creating "patent-free formats" [10:39:00] <jonwil> ok, uploaded the samples that show the problem in ffmpeg [10:39:02] <Dark_Shikari> you can only solve it by eliminating patents wholesale [10:39:04] <jonwil> what do I do now? [10:39:06] <Dark_Shikari> or at least software patents [10:39:57] <jonwil> also, if this happened for VC-1 how come no-one challenged Vorbis with patents to shut that down? [10:41:28] <Dark_Shikari> 1) audio is less patent-covered than video [10:41:29] <pross-au> jonwil: next step is to ship a carton of Swan Lager to the ukraine, then wait for the patch to be applied. [10:41:31] <Dark_Shikari> 2) almost nobody cares about vorbis [10:41:49] <Dark_Shikari> last I heard there were still rumors of submarine patents on vorbis [10:42:10] <Dark_Shikari> also, the difference is probably also in who's involved [10:42:13] <pross-au> Dark_Shikari: didnt know subs dived that low [10:42:14] <Dark_Shikari> i.e. microsoft releases vc-1 [10:42:27] <Dark_Shikari> everyone knows microsoft has money [10:42:33] <jonwil> yeah, MS and Google are good targets [10:42:34] <Dark_Shikari> so they tell microsoft "we have patents on your stuff" [10:42:39] <jonwil> XIPH are not [10:42:42] <Dark_Shikari> but who are you going to sue with vorbis? xiph obviously not [10:42:44] <Dark_Shikari> you'd sue the users [10:42:49] <Dark_Shikari> and you'd have them sign an NDA that says they can't tell anyone they were sued [10:43:04] <Dark_Shikari> There's currently a DVD patent troll going around suing every single DVD maker [10:43:10] <Dark_Shikari> charging $20 per unit for license fees or something [10:43:19] <Dark_Shikari> they sue one at a time, and after the settlement, they require that you don't talk about it [10:43:37] <Kovensky> lol? [10:43:48] <Dark_Shikari> this prevents people from banding together to oppose them [10:43:57] <jonwil> ok, so if patents are so evil, how do we actually get change (or at least the kind of change that eliminates patent trolls and bunk patents whilst allowing the legit patents) [10:44:23] <Dark_Shikari> 1) move to france [10:44:25] * Dark_Shikari runs [10:44:25] <Kovensky> who gets to decide whether the patent is a troll, bunk or a real one [10:44:32] <Kovensky> Dark_Shikari: lolfrance [10:44:40] <Dark_Shikari> the EU patent rules say that patents on "computer programs" are prohibited [10:44:50] <Dark_Shikari> so 1) move away from the US 2) ??? 3) profit [10:44:56] <jonwil> for "bunk" you tighten the rules that grant patents [10:45:00] <Dark_Shikari> note this doesn't cover hardware implementations [10:45:06] <Dark_Shikari> getting rid of software patents won't get rid of video coding patents [10:45:10] <Kovensky> though indeed, the only reason we have the patent shitstorm is because of eagleland [10:45:14] <Dark_Shikari> but you can certainly get rid of patents on software implementations [10:45:34] <jonwil> so that the definition of whats patentable goes back to what it was in the pre-electronics age [10:46:17] * Kovensky still saddens when he remembers that nobody makes true force feedback joysticks anymore because some random company claims patents on it [10:46:24] <jonwil> Any patents on mathematical algorithms (implemented in software or hardware) should be prohibited IMO [10:46:46] <Dark_Shikari> hardware implementation patents are less of an issue though [10:46:52] <Dark_Shikari> if you're making an ASIC, you can generally afford to pay license fees [10:47:09] <jonwil> I will file a FFMPEG bug report for the bink bug [10:47:11] <jonwil> is that the best thing to do? [10:47:14] <Dark_Shikari> yes [10:47:33] <jonwil> ok [10:49:58] <Kovensky> Dark_Shikari: Fridge Logic time: how do you know about the DVD patent troll if all victims are required to not talk about it [10:50:41] <Dark_Shikari> someone who violated the rules obviously [10:53:18] <Kovensky> Dark_Shikari: and why would that stop the hipothetical vorbis victims then [10:55:46] <Dark_Shikari> generally people don't talk about it publicly at least [10:55:47] <Dark_Shikari> maybe in private [10:55:52] <Dark_Shikari> and anyways, I doubt there's a troll going around for vorbis [10:55:58] <Dark_Shikari> we _would_ probably hear about it eventually [10:56:03] <jonwil> ok, bug report created :) [10:56:54] <_av500_> m$ uses vorbis and they have nice wma patents that prolly cover vorbis too [10:57:11] <jonwil> where does Microsoft use Vorbis? [10:57:26] <_av500_> some games i think [10:57:47] <Dark_Shikari> probably not games they make, just ones they publish [10:57:58] <merbzt> halo uses vorbis [10:58:05] <Dark_Shikari> heh [10:58:08] <Dark_Shikari> bungie is pretty independent though. [10:58:26] <Kovensky> they used to make games for macos before moving to the xbox ._. [10:58:28] <_av500_> well, m$ would have told em not to use it [10:58:54] <_av500_> if they feared patents... [10:59:08] <_av500_> but as i believe they have the patents :) [11:00:36] <Dark_Shikari> :) [11:01:34] <_av500_> wma and vorbis fft foo seem similar and m$ has patents [11:01:44] <jonwil> anyhow, YAY for Bink Video in FFMPEG [11:02:14] <jonwil> my wish is that I had the skills to help with EALayer3 :( [11:02:18] <kshishkov> jonwil: I'm downloading samples, will look at them in several minutes [11:02:20] <jonwil> or any codec for that matter [11:02:23] <jonwil> ok, great [11:02:40] <Dark_Shikari> my real question is why anyone would want to make videos for something as crappy as red alert 3 [11:02:43] * Dark_Shikari ducks [11:02:48] <jonwil> lol [11:02:55] <jonwil> there are some good mods for C&C3/RA3 [11:03:04] <jonwil> the best of which is Mid-East Crisis 2 [11:03:11] <jonwil> which is good enough to be a standalone game in its own right [11:03:14] <Dark_Shikari> EA games: because the only way to get anything good out of the games is to mod them to be less shit. [11:03:28] <Dark_Shikari> and so the mods need cutscenes? [11:03:40] <jonwil> not necessarily cutscenes [11:03:40] <kshishkov> yes [11:03:45] <jonwil> but intro movies and other things [11:03:58] <kshishkov> FMV is FMV by any other name [11:04:08] <jonwil> Also btw I see what might be artifacts in R_L08.bik [11:04:13] <jonwil> but I dont know if those are FFMPEG bugs [11:04:17] <jonwil> or present in the source video [11:04:24] <jonwil> mostly around the mouths of various people talking [11:05:08] <kshishkov> if they are like several wrong dots on non-straight edges then it's likely to be FFmpeg artifact [11:05:24] <jonwil> dont know [11:05:27] <jonwil> you can take a look anyway [11:05:35] <jonwil> and see if you see anything that could be a FFMPEG issue :) [11:06:06] <kshishkov> jonwil: there's an official player, you know [11:06:13] <jonwil> yes I did use that [11:06:20] <jonwil> but the artifacts were small and it was hard to tell [11:08:43] <kshishkov> jonwil: is it yours - R_Intro and ea_ww ? [11:08:44] <jez9999> ugh! [11:09:03] <jez9999> tdm's mingw builds fuck apache ant! [11:09:17] <jez9999> Malformed \uxxxx encoding, it's not converting windows backslashes in the path [11:09:20] <jez9999> stupid thing [11:09:27] <jonwil> R_Intro and EA_WW are from a mod I am involved with [11:09:58] <kshishkov> they seem to play fine here [11:10:45] <jonwil> wierd then [11:10:50] <jonwil> maybe something is wrong with my build? [11:11:42] <pross-au> SDL? [11:11:59] <jonwil> using the latest SDL from the SDL homepage [11:12:08] <jonwil> also, this time issue happens if I convert with ffmpeg [11:12:16] <jonwil> as well as if I play [11:12:22] <pross-au> latest isnt always the greatest (except for ffmpeg) [11:12:50] <jonwil> since the problem happens even if I convert, it cant be SDL at fault [11:13:24] <pross-au> what are you playing it backw ith? [11:13:29] <jez9999> Why would the official MinGW convert Windows path separators to /, but tdm's builds not do so? [11:13:56] <jai> jez9999: look at the build configuration for tdm builds [11:14:19] <jez9999> build configuration? i'm installing it using a setup [11:14:36] <jai> jez9999: i meant the gcc build configuration [11:15:02] <kshishkov> yep, verified - plays fine on x86 too [11:15:04] <jez9999> what am i looking for? [11:16:52] <jonwil> Lets see if the built at http://ffmpeg.arrozcru.org/autobuilds/ can play it properly [11:17:16] <jez9999> jai: what am i looking for? [11:18:00] <jonwil> nope, those build also fail [11:18:18] <kshishkov> what message? [11:18:30] <jonwil> no message [11:18:45] <jonwil> what I see when I play the video clip is that the first few frames of the video play faster than the rest of the video [11:18:57] <jonwil> when the official player plays them all at the slower speed [11:20:01] <jonwil> Going to see if 21957 helps [11:20:12] <jonwil> that one isn't in the prebuilt binary [11:21:28] <kshishkov> can be demuxer problem [11:22:18] <kshishkov> or player - try newest MPlayer build as well [11:22:36] <jonwil> the problem happens whether I use ffplay [11:22:40] <jonwil> or whether I convert with ffmpeg [11:24:23] <jonwil> can anyone else confirm if they are or arent seeing the problem I see? [11:24:31] <kshishkov> still, good chance it may be demuxer then [11:24:48] <pross-au> Ye [11:24:51] <pross-au> Yep [11:24:57] <jonwil> so you see it also? [11:25:16] <pross-au> No i am working on the dct audio regression [11:25:26] <jonwil> ok [11:25:29] <pross-au> (binkaudio_dct) [11:27:24] <jai> jez9999: http://www.tdragon.net/recentgcc/devel.php [11:27:37] <jai> jez9999: "Includes a patch which corrects backslash usage in header paths and fixes path problems when debugging." [11:28:15] <jez9999> seems to be a problem with apache Ant [11:28:36] <jez9999> the official msys gives me a /home/xyz style path for pwd [11:28:47] <jez9999> the tdm command prompt gives me a windows path [11:28:50] <jez9999> like C:\... [11:28:56] <jez9999> that fucks up the build [11:28:58] <jai> i misinterpreted your question then [11:29:19] <jai> use msys with tdm then [11:30:17] <jez9999> erm [11:30:26] <jez9999> i see [11:34:04] <jonwil> so how do I find out more about why these files wont play/convert properly? [11:34:19] <jonwil> Or should I wait and let the guys who know what they are doing do something about it? :P [11:35:04] <jonwil> Although waiting for the binkaudio_dct issue to be fixed would help too [11:35:11] <jonwil> since these videos all use binkaudio_dct :P [11:35:27] <jai> jonwil: send pross-au some beer [11:35:48] <jonwil> lol, I have no money to do that :P [11:36:03] <jai> heh [11:36:14] <kshishkov> send him a rabbit then ;) [11:36:24] <jai> lolbunnies? [11:36:25] <jonwil> blame the economic crisis for the lack of jobs in my neck of the woods [11:43:00] <mru> kshishkov: where did those ape neon patches of yours go? [11:43:10] <kshishkov> nowhere [11:43:30] <mru> where's the latest version? [11:43:48] <kshishkov> http://shishkov.homeunix.net/int_neon.patch [11:48:33] <mru> kshishkov: mind if I do some minor fixups and commit? [11:49:23] <kshishkov> not at all! [11:54:27] <mru> kshishkov: q4-q7 are callee-saved [11:54:59] <kshishkov> oh [11:55:50] <mru> I'm fixing it [11:55:58] <mru> and a couple of other minor things [11:57:37] * kshishkov begins to like MIPS approach more [11:58:03] <mru> which? [11:58:14] <kshishkov> for saving registers [11:58:33] <mru> mips also has mixed caller- and callee-saved regs [11:58:38] <mru> which is how it should be [11:59:26] <Dark_Shikari> oh wow, I figured out why firefox was crashing every 3 days [11:59:32] <Dark_Shikari> it hit 2GB of memory usage and OOM'd [11:59:37] <mru> made by mozilla? [12:00:13] <mru> my firefox is only at 366M at the moment [12:00:30] * kshishkov is on the box with 512 MB RAM [12:14:29] * elenril facepalms [12:15:09] <elenril> Codec Name Length: Specifies the number of Unicode characters stored in the Codec Name field. [12:15:23] <elenril> can this be any more braindead? [12:15:42] <kshishkov> yes [12:15:58] * elenril somehow doubts it [12:16:07] <kshishkov> for example, using fixed size [12:16:23] <KotH> kshishkov: actually, that would be more intelligent [12:16:28] * elenril agrees [12:16:44] <kshishkov> this reminds me of Pascal-style strings [12:16:45] <mru> fixed size? [12:16:54] <mru> oh [12:16:54] <kshishkov> yes, like DOS names [12:17:04] <mru> my mind was still on registers [12:18:23] <kshishkov> hmm, "FSF urges Google to free future Theora 2"? [12:18:30] <mru> lol [12:18:51] <KotH> kshishkov: sauce? [12:19:00] <Dark_Shikari> lol vp8 [12:19:03] <mru> is this the mother of all clusterfucks or what? [12:19:06] <kshishkov> KotH: /. [12:19:07] <KotH> kshishkov: and BP style strings are not that bad [12:20:35] <mru> there we go [12:21:08] <elenril> how do tell how many characters are there anyway [12:21:14] <mru> count them [12:21:18] <elenril> do we have a unicode-aware strlen? [12:21:22] <CIA-90> ffmpeg: mru * r21958 /trunk/libavcodec/ (arm/dsputil_init_neon.c arm/int_neon.S Makefile): [12:21:22] <CIA-90> ffmpeg: ARM: NEON scalarproduct_int16 and scalarproduct_and_madd_int16 [12:21:22] <CIA-90> ffmpeg: Patch by Kostya, minor fixes by me. [12:21:24] <CIA-90> ffmpeg: kostya * r21959 /trunk/libavcodec/bink.c: [12:21:24] <CIA-90> ffmpeg: Correct bundle lengths calculation for small Bink files. [12:21:24] <CIA-90> ffmpeg: This fixes issue 1764. [12:29:41] <CIA-90> ffmpeg: stefano * r21960 /trunk/cmdutils.c: [12:29:41] <CIA-90> ffmpeg: Make opt_default() print an error message and exit if the option [12:29:41] <CIA-90> ffmpeg: supplied is not recognized. [12:29:43] <mru> hmm, I don't see anything actually calling scalarproduct_int16 [12:30:30] <mru> in ape decoder [12:30:58] <mru> the only 2 calls are in acelp_pitch_delay.c [12:31:59] <mru> ah, r20739 [12:36:01] <CIA-90> ffmpeg: kostya * r21961 /trunk/libavcodec/bink.c: [12:36:01] <CIA-90> ffmpeg: Make Bink decoder to stop decoding planes after all bits are used. [12:36:01] <CIA-90> ffmpeg: This prevents crashes during decoding grayscale Bink files like [12:36:01] <CIA-90> ffmpeg: samples from Impossible Creatures game demo. [12:36:35] <jonwil> good to see more progress on bink :) [12:36:46] <jonwil> I need to find more things with bink video in them and see what happens... [12:40:00] <mru> from gcc documentation: "Unfortunately, I have forgotten why this was so, and I don't know whether it is still true." [12:40:07] <Dark_Shikari> on what topic [12:40:16] <mru> machine descriptions [12:40:25] <mru> "may also be a need to support fixed point `movm' instructions in and out of floating point registers." [12:40:39] <kshishkov> jonwil: list of games using Bink is available [12:41:00] <jonwil> I need to look through my own collection for bik files [12:41:09] <jonwil> I cant even remember half of what I own [12:42:53] <Dark_Shikari> kshishkov: it's about 5000 miles long [12:44:18] <kshishkov> Dark_Shikari: first entry are for 1C games which are in Russian, so you won't see them [12:44:35] <jonwil> ok, Diablo II bink files play just fine [12:45:00] <Dark_Shikari> kshishkov: it breaks hard on civilization 4 movies [12:45:07] <Dark_Shikari> like, seriously hard [12:45:31] <Dark_Shikari> on the 2K intro movie, it goes too fast at the start, then goes slow to catch up with itself, then locks up at the end of the video (ffplay) [12:45:42] <Dark_Shikari> the intro goes all weird [12:45:44] <kshishkov> ok, ask jonwil to fix it [12:45:53] <jonwil> lol, why ask me? [12:46:01] <jonwil> I know nothing about Bink or Bink codecs [12:46:14] <Dark_Shikari> for that matter, ffplay is just crashing all ovefr [12:46:20] <Dark_Shikari> I wonder if this is an unrelated issue [12:46:33] <kshishkov> samplesarewelcome [12:46:33] <Dark_Shikari> yeah, if I click on the playback window in ffplay, it locks up [12:46:40] * kshishkov has stopped on Civ II [12:46:51] <kshishkov> ah, that's seeking issue - ask Peter [12:47:10] <Dark_Shikari> why would clicking on it cause it to seke? [12:47:12] <Dark_Shikari> *seek [12:47:37] <kshishkov> that's known FFplay feature [12:47:40] <kshishkov> documented too [12:47:52] <Dark_Shikari> lol [12:48:05] <Dark_Shikari> uploading the 2K intro sequence [12:48:16] <Dark_Shikari> beyond locking up at the end and the speed issue, it works fine [12:48:20] <Dark_Shikari> no artifact [12:50:58] <Dark_Shikari> kshishkov: http://www.mediafire.com/?bg2m12ihjnm [12:51:02] <Dark_Shikari> 2K intro from Civilization 4 [12:51:06] <Dark_Shikari> now to test on some other files. [12:51:54] <Dark_Shikari> everything locks up at the end of the file in ffplay. [12:52:10] <jonwil> yes I noticed the same thing on my clips [12:52:15] <jonwil> the lockup at end of file [12:52:25] <jonwil> I got one game that uses BINK only to play some startup logos (wierd) [12:52:31] <Dark_Shikari> oh, I should try Starcraft [12:52:56] <Dark_Shikari> yeah, everything has the lock up at end + speed issue [12:53:17] <Dark_Shikari> oh wait, starcraft uses smacker, not bink [12:53:17] <jonwil> tried with C&C Renegade, Diablo II and some logo movies from Tron 2.0 [12:53:24] <Dark_Shikari> is there a smacker decoder? [12:53:34] <jonwil> and so far nothing has crashed [12:55:11] <kshishkov> Dark_Shikari: you could have sent those two kilobytes more easily [12:55:25] <Dark_Shikari> two kilobytes? [12:55:27] <Dark_Shikari> it's 3 megabytes [12:55:34] <kshishkov> you said 2K [12:55:38] <Dark_Shikari> .... [12:55:42] <Dark_Shikari> it's the intro for 2K Games [12:55:42] <Dark_Shikari> lol [12:56:04] <Dark_Shikari> tested Medieval Total War: works [12:56:09] <Dark_Shikari> tested Psychonauts: works [12:56:14] <kshishkov> Dark_Shikari: guess who implemented Smacker decoder for FFmpeg ;) [12:56:20] <Dark_Shikari> (all of the same problems as mentioned before, but no new ones) [12:56:27] <kshishkov> but I've not REd it completely [12:57:24] <Dark_Shikari> Mass Effect: works but no audio. I'm guessing there's just no audio in the file and they handle it separately [12:57:56] <kshishkov> FFplay prints streams available [12:58:25] <Dark_Shikari> how [12:58:33] <jonwil> hmmm, I wonder if this copy of Riven has Bink video [12:58:40] <jonwil> oh wait no, thats QuickTime :P [12:58:43] <Dark_Shikari> ffplay -h prints nothing [12:58:47] <Dark_Shikari> "ffplay" prints nothing [12:58:54] <Dark_Shikari> ffplay filename shows the video, but prints nothing [12:59:17] <kshishkov> old FFplay? Current ones print the same info as FFmpeg [12:59:24] <Dark_Shikari> more like ffplay is broken on windows [13:00:00] <twnqx> is the "sed s/author/artist/g" patch for mov/m4a already in? :X [13:00:01] <Dark_Shikari> Modern Warfare 2: works [13:00:03] <kshishkov> ah, std{out,err} do not work well with windows and SDL [13:00:32] <Dark_Shikari> Borderlands: works [13:00:40] <Dark_Shikari> Dragon Age: works [13:01:36] <Dark_Shikari> lol @ games using bik for still images [13:01:59] <kshishkov> or for music like Tony Hawk Sakter [13:03:10] <Dark_Shikari> Jade Empire: works [13:03:24] <Dark_Shikari> Left 4 Dead: works [13:03:26] <Dark_Shikari> Team Fortress 2: Works [13:07:04] <jonwil> slowly working down my pile of "games that may have bik files" :) [13:07:20] <jonwil> enter the matrix and RCT dont have them [13:07:23] <Dark_Shikari> I just grepped my entire drive [13:07:31] <mru> don't they usually sport a bink logo on the cover if they use it? [13:07:37] <kshishkov> they do [13:07:46] <kshishkov> (unless it's pirate release) [13:07:49] <mru> I have a pile of bluray games [13:07:55] <mru> unfortunately I can't read the discs [13:07:59] <twnqx> magic: the gathering online has bink files iirc [13:08:13] <twnqx> haven't started it for years though [13:10:47] <Dark_Shikari> Neverwinter Nights: works [13:12:52] <Dark_Shikari> damn, that game had a cool intro [13:13:14] <KotH> Dark_Shikari: put it online itno our samples collection :) [13:13:24] <Dark_Shikari> I have so many fucking biks it's not funny [13:13:32] <Dark_Shikari> if I did that with all of them there'd be like 10 gigs [13:13:34] * kshishkov has only Icewind Dale intro [13:13:36] <jonwil> ok, Red Alert 2 works [13:13:38] <Dark_Shikari> it doesn't compress very well you know [13:13:49] <kshishkov> with Bink or with x264? [13:13:50] <KotH> Dark_Shikari: i dont mind an additional 10g of samples, if they are well sorted ;) [13:13:55] <Dark_Shikari> kshishkov: with bink [13:14:06] <Dark_Shikari> KotH: my upload is 50KBps [13:14:21] <Dark_Shikari> and last I recall people were complaining about incoming running out of disk space [13:14:33] <KotH> Dark_Shikari: well.. i can solve taht issue :) [13:14:39] <kshishkov> Dark_Shikari: it won't be in incoming [13:14:45] <kshishkov> for long at least [13:14:46] <Dark_Shikari> oh I have a better idea [13:14:51] <Dark_Shikari> I'm going to grep the entire Mudd network for bik files [13:15:00] <KotH> mudd? [13:15:03] <Dark_Shikari> my college [13:15:10] <Dark_Shikari> we have a network search engine that searches samba shares [13:15:16] <KotH> lol [13:15:22] <KotH> talk about privacy :) [13:15:33] <kshishkov> "shares" [13:15:50] <mru> he didn't say "hacks into machines and indexes private data" [13:15:51] <Dark_Shikari> KotH: you choose what you share [13:15:58] <Dark_Shikari> it's intended for movies, music, games, etc [13:16:19] <_av500_> mru: just the public exams.doc are enough usually [13:16:25] <kshishkov> mru: not so advanced search engine ;) [13:17:01] <jonwil> RA2 definatly works [13:17:09] <Dark_Shikari> Splinter Cell: works great [13:17:29] <jonwil> and has no bink logo on the disk FYI [13:17:57] <Dark_Shikari> "Shadow Wars" [13:18:00] <Dark_Shikari> works great [13:18:17] <Dark_Shikari> ... or not [13:18:21] <Dark_Shikari> oh wow, instant crash on the main intro [13:19:06] <Dark_Shikari> yup, found a crash in bink! [13:19:29] <jonwil> Dungeon Siege has binkw32.dll [13:19:34] <jonwil> but I cant find out how to get at the bink files [13:19:42] <Dark_Shikari> kshishkov: two bugs for you, in one file! [13:20:08] <Dark_Shikari> Bug 1: [binkvideo @ 00d988a0]DC value went out of bounds: -54566 --> CRASHHHH [13:20:16] <jonwil> aha, movies must be on the other disk :P [13:20:17] <kshishkov> jonwil: could be in some archives like Heroes of Might and Magic III [13:20:25] <Dark_Shikari> It's a bink file from an actual game, so I would suspect the file is valid [13:20:33] <Dark_Shikari> Bug 2: [binkaudio_dct @ 010d8c50]reported data size (480) does not match output data si [13:20:33] <kshishkov> it may [13:20:37] <Dark_Shikari> ze (7680) [13:20:45] <kshishkov> that's standard, ignore it [13:20:57] <Dark_Shikari> fix it [13:20:57] <Dark_Shikari> =p [13:21:07] <jonwil> nope, nothing there, bink must be in resource files I cant get at [13:21:07] <Dark_Shikari> anyways, uploading the file [13:21:09] <kshishkov> that's audio, so ask Peter [13:21:17] <kshishkov> waiting for it [13:21:21] <Dark_Shikari> kshishkov: forward it to him for me, you're the bink guy [13:21:27] <Dark_Shikari> I'm the "spend time grepping servers" guy [13:22:35] <_av500_> grep me a steak sandwich [13:22:50] <mru> you forgot to sudo [13:22:57] <Dark_Shikari> heh, wow, Cantor server just shared his whole hard disk [13:23:10] <kshishkov> that's logical :) [13:23:18] <_av500_> mru: im always logged in as root, no? [13:23:37] <kshishkov> _av500_: only if you are silly sysadmin [13:23:38] <mru> yes of course, no ubuntu there [13:23:52] <mru> kshishkov: didn't you read xkcd today? [13:23:54] <Dark_Shikari> Halo works [13:24:00] <kshishkov> mru: of course I did [13:24:06] <jonwil> so thats Halo 1 on PC? [13:24:08] <Dark_Shikari> yes [13:24:18] <jonwil> <removes from list of games to check> [13:24:21] <kshishkov> Dark_Shikari: make Halo your performance test samples [13:24:31] <Dark_Shikari> Age of Empires 3: works [13:24:37] <Dark_Shikari> wait a minute [13:24:38] <Dark_Shikari> the audio sounds weird [13:24:46] <Dark_Shikari> I'm going to have to check this against the official player [13:24:53] <Dark_Shikari> I doubt they used low quality bink audio in such a modern game [13:25:11] <kshishkov> Peter is hunting that bug [13:25:20] <Dark_Shikari> kshishkov: http://www.mediafire.com/?zzwztmmyyyx here's your crash test sample [13:27:51] <kshishkov> Halo 3 Binks are 1280x960, should be good for testing performance [13:28:49] <Dark_Shikari> ok, I have a sample with audio issues [13:29:36] <Dark_Shikari> I'll leave it up to you to forward these on [13:29:41] <Dark_Shikari> uploading the first 5M bytes of this one, since it's long [13:30:38] * mru keeps thinking it would be nice with a cpu allowing on the fly code generation [13:30:50] <Dark_Shikari> ? [13:31:04] <kshishkov> i.e. running JVM HotSpot :P [13:31:05] <mru> basically a mechanism to feed the result of an instruction directly into the front of the pipeline [13:31:26] <Dark_Shikari> kshishkov: http://www.mediafire.com/?zz3znmzfwwf [13:31:28] <Dark_Shikari> audio issues sample [13:31:39] <jonwil> ok, got another video that crashes ffplay right up [13:32:36] <Dark_Shikari> Rise of Legends: works [13:32:41] <Dark_Shikari> Max Payne 2: works [13:32:50] <jonwil> should I upload this video to samples? [13:33:04] <kshishkov> yes [13:33:24] * elenril wonders where did we get a wma2 encoder [13:33:25] <Dark_Shikari> Sins of a Solar Empire: works [13:33:44] <jonwil> Uploading stccmenu.bik to /incoming now [13:34:07] <jonwil> crashes ffplay on startup [13:34:13] <jonwil> official rad player plays it fine [13:34:17] <kshishkov> elenril: it's virtually the same as wma1 [13:34:23] <Dark_Shikari> Titan Quest: works well, but audio is fucked up as before [13:34:41] <elenril> kshishkov: and where did we get a wma1 encoder? :) [13:34:52] <kshishkov> elenril: some Michael wrote it [13:34:56] <jonwil> EA Sports V8 Challenge seems to work except that one video [13:34:59] <elenril> o_0 [13:35:16] <Dark_Shikari> Assassin's Creed: works [13:35:55] <jonwil> ok, Moto GP 2 works (seems they have .vid files that are really renamed bik files) [13:36:12] <jonwil> seems not to have any audio [13:36:15] <Dark_Shikari> Call of Duty: works [13:36:16] <jonwil> no audio stream [13:37:19] <Dark_Shikari> Fallout 3: works [13:38:54] <Dark_Shikari> Sid Meier's Pirates: works [13:39:19] <jonwil> EA Sports F1 2001 works [13:39:53] <jonwil> did someone say they tested the Tony Hawk games? [13:40:27] <kshishkov> no, but we have samples at MPHQ [13:40:35] <jonwil> from which games? [13:40:52] <kshishkov> thps4 [13:41:00] <jonwil> ok, I have a copy of THPS3 here [13:41:02] <jonwil> which I will test [13:41:15] <Dark_Shikari> Black and White 2: works, with audio issue [13:44:13] <Dark_Shikari> Homeworld: works [13:45:39] <Dark_Shikari> Arcanum: works [13:46:23] <Dark_Shikari> Need for Speed SHIFT: works [13:46:31] <Dark_Shikari> kshishkov: got any results from that crash test? [13:46:45] <kshishkov> none useful results so far [13:47:23] <Dark_Shikari> got it to crash at least? [13:47:30] <kshishkov> of course :) [13:48:45] <Dark_Shikari> Gears of War: works [13:49:07] <jonwil> C&C: Generals works [13:51:29] <jonwil> 6 games left in my pile to test [13:52:21] <CIA-90> ffmpeg: kostya * r21962 /trunk/libavcodec/ (indeo5.c ivi_common.h ivi_common.c): [13:52:21] <CIA-90> ffmpeg: Macroblock and block Huffman code sets are to be used by both Indeo 4 and [13:52:21] <CIA-90> ffmpeg: Indeo 5, so make them global and move their initialization to the common place [13:52:21] <CIA-90> ffmpeg: as well. And fix static VLC initialization, as ff_ivi_create_huff_from_desc() [13:52:21] <CIA-90> ffmpeg: used old way to do so. [13:53:02] <Dark_Shikari> Galatic Civilizations 2: works [13:54:26] <Dark_Shikari> Rainbow 6 Vegas: works [13:55:04] <Dark_Shikari> Prometheus: works [13:55:25] <Dark_Shikari> The Ball UDK Demo: works [13:55:53] <Dark_Shikari> Guitar Hero III: works [13:55:54] <jonwil> 3 games left [13:56:03] <Dark_Shikari> did I mention there's a lot of games on this network [13:56:23] <kshishkov> no [13:56:36] <kshishkov> but since that's college network, it should be obvious [13:57:30] <Dark_Shikari> rhetorical question [13:57:31] <Dark_Shikari> also [13:57:35] <Dark_Shikari> Got another crash + error sample for you [13:57:38] <Dark_Shikari> plays fine in the official player [13:57:42] <Dark_Shikari> from Guitar Hero III [13:58:07] <Dark_Shikari> different error though [13:58:14] <Dark_Shikari> [binkvideo @ 00f388a0]Too many block type values [13:58:22] <Dark_Shikari> might be a different variation of bink [13:59:18] <jonwil> ok, thats it for "games I can find that have bink files" [13:59:46] <Dark_Shikari> kshishkov: http://www.mediafire.com/?mdm0y3kdmmz [13:59:47] <Dark_Shikari> crash sample. [14:01:01] <kshishkov> ok, got it [14:01:32] <KotH> kshishkov: make a dir in incoming where you collect bink samples [14:01:40] <KotH> kshishkov: if you need more space, let me know [14:01:59] <KotH> kshishkov: also let me know when you've collected a few so i can move them to the correct place [14:02:03] <kshishkov> KotH: meh, I'm on par with Dark_Shikari on upload speed [14:03:44] * jonwil is out of bink files to test [14:06:00] <KotH> kshishkov: who cares about speed? [14:06:27] <KotH> i dont mind if it takes a week [14:07:29] <kshishkov> for now it's mostly the same variation [14:09:01] <Dark_Shikari> kshishkov: I got a ton of failure here, from GH3, some seem to fail in different ways [14:09:05] <Dark_Shikari> invalid block type, etc, etc [14:09:13] <Dark_Shikari> they all work fine with the regular player [14:09:52] <kshishkov> _that_ sounds as a new BIKi flavour [14:10:03] <Dark_Shikari> But GH3 is not that new a game [14:10:04] <Dark_Shikari> dunno [14:10:14] <Dark_Shikari> also, they all lock up ffplay [14:10:20] <Dark_Shikari> i.e. it goes to background and doesn't terminate [14:10:27] <Dark_Shikari> so you can end up with 20 ffplays running [14:10:41] <kshishkov> not running :S [14:11:54] <Dark_Shikari> http://www.mediafire.com/?iljotzz3nii [14:11:58] <Dark_Shikari> here's a 7z file of a bunch of broken files [14:12:17] <Dark_Shikari> have fun [14:12:26] <kshishkov> thanks [14:13:09] <kshishkov> I suspect they have an additional size field for the first chroma plane [14:13:17] <kshishkov> and that's flag-based [14:14:17] <Dark_Shikari> this a suspicion from the past or what? [14:14:51] <kshishkov> no, it's new coming from looking at prelude_1.bik first frame [14:16:19] <Dark_Shikari> Ah [14:16:40] <Dark_Shikari> btw, I'm "just started" in terms of number of videos [14:17:06] <Dark_Shikari> not even 20% through the list [14:17:46] <J_Darnley> Dark_Shikari: was the audio problem you got a sort-of pulsating sound? [14:19:11] <Dark_Shikari> yes [14:19:48] <J_Darnley> Right, should I provide the file (BF1942 Intro) that gives me that too? [14:20:02] <kshishkov> nah, too many of them [14:20:25] <J_Darnley> Okay, later perhaps, if it isn't fixed [14:20:35] * kshishkov wonders why nobody heard a problem with audio before recent Bink video decoder addition [14:20:53] <J_Darnley> I didn't bother trying it until today [14:21:20] <J_Darnley> I already got what I needed with the the official tools [14:21:34] <kshishkov> why now then? [14:21:44] <Dark_Shikari> because now we have video [14:21:47] <J_Darnley> Because the video commit reminded me [14:22:15] <kshishkov> of the fact that official tools exist? [14:22:42] <J_Darnley> No, that ffmpeg was getting (had) bink support [14:23:28] <J_Darnley> I've had that video as a lossless-x264/flac/mkv file for ages [14:25:21] <Dark_Shikari> well kshishkov, I'm going to grab some sleep [14:25:27] <Dark_Shikari> when I wake up I expect at least one of those samples fixed! ;) [14:25:46] <kshishkov> probably it will require alpha plane support, dunno [14:25:52] <kshishkov> but I'll try [14:26:23] <kshishkov> ãäŒã¿ [14:27:44] <elenril> moonspeak? in my #ffmpeg-devel ? [14:27:53] <kshishkov> where else? [14:32:30] <KotH> jo, wo süscht? [14:33:33] * elenril throws http://en.wikipedia.org/wiki/UTF-8 at KotH [14:45:17] * KotH throws some http://en.wikipedia.org/wiki/Ebcdic at elenril [14:45:58] * kshishkov throws http://en.wikipedia.org/wiki/Cuneiform at them both [14:46:09] <BBB> kshishkov, you should RE VP8, quick! :-p [14:46:21] <kshishkov> BBB: let's leave it to Mike, OK? [14:47:06] <elenril> KotH: utf-16 is fine too [14:47:18] * elenril now knows how to read and write it thanks to m$ [14:48:08] <BBB> kshishkov, you mean so it'll be finished in 3011? [14:48:10] * kshishkov can write a lot of things [14:48:27] <BBB> kshishkov, or you men that adobe will somehow find a reason to finance it, because it's advantageous to them somehow? [14:48:36] <kshishkov> BBB: no, I mean if he don't write spec for it, Xiph won't adopt it [14:48:47] <BBB> xiph is relevant why exactly? [14:48:52] <BBB> xiph is like MS [14:48:54] <BBB> they take a standard [14:48:57] <BBB> modify it incompatibly [14:49:00] <kshishkov> VP8 may become Theora 2 [14:49:01] <BBB> and publish it as their own [14:49:18] <BBB> and tell everyone that WE DID IT WE ARE AWESOME WE ARE PERFECT WE DID IT ALL BY OURSELVES!!! 111 222 [14:50:18] <elenril> BBB: want to apply a few patches for me? ;) [14:50:47] <elenril> btw who do i need to bug to get a svn account? [14:51:02] <kshishkov> DonDiego [14:52:16] * elenril summons DonDiego from depths of he^w Germany [14:52:17] * KotH throws a http://en.wikipedia.org/wiki/Cruciform_%28Hyperion_Cantos%29 at kshishkov [14:54:54] * janneg thinks that throwing classical lexika like Britannici or Brockhaus has more impact [14:55:22] <kshishkov> Nordiska Familjebok [15:00:43] <CIA-90> ffmpeg: kostya * r21963 /trunk/libavcodec/bink.c: Make Bink decoder able to skip alpha plane [15:04:26] <BBB> elenril, but anyway, tell me which patches and I can apply [15:04:35] <BBB> elenril, and send dondiego an email [15:04:49] <elenril> BBB: nut metadata conv table [15:05:58] <merbzt> elenril: I have a asf patch you can look at [15:06:00] <elenril> and 4 patches in 'asfenc: fix extended content header', mail on Sun, 21 Feb 2010 15:54:40 +0100 [15:06:33] <elenril> merbzt: what patch? [15:07:57] <merbzt> w8 and I'll dig it up for you [15:08:44] <BBB> elenril, ok, will look [15:09:16] <elenril> thanks [15:11:02] <merbzt> elenril: http://pastebin.ca/1805785 [15:11:19] <merbzt> this is needed for wmapro over spdif [15:12:04] <merbzt> is it related to the metadata work you do ? [15:12:33] <elenril> don't think so [15:13:03] <elenril> revision 11824 o_0 [15:13:33] <elenril> where did you get it/why isn't it applied? [15:14:20] <BBB> might be from last year's soc [15:14:20] <BBB> :) [15:14:27] <merbzt> not needed for anything yet [15:14:55] <merbzt> this need to go from the asf container to the spdif container [15:15:11] <merbzt> or asf demuxer to spdif muxer [15:15:32] <merbzt> not sure how to transport it [15:15:47] <merbzt> dolby e needs something like this also [15:16:04] <elenril> well i don't know a thing about spdif :) [15:16:14] <merbzt> you don't need to [15:16:33] <merbzt> this is just metadata from one container to another [15:16:46] <BBB> putting it in extradata is terrible [15:16:52] <BBB> you should put it in ... metadata! :) [15:17:21] <elenril> lol [15:18:45] <jez9999> BBB: looks like Michael is being ultra-anal over file.c, eh? [15:19:13] <jez9999> good job i'm building my own version so fuck his retardedness [15:20:01] <merbzt> BBB: do we have that framework ? [15:21:11] <BBB> merbzt, now we do, yes [15:21:16] <BBB> merbzt, AVMetadata [15:21:19] <BBB> merbzt, \o/ [15:21:23] <merbzt> yey [15:21:24] <BBB> last year we didn't [15:21:29] <BBB> or so [15:21:31] <BBB> maybe we did [15:21:46] <BBB> jez9999, this is his regular self, he's OK with it I just need to convince him [15:22:00] <merbzt> do we have some demuxer that ses it ? [15:22:06] <merbzt> *uses [15:22:09] <BBB> jez9999, I've worked with Michael for a while, so I think I have a good idea of how it works [15:22:17] <BBB> merbzt, uses the metadata framework? or something else? [15:22:25] <merbzt> uses the metadata framework [15:22:37] <BBB> ID3 demuxer uses it pretty well [15:22:47] <merbzt> ok [15:22:50] <BBB> it supports "any" tag, and for some it uses the id3 tag if it doesn't recognize it [15:22:57] <BBB> like TYER, apparently ("year") [15:22:57] <jai> most demuxers do right [15:22:57] <jai> ? [15:23:01] <BBB> I think so [15:23:16] <BBB> but me no expert so I might be wrong [15:23:25] <BBB> btw did mike file the application for this year's soc? [15:23:40] <merbzt> not that I know of [15:24:14] <elenril> asf now handles metadata quite well too :) [15:24:56] <BBB> oh that's march [15:24:57] <BBB> n/m [15:25:03] <elenril> BBB: yes, TYER is supposed to be year [15:25:18] * elenril should fix this soon [15:25:57] <BBB> get a svn account first [15:26:01] <BBB> I love this work by the way [15:27:14] * elenril goes to school, bbl [15:27:53] <kshishkov> why not to kindergarden? [15:28:20] <jez9999> BBB: if/when the query string patch gets in, do you admin the rtsp.c and rtpproto.c files? [15:28:25] <jez9999> s/admin/maintain/ [15:28:29] <BBB> me and luca [15:28:35] <BBB> and yes that'll be easier [15:28:44] <jez9999> ok, well i will then start an issue for my patch there [15:28:48] <BBB> don't despair, I told you I'd help find a solution to your problem [15:28:49] <jez9999> which is working already, im using my own build [15:28:54] <BBB> and I did :) [15:29:34] <jez9999> well, i could've used the 'add to avformatcontext' trick with my own build... [15:32:16] <BBB> believe me, I maintained a heavily modified ffmpeg for years [15:32:18] <BBB> (gst-ffmpeg) [15:32:20] <BBB> and it's a pain [15:32:24] <BBB> you want to kill yourself in the end [15:32:26] <BBB> it's not worth it [15:32:35] <BBB> better work with upstream [15:32:50] <kshishkov> nah, my local copy is better ;) [15:47:46] <CIA-90> ffmpeg: mstorsjo * r21964 /trunk/libavformat/ (rtsp.c rtsp.h): Create AVFormatContext objects as private transport for output RTSP sessions [15:48:00] <kshishkov> yay, he got an account! [15:50:48] <andoma> swedish guy isn't he? [15:51:02] <kshishkov> nej [15:51:10] <kshishkov> han Ã€r finsk [15:51:17] <BBB> go martin! [15:51:28] <BBB> he's not on irc is he? [15:51:50] <andoma> kshishkov: ah [15:52:37] <kshishkov> andoma: it depends on whether you believe in Ãsterland or not [15:53:20] <mru> finland is just the intersection of sweden and russia [15:53:36] <kshishkov> hell no! [15:54:20] <kshishkov> it's a mix of Swedes and Sami on the same land [15:54:51] <mru> no, that's Lappland [15:55:01] <kshishkov> Finland as well [15:55:47] <kshishkov> it looks like a piece of Sweden too, not as a dung heap [15:57:18] <CIA-90> ffmpeg: mstorsjo * r21965 /trunk/libavformat/rtsp.c: [15:57:19] <CIA-90> ffmpeg: Add a function rtsp_setup_output_streams for announcing the SDP [15:57:19] <CIA-90> ffmpeg: and setting up the internal RTSPStream data structures when using [15:57:19] <CIA-90> ffmpeg: the RTSP code in muxer mode. [15:58:44] <CIA-90> ffmpeg: mstorsjo * r21966 /trunk/libavformat/rtsp.c: Don't follow RTSP redirects when used as a muxer [16:12:27] <CIA-90> ffmpeg: mstorsjo * r21967 /trunk/libavformat/rtsp.c: Cosmetics: reindent after applying patches [16:39:33] <kierank> anybody knowledgable about kbd windows? [16:41:30] <kshishkov> jruggles but good luck catching him [16:41:37] <kshishkov> what do you want to know though? [16:42:12] <kierank> how the ffmpeg implementation works [16:42:30] <kierank> and whether it can do non symmetrical windows [16:43:03] <kshishkov> libavcodec/mdct.c ff_kbd_window_init() [16:43:28] <kshishkov> and what do you mean "non symmetrical"? [16:44:20] <kierank> Basically what happens is you mix for example the first half of KBD(64, 3.2) and the second half of KBD(64, 3.0) [16:44:52] <kshishkov> ah [16:45:12] <kshishkov> looks like you need to generate two windows and merge them [16:46:13] <kierank> ff_kbd_window_init only does the first half, right? [16:46:44] <kshishkov> yes [16:47:29] <kierank> so I guess I could put it in a temporary buffer and reverse it [16:47:39] <kshishkov> not reverse [16:48:00] <kshishkov> just add in reverse order to the first generated half window [16:49:07] <kierank> ok [16:49:08] <kierank> thanks [16:50:19] <kshishkov> FFmpeg can benefit from supporting another codec or two after all... [16:51:02] <_av500_> preserve the environment, use less codecs [16:51:24] <kierank> someone will make a "green codec" soon [16:51:43] <kierank> there's already a "green browser" in that microsoft browser selection page [16:52:03] <kshishkov> telnet ;) [17:42:52] <elenril> can somebody produce a char that requires surrogate pairs to encode in utf16? [17:43:03] * elenril doesn't want to wait half an hour for ff to start [17:43:52] <kshishkov> copypaste from wikipedia? [17:48:59] <elenril> hmm, so according to m$ "number of Unicode characters" actually means length in bytes / 2 [17:51:09] <iive> elenril: no rounding? [17:54:11] <Kovensky> iive: there is never an odd byte count in well-formed utf16 [17:54:14] <elenril> iive: it's utf-16 [17:55:10] <BBB> crafted streams can always contain any number of bytes [17:55:31] <iive> just kidding. [17:56:01] <iive> BBB: it needs 2 bytes for \0 too. [17:57:04] <kshishkov> it's a definitely \0 then ;) [17:58:21] <elenril> 0/ [17:59:25] <kshishkov> that's for Danish/Norwegians or people who can't cross zero themselves [18:00:12] <iive> "\0" [18:12:44] <Dark_Shikari> kshishkov: any progress? [18:13:44] <kshishkov> yes and no [18:14:38] <kshishkov> look at r21963 [18:17:45] <Dark_Shikari> why not decode the alpha plane? [18:19:33] <kshishkov> why do we need it? [18:19:50] <kshishkov> in future it can be decoded though [18:20:10] <kshishkov> BTW, all those Guitar Hero Binks are decoded fine with alpha [18:20:25] <kshishkov> (maybe except for the sound) [18:20:52] <Dark_Shikari> why don't we need it? [18:21:01] <Dark_Shikari> people wanting to use lavc as a replacement for bink will want alpha support [18:21:18] <kshishkov> ah, ok then [18:22:04] <Dark_Shikari> lavc should be a fully functional replacement for crappy proprietary software [18:22:08] <Dark_Shikari> in the general case [18:22:45] <kshishkov> and for some of opensource too [18:22:53] * kshishkov looks at Xiph projects [20:15:44] <Vitor1001> mru: You there? [20:15:58] <mru> pong [20:16:18] <Vitor1001> Could you test a command in your PPC box? [20:16:34] <Vitor1001> (I'm not asking for a account if I can't reproduce the bug I'm tracking) [20:16:44] <mru> you can have an account anyway [20:16:59] <Vitor1001> ok, I send you the passwd GPG encrypted? [20:17:11] <mru> send ssh public key and username [20:18:05] <Vitor1001> weird, I don't find your key fingerprint in MAINTAINERS file... [20:18:29] <mru> no need for encryption [20:18:40] <mru> that's the point of public keys [20:19:53] <Vitor1001> ow, I was lousy [20:20:00] <Vitor1001> I'm sending now the public key file [20:20:47] <Vitor1001> done [20:22:08] <mru> ok, try ssh saracen.mansr.com [20:22:23] <Vitor1001> works, thanks! [20:23:01] <mru> usual devtools are installed [20:23:07] <mru> shout if you need more [20:23:41] <mru> samples archive in /misc/samples/mphq [20:23:49] <Vitor1001> ok, thanks! [20:27:39] <Kovensky> http://blogs.msdn.com/oldnewthing/archive/2010/02/18/9965469.aspx <-- what, so you expect people to use PROPER hungarian notation, and derive the bug from that? D: [20:30:41] <Kovensky> <@TheFluff> if you put a bottle of beer outside in this weather it'll freeze solid in less than half an hour [20:30:45] <Kovensky> <@TheFluff> I know because I've tried [20:30:47] <Kovensky> <@TheFluff> I didn't think it'd go quite that fast :| [20:30:50] <Kovensky> <@TheFluff> i just wanted a cold beer [20:30:53] <Kovensky> lol [20:45:48] <Yuvi> ru_maxrss appears to be in bytes rather than kilobytes on OS X contrary to the documentation [20:47:56] <mru> go apple! [20:48:11] <Yuvi> it's hidden with -D_POSIX_SOURCE anyway [21:21:21] <CIA-32> ffmpeg: mstorsjo * r21970 /trunk/libavformat/rtsp.c: [21:21:21] <CIA-32> ffmpeg: Free metadata in chained RTP muxers in the RTSP muxer [21:21:21] <CIA-32> ffmpeg: This fixes a minor memory leak [21:22:43] <peloverde> Can I expect a value preserving promotion when comparing uint8_t to int32_t? [21:23:36] <BBB> you mean will it compare as 8bit or 32bit? [21:23:53] <peloverde> I mean will it compare as unsigned or as signed? [21:24:37] <BBB> signed, I'd guess? [21:24:45] <peloverde> That's what I thought to [21:24:54] <peloverde> But that's not what i'm seeing [21:25:20] <BBB> I was about to make a gcc-joke but then I figured that was cruel and unnice [21:25:23] <BBB> maybe I was wrong [21:25:51] <peloverde> I'm starting to confuse myself here, maybe that isn't even my problem [21:25:51] <mru> if the full range of the type fits in signed int, it will be promoted to that [21:26:13] <mru> so uint8_t will be converted to int [21:29:09] <CIA-32> ffmpeg: mstorsjo * r21971 /trunk/ (8 files in 3 dirs): Add an RTSP muxer [21:34:19] <janneg> bah, no luck rendering the second part of the first Big Buck Bunny scene with only 4G [21:45:22] <_av500_> dman [21:50:23] <janneg> the second scene rendered fine though [21:52:37] <mru> what resolution are you rendering? [21:54:06] <janneg> 2700x1440 [21:54:29] <mru> how did you arrive at that number? [21:55:47] <janneg> 900x720 * 6 [21:56:04] <mru> but 900? [21:56:38] <mru> oh, I see [21:56:45] <janneg> 5:4 [21:57:48] <janneg> http://www.jannau.net/peach_2700x1440/ has all png I've rendered so far [22:00:23] <_av500_> janneg: buy more ram [22:01:46] <kierank> I thought mru was doing it as well? [22:02:24] <mru> nah, I'll do the bits janneg can't manage [22:06:09] <CIA-32> ffmpeg: michael * r21972 /trunk/libavformat/utils.c: [22:06:09] <CIA-32> ffmpeg: Make sure mp1/mp2 get their frame_size set. [22:06:09] <CIA-32> ffmpeg: Fixes issue1696 [22:07:43] <janneg> _av500_: RAM is so expensive ATM [22:14:19] <superdump> it is? [22:15:57] <DonDiego> ld: duplicate symbol _rtsp_connect in libavformat/libavformat.a(rtsp.o) and stre [22:15:58] <DonDiego> am/librtsp/rtsp.o [22:16:15] <DonDiego> for once I think a compilation failure is not mplayer's fault [22:16:34] <DonDiego> something should either be static or have a proper prefix [22:16:45] <DonDiego> and somebody missed this during a review.. [22:18:11] <DonDiego> missing ff_ prefix AFAICT [22:18:25] <mru> just add it [22:18:57] <BBB> did you make clean? [22:19:32] <DonDiego> BBB: make clean does not rename symbols [22:19:46] <BBB> I know, but rtsp_connect() duplicate symbol [22:19:48] <BBB> confuses me [22:19:57] <BBB> anyway, sorry about the ff_ prefix, yes I missed that [22:20:03] <DonDiego> what's there to confuse you? [22:20:05] <BBB> can you bring it up on the mailinglist? [22:20:11] <DonDiego> there is another lib with the same symbol [22:20:23] <DonDiego> object file rather than lib [22:20:28] <DonDiego> but it's the same thing [22:20:30] <BBB> ooooh [22:20:32] <BBB> librtsp [22:20:33] <BBB> now I get it [22:20:36] <BBB> that sucks [22:20:44] <BBB> we should tell them to rename the symbol :-p [22:20:44] <DonDiego> no, ffmpeg sucks [22:20:47] <BBB> yes I know [22:21:04] <DonDiego> everything in libavformat/rtsp.h should have an ff_ prefix [22:21:11] <BBB> again, sorry, I missed the ff_ prefix, please bring it up on the mailinglist [22:21:14] <BBB> I'll cook up a patch [22:21:16] <DonDiego> you're the maintainer, so go ahead and fix it [22:21:23] <DonDiego> i'm not following the ml [22:21:41] <DonDiego> this friendly reminder should be all you need :) [22:22:48] <CIA-32> ffmpeg: reimar * r21973 /trunk/ (configure doc/ffmpeg-doc.texi ffmpeg.c): Make -benchmark also print the maximum memory usage if possible. [22:40:21] <astrange> http://pastebin.com/m70da91e4 current-ish global symbols [22:52:09] <astrange> is anyone reading coverity lately? [22:52:36] <mru> is it alive? [22:52:47] <mru> I thought it was dead since 2007 [22:53:05] <mru> I emailed them several times and got no reply [22:53:13] <peloverde> I've been looking into metafuzz lately [22:54:11] <astrange> the page is up but they don't list the versions they scanned [22:55:00] <mru> they ran ffmpeg twice [22:55:05] <mru> both times in july 2007 [22:55:19] <mru> sorry, one was june 2007 [22:56:03] <mru> hmm, mplayer seems to be running [22:58:42] <peloverde> I hate that all these people running automated crap looking for exploits seem to use mplayer instead of ffmpeg [22:59:28] <Dark_Shikari> peloverde: I'm about to post a massive, massive tl;dr blog post on vp8 and flash [22:59:34] <Dark_Shikari> so you can get up in arms again [23:00:53] <mru> well, in this case ffmpeg is a subset of mplayer [23:01:01] <mru> so most of what we want is there [23:01:40] <peloverde> mpalyers demuxers and third party libraries wind up masking a lot of ffmpeg [23:01:53] <mru> this is static analysis [23:01:56] <astrange> static analysis of mplayer is fine [23:02:00] <mru> all code is checked [23:02:09] <astrange> well, except i'd rather check --disable-asm [23:02:24] <jermy> I'm just trying to work out if a bug is real at the moment (can't find any bugreports) - If anybody has a moment, could they try encoding stereo audio with a one channel muted using libvorbis. [23:02:26] <peloverde> that makes sense, but i've been looking more at fuzzing stuff lately [23:02:40] <peloverde> there are fewer false positives popping out of fuzzers [23:03:14] <jermy> (I've got one at http://jeremy.publication.org.uk/a.orig.wav.gz, but perhaps there's something odd with the audio I'm giving it) [23:12:06] <peloverde> Dark_Shikari, I don't see what you think would make me angry in that post [23:12:21] <jermy> (Oops - Actually, I mean the built-in -acodec vorbis) [23:13:36] <Dark_Shikari> peloverde: I was kidding [23:13:37] <Dark_Shikari> lol [23:13:53] <Yuvi> Dark_Shikari: google has at least two non-hd versions of most videos, one 360p mp4 and one 480p h.264 in flv [23:14:41] <Dark_Shikari> isn't the 360p the old flv? [23:14:49] <Dark_Shikari> Either way, they're still not using high profile are they? [23:14:51] <Yuvi> no, it's h.264 as well [23:15:00] <Dark_Shikari> last time I downloaded there was no high profile stream [23:15:04] <Dark_Shikari> except in HD [23:15:06] <Yuvi> (it's the one used for <video>) [23:15:19] <Dark_Shikari> er, actually [23:15:23] <Dark_Shikari> fmt=18 gives me the 480p version [23:15:34] <peloverde> speaking of <video> chrome needs a real scaler yesterday [23:16:02] <Yuvi> get them to pay michael to relicense swscale asm under lgpl ;) [23:16:16] <peloverde> I think a lot of people don't realize that's an option [23:16:46] <peloverde> Just like that colorspace conversion article [23:17:12] <Dark_Shikari> upvote my HN post http://news.ycombinator.com/item?id=1144014 [23:17:28] <peloverde> I don't do social news anymore. It got me too stressed out. [23:17:55] <Dark_Shikari> HN is pretty good [23:17:58] <Dark_Shikari> it's much less retarded than reddit. [23:18:03] <Dark_Shikari> They're not full-freetard. [23:18:26] <astrange> posted to reddit out of curiosity [23:18:54] <Dark_Shikari> >_> [23:19:13] <peloverde> I also don't understand reddit's whole subreddit thing [23:19:15] <astrange> btw safari's <video> is quite good [23:19:31] <peloverde> There were always theora articles in the linux subreddit, what does theora have to do with linux? [23:19:32] <astrange> but i wish they'd added a format whitelist, you can embed mkv/wmv into it [23:19:45] <astrange> and i don't consider my own code in perian to be internet-ready [23:20:18] <peloverde> Google did some voodoo to make their ffmpeg not conflict with totem plugin [23:20:40] <peloverde> it kind of scares me that people would run such a plugin [23:21:11] <Yuvi> fmt=18 gives you 480p h.264 in mp4 or flv? [23:21:14] <astrange> hmm, i guess it's probably sandboxed actually [23:21:43] <Dark_Shikari> Yuvi: no idea [23:21:48] <Dark_Shikari> it just gives me 480p [23:22:37] <Yuvi> actually, the "360p" mp4 for this random vid is 480x270 [23:22:50] <Yuvi> I don't think youtube serves h.263 anymore [23:23:13] <Yuvi> unless it was uploaded pre-2006 or 7 [23:24:08] <Dark_Shikari> Interesting [23:24:09] <Dark_Shikari> I'm not surprised. [23:26:16] <Dark_Shikari> oh btw, feel free to poke holes in the post so I can fix them [23:26:58] <Yuvi> is there an easy way to check the profile? [23:27:13] <Honoome> astrange: I actually was able to nastily crash perian a couple of times before, with rtsp streams through feng ^^;; [23:27:57] <Dark_Shikari> Yuvi: download it [23:27:58] <Dark_Shikari> open in streameye [23:28:18] <Yuvi> streameye completely failed at installing under win7 [23:28:24] <Dark_Shikari> worked fine here [23:28:26] <Yuvi> and I lost my older VMs [23:28:27] <Dark_Shikari> well, then again, I use an older version [23:28:31] <Dark_Shikari> streameye STUDIO fails horribly [23:29:26] <astrange> i copied the folder from an xp backup [23:29:34] <astrange> never bothered reinstalling to get it in a menu [23:29:48] <Dark_Shikari> you can find the trial version on various websites not theirs [23:29:50] <Dark_Shikari> i.e. the old one [23:30:05] <astrange> Honoome: if you have crash logs from 1.2 i'll take them [23:31:13] <Honoome> astrange: nah it should probably have been 1.1 last time I crashed itâŠ but if I'll get any in the future I'll remember to drop a line ;) [23:32:52] <Dark_Shikari> astrange: it's still baseline [23:32:56] <Dark_Shikari> used a video from dec 2009 [23:37:26] <Yuvi> Dark_Shikari: turns out it's faster to upload them and have you look at what youtube gives me than to boot my vm http://www.mediafire.com/?yjgyy4ewiij [23:38:40] <Dark_Shikari> Yuvi: I already looked [23:38:45] <Dark_Shikari> but I can check those too [23:40:11] <Dark_Shikari> 360p: Baseline 2.1 [23:40:33] <Dark_Shikari> 480p: Main 3.1 (wat) [23:41:19] <mru> Dark_Shikari: s/adobe/macromedia/ [23:41:49] <Dark_Shikari> oh yeah. let me fix that [23:42:09] <astrange> you could mention dirac, i suppose [23:42:18] <astrange> i read another article just now that claimed it was suitable for HD web video [23:42:22] <Dark_Shikari> It should be. [23:42:38] <peloverde> Wasn't Dirac (more-or-less) abandoned [23:43:02] <Dark_Shikari> added. [23:43:05] <Dark_Shikari> no, it's still in development [23:44:16] <peloverde> There has been no new news on diracvideo.org for a year [23:45:46] <astrange> http://diracvideo.org/git?p=schroedinger.git;a=summary [23:45:52] <peloverde> ahh [23:46:08] <Dark_Shikari> there's been no news on x264.com for a year at least too ;) [23:46:35] <mru> bbc dropped dirac development [23:46:36] <peloverde> I assumed that's because everybody goes to x264.nl [23:46:42] <mru> because h264 was cheaper [23:46:52] <peloverde> mru, that's what i'm thinking of [23:47:02] <Dark_Shikari> they use it internally, iirc [23:47:02] <Yuvi> supposedly anu has a current contract with them to do schroedinger work [23:47:04] <Dark_Shikari> as an intermediate format [23:47:16] <mru> that was the intent [23:47:19] <mru> but they don't [23:47:29] <kierank> they do [23:47:35] <kierank> they use it on the bbc raman network sometimes [23:47:46] <kierank> for point to point hd [23:47:53] <mru> hmm, guess my sources are unreliable [23:48:09] <kierank> and they sold devices to a few other people [23:48:21] <mru> either way, it was never intended to be a distribution format [23:48:23] <kierank> though by no means a success [23:48:47] <kierank> there was meant to be some distribution format because they split it up into Dirac and Dirac Pro [23:48:57] <kierank> the latter went somewhere but the former didn't [23:49:24] <mru> because licensing h264 was cheaper than developing a new codec [23:50:18] <kierank> they didn't plan to use it within the lifetime of h264 [23:50:30] <kierank> it was meant to be the next generation [23:55:17] <justlooking> im pritty sure the bbc call it DIRAC PRO and they have hardware for it too http://www.bbc.co.uk/rd/projects/dirac/diracpro.shtml [23:55:52] <Yuvi> also, from what I've done with dirac it starts falling apart at a higher bitrate than theora, even for HD [23:57:38] <kierank> i heard dirac pro was why the beijing olympics didn't look to good on bbc [23:57:42] <kierank> too*

1 0

IRC log for 2010-02-21
by irc＠mansr.com 22 Feb '10

22 Feb '10

[00:11:37] <CIA-90> ffmpeg: conrad * r21927 /trunk/libavcodec/vp3.c: [00:11:38] <CIA-90> ffmpeg: Use memset to set the runs partially coded superblocks [00:11:38] <CIA-90> ffmpeg: Much faster for long runs (e.g. nearly uncoded frames), slightly faster [00:11:38] <CIA-90> ffmpeg: for the general case. [00:11:38] <CIA-90> ffmpeg: conrad * r21928 /trunk/libavcodec/vp3.c: Make the special 4129 case for long-run bit strings a #define and explain it [00:11:38] <CIA-90> ffmpeg: conrad * r21929 /trunk/libavcodec/vp3.c: [00:11:39] <CIA-90> ffmpeg: Decode fully coded superblocks in the same manner as partial superblocks and qpi [00:11:39] <CIA-90> ffmpeg: No speed difference, but it will simplify the special 4129 case. [00:11:40] <CIA-90> ffmpeg: conrad * r21930 /trunk/libavcodec/vp3.c: [00:11:40] <CIA-90> ffmpeg: Handle Theora's continued runs in superblock coding. [00:11:41] <CIA-90> ffmpeg: This doesn't really matter yet since 4:2:0 1080p has only 3060 superblocks, [00:11:41] <CIA-90> ffmpeg: but larger resolutions or 4:4:4 1080p could hit this case. [00:11:42] <CIA-90> ffmpeg: conrad * r21931 /trunk/libavcodec/vp3.c: [00:11:42] <CIA-90> ffmpeg: Simplify determing whether fragments are coded [00:11:43] <CIA-90> ffmpeg: No measurable speed difference [01:28:00] <Dark_Shikari> Yuvi: what other patches do you have locally? [01:29:36] <Dark_Shikari> for theora [01:31:41] <Yuvi> simplifying mv decode, macroblock-based mc, some intra-only special cases, DC and 10-element idct, and some optimizations to the sse2 idct [01:31:56] <Yuvi> but my branch is pretty diverged from head [01:44:05] <Dark_Shikari> you need to get it merged :/ [01:44:18] <Dark_Shikari> guess you're working on that though [01:54:13] <pentanol> g'afternoon, anyway dsputil.h:449: error: expected ';', ',' or ')' before 'v1' with gcc version 4.4.3 20100108 [02:43:52] <mru> gaaaaaah [02:47:36] <CIA-90> ffmpeg: mru * r21932 /trunk/libavcodec/vc1dec.c: VC1: fix missing include h263.h [02:52:47] <astrange> zero/sign_extend can use builtin_constant_p and avoid any unnecessary asm [02:53:04] <astrange> note gcc evaluates builtin_constant_p after inlining but llvm doesn't. i forgot to write a bug about that [02:53:28] <mru> so llvm builtin_constant_p is essentially useless [02:56:39] <Yuvi> could be a macro [02:56:59] <mru> so 10% useful [03:02:44] <astrange> they probably just didn't notice it [03:02:50] <mru> tossers [03:24:19] <CIA-90> ffmpeg: ramiro * r21933 /trunk/libavdevice/oss_audio.c: Indent. [03:26:07] <Honoome> 10%? if it's a macro I'd expect the constant propagation to happen automaticallyâŠ I'd say 5% [03:28:16] <astrange> it's an asm macro [03:40:34] <pentanol> hm , looks like my camera... Linux 2.6.25 on a armv5tejl based always received http://codepad.org/tIeHLYih [03:41:03] <pentanol> weid, but why they seeding compilers for cris [03:42:04] <Honoome> astrange: no I was more thinking along the lines about Yuvi's remarkâŠ [04:13:29] <astrange> git merge doesn't work at all when there's conflicts [05:05:14] <astrange> Yuvi: did you change the vp3 decoder to do luma and chroma at the same time, or is it only calling draw_horiz_band after the last plane? [05:06:57] <Yuvi> after the last plane [05:12:42] <ohsix> can you deencap stuff in flv's from rtmp? the source is just an mp4 for this particular thing and afaik they just shuttle it through fms [05:12:56] <ohsix> remux them back into something else [05:15:45] <astrange> hmm, i was using pixel_addresses_initialized. guess it didn't need it [06:22:33] <astrange> hmm, merging h264 worked fine but vp3 is still messed up. maybe i'll not bother until the next patch [06:52:10] * elenril pokes Honoome [08:43:17] <elenril> when converting utf8 to utf16, is there a better estimate of output length than strlen(input)*4? [08:44:08] <kshishkov> no [08:44:18] <kshishkov> but it's safe upper bound [08:45:00] <kshishkov> unless you write utf8-aware strlen [08:48:07] <elenril> well for 1-byte utf-8 characters you always get 2-byte utf16 [08:48:34] <elenril> so i hoped there'd be a lower upper bound [08:49:17] <elenril> bbl [08:49:19] <kshishkov> if you can't have 4-byte chars then upper bound is strlen()*2 [09:18:04] <_av500_> what about surrogate pairs? [09:18:52] <jai> hm [09:18:55] <jai> ramiro: ping [09:19:26] <kshishkov> _av500_: presumably it will take a lot of bytes on UTF-8 input too [09:23:04] <_av500_> they should have made utf8 a turing complete bytecode interpreter [09:23:22] <kshishkov> why? It's simple VLC [09:23:38] <_av500_> too restricted [09:24:04] <kshishkov> hmm? [09:25:19] <kshishkov> 1,114,111 characters should be enough for now [09:25:34] <_av500_> i mean you can find the length of a string in finite time, no fun in that :) [09:26:16] <kshishkov> yeah, take Markov chain [09:39:03] <kshishkov> mate! [09:39:06] <pross-au> Gday [09:40:04] <kshishkov> unless somebody objects, I think I'll commit Bink video decoder tomorrow [09:40:37] <Dark_Shikari> \o/ \o/ \o/ \o/ [09:42:14] <pross-au> kshishkov: see my mail [09:50:35] <KotH> /o\ /o\ /o\ /o\ [09:50:53] <pross-au> What's a \o/ ? [09:51:05] <thresh> backslash o slash [09:51:07] <kshishkov> KotH: is that Australian rejoice or facepalming? [09:51:13] <pross-au> a happy person? [09:51:25] <kshishkov> or praying one [09:51:41] <KotH> kshishkov: it's ducking for cover :) [09:53:10] * pross-au hands kshishkov a VB [09:53:25] * kshishkov has it, including VB for DOS [09:55:40] <pross-au> 'Victorian Bitter' [09:56:01] <kshishkov> sounds like a beer name [09:57:07] <pross-au> Man, you're smart cookie kshishkov [09:59:51] <kshishkov> okay, give VB to KotH along with cookies with RFID embedded [10:11:58] <KotH> .o0(someone wants to know where i'm going) [10:12:23] <kshishkov> not at all, not even ICBM [10:19:34] <pross-au> ICBMs? [10:19:48] <kshishkov> intercontinental ballistic missiles [10:21:03] <pross-au> Ukraine has those?? [10:21:29] <kshishkov> yes [10:21:39] <pross-au> Cool [10:22:11] * kshishkov should point out that 2 out of 3 Soviet rocket designers were Ukrainian. The last one was Polish. [10:22:12] <pross-au> No nuclear hear, well except for the infite supply of uranium ore [10:25:19] <KotH> pross-au: everyone has them [10:25:22] <KotH> pross-au: even .ch :) [10:34:17] <twnqx> morning [10:43:29] <KotH> grüezi twnqx [10:46:00] <pross-au> .ch ? [10:46:12] <pross-au> oh right [10:48:49] <KotH> you know, neutral, but heavly armed :) [10:51:04] <pross-au> What do you percieve australia as? Neutral? [10:51:18] <pross-au> *perceive [10:51:24] <Dark_Shikari> censored [10:51:25] <KotH> nah... .au is a backwaters continent :) [10:51:40] <pross-au> High Five KotH [10:52:06] * KotH Z-Fives pross-au [10:52:17] * pross-au goes back listening to the Beach Boys [10:52:40] <pross-au> Back on topic: Bink looks good [10:53:32] <Dark_Shikari> do we have any way of comparing performance to the official decoder? [10:57:32] <CIA-90> ffmpeg: stefano * r21934 /trunk/doc/ (4 files): [10:57:32] <CIA-90> ffmpeg: Put all the options shared amongst the ff* tools under a dedicated [10:57:32] <CIA-90> ffmpeg: section "Generic options". [11:13:09] <kshishkov> pross-au: sorry [11:13:27] <kshishkov> Dark_Shikari: official Bink players can print some stats [11:13:39] <Dark_Shikari> why not make it the goal to beat them? [11:13:53] <Dark_Shikari> I would be willing to write x86 simd for you. [11:13:58] <kshishkov> because there's no video decoder in FFmpeg [11:14:07] <Dark_Shikari> ? [11:14:08] <kshishkov> heh, even I can write that SIMD [11:14:17] <Dark_Shikari> I meant, after you commit it [11:14:18] <kshishkov> for x86/PPC/ARM [11:14:24] <kshishkov> ah, OK [11:14:36] <Dark_Shikari> the 8x8 -> 16x16 one actually has a very smart way of doing it [11:14:40] <Dark_Shikari> movq mm0, [8x8 src] [11:14:41] <Dark_Shikari> pshufb [11:14:49] <Dark_Shikari> er, xmm0 [11:14:50] <Dark_Shikari> movdqa [16x16 dst], xmm0 [11:15:02] <Dark_Shikari> One non-loadstore op per line [11:15:20] <kshishkov> yes, rather obvious [11:15:20] <Dark_Shikari> hmm actually you don't even need that [11:15:25] <Dark_Shikari> punpcklbw xmm0, xmm0 [11:15:40] <Dark_Shikari> a total of 32 ops [11:15:46] <Dark_Shikari> might as well unroll the whole thing [11:15:52] <kshishkov> try to optimize fill_block next ;) [11:15:58] <Dark_Shikari> lol [11:17:15] <Dark_Shikari> and of course unclamped put pixels [11:17:15] <Dark_Shikari> etc [11:17:21] <Dark_Shikari> you should really use the x264 simd strategy [11:17:21] <Dark_Shikari> i.e. [11:17:26] <Dark_Shikari> "this looks simdable, make a dsp function!" [11:17:26] <kshishkov> still, I think it may be Bink audio that is slow [11:17:55] <kshishkov> someone should organize dsputil [11:18:10] <Dark_Shikari> probably a good idea at some point [11:18:53] <pross-au> what do you mean 'organise' ? [11:19:03] <Dark_Shikari> separate into codecs [11:19:11] <Dark_Shikari> clean up [11:19:13] <Dark_Shikari> make less messy [11:19:17] <Dark_Shikari> port to yasm, remove inline asm [11:19:22] <pross-au> dsputil.c is a big file to compile [11:19:29] <kshishkov> yes [11:19:33] <kshishkov> and very messy [11:19:40] <_av500_> libavdsputil [11:19:46] <Dark_Shikari> lol [11:19:47] <pross-au> this little ppc takes a few minutes to compile it [11:19:49] <iive> it would be better to be split by functional criteria [11:19:59] <iive> e.g. dct at one place, mc at another [11:20:02] <kshishkov> pross-au: try motionest.c ;) [11:20:14] <_av500_> even better, it could be split into ffcc intrinsics [11:20:17] <Dark_Shikari> well motion_est is hilarious [11:20:32] <Dark_Shikari> it has single functions larger than x264's entire ME module [11:20:33] <pross-au> kshishkov: that too [11:20:47] <Dark_Shikari> I think motion_est is larger than x264's entire analysis module, doubled [11:20:50] <Dark_Shikari> or tripled [11:21:15] <iive> any volunteers? [11:21:37] <Dark_Shikari> oh and of course it has functions larger than the L1 cache of any known cpu [11:21:42] <kshishkov> iive: yes, right after they finish making good documentation for FFmpeg [11:23:35] <_av500_> Dark_Shikari: i am sure intel can be convinced to 1mb l1 [11:23:42] <_av500_> to add [11:23:44] * kshishkov thinks that maybe he can commit decoder even today. To start/end week on a bright side. [11:24:25] <kshishkov> _av500_: ask them for 256 additional 512-bit SIMD registers while you're on it [11:25:13] <_av500_> kshishkov: but then they put h264 decoder in chipsets now, so maybe not... [11:25:38] <kshishkov> _av500_: ask them for HW Theora decoder then [11:26:39] <kshishkov> so you can write in yasm " pdecodetheora m0, m1" [11:28:33] <_av500_> kshishkov: i think the will rather put flash in hw :) [11:29:03] <kshishkov> heh [11:29:24] <pross-au> kshishkov: agree [11:29:55] <Dark_Shikari> lol cisc [11:30:04] <pross-au> i suspect there is a quality regression in the bink audio decoder [11:30:08] <twnqx> rather... commit the mov/mp4 tag changes :D [11:30:12] <pross-au> certain files sound poor wishy-washy here [11:30:19] <kshishkov> here too [11:30:23] <kshishkov> mostly DCT ones [11:30:49] <pross-au> also i had a seeking patch for the demuxer [11:30:55] <pross-au> *have [11:31:31] <kshishkov> feel free to apply ;) [11:31:57] <kshishkov> you can even register yourself as its maintainer [11:36:07] <CIA-90> ffmpeg: stefano * r21935 /trunk/ffplay.c: Use the official FFmpeg spelling: "ffmpeg" -> "FFmpeg". [11:43:50] <CIA-90> ffmpeg: stefano * r21936 /trunk/ (Makefile configure doc/ffprobe-doc.texi ffprobe.c Changelog): Add FFprobe tool. [12:05:05] <elenril> kshishkov: i think length of output <= strlen(input)*2 for all characters [12:05:24] <kshishkov> yes [12:06:03] <elenril> good [12:32:35] <mru> kshishkov: all latin1 characters map into <= 2 bytes of utf8 [12:33:08] <kshishkov> it was not matter of utf8 here, it was mostly the matter of output [12:33:25] <kshishkov> for utf8 strlen() is always <= length of string [12:33:44] <mru> >= [12:33:59] <kshishkov> yes, the other way round [12:47:30] <iive> strlen is always returning number of bytes, so it doesn't include the '\0' so it is always < [12:49:25] <kshishkov> in this case length of string meant number of Unicode characters in that string, terminator is irrelevant [12:51:49] <iive> :) [12:52:08] <mru> "terminator is irrelevant" ... tell that to arnie [12:53:27] <kshishkov> studios told him already [12:53:49] <mru> so they did [12:53:50] <kshishkov> last movie hasn't featured him [12:54:06] <mru> only as CGI [12:55:14] <Kovensky> he probably isn't convinced yet [12:55:28] <Kovensky> maybe it was just because they thought he was too busy as the governator, etc [12:57:45] <iive> i just pretend that the last 2 movies doesn't exist. [12:58:34] <Kovensky> heh [12:58:45] * Kovensky never watched any terminator other than the 2nd one [12:58:50] <kshishkov> reminds me of XKCD saying that Matrix was a good movie [12:59:16] <Kovensky> Matrix was, too bad they never made a sequel [12:59:32] <iive> they did, it's called animatrix [12:59:37] <twnqx> :D [12:59:40] <Kovensky> o rly [12:59:46] * elenril <3 animatrix [12:59:48] <Kovensky> I thought those were side stories [13:00:16] <kshishkov> Kovensky: I also saw the third. It featured female terminator able to whistle as modem (and consequently dialup via cellphone). That's all I remember about it. [13:01:29] <mru> t3 was the worst of them [13:01:30] <iive> actually in 3 and 4'th movies the terminator characters are quite good hit. too bad nothing else is on their level. [13:01:43] <mru> t4 is better [13:01:49] <mru> t2 still the best [13:01:59] <iive> kshishkov: you forgot the automatic breast augmentation! [13:01:59] <mru> regular version, not director's cut [13:02:07] <mru> iive: :-) [13:02:46] <kshishkov> iive: I don't remember that. Nor don't want really. [13:03:41] * kshishkov likes movies directed by Olle Hellbom [13:08:10] <iive> i'm not sure i've watched anything from him. He is swedish , isn't he? [13:08:36] <kshishkov> of course [13:08:39] <mru> name sounds swedish [13:08:57] <kshishkov> all in Wikipedia ;) [13:10:05] <mru> I've found something disturbing in lavc [13:10:12] <mru> shifts by negative amounts [13:10:39] <kshishkov> where? [13:10:42] <twnqx> that... works? [13:10:47] <mru> libavcodec/bitstream.c:164 [13:10:51] <mru> libavcodec/golomb.h:172 [13:11:15] <mru> I hacked an emulator to trap on invalid shifts [13:12:43] <mru> the first one is mostly harmless [13:12:47] <mru> but dangerous still [13:12:54] <mru> the result of that shift is never used [13:13:55] <mru> but a negative shift has undefined behaviour [13:14:13] <mru> it's perfectly valid for it to crash [13:17:27] <DonDiego> h264.h:816: warning: unused variable 'mb_xy' [13:17:33] <DonDiego> how lame is that, guys? [13:17:54] * mru blames michael [13:18:04] <mru> he seems to build with warnings off [13:18:13] <mru> or else his eyes should be bleeding by now [13:19:37] <DonDiego> well, somebody just fix this.. [13:19:49] <mru> you have write access... [13:19:50] <DonDiego> Yuvi: you also introduced a few fresh warnings .) [13:22:45] * kshishkov prepares for conducting lavc minor bump [13:23:12] <Kovensky> -w ftw [13:23:25] * Kovensky usually builds his own code with -pedantic [13:23:32] <mru> that's silly [13:23:39] <mru> that's bordering on lint-level whinging [13:24:43] <DonDiego> -Werror has done wonders to the projects i work on at uni.. [13:24:45] <twnqx> -Wall -Werror ftw [13:25:00] <mru> -Wextra too [13:25:20] <twnqx> try to compile a gentoo with it and start crying :P [13:25:29] <mru> -Werror can be useful if you always use the same compiler [13:25:50] <mru> if the code will be built with lots of different compilers, as released code will, it's a very bad idea [13:25:51] <twnqx> for me it meant "omg, lots of things changed with gcc 4... let's go to work [13:26:18] <twnqx> anyway. still the trivial fixes for mp4/mov tagging aren't in? :X [13:26:19] <mru> like when gcc4 started throwing warnings on 95% of all str*() calls [13:26:37] <Kovensky> why did it do that? [13:26:46] <mru> pointer target types differ in signedness [13:27:19] <mru> it really shouldn't do that for char [13:27:26] <mru> since signedness of char is undefined [13:27:38] <mru> or unspecified for the pedants [13:29:02] <kshishkov> the bomb has been dropped [13:29:45] <CIA-90> ffmpeg: kostya * r21937 /trunk/ (11 files in 3 dirs): Bink video decoder [13:30:15] * Kovensky waits for the boom [13:30:33] <mru> 5 [13:30:34] <mru> 4 [13:30:36] <mru> 3 [13:30:38] <mru> 2 [13:30:39] <mru> 1 [13:30:42] <mru> BOOM [13:31:03] <Kovensky> oh you [13:31:19] <kshishkov> Compn: you around? [13:31:36] <iive> i thought fate needs more time. [13:32:17] <kshishkov> it's Mike's problem [13:33:12] <DonDiego> bink.. [13:33:36] <kshishkov> s/bink/yet another obscure game codec/ [13:34:07] <mru> let's celebrate: http://imagebin.ca/view/x6Tdu5C.html [13:34:14] <kshishkov> DonDiego: http://shishkov.homeunix.net/bink-mplayer.patch [13:35:05] <thresh> compiles here fine on osx [13:35:17] <thresh> no boom at all :( [13:35:30] <DonDiego> kshishkov: what are you waiting for, commit it :) [13:36:11] <kshishkov> ok, wait a minute [13:40:27] <pentanol> hi, I need suggestion so as to open rtsp stream AVInputFormat *fmt = NULL; pd->filename = "rtsp://mystream"; av_probe_input_format(pd, 0); then do what? rtsp_read_play()? [14:27:58] <KotH> am i correct that the power density spectrum is the square of the fourier transformation of a signal? [14:31:28] <mt> KotH: Yes I believe so. [14:33:15] <KotH> hmm... no it's not... it's only in the case that the fourier transformation is real [14:36:04] <mt> Ah. I was wrong then. I read something about it months ago but it didn't mention anything about the transform being complex or real. But iirc, all the transforms on that page were real so probably why it wasn't mentioned. [14:38:25] <KotH> well.. it's been ages since i last had a look at signal theory, so i forgot most of it [14:40:22] <kshishkov> KotH: lucky you, you have something to forget [14:40:34] <KotH> ^^' [14:40:44] <KotH> i forgot too many things already [14:41:05] * elenril thought projects L^2(R)->L^2(R) [14:41:11] <elenril> *FT [14:42:27] <CIA-90> ffmpeg: vitor * r21938 /trunk/libavformat/idcin.c: Fix memory leak for truncated packets in idCin demuxer [14:43:43] <Vitor1001> kshishkov: so avcodec_check_dimensions() is needed after all? [14:45:13] <kshishkov> Vitor1001: it seems to be still present in other decoders, so unless someone can guarantee it's safe to remove I'll leave it there as well [14:46:17] <Vitor1001> kshishkov: looking at libavcodec/utils.c it looks like avcodec_encode_video() check it. [14:46:33] <Vitor1001> not very important anyway [14:46:41] <kshishkov> it's decode [14:46:57] <Vitor1001> oops, also in avcodec_decode_video2() [14:47:01] <Vitor1001> well, have to go now [14:47:13] <Vitor1001> Congrats for the commit \o/ [14:47:29] <kshishkov> I had no problems committing it :P [14:51:30] <kshishkov> ok, looks like the rest of FFmpeg 0.6 pendiang features are not of my concern (except maybe AMR-NB) [15:10:15] <Honoome> elenril: yes? [15:10:51] <kshishkov> Honoome: IIRC you've promised him to apply his patch at weekend [15:11:27] <Honoome> kshishkov: I actually sent a patch for review, I should be able to apply part of it if I can solve Michael's rebus :P that I will do after a coffee [15:12:51] <CIA-90> ffmpeg: mru * r21939 /trunk/libavcodec/bitstream.c: [15:12:51] <CIA-90> ffmpeg: Avoid negative shifts in build_table() [15:12:51] <CIA-90> ffmpeg: A shift by a negative amount has undefined behaviour. Even though [15:12:51] <CIA-90> ffmpeg: the result of this shift is never used, the shift itself could [15:12:51] <CIA-90> ffmpeg: cause an exception of some kind. [15:12:52] <CIA-90> ffmpeg: mru * r21940 /trunk/libavcodec/bitstream.c: indent [15:21:18] <elenril> Honoome: i saw your comment here https://bugs.freedesktop.org/show_bug.cgi?id=17431 [15:21:31] <elenril> did you figure out how to fix it? [15:21:50] <elenril> kshishkov: no, nobody promised me to apply my patches [15:21:56] <elenril> you're all being lazy slackers =p [15:21:57] <Honoome> elenril: sortaâŠ my solution was to simply change SDL to unbundle the library :) [15:22:16] <elenril> so the problem is in SDL? [15:22:24] <kshishkov> elenril: good engineer must be lazy. So we are both lazy and proud of it! [15:22:33] <kshishkov> (at least some of us) [15:22:37] <Honoome> yeah they bundle an old copy of Xxf86vm library and that is causing the problem [15:22:50] * elenril facepalms [15:23:04] <mru> still should not make the server crash [15:23:20] * Kovensky is reminded of sisimedia [15:23:27] <mru> a client should never be able to crash the server [15:23:43] <Kovensky> not only it comes with a broken configure script but it uses headers that were deprecated on 7.5 :( [15:23:57] <Honoome> mru: yeah I know, but me and Xorg devs don't get much along [15:24:13] <mru> heh [15:24:42] <Honoome> I went into a pissing contest with Eric Anholt when I worked on Gentoo/FreeBSD because I insisted into making Xorg work with FreeBSD by default [15:24:48] <Honoome> he didn't care because ports had all the patches neededâŠ [15:25:19] <mru> typical bsd attitude [15:25:24] <Kovensky> and then some people complain that downstream is uncooperative and keep all their patches to themselves... [15:25:44] <Honoome> Kovensky: he's both _up_ and _down_ stream for Xorg/FreeBSDâŠ [15:26:03] <Kovensky> D: [15:26:24] <mru> a vortex [15:26:36] <Honoome> when they split Xorg, FreeBSD was still on the old merged one and Gentoo/FreeBSD was trying to move to split (with the rest of Gentoo)âŠ I reported bugs and his answer was âuntrue, Xorg works perfectly on FreeBSDâŠ use monolithicââŠâŠ d'oh! >_< [15:26:59] <mru> I actually liked the monolithic one better [15:27:04] <mru> it worked [15:27:21] <mru> the split one is version hell all over the place [15:27:23] <Kovensky> <@mru> typical bsd attitude <-- not really, it isn't related to freebsd other than using the same kernel [15:27:41] <Honoome> Kovensky: what are you referring to? [15:27:47] <Kovensky> gentoo/fbsd [15:27:47] <mru> it's typical bsd attitude to shove the ports tree full of patches and refuse to talk [15:27:57] <Honoome> Kovensky: gentoo/freebsd is not the same as debian's gnu/kfreebd [15:28:08] <Honoome> Kovensky: gentoo/freebsd uses same kernel, same libc, same userland commands [15:28:28] <Kovensky> only with portage instead of ports? [15:29:01] <Honoome> yep [15:29:13] <Honoome> [and unbundled packages that are otherwise part of freebsd base system, such as libarchive] [15:30:09] <CIA-90> ffmpeg: diego * r21941 /trunk/libavcodec/h264.h: [15:30:09] <CIA-90> ffmpeg: Remove unused variable, fixes warnings of the type: [15:30:09] <CIA-90> ffmpeg: libavcodec/h264.h:816: warning: unused variable `mb_xy' [16:17:04] <mru> oh no, fate is going yellow again [16:17:29] <kshishkov> somebody "fixed" idcin? [16:17:34] <mru> yep [16:24:58] <CIA-90> ffmpeg: reimar * r21942 /trunk/ffprobe.c: [16:24:58] <CIA-90> ffmpeg: Avoid using log2, it is not available everywhere. [16:24:58] <CIA-90> ffmpeg: Should fix compilation on FreeBSD. [16:34:21] * Kovensky wonders why it isn't in fbsd anyway [16:34:28] <Kovensky> not log2 or log2f <_< [16:35:14] <kshishkov> because they are idiots [16:36:39] <mru> they are bsd [16:36:43] <mru> they don't do modern stuff [16:37:06] <kshishkov> they always did it their way even in times of System V [16:37:32] <mru> sysv and bsd forked a long time back [16:37:43] * elenril wonders how did asfenc ever work [16:38:22] * kshishkov considers SysV to be the True UNIX [16:38:48] <mru> Tru64 is of course the true one [16:40:11] <kshishkov> well, since it's from DEC... [16:41:47] * Kovensky pats elenril [16:42:27] * elenril still wonders why he's wasting his free time on this [16:42:33] <elenril> it's not like i use asf [16:53:51] <KotH> elenril: masochism [16:55:31] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/BileFascination [16:59:12] <Honoome> elenril: rotfl [17:09:36] <elenril> what's the best way to check if an array is all zero? [17:09:49] <kshishkov> flag and loop [17:10:29] <elenril> only 5 pointers in it [17:11:04] <kshishkov> do | and check the result [17:11:05] <mru> array of 5 pointers? [17:11:19] <elenril> yes [17:11:37] <mru> what kshishkov said [17:11:52] <elenril> hmm, i hoped there'd be some nice black magi [17:11:54] <elenril> c [17:11:54] <mru> unless you're on a 64-bit machine with 32-bit pointers and the array has suitable alignment [17:12:47] <mru> probably not worth the trouble though [17:13:28] <elenril> right [17:40:41] * justlooking always thought the AT&T Unix System V Release 4 for the Amiga computer family was the true UNIX ? being the First ONE ordinary end users got access to on 1990 ...http://en.wikipedia.org/wiki/Amiga_Unix [17:55:50] <kierank> So, i need to use half sized KBD windows. Is it worth me writing an "ff_half_kbd_window_init" function or just using the current one then overwriting half of the output? [18:03:05] <CIA-90> ffmpeg: vitor * r21943 /trunk/ (6 files in 3 dirs): [18:03:05] <CIA-90> ffmpeg: AMR-NB floating-point based decoder. [18:03:05] <CIA-90> ffmpeg: Code produced during SoC by Robert Swain and Colin McQuillan. [18:04:30] <mru> congrats [18:04:44] * mru waits for fate to turn red [18:04:48] <iive> \o/ [18:05:39] <Vitor1001> congrats to Robert and Colin, who did the bulk of the work [18:06:24] <Vitor1001> In these last few days, the pipeline of important things remaining to get committed got significantly shorter :D [18:07:34] <Vitor1001> FFprobe, WMAVoice, AMR-NB, ALS, Bink... [18:08:28] <kshishkov> yes, now we have only bunch of lossless audio codecs, some Windows Media codecs, Indeo 4, some Apple codecs and whatever [18:13:59] <Vitor1001> I agree, but those are not really low-hanging fruits [18:14:00] <mru> VP8 [18:14:09] <Vitor1001> LAME hostile takeover ;) [18:14:17] * Vitor1001 runs away from the flames [18:14:17] <kshishkov> mru: I said "whatever" [18:15:02] <Vitor1001> Is any working code written for indeo 4? [18:15:03] <kshishkov> Vitor1001: well, if you are goingto undertake that task, maybe why not? Maybe the same devs will improve our MP2 encoder too ;) [18:15:11] <kshishkov> yes [18:15:27] <kshishkov> but it's only in autor posession [18:15:55] <Vitor1001> lame is a project that is in a pretty mature stage, also in the sense of not evolving very fast [18:16:13] <Vitor1001> but I don't have time for that :( [18:16:25] <Vitor1001> and I don't think it would need to be hostile... [18:19:29] <kshishkov> still, FFmpeg can benefit from good lossy audio encoder or two [18:25:10] <Vitor1001> is a good psychoacoustic model all ffaac is missing? [18:25:23] <kshishkov> no [18:25:27] <Vitor1001> :( [18:25:42] <kshishkov> it's mostly good rate control and good bit allocator [18:28:26] <peloverde> I think I know how to make the coef coder not suck [18:28:26] <Compn> someone take out amr from wiki yet ? [18:28:41] <peloverde> I still have no intention of touching the psymodel [18:28:46] * kshishkov looks at Compn [18:29:25] <kshishkov> peloverde: can you say technical reasons why coef coder suck? [18:30:17] <Vitor1001> Compn: yes [18:30:25] <peloverde> Well there are three of them and it's slow [18:31:29] <kshishkov> and none of them works as supposed I fear [18:31:52] <peloverde> In general it makes more sense to build a codeword than find it in the table [18:32:32] <kshishkov> ah [18:32:44] <peloverde> All the shit in the spec when you are supposed to divide and subtract that makes writing a decoder suck (that we do with tables in our decoder) can be done as adds and multiplies in the encoder [18:33:39] <peloverde> Also we can pick up quite a bit of speed by templating [18:34:14] <CIA-90> ffmpeg: stefano * r21944 /trunk/ (doc/ffprobe-doc.texi ffprobe.c): [18:34:14] <CIA-90> ffmpeg: Add support to an option -f which forces the format to use for opening [18:34:14] <CIA-90> ffmpeg: the probed multimedia resource. [18:34:35] <peloverde> we waste a lot of time checking if things are unsigned and what size they are and if escapes are possible [18:35:25] <peloverde> I have a patch to inline the coder into 6 cases: 0, 2U, 2S, 4U, 4S, and ESC [18:35:52] <peloverde> where 2U is unsigned pair for instance [18:37:34] <Compn> ah thats what still needs to be done [18:37:43] <Compn> add ffamr to mplayer codecs.conf :) [18:38:28] <kshishkov> ffamrnb for now [18:38:34] <Compn> right [18:40:39] <peloverde> Also money would help, PS has money attached, if google managed to find $100 million for on2 and wants an AAC encoder they are going to have to find a few dollars somewhere [18:41:01] <kshishkov> :) [18:41:48] <peloverde> I don't want $100 million but I'd like to be able to pay my rent, buy a new PC, and afford a few meals out [18:42:11] <kshishkov> a thousand bucks then [18:42:13] <iive> peloverde: submit your CV to google. [18:43:11] <Compn> kshishkov : btw have you thought about moving to usa/canada? the northern parts are cold ... [18:43:16] <peloverde> I learned when I applied to M$ that if you have a specific skillset and are applying to a big company you get lost in the shuffle [18:43:18] <Compn> moving/finding job there [18:43:50] <kshishkov> Compn: too far away from Sweden [18:44:02] <iive> peloverde: you have taste for evil! [18:44:03] <Compn> peloverde : yeah, but with google you can ask skal for help in the shuffle [18:44:14] <Honoome> peloverde: you'd end up getting asked a lot about python during the interview, for google development positions [18:45:19] <kshishkov> and probably VB for M$ [18:46:08] <janneg> probably .net now [18:46:18] <kshishkov> vb#.net [18:46:35] <peloverde> microsoft asked a little about .net, they mostly asked about datastructures and whatnot [18:46:54] <peloverde> and not a single question about signal processing [18:46:57] <kshishkov> and you were overqualified [18:47:24] <Compn> microsoft just wants to throw more developers at IE or windows api and hope someone can work on either without going insane :P [18:47:26] <kshishkov> peloverde: look at me, I have not studied signal processing at all [18:48:11] <peloverde> I was in thoery interving for a position in the Windows Media group but I think all I got was a screen interview for comp scis [18:48:53] <kshishkov> do you think their WM division knows _anything_ about signal processing? [18:49:09] <peloverde> Rico malvar wrote a decent book [18:49:12] <kierank> presumably gary sullivan does [18:49:18] <kshishkov> IIRC their audio codecs used Intel implementation of FFT [18:49:34] <kshishkov> Malvar - yes, known transforms guy [18:49:39] * elenril wonders if GET_UTF8 is broken [18:50:22] <iive> peloverde: did you got some tick puzzle questions? [18:50:32] <peloverde> no puzzle questions [18:50:46] <peloverde> puzzle questions are pretty out of vogue these days [18:52:38] <peloverde> I worry that I would get a generic screening interview at google and get tossed aside, I also worry I would get stuck on something internal (like when was the last time skal submitted any code) [18:53:14] <kshishkov> not that he contributed much before that [18:53:59] <DonDiego> geez [18:54:02] <DonDiego> amr-nb... [18:54:02] <iive> were you soc student? [18:55:14] <iive> you can write you've completed a number of tasks in soc, it should be enough to skip the first round. [18:55:25] <peloverde> I was never SoC [18:55:50] <iive> even as ... teacher? [18:56:21] <peloverde> never, this will be my first year as a mentor if i cna find a student [18:57:39] <elenril> anybody has a working knowledge of utf8? [18:57:45] <peloverde> FFmpeg started participating in SoC when I graduated, and then I worked for a a semiconductor firm for two years [18:58:55] <peloverde> Pretty much I picked up all my signal processing theory in school and all my multimedia knowledge at work [18:58:56] <kshishkov> elenril: what exactly? [18:59:04] <iive> elenril: it would be much easier if you ask specific questions, instead of asking for asking. [18:59:31] <kshishkov> peloverde: you're lucky. Neither school nor university gave me any real education [18:59:34] <elenril> kshishkov: GET_UTF8 seems to return zeros for non-ascii characters [18:59:49] <elenril> i'd like someone to check it for signs of obvious brokenness [19:00:10] <kshishkov> I'll look right now [19:00:18] <iive> be sure you read chars as unsigned. is that ffmpeg code? [19:00:48] <kshishkov> elenril: how you use it? [19:01:45] <elenril> http://pastebin.ca/1804892 [19:03:16] <elenril> works fine with latin strings [19:05:19] <iive> elenril: what is the type of q? [19:05:22] <kshishkov> hmm, even for non-ascii strings it should set ch to the first character [19:05:47] <elenril> iive: char* [19:05:48] <kshishkov> can't you print q[0] and q[1] to verify input? [19:06:16] <iive> elenril: try with uint8_t [19:06:39] <kshishkov> indeed [19:09:39] <elenril> heh, seems to work [19:09:46] <elenril> why would it break just because of this? [19:09:54] <kshishkov> of course [19:10:04] <kshishkov> input value range differs [19:10:49] <iive> 0x80 is extended to 0xffffff80 [19:11:37] * elenril should really learn C soon [19:11:54] <kshishkov> or go in management [19:12:41] <elenril> =p [19:12:54] <elenril> i'm a physicist, not a programmer [19:13:49] <kshishkov> yes, I saw what people like you can do. Hasn't got through all Half Life game though. [19:14:25] <elenril> lol [19:14:26] <iive> i bet you haven't got to the better half yet. [19:33:37] <CIA-90> ffmpeg: cehoyos * r21945 /trunk/libavcodec/h264.c: [19:33:37] <CIA-90> ffmpeg: Remove unused variable mb_xy. [19:33:37] <CIA-90> ffmpeg: Patch by avcoder, ffmpeg gmail [19:42:17] <ramiro> elenril: is there any reason to use the external amr libraries instead of ffamr-nb for decoding? as in is there any feature missing from ffamr-nb? [19:42:27] <ramiro> elenril: oops, that wasn't meant for you [19:42:48] <kshishkov> probably not [19:42:54] * elenril agrees ;) [19:42:59] <kshishkov> and IIRC it had not special features [19:43:26] <jai> hello ramiro [19:43:34] <ramiro> jai: hi, I just got your reply =) [19:43:55] <ramiro> I just skipped over that thread, let me check. [19:44:42] <jai> ramiro: sure, np :) [19:45:35] <elenril> kshishkov: what about reverse conversion utf16->utf8. how much space would that need? [19:45:55] <kshishkov> twice as well ;) [19:45:59] <Kovensky> ohi ramiro, still dodging teh floods? =p [19:46:11] <kshishkov> in char size - 2 bytes, out char size 1-4 bytes [19:48:20] <elenril> thanks, thought as much [19:50:14] <ramiro> Kovensky: what floods? I'm not in sao paulo. [19:50:15] <elenril> everybody rejoice, now asfenc/dec can read/write metadata correctly! [19:50:28] <elenril> (not that anybody cares about asf) [19:50:32] <twnqx> what about mov/mp4? [19:50:33] <kshishkov> *bored* yaaaay [19:50:50] <Kovensky> ramiro: I meant the state [19:50:58] <elenril> mov is :effort: [19:51:10] <Kovensky> ramiro: where are you anyway [19:51:28] <ramiro> jai: I'm no parser expert (in fact I still don't understand most of it), but it seems that if ff_combine_frame is called, buffer is allocated, and so it must be freed at some point. so I guess it's ok if it works... [19:51:45] <jai> ramiro: indeed [19:51:53] <ramiro> Kovensky: florianopolis [19:52:05] <Kovensky> ramiro: for some reason I thought you were in SP [19:52:06] <Kovensky> lol [19:52:44] <ramiro> Kovensky: no, I don't like that place. too many people. I only go there for concerts =) [19:53:08] <Kovensky> heh [19:53:18] <Kovensky> btw ramiro, I added a paypal button to my page [19:53:26] <Kovensky> two weeks and $0 ._. [19:53:47] <kshishkov> swap it randomly with download link ;) [19:53:51] <elenril> lol [19:53:53] <ramiro> lol [19:53:59] <jai> heh [19:54:09] <Kovensky> lol [19:54:18] * kshishkov received much more in donations [19:54:22] <elenril> that's because you didn't make new builds for so long [19:54:39] <ramiro> Kovensky: well, it's kind of hidden [19:55:47] <ramiro> I once had a script that generated a random amount of money (from 2 to 20$) and put it in the donation link, with a "refresh" button. people thought it was funny and I got a bunch of 2.something donations... [19:57:33] <ramiro> Kovensky: did you add dxva2api.h to build ffmpeg? [19:58:00] <Kovensky> ramiro: yes, ffmpeg is built with fxva support; but mplayer can't use it :( [19:58:03] <Kovensky> dxva* [19:58:27] <ramiro> hmm, oh well, I don't know about mplayer... [19:58:42] <peloverde> I added a donate link and got nothing too [20:00:18] <kshishkov> Kovensky: another reason to dith MPlayer for FFplay ;) [20:00:51] <kshishkov> peloverde: I found that having popular blog is better than "Donate" on less popular one ;) [20:00:55] <elenril> ffplay - sdl -meh [20:01:10] <kshishkov> elenril: libvo support is welcome ;) [20:01:10] <Vitor1001> Who [20:01:20] <ramiro> kshishkov: after michael's rdft output, ffplay beats the hell out of WMP's visualization =) [20:01:35] <elenril> kshishkov: :effort: [20:01:38] <peloverde> I just put it directly on my git page. I haven't blogged in years [20:01:45] <Vitor1001> err, who said valgrind devs never fix bugs? [20:01:46] <Vitor1001> ;) [20:01:47] <Vitor1001> https://bugs.kde.org/show_bug.cgi?id=210264 [20:01:51] <ramiro> that definitely got us a couple of steps closer to world domination. [20:01:53] <peloverde> ramiro, now all we need is an sse rdft [20:02:11] <Honoome> given I freed myself from Gentoo today I might be finally able to look into getting a Planet Multimedia to aggregate our blogs :P [20:02:22] <kshishkov> and altivec [20:02:28] <Kovensky> did SDL ever fix their static linking bug? [20:02:40] <ramiro> Vitor1001: elenril said he's a physicist. didn't you graduate in physics too? [20:02:48] <Honoome> Kovensky: did SDL fix _anything_ in the past five years? :P [20:03:01] <ramiro> Honoome: no, but they indent to charge for 1.3 [20:03:13] <ohsix> freed from gentoo again? :O [20:03:27] <Vitor1001> ramiro: Trying to finish my phd in physics [20:03:28] <Kovensky> 1.3 was WIP back when I first heard of SDL [20:03:31] <Kovensky> that was almost 10 years ago [20:03:55] <kshishkov> Kovensky: same as FFmpeg 0.5, I presume? [20:03:58] <Honoome> they are trying to reuse part of the Duke Nukem Forever code [20:05:03] <Kovensky> explains everything [20:05:04] <ramiro> Kovensky: another idea is to make your builds slightly broken, and suggest that people may sponsor better builds... [20:05:06] * jai has a local ffplay hack to output to libvo gl2 [20:10:30] <ohsix> hm, cant ffmpeg do virtualdub stype dubbing when one track is cbr and one is vbr? [20:12:49] <elenril> btw anybody wants to apply a few patches for me? [20:13:18] <Kovensky> more meta stuff? =p [20:13:24] <elenril> ofc [20:13:50] <elenril> metadata is important! [20:14:31] <Kovensky> yes it is [20:14:49] <Kovensky> more importantly, I want a way to be able to export / import metadata [20:15:03] <Kovensky> it seems that I may end up having to write my own thing for doing that >_> [20:15:26] <twnqx> just define a metadata XML [20:15:49] <elenril> Kovensky: what to you mean by that? [20:16:10] <Kovensky> dump metadata from a file to a text file [20:16:15] <twnqx> he wants to be able to import/export metadata standalone [20:16:18] <Kovensky> load the dumped metadata into another file [20:16:27] <elenril> write a muxer/demuxer [20:16:30] <elenril> should be easy [20:16:46] <Kovensky> o_O [20:16:54] <Kovensky> how would that work [20:16:55] * elenril slaps twnqx for using the X-word here [20:17:13] <Honoome> could be worse [20:17:34] <Kovensky> how worse [20:17:37] <mru> could be xiph-specified xml [20:17:47] <mru> double-x [20:17:52] <Honoome> haha :) [20:18:00] <Honoome> I was thinking of aXML though [20:18:19] <Yuvi> mru: http://wiki.xiph.org/XMLEmbedding ? [20:19:09] <elenril> Kovensky: a muxer consisting of only write_header() [20:19:29] <Kovensky> hmm [20:19:30] <elenril> i supposed even i could write it in less than one afternoon [20:19:40] <Kovensky> lol [20:20:01] <Kovensky> I was thinking of using YAML for the export ._. [20:20:30] <elenril> why do you need anything like that [20:20:48] <Kovensky> because uploading tags is much faster than uploading .flac [20:21:13] <elenril> just use a text file with tag=value\n [20:21:40] <Honoome> ini-compatible key-value files! I love that :D [20:21:48] <Kovensky> lol [20:22:02] <mru> but without [this] [20:22:06] <Kovensky> key: value\n is better :D [20:22:13] <Honoome> mru: that's trueâŠ but stillâŠ :) [20:22:28] <Honoome> you can use the same code to parse both in most cases and there are quite a few libraries in almost every language that support it [20:22:29] <mru> key $arbitrary_separator value [20:23:04] <Honoome> [and it actually says a lot, about Microsoft (or whoever used them first) having had a not half-bad idea at the timeâŠ] [20:23:29] <jai> json perhaps [20:23:43] * mru prefers frddy [20:23:44] * Kovensky prefers YAML to JSON [20:23:54] <jai> hmm [20:23:58] * Kovensky pats Dark_Shikari [20:24:18] <mru> jaison [20:24:46] <elenril> lol [20:25:10] <jai> :) [20:25:52] * elenril should learn how to use git send-email [20:26:20] <jai> man page isn't useful? [20:26:32] <elenril> :effort: [20:26:43] <mru> less than sending patches manually [20:27:06] <elenril> btw is there anything better than mutt? [20:27:11] <Honoome> git send-email --to=ffmpeg-devel@.. origin/master.. [20:27:35] <mru> elenril: matter of taste [20:27:38] <Honoome> or if it's just the one last patch use -1 [20:27:39] <elenril> i'm starting to hate it [20:27:40] * mru prefers cat [20:27:59] <elenril> http://en.wikipedia.org/wiki/Cat ? [20:28:03] <mru> but if you're a dog person... [20:28:04] <Kovensky> what about tac | tac [20:28:16] <Honoome> mru: âemerge dogâ [20:28:35] <Honoome> and I'm not even kidding : [20:28:35] <Honoome> :P [20:28:41] <mru> I know [20:28:55] <twnqx> anyone here with an idea for a decent spice simulator for windows? [20:29:10] <Kovensky> to simulate what [20:29:16] <Honoome> I use Evolution anywayâŠ and mutt for sending automated mails [20:29:18] <elenril> http://notmuchmail.org/ this looks pretty interesting [20:29:21] <elenril> anybody tried it? [20:29:24] <Honoome> Kovensky: peppermint, sage, basilâŠ [20:29:41] <mru> twnqx: doesn't spice work in cygwin? [20:29:53] <twnqx> i want a gui to click the pieces [20:29:55] <twnqx> :P [20:30:04] <twnqx> otherwise i'd just use spice-ng, fast and nice [20:30:06] <jai> elenril: give sylpheed a try if you prefer GTK UIs [20:30:27] * mru used to run some bizarre patchwork of spice and matlab [20:30:40] <elenril> jai: i prefer something that runs in screen ;) [20:30:54] <Honoome> elenril: emacs and vm :D [20:30:58] <peloverde> twnqx, LTSpice has a nice gui [20:30:59] <mru> emacs and gnus [20:31:00] <elenril> >emacs [20:31:00] <Honoome> [it's actually not half bad] [20:31:06] <mru> gnus >>>> vm [20:31:13] <Honoome> mru: gnus is not much for mail as much for mailing lists [20:31:15] * elenril uses vim [20:31:23] <mru> gnus is for everything [20:31:34] <Kovensky> gnus are* [20:31:36] * Kovensky ducks [20:31:44] <twnqx> peloverde: will give it a shot, thanks [20:31:55] * Honoome goes to the espresso machine [20:32:02] * mru suddenly has flashbacks of pspice [20:32:13] * Kovensky still wonders what spice is [20:32:28] <Honoome> Kovensky: cinnamon! :P [20:32:38] <peloverde> Kovensky, a circuit simulator [20:32:52] <Honoome> peloverde: oh shush I was having so much fun :( [20:32:55] <mru> there's spice in the kitchen, spice in the lab, and spice in dune [20:33:01] <Kovensky> I remember it now D: [20:33:06] * Kovensky has used it before, a long time ago [20:33:23] * mru had curry for dinner the other day... [20:33:34] * Kovensky does not like spicy food [20:33:43] <mru> don't come to my house then [20:33:44] * twnqx does sometimes [20:34:30] <Kovensky> though the last time I tried spicy food was back when I was 10 [20:34:31] <Kovensky> lol [20:36:38] <mru> now take your electronics simulator, enter schematics for a computer, run a simulator on it, enter schematics for a computer... [20:37:20] <_av500_> a drug? [20:38:14] * _av500_ finds his terminal on drugs [20:38:33] <mru> http://www.youtube.com/watch?v=Rw8gE3lnpLQ [20:41:09] <elenril> yo dawg [20:47:59] <CIA-90> ffmpeg: mru * r21946 /trunk/libavutil/mathematics.h: More accurate value for log2(1) [20:49:15] <elenril> more accurate value of zero? [20:50:45] <mru> zero is the most important number, got to get it right [20:51:33] * mru blames 0 and ) being on the same key [20:52:28] * Kovensky never knew log2(1) == 0 [20:52:49] <mru> log_everything(1) == 0 [20:52:49] * elenril thinks Kovensky needs to repeat his math class [20:53:00] <kierank> lol [20:53:25] * Kovensky also thinks so [20:54:04] <Honoome> mru: beside log_0(1) iirc? [20:54:23] <mru> everything == positive numbers [20:55:23] <twnqx> hm [20:55:33] <twnqx> my circuit approaches -9GV [20:55:42] * Honoome waits for Baptiste to check his patch âŠ should solve the Rebus [20:55:42] <twnqx> something.. is quite wrong here [20:55:55] * elenril throws EUNDEFINED at Honoome [20:56:04] <Honoome> elenril: uh? :P [20:56:05] <mru> ERANGE [20:56:41] <Honoome> ah log_0 ^^ I thought you referred to Baptiste, since it was the metadata patch [20:57:19] <elenril> well he's not here either [20:57:27] * Kovensky throws ENOTIMPLEMENTED at elenril [20:57:57] * elenril didn't see him here for more than a week [20:58:11] * Kovensky misses his onjoin script [20:58:21] <mru> hi guys [20:58:37] <Kovensky> it's not the same thing :( [21:00:24] <bcoudurier_> hi guys [21:00:42] <mru> better? [21:00:46] <elenril> sounds fake for some reason [21:00:49] * elenril wonders why [21:01:02] <elenril> probably the color [21:01:51] <Honoome> elenril: it was the wrong shade of invisible pink? [21:02:27] <elenril> no, my nick-coloring script colors real bcoudrier blue [21:02:33] <elenril> this fake one was yellow [21:02:51] <Honoome> for me it was green [21:03:02] <elenril> you should fix it then ;) [21:03:22] <Kovensky> for me he was yellow too [21:03:23] <Kovensky> lol [21:03:39] <elenril> Honoome: see -- your script is broken [21:03:54] * Honoome has no script, this is Quassel! [21:04:18] * Kovensky doesn't even try quassel precisely for that reason [21:04:30] * Kovensky is addicted to perl scripting [21:04:37] * elenril is addicted to screen [21:05:09] <Honoome> I'm addicted to Gentoo, but I'm trying to stop that [21:07:31] <Kovensky> lol [21:07:42] <Kovensky> I can't even get myself addicted to lunix :( [21:07:57] <elenril> then you're DoingItWrong [21:08:08] <Kovensky> only windows has graphic drivers for my thing-that-draws-to-the-LCD [21:08:19] <elenril> hey, there's a trope for that [21:08:59] <Honoome> elenril: about drivers? [21:09:16] <elenril> Honoome: about DoingItWrong [21:09:23] <Honoome> no wonders [21:09:25] <elenril> (actually it redirects to EpicFail) [21:12:05] <Kovensky> the only things that keep pushing me back to windows are driver issues [21:12:26] <Honoome> change videocard :P [21:12:46] <Kovensky> Honoome: craptop :P [21:12:52] <Honoome> change crap :P [21:13:01] <Kovensky> I can't use fbsd here either, even with vesa, becausethere's no sis191 support <_< [21:13:04] <Kovensky> not even with ndis [21:13:09] <Kovensky> +\ [21:13:30] <elenril> 1)learn how to RE [21:13:34] <elenril> 2) write the drivers [21:13:38] <elenril> 3) ??? [21:13:51] <elenril> 4) world domination [21:13:52] <Kovensky> it's to crap to give a damn [21:13:57] <Kovensky> too* [21:14:00] <Honoome> ouch sisâŠ that'sâŠ bad [21:14:02] <Kovensky> and no, I don't want to help SiS [21:14:17] * elenril wonders how Honoome writes those ellipses [21:14:30] <Kovensky> he has some silly s/// :V [21:14:32] <Honoome> elenril: super+. [21:14:36] <Honoome> I remapped the keyboard :D [21:14:50] * Honoome got a bunch of other unicode charaters in there, including ââ and â :D [21:15:28] <Kovensky> compose+... [21:15:42] <Kovensky> ââ <-- dunno how to write this one lol [21:15:43] <Honoome> Kovensky: compose is not working in qt4 for me =_= [21:15:48] <Kovensky> â <-- ã»ã [21:15:53] <mru> what's the point? 7 bits ought to be enough for anyone [21:16:04] <Honoome> Kovensky: to compose the arrows just compose <- [21:16:06] <Honoome> and -> [21:16:17] <Honoome> but the three dots don't compose to the ellipsis here [21:16:33] <Kovensky> ââ <-- works with MS IME [21:16:36] <elenril> ? ?oo? [21:16:39] <Kovensky> <- space -> space [21:47:07] <DonDiego> [sipr @ 0x904aef0]Internal error, IDCT permutation not set [21:47:50] <mru> not like sipr would need it... [21:47:59] <mru> what prints that line? [21:48:27] <DonDiego> http://samples.ffmpeg.org/V-codecs/MSS1/GipsyGuitar.wmv [21:48:31] <DonDiego> played with mplayer [21:48:41] <DonDiego> can somebody quickly run this through ffplay? [21:48:50] <DonDiego> my tree will take a moment to recompile.. [21:49:29] <CIA-90> ffmpeg: mru * r21947 /trunk/libavcodec/mathops.h: Add zero_extend() function [21:49:29] <CIA-90> ffmpeg: mru * r21948 /trunk/libavcodec/get_bits.h: Deobfuscate LE SHOW_[SU]BITS; these are simple sign/zero-extend [21:49:44] <mru> no errors [21:50:22] <DonDiego> k [21:57:21] * mru likes closing issues as invalid <5 minutes after they're opened :-) [22:00:59] <DonDiego> SDL_OpenAudio: [22:01:00] <DonDiego> /tmp/GipsyGuitar.wmv: could not open codecs [22:01:01] <DonDiego> hmm [22:13:10] <j-b> Vitor1001: nice [22:13:24] <Vitor1001> j-b: :D [22:13:38] <Vitor1001> j-b: But I wasn't the one who did most of the work [22:13:48] <j-b> you merged :) [22:13:52] <Vitor1001> It works fine on VLC? [22:14:09] <j-b> I'll tell you in half an hour [22:14:10] <Vitor1001> Well, I finished the review. Collin started it. [22:14:16] <Vitor1001> Cool [22:14:45] <j-b> but, that's a huge "pain" out of my schedule... [22:15:00] <j-b> no more "I can't hear this 3gpp" file in VLC... [22:15:16] <mru> is amr still used in the wild? [22:15:21] <Vitor1001> Aren't the windows binaries distributed with opencoreamr? [22:15:29] <j-b> Vitor1001: they are not. [22:15:35] <Vitor1001> Why? [22:15:41] <j-b> GPLv3 [22:16:00] <Vitor1001> I see [22:16:18] <j-b> I had private builds [22:16:29] <j-b> but the official one weren't with it [22:16:37] <j-b> mru: no idea, but I see many complaints [22:17:31] <Honoome> I'm quite sure Symbial still uses AMR [22:17:50] <j-b> Vitor1001: anyway, many thanks to you... And superdump ain't around [22:19:41] <Vitor1001> j-b: Do you get also a lot of complains about HE-AAC? [22:20:11] <j-b> Vitor1001: no. Faad2 works IIRC [22:20:35] <Vitor1001> VLC uses it by default? [22:20:46] <j-b> yes sir [22:24:50] <j-b> Vitor1001: but with DVB-HD Sub, WMAVoice, AMR-NB, WMAPro, Indeo5, Avcodec sub, Atrac1, avformat improvements + DxVA/VAAPI/OpenMax decoding, VLC 1.1 might get quite popular [22:25:21] <Vitor1001> :D [22:25:49] <Vitor1001> I think I also remember someone asking also about bink in some vlc ML ;) [22:25:53] <kierank> "DVB-HD Sub" --> what's that? [22:26:56] <j-b> Vitor1001: yes, I am waiting for Bink [22:27:07] <j-b> Vitor1001: but that is less important [22:27:20] <Vitor1001> j-b: see r21937 [22:27:46] <j-b> http://git.videolan.org/?p=vlc.git;a=commitdiff;h=91b3be07653bbfef1ac666436… [22:27:49] <Vitor1001> j-b: bink is committed (both audio and video) [22:28:16] <j-b> video is commited? [22:28:21] <j-b> I missed that [22:28:35] <Vitor1001> Since 2 PM today [22:28:41] <j-b> Kewl [22:33:53] <mru> we're dominating more than ever [22:42:43] <kierank> merbzt, ping [22:47:56] <peloverde> As far as the AAC goes, we are rapidly reaching the point where both faad and ffmpeg can handle nontrivial streams the other can't [22:48:16] <Dark_Shikari> yup [22:48:18] <Dark_Shikari> we're already there [22:49:19] <peloverde> I don't know whay faad is so resistent to implementing whole levels and profiles [22:50:33] <DonDiego> well, ffmpeg cannot handle sbr yet.. [22:50:44] <DonDiego> so i guess faad2 is still in front [22:50:52] <DonDiego> what can ffmpeg do that faad2 cannot? [22:52:44] <peloverde> channel coupling [22:53:00] <peloverde> decode the conformance files within the required accuracy parameters [22:53:36] <peloverde> Also SBR works fine, it's just not merged [22:54:01] <mru> so faad isn't in fact an aac decoder at all ;-) [22:55:06] <peloverde> indeed :) [22:55:31] <peloverde> Also a 5.1 channel LC decoder is required to support at least one dependent coupling channel [22:55:52] <peloverde> (even though nobody seens to use it in the wild) [22:57:10] <Dark_Shikari> peloverde: another thing ffmpeg does [22:57:15] <Dark_Shikari> not be horribly slow [22:57:49] <peloverde> Dark_Shikari, we are horribly slow on mainprofile with the backward predictor on, but nobody uses that [22:58:46] <iive> peloverde: does faad handle that case better? [22:59:41] <peloverde> I'm sure if they are then they aren't conformant, you need to round to half float periodiclly or evertrhing goes to hell [22:59:50] <peloverde> that's where most of the speed loss comes from [23:01:46] <mru> cortex-a9 can do that in hw [23:02:11] <_av500_> mru: can it be backported :) [23:02:28] <mru> maybe with one of those plasma cannons... [23:08:52] <j-b> Vitor? [23:08:53] <j-b> too late [23:08:57] <peloverde> Anyway I don't think anyone really cares about that feature, i just added it because flash and faad support it and i wanted to be checklist compliant [23:23:40] <CIA-90> ffmpeg: michael * r21949 /trunk/libavcodec/mpeg12.c: [23:23:40] <CIA-90> ffmpeg: Fix timestamp association for mpeg2 field pictures. [23:23:40] <CIA-90> ffmpeg: Fixes /MPlayer/incoming/codec_copy_fails_vob_to_mpeg-ts/codec_copy_fails_vob_to_mpeg-ts.vob [23:29:10] <CIA-90> ffmpeg: mru * r21950 /trunk/configure: Suppress armcc warnings about unknown attributes [23:29:11] <CIA-90> ffmpeg: mru * r21951 /trunk/libavcodec/get_bits.h: [23:29:11] <CIA-90> ffmpeg: get/show_bits() can read up to MIN_CACHE_BITS bits [23:29:11] <CIA-90> ffmpeg: The limit for get/show_bits_long() to use get/show_bits() directly [23:29:11] <CIA-90> ffmpeg: should be MIN_CACHE_BITS, not 17.

1 0

IRC log for 2010-02-20
by irc＠mansr.com 21 Feb '10

21 Feb '10

[00:40:36] <Honoome> … michael now replies in rebuses? did I miss his replies in Haiku before? [00:57:12] <Dark_Shikari> http://i45.tinypic.com/w7d3ch.jpg [00:57:18] <Dark_Shikari> http://i46.tinypic.com/2v1uikh.jpg [00:57:52] <Dark_Shikari> I now have my x264 shirt. [00:57:58] <Honoome> haha :) [00:58:05] <Honoome> for a moment I was expecting Michael's haiku :P [00:58:14] <Dark_Shikari> lol [01:00:29] <beandog> Dark_Shikari: very nice [01:02:45] * Honoome is tempted to make one with ffmpeg, xine, lscube and gentoo logos for the next fosdem [01:02:59] <Honoome> it was difficult to find the rest of the guys not knowing anybody's face :P [01:04:58] <peloverde> I was lucky that I overheard mru, KotH, and siretart talking about FFmpeg at delirium [01:07:52] <Honoome> I was lucky I was with Luca ;) [01:36:29] <Dark_Shikari> btw, if you want a shirt [01:36:31] <Dark_Shikari> I recommend spreadshirt [01:36:36] <Dark_Shikari> 1) upload pngs with transparency (high res) [01:36:37] <Dark_Shikari> 2) ??? [01:36:38] <Dark_Shikari> 3) profit [01:36:46] <Dark_Shikari> cafepress doesn't let you print on the back of a black t-shirt. [01:37:35] <Honoome> Dark_Shikari: myself I have a supplier already ;) -- a customer of mine does prints, so I don't even have to pay, beside the shirt itself [01:38:14] <Dark_Shikari> ah [01:38:57] <peloverde> I've thought about doing FFmpeg stickers [03:12:42] <Dark_Shikari> http://pastebin.com/f6dd893ef <--this sort of thing good for porting the x264 presets to ffmpeg? [03:29:02] <mfg> I have a question about AVMetadataConv: does it actually do anything for a demuxer? is the idea that the application use it to translate the metadata tags into something useable (with av_metadata_conv), because otherwise, it doesn't do anything on its own (as far as I can tell). TIA! [05:10:14] <ramiro> great. I took apart the only windows notebook I had left and there are broken pieces scattered all around my room. [05:10:38] <ramiro> any suggestion for a cheap netbook I could acquire? (with windows) [07:58:57] <elenril> morning [08:06:40] <kshishkov> god morgon [08:12:37] <Yuvi> astrange: how much speedup did you get from http://github.com/astrange/ffmpeg/commit/cfd4b6027476aca8bfc25e5f1ee95accf5… ? [08:13:01] <Dark_Shikari> wow, "not much speedup"? [08:13:05] <Dark_Shikari> I guess because most of the time is in bitstream decoding? [08:13:23] <Yuvi> yeah, and that isn't included in what can be multithreaded within a frame [08:13:45] <astrange> yeah, i hardly measured any. that was before fast fragment mapping [08:13:52] <kshishkov> 1.73 cycles speedup ? [08:14:00] <astrange> so it still spent pretty much all the time in bitstream decoding [08:14:01] <Yuvi> I'm wondering because the next patch gives a speedup of 12-20% but makes that impossible to do [08:14:13] <Dark_Shikari> Yuvi: that's fine imo [08:14:16] <Dark_Shikari> any good threading will be frame based [08:14:39] <astrange> yeah, whatever you do won't break frame threading [08:14:57] <astrange> actually draw_horiz_band code can be combined with that [08:15:11] <astrange> since they both run when the smallest possible # of rows are finished [08:16:08] <astrange> let me try it again [08:17:02] <astrange> what's a difficult theora clip? i only have small ones [08:17:26] <Yuvi> 1080p BBB is decent [08:17:46] <Yuvi> http://mirror.bigbuckbunny.de/peach/bigbuckbunny_movies/big_buck_bunny_1080… [08:18:57] <astrange> that's.... big [08:19:18] <kshishkov> someone should name next opensource movie something like "Medium Robust Unicorn" to cause further confusion on this channel [08:19:46] <Yuvi> yeah... and it's slightly worse quality than that 1.2 mbit x264 BBB [09:00:02] <pentanol> hi mru [09:01:32] <pentanol> or perhaps someone here may help me [09:02:16] <pentanol> I want make ffpmeg for rtp-proxy for arm [09:02:22] <pentanol> I did it ./configure --prefix=/usr/local/ffmpeg-dev-cris --arch=arm --enable-cross-compile --cross-prefix=cris- --disable-doc --sysinclude=/usr/local/cris/cris-axis-linux-gnu/include [09:02:39] <pentanol> but there.. Enabled protocols: [09:02:39] <pentanol> file pipe [09:03:05] <pentanol> I can't obtain tcp, udp, rtp... so on [09:03:31] <kshishkov> obviously your compiler lacks networking headers [09:03:37] <kshishkov> look at config.log [09:05:38] <pentanol> perhaps, it looks like --sysinclude=/usr/local/cris/cris-axis-linux-gnu/include won't work [09:06:06] <pentanol> but there /usr/local/cris/cris-axis-linux-gnu/include/net/ [09:06:26] <kshishkov> whatever, look at logs [09:06:49] <kshishkov> and probably ask at #ffmpeg, this has nothing to do with FFmpeg development [09:21:24] <astrange> int current_edge_emu_buffer = s->edge_emu_buffer; oops [09:21:36] <pentanol> #ffmpeg there no one :( [09:21:47] <pentanol> hm, why if I put it... --sysinclude=/usr/local/cris/cris-axis-linux-gnu/include/ it said netinet/in.h: No such file or directory [09:22:27] <pentanol> it's header exist there... /usr/local/cris/cris-axis-linux-gnu/include/netinet/in.h [09:23:49] <kshishkov> dunno, must be some compiler options you don't pass, like --basedir [09:23:58] * kshishkov does not know about it a thing [09:31:59] <Yuvi> Dark_Shikari: http://pastebin.com/m89f3ebe you mentioned this was uncommented, is that clearer? [09:32:01] <pentanol> kshishkov looks like it broken in current, with 0.5 it works [09:32:52] <astrange> Yuvi: 15.97s -> 14.24s [09:33:12] <astrange> but the crcs don't match so i must have rebased it wrong (it looks visually correct) [09:35:56] <Yuvi> so a little less than what I'm getting from not sorting the coeffs until right before idct [09:37:57] <astrange> ffmpeg-mt (r21620) 1: 17.19s 2: 12.036s [09:39:02] <Yuvi> different vp3.c bases? [09:40:46] <astrange> yeah, i haven't merged mainline since before the loop filter changes [09:45:06] <Yuvi> woah, 28% faster on BBB 1080p on my g4 [10:20:35] <Dark_Shikari> Yuvi: LOOKS GOOD [10:20:50] <Dark_Shikari> er, oops, caps [10:56:05] <siretart> Dark_Shikari: I botched the last upload, it wasn't really r1442 after all. I've now redone the package properly, and r1442 does build on armel just fine [10:57:03] <Dark_Shikari> lol [10:57:06] <Dark_Shikari> oops :) [10:58:27] <siretart> I've also redone version.sh in the package, it now identifies (x264 --version) itself as: 'x264 0.85.1442 Ubuntu_2:0.85.1442+git781d30-1' [10:58:55] <Dark_Shikari> isn't that a bit redundant? [10:59:03] <siretart> a bit, yes [11:00:07] <siretart> I wasn't sure what other tools might parse the original information, and this was the least annoying I could come up after 20min thinking on it [11:01:32] <Dark_Shikari> I guess you have 80 characters to work with [11:01:34] <Dark_Shikari> so it's not really a big deal [11:23:38] <CIA-90> ffmpeg: vitor * r21916 /trunk/libavformat/mpc.c: [11:23:38] <CIA-90> ffmpeg: Do not leave uninitialized data in the packet in MPC demuxer. Should allow for [11:23:38] <CIA-90> ffmpeg: adding a demuxer test to FATE. [11:36:31] <lool> siretart: w00t [11:36:38] <lool> Dark_Shikari: Heya, around? [11:36:52] <lool> Dark_Shikari: siretart suggested I could probably discuss this directly on IRC with you [11:37:11] <lool> Dark_Shikari: By default, x264 turns on NEON support if one doesn't set any fpu/cpu CFLAGS [11:37:31] <astrange> -> #x264dev if you're going to have too many long conversations [11:37:35] <lool> Dark_Shikari: But Debian/Ubuntu's armel architecture doesn't expect NEON [11:37:42] <lool> astrange: Ok [11:37:52] <lool> astrange: Not many, but perhaps one long [12:23:12] <CIA-90> ffmpeg: cehoyos * r21917 /trunk/libavutil/internal.h: Gcc attribute may_alias is not supported (or silently ignored) by all supported compilers. [12:33:21] <CIA-90> ffmpeg: stefang * r21918 /trunk/libavcodec/aactab.c: [12:33:21] <CIA-90> ffmpeg: remove tables of codebook vector values which are contained in [12:33:21] <CIA-90> ffmpeg: another table [13:13:39] <pentanol> static void put_pixels_clamped_c(const DCTELEM *block, uint8_t *restrict pixels,int line_size) [13:13:53] <pentanol> looks like a bug? restrict [13:14:04] <kshishkov> looks like an attribute [13:14:24] <pentanol> my gcc give an error [13:14:46] <kshishkov> it's not C99-compliant then [13:15:18] <mru> restrict is c99 [13:15:30] <kshishkov> pass -Drestrict= and it should be fine [13:15:34] <mru> supported in gcc at least since 2.95 [13:15:40] <kshishkov> (or upgrade to this century compiler) [13:15:43] <mru> and configure probes for it [13:20:22] <CIA-90> ffmpeg: mru * r21919 /trunk/Makefile: Delete all test related files in testclean rule [13:20:23] <CIA-90> ffmpeg: mru * r21920 /trunk/Makefile: Delete avconfig.h on distclean [13:27:02] <pentanol> hm, I delete from config.mak -std=c99 and -D__ISO.... , anyway [13:27:26] <pentanol> that is exact? CFLAGS="-Drestrict=" ? [13:27:48] <pentanol> or equal something? [13:28:20] <mru> DO NOT EDIT config.mak [13:28:32] <mru> that's asking for trouble [13:28:47] <mru> what compiler are you using? [13:30:00] <pentanol> cris-gcc [13:30:05] <pentanol> arm for axis [13:30:38] <pentanol> gcc version 3.2.1 Axis release R64/1.64 [13:30:56] <mru> arm or cris? I'm confused... [13:32:08] <kshishkov> why? It sounds valid as MIPS III for AVR [13:32:18] <mru> and why the hell are you running ffmpeg on a cris? [13:34:07] <mru> hmm, they're not even selling them anymore [13:34:40] <pentanol> actually I need convert rtsp to rtmp [13:35:59] <pentanol> --arch= no even know about cirs [13:36:04] <pentanol> cris [13:40:47] <pentanol> with live555 we've this one config.cris-axis-linux-gnu, with ffmpeg hm... [13:44:11] <mru> why don't you use a modern gcc version? [13:45:28] <_av500_> 2.9.5 ftw [13:52:09] <pentanol> you mean configure it by default and then make ARCH=CRIS ? [13:52:19] <mru> no [13:52:29] <mru> I mean get a modern gcc version [13:54:34] <pentanol> I've gcc version 4.3.2, but there nothing about cris in configure [13:54:48] <mru> just pass --arch=cris anyway [13:54:54] <mru> it will print a warning and continue [13:55:17] <mru> and why did you say you have gcc 3.2.1 a while ago? [13:58:58] <pentanol> it was about cris [13:59:04] <pentanol> anyway dsputil.h:449: error: expected ';', ',' or ')' before 'v1' [13:59:10] <mru> you're more confused than I am [13:59:17] <mru> why don't you get a modern gcc FOR CRIS? [13:59:38] <pentanol> because you said [13:59:51] <pentanol> agh doN't [14:00:06] <pentanol> 4.3.2 looks like modern? [14:00:13] <mru> but you said you have 3.2.1 [14:00:24] <pentanol> yes, it's latest [14:00:29] <mru> no, 4.4.3 is latest [14:00:39] <mru> go see at gcc.gnu.org for yourself [14:01:14] <pentanol> with 4.3.2 it wouldn't work? [14:01:27] <mru> 4.3.2 should be fine [14:01:35] <mru> but apparently 3.2.1 isn't working [14:02:01] <pentanol> dsputil.h:449: error: expected ';', ',' or ')' before 'v1' it was with 4.3.2 [14:02:12] <pentanol> gcc -DHAVE_AV_CONFIG_H -I. -I"/lib/init/rw/ffmpeg" -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -I/usr/local/cris/cris-axis-linux-gnu/sys-include/ -L/usr/local/cris/cris-axis-linux-gnu/lib/ -MMD -MF libavdevice/v4l.d -MT libavdevice/v4l.o -c -o libavdevice/v4l.o libavdevice/v4l.c [14:02:51] <mru> SO WHY DID YOU TALK ABOUT 3.2.1? [14:03:17] <pentanol> I use it [14:03:25] <mru> gaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaahhhhhhhhhhhhh [14:03:28] * kshishkov ansiktehandflatar [14:03:47] <mru> I'll footarse him if he continues [14:03:54] <pentanol> libavcodec/dsputil.h:449: parse error before "v1" whis what I 've got with 3.2.1 [14:04:04] <mru> so don't bloody use that broken version then [14:05:10] <pentanol> it's cleaned find ./ -name "*\.o" rm -rf {} \; [14:05:22] <pentanol> -exec* [14:05:24] <mru> ????????????? [14:05:43] <pentanol> what you mean about broken version [14:07:16] <kshishkov> only a couple of shrimps [14:07:31] <mru> broken: something that doesn't work [14:08:17] <pentanol> which would works? [14:08:53] <mru> 4.3 or 4.4 I'd guess [14:44:07] <KotH> mru: take it easy [14:44:19] <KotH> mru: life is too short for broken gcc versions [14:45:57] <kshishkov> may I add that idiots are in abundance as well? [14:47:08] <mru> kshishkov: I've noticed [14:47:21] <mru> KotH: tell that to the gcc devs [14:50:31] * elenril wonders why is it harder to find someone to apply the patch than to get it through review [14:51:34] <kshishkov> because patch monkeys are out? [14:52:28] <elenril> no, because you're too lazy =p [14:52:49] <elenril> btw who should i blame for bink audio bugs? [14:53:12] <kshishkov> Bink owners for not disclosing the code [14:54:05] <elenril> audio in one of my sh2 videos sounds weird [14:54:19] <kshishkov> dct or rdft? [14:54:22] <elenril> dct [14:55:00] <kshishkov> yes, it's output is far from perfect [14:55:03] <kshishkov> *its [14:55:13] <elenril> another one sounds fine [14:58:13] <elenril> at least the colors look fine now [14:58:20] <kshishkov> sorry [14:59:12] <elenril> they were weird with some earlier version of the decoder [15:00:43] <kshishkov> yes, I saw them myself too [15:28:23] <twnqx> hi [15:28:36] <kshishkov> why? [15:28:44] <twnqx> is the tag-fix for mp4/mov already applied? [15:30:06] <elenril> no [15:30:15] <twnqx> :( [15:30:37] <elenril> you'll probably have to wait for bcoudrier to reappear [15:40:17] <CIA-90> ffmpeg: ramiro * r21921 /trunk/libavcodec/Makefile: x86_fft.o depends on MMX. [16:00:25] <pentanol> ho I may run it on i386 http://codepad.org/QP7eRmEs hen ... make ARCH=cris if I building it for cris? [16:00:50] <mru> obviously not [16:03:38] <CIA-90> ffmpeg: mru * r21922 /trunk/libavutil/internal.h: Add casts to correct return type in macros for missing libm funcs [18:28:59] <CIA-90> ffmpeg: vitor * r21923 /trunk/libavcodec/utils.c: [18:28:59] <CIA-90> ffmpeg: Free encoder extradata in avcodec_close(). Should fix several small memory [18:28:59] <CIA-90> ffmpeg: leaks when encoding (at least for asv, wma and aac). [18:28:59] <CIA-90> ffmpeg: Fix also issue 1577. [19:45:39] <BBB> Vitor1001, I'm confused about the fft code in the postfilter [20:14:37] <CIA-90> ffmpeg: mru * r21924 /trunk/ (libavutil/mathematics.h libavcodec/acelp_pitch_delay.c): Replace log2f(10) with a constant [20:17:37] <Vitor1001> BBB: what's the problem? [20:21:55] <BBB> Vitor1001, it doesn't work :) [20:22:12] <BBB> Vitor1001, you said that ForwFFT_INT was the same as Fourier [20:22:22] <BBB> but I tried ff_fft_permute+calc, and I get completely different results [20:22:28] <BBB> I think I misunderstand something very basic [20:22:42] <Vitor1001> Are you trying rdft? [20:22:46] <BBB> no, fft [20:22:56] <Vitor1001> But the input is real-only [20:23:18] <BBB> I'm affraid I don't really know what the difference is [20:23:23] <Vitor1001> So I think you should be using rdft [20:23:28] * BBB should read documents on what fft is [20:23:36] <BBB> I tried, and the result was also completely confusing [20:23:42] <Vitor1001> fft [20:24:04] <Vitor1001> q_k = sum_i x_i Exp[2 * pi* i/n] [20:24:07] <Vitor1001> rdft same thing [20:24:08] <BBB> can you recommend a doc on what it is? [20:24:11] <Vitor1001> but x_i is real [20:24:32] <BBB> what is q_k, what is sum_i, what is x_i and what is i/n? [20:26:30] <BBB> I remember getting complex numbers in math class, that was about as much as I understood of fft [20:26:39] <Vitor1001> ok [20:26:46] <Vitor1001> I'll try to explain [20:27:14] <Vitor1001> I pose j "=" sqrt(-1) [20:27:25] <Vitor1001> So [20:28:15] <Vitor1001> q[k] = (x[0].Re + j * x[0].Im)*Exp[2 * pi * 0 * j / n] +(x[1].Re + j * x[1].Im)*Exp[2 * pi * 1 * j / n] + ... [20:28:27] <Vitor1001> That's the FFT [20:28:58] <Vitor1001> RDFT is the special case where x[a].Im == 0 for all a. [20:29:52] <BBB> ok [20:30:54] <BBB> (I think) [20:31:05] <Vitor1001> I think the simplest thing to do is to print both the output of the function and the RDFT of the input [20:31:10] <Vitor1001> and them compare them [20:31:18] <BBB> I'm trying to do that [20:31:24] <BBB> let me try again [20:31:31] <Vitor1001> the second zero you put it by hand, it should be always 0. [20:32:00] <Vitor1001> The output of the function should be the first half of rdft interleaved with the second half [20:33:07] <Vitor1001> First thing I'd do is to rescale by the right constant [20:33:30] <Vitor1001> I think you should be able to find it by the first component of both (that should correspond) [20:34:37] <BBB> hmm.... [20:34:39] <BBB> [0/47] 0.001923 -> 0.002190 (RDFT: 0.002190, div=1.000000) [20:34:39] <BBB> [1/47] 0.000158 -> 0.000000 (RDFT: 0.001870, div=inf) [20:34:39] <BBB> [2/47] 0.000213 -> 0.002202 (RDFT: 0.002202, div=1.000024) [20:34:39] <BBB> [3/47] 0.000114 -> 0.000019 (RDFT: 0.000019, div=1.008606) [20:34:39] <BBB> [4/47] -0.000117 -> 0.002233 (RDFT: 0.002233, div=1.000065) [20:35:01] <BBB> where the first number is input (as int-num / (1<<30)) [20:35:07] <BBB> the second number is output (same) [20:35:13] <BBB> the third is output of ff_rdft_calc() [20:35:18] <BBB> ad div is the two divided by each other [20:35:54] <Vitor1001> looks good to me [20:36:05] <BBB> how come each second number is worse than each third [20:36:06] <BBB> ? [20:36:06] <Vitor1001> The second zero you should put by hand [20:36:11] <BBB> is that imprecision? [20:36:19] <BBB> look at [3] [20:36:21] <BBB> or 5: [20:36:27] <Vitor1001> no, the second number of the FFT of a real vector is always 0. [20:36:34] <Vitor1001> no matter the input [20:36:35] <BBB> [5/47] -0.000113 -> 0.000018 (RDFT: 0.000019, div=1.015727) [20:36:35] <BBB> [6/47] 0.000067 -> 0.002255 (RDFT: 0.002255, div=1.000046) [20:36:35] <BBB> [7/47] 0.000007 -> -0.000003 (RDFT: -0.000002, div=0.948960) [20:36:46] <BBB> I don't mean [1], I understand that's uninitialized [20:36:51] <BBB> but [3], [5] and [7] [20:37:04] <BBB> those are result[1].im, result[2].im and result[3].im, right? [20:37:11] <BBB> (the ones before are result[n].re) [20:37:50] <Vitor1001> You mean the ~ 5% difference? [20:38:07] <BBB> yes [20:38:10] <Vitor1001> I think it should be some bad numerical precision [20:38:22] <Vitor1001> if it is always not much greater than that [20:38:30] <BBB> it's about stable [20:38:37] <Vitor1001> Doing a FFT with reals should be not very precise [20:38:51] <Vitor1001> well, I'll be back in a few hours, have to go now. [20:40:27] <BBB> ok, thanks [20:43:46] <Kovensky> math D: [20:43:47] * Kovensky runs [20:45:44] <peloverde> BBB "i=0 is a special case because of packing, the DC term is real, so we are going to throw the N/2 term (also real) in with it. " [20:46:18] <BBB> peloverde, so it is uninitialized? [20:46:31] <peloverde> BBB: No [20:46:37] <BBB> or result[1<<n_bits].real is placed in result[0].im? [20:47:27] <peloverde> yes [20:49:25] <BBB> but because rdft functions on float[], not fftcomplex[], each float[n*2] is really the real and float[n*2+1] is its complementary im [20:49:26] <peloverde> you need it if you are going to unfold the RDFT into a regular FFT [20:50:06] <peloverde> yes that is the output on the forward RDFT [20:50:25] <peloverde> For the IRDFT it's interleaved complex in and real out [20:50:32] <BBB> got it [20:50:53] <BBB> does irdft expect the result[1<<n_bits].real to be in [1]? [20:50:58] <BBB> or is it unused? [20:51:29] <peloverde> it is needed for correct output [20:51:52] <BBB> because I believe this code does irdft also [20:51:59] <BBB> although I have no idea what its purpose is [20:53:03] <peloverde> We also have a pair that does complex time to real frequency and vice versa [20:55:50] <BBB> can I ask very stupid questions? [20:55:53] <BBB> what is the point? [20:56:06] <BBB> how does the output of rdft help in smoothening the audio? [20:56:14] <BBB> or what is the significance of the output of the rdft? [20:56:53] <BBB> here, for example, they're doing rdft(lpcs) [20:57:16] <BBB> x=rdft(lpcs); <- now what is x, except for some very complex set of numbers? [20:58:19] <peloverde> increasing indicies in the RDFT represent sines and cosines of increasing frequency [20:59:11] <Kovensky> [mp3 @ 0x8844460]max_analyze_duration reached <-- any harm? [20:59:28] <peloverde> So if you took the RDFT and multiplied it by function that decreased in value as index increased, you would put more emphasis on low frequencies and less on high frequencies [20:59:35] <Kovensky> elenril: TYER: 2009 <-- what [21:00:00] <peloverde> that's called frequency domain filtering [21:00:46] <BBB> that's the name of one of the functions here!!!!! [21:00:49] <BBB> I think [21:00:59] <BBB> (i.e. you're genious) [21:01:22] <BBB> "filterframefrequencydomain" [21:02:19] <peloverde> glad to help [21:09:07] <elenril> Kovensky: ? [21:09:59] <Kovensky> elenril: it's showing "TYER" instead of "date" (mp3 demuxer) [21:10:10] <elenril> ah [21:10:22] <elenril> blame me for being lazy/busy [21:33:22] <Kovensky> I also noticed that some demuxers export metadata all lower, some others all upper [21:33:34] <Kovensky> (metadata names, not values) [21:33:59] <elenril> export means before or after conversion? [21:34:19] <Kovensky> whatever mplayer prints when you use -demuxer lavf :P [21:35:09] <elenril> metadata system is mostly case insensitive [21:36:31] <elenril> generic keys in the conversion tables are lowercase, so converted tags would be lowercase [21:36:36] <Kovensky> and I see that flac still can't tell / seek :( [21:36:45] <elenril> blame jruggles [21:37:01] <elenril> he said it's on his todo list :) [22:48:59] <CIA-90> ffmpeg: michael * r21925 /trunk/libavformat/mov.c: [22:48:59] <CIA-90> ffmpeg: Do not attempt to open references through absolute pathes. [22:48:59] <CIA-90> ffmpeg: This would allow an attacker to test remotely if a local file exists. [22:58:11] <CIA-90> ffmpeg: michael * r21926 /trunk/libavformat/mov.c: [22:58:12] <CIA-90> ffmpeg: Make sure we dont write more bytes into filename than the array is long. [22:58:12] <CIA-90> ffmpeg: just a precaution in case the size of the source array is increased or [22:58:12] <CIA-90> ffmpeg: made dynamically allocateable.

1 0

IRC log for 2010-02-19
by irc＠mansr.com 20 Feb '10

20 Feb '10

[00:00:16] <mru> if speed matters you should use asm [00:00:27] <Dark_Shikari> we only have inline asm on x86 atm [00:00:47] <mru> sometimes inline asm is the best solution [00:01:17] <Dark_Shikari> hmm. michael's idea seems to hurt in x264. [00:02:02] <Dark_Shikari> in fact, michael's idea would hurt in ffmpeg if ffmpeg had inline SIMD like x264 did [00:02:05] <Dark_Shikari> for that code [00:02:11] <Dark_Shikari> we use simd for the following [00:02:12] <Dark_Shikari> MIN(((x+28)*2184)>>16,2) = (x>2) + (x>32) [00:02:20] <Dark_Shikari> on two values at once [00:02:28] <Dark_Shikari> left side is simd, right side is C [00:10:25] <astrange> the snowll regression test works with gcc-svn now. used to break with an aliasing bug [00:10:37] <astrange> i think gcc fixed that and not av_alias, though [00:15:40] <mru> r21876: http://fate.multimedia.cx/index.php?build_record=183656 [00:15:55] <mru> r21882: http://fate.multimedia.cx/index.php?build_record=183753 [00:16:02] <mru> same compiler [00:18:28] <Dark_Shikari> toldyaso [00:18:34] <mru> also http://fate.multimedia.cx/index.php?build_record=183523 and http://fate.multimedia.cx/index.php?build_record=183617 [00:19:06] <mru> or are you saying mike just happened to update the compiler between those commits *and* forgot to update the description in fate? [00:20:16] <astrange> oh, did you use it in copy_block? [00:20:36] <mru> I added the aliasing stuff to all the AV_RW and AV_COPY macros [00:20:50] <mru> so anything that uses those might have been affected [00:34:06] <astrange> oh, i thought copy_block wasn't using AV_RN, but it seems like it is, so that was it then [00:36:38] <Dark_Shikari> is there seriously no mmx multiply bytes instruction? :/ [00:38:46] <Kovensky> <&jfs> still the best constant name in vsfilter: [00:38:46] <Kovensky> <&jfs> static const __int64 _00ff00ff00ff00ff = 0x00ff00ff00ff00ffi64; [00:39:22] <Dark_Shikari> awesomes. [00:45:15] <Dark_Shikari> my god [00:45:29] <Dark_Shikari> a customer with... wait for it... svn 7760 [00:45:34] <Dark_Shikari> reporting a problem with mp4 muxing [00:45:48] <mru> that's x264 I hope [00:46:08] <Dark_Shikari> ffmpeg [00:46:16] <astrange> only 3 years old [00:46:17] <mru> ffmpeg 7760?!?!?!? [00:47:18] <mru> 1406 files changed, 312398 insertions(+), 159653 deletions(-) [00:47:27] <Dark_Shikari> lol [00:47:36] <mru> that's like... everything [00:49:31] <mru> on movenc.c: 963 insertions(+), 544 deletions(-) [02:38:00] <CIA-90> ffmpeg: michael * r21888 /trunk/libavcodec/h264_cabac.c: Get rid of a local variable, 10 cpu cycles faster. [03:11:18] <CIA-90> ffmpeg: michael * r21889 /trunk/libavcodec/h264_cabac.c: get rid of an if() 1 cpu cycle faster. [03:11:41] <mru> lol [03:13:08] <BBB> he's trying really hard [03:13:10] <BBB> that's good [03:13:29] <BBB> how do I resolve timestamps for audio encoding? [03:13:49] <BBB> e.g. I call av_encode_audio(), where do I store the input data timestamp and how do I read it out once it gets returned? [03:14:30] <mru> you close your eyes and wave your hands around a lot [03:16:00] <BBB> why don't we change the function prototype to take a AVPacket, like av_encode_video17()? [03:16:18] <astrange> isn't encoding video wrong too? [03:16:27] <mru> that's scheduled for avcodec_encode_audio42() [03:16:42] <astrange> you have to check avctx->returned_packet.pts afterwards instead of it returning something with a reordered_opaque [03:16:54] <Dark_Shikari> good thing we don't have audio b-frames yet [03:17:04] <mru> why is that? [03:17:57] <BBB> astrange, well, yes, maybe, but at least for video there is coded_frame->pts, which is better than nothing [03:18:05] <BBB> AAC encoding caches several audio frames [03:18:31] <BBB> so I need to know how many hands to wave, and how long [03:18:35] <BBB> and whether to close 1 eye or 2 [03:20:54] <CIA-90> ffmpeg: mru * r21890 /trunk/libavutil/ (intreadwrite.h tomi tomi/intreadwrite.h): TOMI: 16- and 32-bit intreadwrite functions [03:21:50] <Dark_Shikari> TOMI? [03:22:01] <mru> a new cpu [03:22:39] <Dark_Shikari> by who, for what? [03:22:42] <Dark_Shikari> what class of cpu? [03:24:52] <mru> see patent US 2007/0192568 A1 [03:25:00] <Dark_Shikari> I know, but who is actually making it? [03:25:19] <mru> Russell Fish [03:25:27] <Dark_Shikari> 4-bit access to registers? [03:25:34] <Dark_Shikari> I mean who is MAKING it [03:25:35] <Dark_Shikari> i.e. fabbing it [03:25:53] <mru> it doesn't exist in silicon yet [03:26:06] <Dark_Shikari> why are we committing stuff for a chip that doesn't exist in silicon? [03:26:14] <mru> $$$ [03:26:22] <Dark_Shikari> wait, is he paying you? [03:26:25] <mru> yes [03:26:27] <Dark_Shikari> .... lol [03:26:39] <Dark_Shikari> paying you to optimize for a chip that doesn't exist yet [03:26:48] <Dark_Shikari> with a patent application that looks like a restatement of the past 20 years of chip design [03:26:53] <mru> his problem, not mine [03:27:02] <Dark_Shikari> I know, I just find it hilarious [03:27:34] <Dark_Shikari> so, how much are you getting for this? and what else is involved? [03:27:36] <Dark_Shikari> simd? [03:27:57] * Dark_Shikari doesn't see simd in that chip [03:28:44] <Dark_Shikari> does the chip even exist in _simulation_ yet? [03:28:49] <mru> yes [03:28:51] <Dark_Shikari> or it just a vague design doc [03:28:56] <mru> I have a simulator [03:29:32] <mru> there are more docs available that I can't show you [03:30:18] <mru> that code I committed doesn't reveal anything that isn't in the patent document [03:30:32] <Dark_Shikari> is there simd? [03:30:49] <Dark_Shikari> also, as it happens, I know another developer who is developing for a mystery chip under mysterious circumstances [03:30:52] <Dark_Shikari> I wonder if it's the same one [03:31:07] <mru> anyone I'd know? [03:38:49] <ohsix> tomi-vac! this fish guy sounds a bit off too; more power to you [03:39:34] <ohsix> claims to have invented email too? [03:39:44] <Dark_Shikari> lol [03:40:43] <ohsix> http://www.dallasobserver.com/2007-11-15/news/crazy-fish-story/print [03:41:22] <Dark_Shikari> lol, he's nuts [03:44:06] <astrange> how did they fit something that long in the paper? [03:46:27] <ohsix> papers have pretty small print [04:07:48] <kierank> that guy is brilliant [05:31:49] <Yuvi> mru: idct_row4_pld_neon <- isn't the data from MC already in L1 cache? [05:32:10] <Yuvi> or is there a penalty for L2 miss on store? [06:31:35] <elenril> http://games.slashdot.org/story/10/02/19/008216/Switzerland-Pursues-Violent… wait, what? [06:35:47] <astrange> ramiro: http://ffmpeg.arrozcru.org/wiki/images/d/dd/Ffmpeg_r15966_static_pthreads.d… what happens without the atexit()? [06:58:03] <elenril> and some HD videos encoded in AVC or h.264 formats. << lol@slashdot [06:58:39] <kshishkov> you mean "you netbook can play 1080i H.264 with CoreAVC"? [06:58:45] <elenril> yes [06:58:53] <elenril> morning btw [06:59:00] <kshishkov> morning [06:59:13] <kshishkov> as one of CoreAVC developers may say "bollocks" [06:59:52] <pJok> mornings [06:59:59] <kshishkov> goda morgnar [07:00:12] <thresh> moroning [07:00:15] <av500> guten morgen [07:00:22] <benoit-> ditto [07:00:42] <CIA-90> ffmpeg: kostya * r21891 /trunk/libavformat/Makefile: [07:00:42] <CIA-90> ffmpeg: WavPack demuxer supports ID3v1 tags, so don't forget id3v1.o dependency for it [07:00:42] <CIA-90> ffmpeg: in Makefile [07:01:36] * elenril wonders if he should add id3v2 reading for everything [07:01:47] <av500> you have id3 in asf covered? [07:01:56] <elenril> no [07:01:59] <kshishkov> no, I'd like ID3 _removed_ from everything [07:02:05] <elenril> it was threatening my sanity [07:02:16] <elenril> (at least what's left of it) [07:02:27] <kshishkov> having ID3 tags before actual file data is idiotic too [07:03:39] <elenril> how would you design a metadata format usable for all/most containers? [07:04:13] <kshishkov> as a text block [07:04:25] <elenril> placed where? [07:04:41] <kshishkov> in "metadata" chunk supported by format [07:05:24] <av500> well, id3v2 in asf is stored at a proper place [07:05:39] <elenril> is it even standardised? [07:06:06] <elenril> asf specs don't mention id3 at all [07:06:17] <av500> elenril: as usual, not std, but used widely [07:06:24] <elenril> orly [07:06:48] <av500> iirc musicmatch jukebox did it that way [07:08:32] <kshishkov> it could be somebody's hack for WMA [07:09:05] <elenril> well if everybody does it like that file i saw yesterday [07:09:17] <elenril> then we're better off not supporting it [07:09:35] <av500> elenril: url? [07:10:44] <elenril> http://filebin.ca/skhpks/error_while_opening2.wma [07:11:01] <elenril> basically it has normal asf tags intermixed with id3 tags [07:11:31] <elenril> id3 tags have ID3/tagname in utf-16 as a key [07:11:53] <elenril> and an array of [TAG, VALUE] in utf8 as value [07:12:20] <kshishkov> so it's probably a hack for some MP3 player [07:13:55] <av500> elenril: http://msdn.microsoft.com/en-us/library/dd743220(VS.85).aspx [07:14:11] <av500> "..If you want to use the ID3 tags as attributes rather than using the standard attribute names, add the prefix "ID3/" to the tag name..." [07:14:30] * av500 must add that since he now has a sample file... [07:15:04] <elenril> that doesn't excuse the way they are stored [07:17:16] <av500> elenril: yes, you are right, this is crazy [07:27:45] <elenril> anyone knows how metadata in mov works? [07:28:01] <Yuvi> which scheme? [07:28:27] <elenril> scheme? [07:28:54] <Yuvi> itunes, quicktime, and base isom defined a third that noone uses outside of 3gp (not 3gp2) [07:29:08] * elenril facepalms [07:29:54] <elenril> are specs for those available somewhere? [07:31:21] <Yuvi> you can get 3gp from somewhere, itunes isn't really documented (the QT 7.0 headers promised it was coming... in 2006), the quicktime might be documented somewhere [07:31:54] <superdump> there's a publically available qtff.pdf that might have some info in it [07:31:55] <elenril> also it seems mov demuxer doesn't export everything [07:32:09] <elenril> i wonder if there's any reason for that [07:32:10] <superdump> http://developer.apple.com/documentation/quicktime/QTFF/qtff.pdf [07:32:33] <Yuvi> mm, apple broke that link [07:32:49] <superdump> they did? [07:33:06] <superdump> they did [07:33:08] <superdump> hrm [07:36:08] <astrange> http://multimedia.cx/mirror/qtff-2007-09-04.pdf [07:36:12] <Yuvi> http://www.mediafire.com/?ggzzomtmxey because I don't feel like searching developer.apple.com [07:36:24] <Yuvi> that works too [07:36:57] <Yuvi> look for "user data" [07:37:06] <superdump> http://developer.apple.com/mac/library/documentation/QuickTime/QTFF/QTFFPre… [07:37:49] <superdump> there's a pdf button in the top-right [07:37:57] <superdump> if you click on that you can download the current pdf [07:38:31] <Dark_Shikari> hmm, mpeg-2 has a fullpel mode? [07:47:28] <av500> err, gg opening vp8 next week is that speculation or real news? [07:50:02] <Dark_Shikari> gg? [07:50:11] <Dark_Shikari> that sounds like crazy speculation from slashdot [07:51:21] <av500> GooGle [07:51:25] <KotH> moin boys [07:52:34] <benoit-> salut KotH [07:52:58] <av500> 'jour [08:07:57] <CIA-90> ffmpeg: thilo.borgmann * r21892 /trunk/libavcodec/alsdec.c: Do sequential bit reading outside of []-operators. [08:18:42] <astrange> http://www.bluishcoder.co.nz/2010/02/19/comparing-colour-space-conversion-l… [08:22:43] <kshishkov> sounds a bit suspicious [08:23:16] <Dark_Shikari> swscale is not very fast [08:23:19] <Dark_Shikari> it only has mmx [08:23:31] <superdump> astrange: i'd post that to the ml [08:23:45] <Dark_Shikari> but the gap is too large. probably different resizing methods being used. [08:23:56] <Yuvi> maybe no --enable-gpl? [08:24:01] <Dark_Shikari> oof. that could be it [08:24:06] <Dark_Shikari> probably should comment about that [08:24:16] <astrange> i'll post it somewhere else if he does what i already commented [08:24:42] <Dark_Shikari> should probably make a note there about the GPL bit though... [08:25:24] <astrange> which parts of sws are GPL still? [08:25:32] <Dark_Shikari> the asm! [08:25:32] <Yuvi> all x86 asm, I think that's it [08:25:33] <Dark_Shikari> lol [08:25:36] <astrange> ah [08:25:39] <av500> doesnt X have like hardware yuv overlays? [08:25:47] <astrange> i thought it was just yuv<>rgb, then i could replace http://trac.perian.org/browser/trunk/ColorConversions.c with it [08:26:09] <Dark_Shikari> av500: this is mozilla, doing things right is against their code of conduct [08:26:21] <av500> Dark_Shikari: ah [08:26:52] <bilboed> or maybe it's time to relicense the GPL parts of libswscale [08:26:57] <Yuvi> can you even blend hardware yuv overlays with web pages? [08:27:07] <astrange> you can do rendering in GL [08:27:08] <Yuvi> except via shaders of course [08:27:12] <av500> Yuvi: probably not [08:27:16] <Dark_Shikari> Yuvi: most of the time you don't have to [08:27:23] <CIA-90> ffmpeg: thilo.borgmann * r21893 /trunk/libavcodec/Makefile: Add the dependency for mpeg4audio.o of the ALS decoder. [08:28:22] <Dark_Shikari> of course, mozilla would never use anything GPL [08:28:28] <Dark_Shikari> even LGPL seems to be against their credo [08:28:41] <bilboed> oh right, mozilla [08:35:19] <astrange> theora uses jpeg chroma siting? [08:35:24] <astrange> i guess mpeg1 did too [08:36:39] <Yuvi> h.263 too actually [08:38:39] <kshishkov> everything else with old swscale as well ;) [08:42:51] <Dark_Shikari> astrange: wait, C1x? [08:43:19] <Dark_Shikari> oh wow. they are actually doing it. [08:46:13] <KotH> what's so astonishing about that? [08:48:07] <superdump> Dark_Shikari: you have a post on your blog about orc don't you? [08:48:12] <superdump> i'm struggling to find it [08:48:37] <superdump> the in-page search doesn't find it it seems [08:53:15] <andoma> hm, does anyone know where I can find matrixes for converting various colorspaces to RGB ? [08:53:30] <kshishkov> almost everywhere [08:53:52] <andoma> my google fu must be bad [08:54:31] <kshishkov> http://www.fourcc.org/fccyvrgb.php [08:54:54] <kshishkov> http://en.wikipedia.org/wiki/YUV [08:56:01] <andoma> right, thanks [09:01:08] <Dark_Shikari> superdump: no I don't [09:01:14] <superdump> hmm [09:01:16] <superdump> weird [09:01:25] <superdump> i remember reading an article about someone bashing orc a while ago [09:01:37] <superdump> mru: was it you then? did you write an article about orc? [09:02:15] <Dark_Shikari> I don't know enough to write about it [09:02:23] <Dark_Shikari> all I know is that it's probably the best platform-generic simd method [09:02:31] <Dark_Shikari> which isn't hard, considering the only other one I know is gcc vector types [09:04:14] <pengvado> gcc vector types. which define only the operations +-*~|&^ [09:05:18] <superdump> apparently the framewave (amd) yuvtorgb uses sse2 and is multi-threaded [09:05:58] <Dark_Shikari> pengvado: and even then don't usually do them very well [09:06:05] <superdump> it seems like most of their stuff does [09:06:06] <superdump> http://framewave.sourceforge.net/Manual/fw_function_020_0060_00070.html#fw_… [09:07:52] <Dark_Shikari> lol @ inability to specify bt.601 vs 709 [09:08:00] <Dark_Shikari> sure swscale sucks too but we knew that [09:09:35] <kshishkov> patchiswelcome [09:42:34] <iive> Dark_Shikari: did you happen to find the swap for abs of 2 short values in int register? [09:42:37] <iive> swar [09:43:40] <Dark_Shikari> ended up being better to do it a different way that didn't require that [09:43:42] <Dark_Shikari> but I'm still curious [09:44:11] <kshishkov> what about usual sources? [09:45:36] <Dark_Shikari> ? [09:45:56] <kshishkov> aggregate.org, TAoCP, HAKMEM [09:46:22] <Dark_Shikari> very little swar on most of those [09:47:39] <iive> i was trying to do something with the abs forumula a=(a^mask)-mask; the tricky part is getting the mask [09:48:11] <Dark_Shikari> yeah [09:48:15] <Dark_Shikari> that's the problem [09:48:34] <kshishkov> ((val & 0x8080) >> 7) * 0xFF [09:48:59] <iive> multiply instead of if :) [09:49:27] <Dark_Shikari> kshishkov: heh. probably slower than 2xabs that way [09:49:32] <Dark_Shikari> you'd need 4 elements to make it worth it. [09:50:06] <kshishkov> TAoCP contains totally branchless sorting algorithm. The only catch it's O(n^3) [12:37:31] * twnqx wonders if itunes can import flac... [12:37:44] <kshishkov> probably not [12:37:52] <av500> it likes ALAC more [12:38:22] <twnqx> i have a choice of (tta and ape with cue) or flac [12:38:23] <twnqx> :S [12:38:43] * av500 wonders what happened to MP3 files..... [12:39:02] <twnqx> they died the death of "too low quality, and we have the disk space now" [12:39:11] * Kovensky foobar2000 (v1.0): Soilwork [2003 Figure Number Five #03] Figure Number Five [0:18/3:12] 192kbps MP3 CBR <-- unfortunately not dead enough yet [12:40:33] <av500> twnqx: disk space is for raw YUV! :) [12:40:40] <Kovensky> y4m \o/ [12:40:51] * twnqx uses lossless h.264 for that purpose [12:42:16] <Honoome> twnqx: convert from flac to alac :) [12:42:16] <Honoome> and in the mean time, fix the map_meta_data for me :D [12:42:25] <twnqx> Oo [12:42:44] <twnqx> i didn't even know about ALAC's existance... [12:43:00] <Honoome> twnqx: it's the Apple Lossless Audio CodecâŠ performs about the same as FLAC afaics [12:43:12] <Honoome> but uses m4a as container format rather than flac's braindamaged one so can't be too bad :D [12:43:13] <mru> it's 90% the same codec as flac [12:43:32] <mru> same basic algorithms [12:43:50] <mru> a few minor differences and different bitstream syntax [12:44:25] <Honoome> but a saner container (and saying that mp4 is saner than something else is to say a lot) [12:44:39] * Honoome has all his lossless content in ALAC for interoperability [12:45:07] * Kovensky has almost all of his lossless content in wavpack [12:45:16] <mru> raw flac is pretty hellish to deal with [12:45:30] <kshishkov> try MP3 then :P [12:45:42] <twnqx> can ipods play alac? [12:45:43] <Honoome> Kovensky: I used to have that, but WavPack is a bit far-fetched for most users :( [12:45:49] <Honoome> twnqx: yup [12:45:59] * twnqx is sold on converting [12:46:26] * twnqx wonders if audacious can play alac, though [12:46:49] <Honoome> -map_meta_data works with a twist: current ffmpeg does not set the author/artist mapping correctly :P and the culprit just fled! ;) [12:47:01] <twnqx> :S [12:47:10] <twnqx> so i have to find something else to convert, thanks for the hint [12:47:12] <Honoome> which reminds me I have to find how to fix that so I can convert the rest of my magnatune downloads [12:47:41] <Honoome> twnqx: just use an older version of ffmpeg if you don't want to fix it âŠ or to get elenril to fix itâŠ or wait for me to find the time to fix itâŠ [12:47:45] <twnqx> so who's wrong, the flac reader or the alac writer? [12:47:55] <Honoome> the mov/mp4 muxer [12:48:07] <twnqx> uh. [12:48:20] <twnqx> how old do i have to use? :P [12:48:33] * elenril blames Kovensky for everything [12:48:52] <elenril> and people who wrote mov specs [12:49:09] * Kovensky redirects blame to movax [12:49:55] <Honoome> twnqx: 20601 worked fine [12:50:06] <Honoome> 21602 had that bug [12:50:18] <Honoome> elenril might know the exact revision that broke it ;) [12:50:25] * twnqx has 21013 on disk [12:50:31] <elenril> its' not a bug, it's a feature [12:50:37] <twnqx> :S [12:51:12] <Honoome> elenril: is it just a matter of sed -i -e 's:"author":"artist":' in the movenc.c file? :) [12:51:22] <elenril> yes [12:51:32] <Honoome> ghaaaa :P [12:51:47] * elenril wanted to write a proper metadata conv table for mov [12:51:54] <elenril> but it turned out to be :effort: [12:52:08] <Kovensky> everything is :effort: [12:52:12] <Kovensky> it's one of the rules of the universe [12:52:22] <elenril> yeah, exactly [12:52:40] <elenril> it's called principle of least :effort: [12:52:41] * Honoome sends the patch to the list, sure that people will kill him for that :D [12:53:03] <elenril> http://en.wikipedia.org/wiki/Principle_of_least_action [12:53:20] <twnqx> test it first :P [12:54:21] <Honoome> twnqx: right :D [12:56:22] <merbzt> elenril: did baptiste nix the changes ? [12:58:05] <twnqx> mov_write_string_metadata(s, pb, "\251ART", "author" , 1); <- sounds reasonable to change to artist... [12:58:30] <elenril> merbzt: did baptiste what? [12:58:41] <kshishkov> vetoed [12:58:45] <twnqx> elenril: why is ART in capitals, while all other tags are lovercase? [12:58:45] <kshishkov> draw a line [12:58:48] <twnqx> powercase* [12:58:57] <kshishkov> send them pining to the fjords [12:59:08] <elenril> no, michael suddenly changed author->artist overnight [12:59:17] <merbzt> :) [12:59:19] <elenril> and i forgot to adapt in a few places [12:59:41] <twnqx> he... changed that in one place only? wtf [12:59:41] <merbzt> please mista fix it [12:59:43] <elenril> twnqx: don't ask me, i don't know why is metadata in mov so braindead [13:00:10] <av500> elenril: to fit the overall scheme of mov [13:00:18] <elenril> sounds reasonable [13:01:12] <av500> what I dont understand is why it is kept in one place and not spread all over the file with some other atoms to tell you where to find it [13:02:04] <elenril> it's not? [13:17:51] <Honoome> elenril: uhm, may I ask you one thing because I'm definitely not into the metadata code myself? :) is there already a mapper between authorâartist for _reading_ metadata? [13:18:26] <elenril> in what? mov? [13:18:34] <Honoome> in av_metadata_set() [13:18:53] <elenril> not sure what you mean [13:19:13] <elenril> the demuxers are supposed to export metadata exactly as they are stored in the file [13:19:34] <Honoome> libavformat/mov.c:109: case MKTAG(0xa9,'A','R','T'): key = "author"; break; [13:19:38] <elenril> if the calling app wants to convert them into some other format, it calls av_metadata_conv [13:19:42] <Honoome> this is why I asked about it :) [13:20:02] <Honoome> and it seems like there are a couple of other places that use "author" still [13:20:08] <elenril> yeah, i know [13:20:22] <elenril> it's wrong, i just forgot about them [13:20:42] <Honoome> so they should all be updated to use artist? I might as well do that instead of just limiting to movenc.c :) [13:21:00] <Honoome> and I asked because libavformat/metadata_compat.c seems to be mapping authorâartist [13:21:18] <elenril> don't look at metadata_compat ;) [13:21:39] <Honoome> ooookay :) [13:21:54] <elenril> and yeah, most of those should be changed to 'artist' [13:22:24] <twnqx> can you push a fix like... today? :X [13:24:50] <elenril> sure, right after i figure out why is my ca invalid [13:26:29] <Honoome> twnqx: fwiw 21586 is the last one that will work correctly until it's all fixed :P [13:26:32] <Honoome> I'll send a patch soonish [13:32:40] <Honoome> mail sent :) [13:32:47] <twnqx> still busy PRODUCING the flacs... [13:32:58] <twnqx> fighting with character sets [13:33:09] <twnqx> e.g. this one... it's *rage* [13:33:16] <twnqx> cat in a unicode enabled shell show kanji [13:33:18] <Honoome> err producing from what? :) [13:33:21] <twnqx> .tta [13:33:28] <twnqx> occasionally .ape [13:33:33] <Honoome> ah cued? [13:33:37] <twnqx> yes [13:33:55] <twnqx> maybe u16.... [13:34:29] <Honoome> twnqx: check what âlocaleâ says :P and what the shell is set to :) [13:34:40] <twnqx> ... utf [13:35:13] <twnqx> R.cue: UTF-8 Unicode (with BOM) text [13:35:17] <twnqx> hmmmmmmmm [13:36:39] <twnqx> so what happens... [13:37:56] <Honoome> elenril: I sent the patch to -devel ;) [13:38:22] * elenril reading [13:38:50] <elenril> asf changes are wrong [13:39:22] <elenril> it already has a conv table mapping author to artist [13:40:24] <twnqx> why would that be right? [13:40:29] <twnqx> they could actually differ :X [13:40:35] <Honoome> elenril: ahâŠ I missed that one [13:41:32] <Honoome> elenril: asfdec or asfenc? because afaics asfenc only gets author [13:41:37] <elenril> both [13:41:51] <elenril> asfdec exports author [13:41:53] <Honoome> so tell me the magic of the conversion table? [13:42:01] <elenril> av_metadata_conv then converts it to artist [13:42:26] <elenril> for muxing, you set artist, av_metadata_conv converts it to author [13:42:37] <elenril> asfenc writes author [13:42:46] <Honoome> aaah I see it now, sorry [13:45:10] <mru> wtf is G2M3? [13:45:13] <Honoome> elenril: new version [13:45:28] <kshishkov> mru: MPEG-4 variation with new fourcc? [13:45:38] <Honoome> mru: http://wiki.multimedia.cx/index.php?title=G2M3 [13:46:18] <mru> screen capture codec? [13:46:21] <kshishkov> Honoome: MultiMedia Wiki is write-only ;) [13:46:27] <kshishkov> video chat rather [13:46:32] <Honoome> kshishkov: hahaha :) [13:47:07] <mru> someone's offering an undisclosed amount of money for support in ffmpeg [13:47:11] <av500> mru: is that the required codec for TOMI? [13:47:55] <Honoome> TOMI? [13:48:00] <kshishkov> what does TOMI stand for? [13:48:24] <kshishkov> (it's obvious to be some embedded arch CPU) [14:06:30] <CIA-90> ffmpeg: kostya * r21894 /trunk/libavcodec/wavpack.c: [14:06:30] <CIA-90> ffmpeg: Since WavPack chunk can contain more samples than FFmpeg is guaranteed to [14:06:30] <CIA-90> ffmpeg: hold, decode it in several iterations outputting as many samples as possible. [14:07:08] <CIA-90> ffmpeg: kostya * r21895 /trunk/libavcodec/wavpack.c: cosmetics: reindent after last commit [14:47:25] <jez9999> BBB: hello [14:47:51] <av500> mru: so how long did 1 frame take? [14:48:38] <mru> about 6 minutes [14:48:50] <mru> 1920x1080 [14:49:50] <av500> so 10s/per day [14:50:13] <kshishkov> sounds fine even for hand-drawn animation [14:50:43] <av500> 60days for BBB [14:50:58] <av500> but that is only 1080p.... [14:51:47] <av500> kshishkov: we should animate an xkcd story, that can be drawn fast [14:52:24] <BBB> jez9999, hi [14:52:46] <BBB> av500, did you figure out the asf caption thing? [14:53:02] <av500> no, not yet [14:53:16] <av500> but I guess I need to 1st tell the server to send it to me... [14:53:32] <jez9999> BBB: checkin of the patch for issue 1740? :-) [14:53:41] <BBB> jez9999, will check [14:57:00] <BBB> astrange, can I bug you with aac encoding bugs? [14:57:40] <merbzt> regarding the G2M3 codec [14:57:52] <BBB> what's that codec anyway? [14:57:53] <merbzt> If you are using a Mac,Â download the Windows Media ComponentsÂ to view recorded meetings [14:58:03] <merbzt> http://www.microsoft.com/downloads/details.aspx?FamilyId=915D874D-D747-4180… [14:59:26] <merbzt> I have a hard time thinking that Flip4Mac would support it unless it is vc1 with some tricks [15:00:10] <merbzt> so does we have samples ? [15:02:33] <BBB> compn says yes [15:02:37] <Compn> whas [15:03:00] <Compn> v-codecs/g2m3 [15:03:35] <Compn> uncommon_video_codecs_final.txt [15:03:40] <Compn> also lists a ton of them merbzt [15:04:16] <merbzt> is the name g2m.dll ? [15:04:56] <Compn> g2m.dll is in samples/drivers32/nwe/ [15:04:58] <Compn> new* [15:05:17] <Compn> er G2M.dll [15:05:28] * Compn runs afk [15:20:38] <kshishkov> wow, G2M decoder is larger than both samples using it [15:21:04] <av500> maybe it has them both stored inside? [15:22:58] <merbzt> the decoder mentions inflate and rtp [15:23:05] <kshishkov> and fft [15:23:33] <merbzt> and aes [15:23:44] <kshishkov> and JPEG! [15:23:48] <kierank> so how do I map one avpacket to multiple streams? [15:24:11] <av500> map? [15:24:47] <merbzt> g729 [15:24:54] <kierank> map isn't the right word here but I couldn't think of a better one. Basically I need the AVPacket to be available to multiple streams [15:26:24] <av500> duplicate it? [15:26:34] <kshishkov> merbzt: g722 and g723 as well [15:27:03] <merbzt> kierank: I think you need to copy it [15:27:08] <kshishkov> merbzt: and amrwb and iLBC. Is that parody of FFmpeg? [15:27:12] <kierank> av500: is that possible when read_packet passes a pointer to one avpacket? [15:27:29] <av500> err [15:27:37] <av500> kshishkov: maybe it IS ffmpeg? [15:27:40] <merbzt> kshishkov: I think it is a complete sip client with the codecs [15:27:49] <merbzt> GIPS also :) [15:28:28] <kshishkov> indeed [15:28:36] <Honoome> av500: it just statically links in libavcodec :P [15:28:44] <kshishkov> hmm, it mentions MSS2 and WMV3 [15:30:05] <merbzt> kshishkov: can you try and see what happens with a sample ? [15:30:14] <merbzt> if it is feed though the wmv3 decoder ? [15:30:46] <kshishkov> it does not look like one and has own 14-byte header [15:31:15] <merbzt> hmm [15:31:20] <merbzt> VP71 [15:31:25] <justlooking> mru, apparently they do a simple cross platform blender farm called loki http://loki-render.berlios.de/index.php/docs/22-using-the-master and you can do tiled rendering if you prefer,should spped things up if you happen to have a few PC onthe LAN. [15:31:30] <kshishkov> yuck! [15:32:06] <mru> ram could be an issue [15:32:16] <mru> none of my other machines have >4GB [15:32:29] <mru> and some have only 2 [15:32:56] <av500> "...Rendering a small part of an image uses less memory. Useful if you don't have enough system memory for rendering the entire image. Note however that if you're trying to render high-resolution/complex images on 32-bit systems, you may still run into problems even with tile rendering...." [15:33:00] <mru> wonder how long it would take to render if I let the c2q churn away undisturbed [15:33:14] <janneg> justlooking: distributing scenes or frames is probably easier [15:33:34] <av500> janneg: but if we really want 6x1080p. slicing it per 1080p bit might make sense [15:34:19] <mru> the wall is 6x1280x1024 [15:34:32] <av500> mru: but we can only decode 6-x1280x720 [15:34:46] <mru> even smaller [15:34:53] <janneg> the commandline renderer was successful at 1080p, but still no luck at 3840x2048 [15:35:41] <mru> maybe I'll beat the c2q into shape again... [15:35:42] <av500> so, 3840x1440 [15:35:42] <janneg> doesn't that just depend on the video codec? [15:36:16] <av500> janneg: I guess raw YUV would be OK :) [15:36:33] <mru> av500: not enough storage bandwidth [15:36:34] <janneg> I was more thinking about mpeg2 [15:36:43] <mru> too high bitrate [15:37:09] <mru> high-res mpeg2 gets constrained by vlc decoding after a while [15:38:25] <kierank> how about making ffmpeg call read_frame multiple times but not moving the file pointer forward until the last stream is read? [15:39:22] <kierank> s/read_frame/read_packet [15:39:47] <av500> kierank: ? [15:41:16] <kierank> av500: it's because dolby e has a weird structure in that one "stream" as viewed by the container actually contains multiple separate streams [15:42:07] <kierank> but as I see it read_packet is designed only for reading one stream into one avpacket [15:42:09] <kshishkov> merbzt: whole G2M3 frame is 'G2M3' sig and some chunks pasted together. [15:46:07] <superdump> Dark_Shikari: ping? [15:46:56] <superdump> Dark_Shikari: how many 1080p streams can one encode with good quality in real time on an i7? [15:47:35] <av500> kierank: I guess you volunteer to implement demuxer chaining... :) [15:50:38] <jez9999> BBB: not seeing any progress on issue 1740 :-) [15:55:18] <BBB> jez9999, patience is a virtue [15:55:36] <janneg> rendering at 2720x1440 was succesfull with 4G [15:55:43] <merbzt> http://www.youtube.com/watch?v=EljaGpogiws [15:57:15] <merbzt> kshishkov: anyway, I think it is a MSSC then [15:57:31] <kshishkov> what's that? [15:57:42] <merbzt> M$ Screen Codec [15:57:51] <merbzt> forgot the 4cc [15:57:53] * kshishkov does not know a thing about it [15:59:04] <justlooking> superdump, "#videolan 17:37 <Dark_Shikari> x264 on "ultrafast" is 100 times faster than on "placebo ... Dark_Shikari> ultrafast is generally overkill ....Dark_Shikari> don't use it, its compression is awful ...Dark_Shikari> it _can_ get realtime 1080p on one core... Dark_Shikari> but you'd be insane to do it =p " so i guess you might get away with useing fast or faster! for 4 streams. [15:59:13] <merbzt> kshishkov: http://support.gotomeeting.com/ics/support/default.asp?deptID=5641 [15:59:22] <merbzt> look at the preferences text [16:02:05] <merbzt> the codec is something from the wmp9 suit [16:02:35] <kshishkov> from what I see it's either converts it to wmv9 or uses something own [16:03:32] <kshishkov> that's why it says wmv only for Mac [16:04:01] <merbzt> hmm [16:04:12] <merbzt> but the prefe [16:04:35] <merbzt> preferences image said that with wmp9 you didn't need any codec [16:04:47] <kshishkov> yes, but it converts then [16:05:42] <merbzt> MSS2 [16:05:48] <merbzt> that's what I think it is [16:10:36] <kshishkov> unlikely - I'm pretty sure it won't play on Mac either [16:12:16] <merbzt> kshishkov: I think we should bicker about this for the rest of the evening, that would be good use of the time [16:12:46] * kshishkov is upgrading Flip4Mac to test [16:13:04] <merbzt> ahhh, you even has a mac to test with cool [16:13:25] <kshishkov> my primary workhorse - MacMini with PowerPC [16:14:33] <av500> kshishkov: I didnt know they ship all the obsolete tech to .ua [16:15:17] <kshishkov> av500: where does it end then? But I've bought it when Apple hasn't even thought about Intel CPUs [16:15:44] <av500> kshishkov: I thought they ship it to japan as landfill [16:15:50] <kshishkov> it was a few months before I got CVS writing access on FFmpeg actually [16:17:56] <kshishkov> av500: nah, otherwise KotH would have disguised himself as IBM PCjr [16:27:12] <CIA-90> ffmpeg: rbultje * r21896 /trunk/libavformat/ (rtsp.c rtsp.h): [16:27:12] <CIA-90> ffmpeg: Rename RTSP_STATE_PLAYING to _STREAMING, since that better covers the [16:27:12] <CIA-90> ffmpeg: future use of the rtsp* codebase for RTSP muxing. [16:27:12] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>. [16:46:26] <av500> BBB: http://pastebin.ca/1802786 [16:46:50] <av500> thats what I get in the caption stream [16:49:51] <ramiro> astrange: for static ffmpeg.exe, I think nothing... It's probably similar to not calling WSACleanup(). btw I'm using this patch for pthreads-win32 now http://ffmpeg.pastebin.com/m5c6f5164 . This way it links both with mingw and msvc. [16:50:12] <BBB> jez9999, almost there with your patch [16:56:27] <BBB> av500, that looks about right [16:56:54] <BBB> av500, now, is there anything in the stream header that allows us to assign a codecid to this stream? I mean anything? [16:57:14] <BBB> right now it's CODEC_TYPE_DATA with CODEC_ID_NONE [16:57:17] <BBB> which isn't useful [16:57:33] <BBB> I want it to be CODEC_TYPE_SUBTITLE With CODEC_ID_SPECIALTEXTFORMAT [16:57:33] <BBB> or so [16:58:52] <av500> :) [16:59:06] <av500> yes, I just asked my self the same thing in my own asf/mms handler :) [17:05:38] <ramiro> can anyone help me understand juan gonzales' second response to the thread here: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/dm3x/f/100/p… [17:07:05] <mru> he's saying the low-level functionality is exposed by vicplib but the TI codecs implemented on top of that are available as binaries only [17:07:06] <ramiro> there must be a way to call the optimized hardware directly for the codec-specific optimized functions. or are there no such functions? (vicplib only contains generic math optimizations) [17:07:56] <av500> ramiro: ? [17:08:05] <av500> he says no source code for the codecs [17:08:27] <av500> although the codecs mostly use the hw accell, they do not provide the source [17:08:36] <ramiro> ah, ok... I just don't think that's what I asked =) [17:08:42] <av500> but you could use the hw accells to make your own codecs [17:09:27] <av500> but what do you mean with: "From the current vicplib I don't see any codec-specific optimization." [17:09:43] <ramiro> in lavc we have a bunch of h264 specific optimizations for example [17:12:16] <av500> ramiro: right, I never looked deeply into the viclib [17:12:44] <av500> could well be that ti did just a token effort there and did not include any of the highly specific stuff [17:14:21] <av500> ramiro: and yes, TI engineers are very skilled in not answering your questions [17:18:10] <CIA-90> ffmpeg: stefang * r21897 /trunk/libavcodec/ (indeo5data.h indeo5.c): remove ivi5_scans8x8[0], it duplicates ff_zigzag_direct [17:18:21] <Honoome> av500: hahaha that's quote-worthy! :D [17:20:32] <Rathann|work> Honoome: there's a quote collection page on the wiki, feel free to contribute [17:21:57] <ramiro> I wonder what TI means by "natural C". [17:22:35] <av500> organic C [17:23:48] <CIA-90> ffmpeg: vitor * r21898 /trunk/libavcodec/Makefile: Add missing dependency of TwinVQ [17:27:23] <CIA-90> ffmpeg: rbultje * r21899 /trunk/libavformat/rtsp.h: [17:27:23] <CIA-90> ffmpeg: Remove stale function declaration. [17:27:23] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>. [18:32:50] <Compn> mru : does your ppc box have osx on it ? [18:33:05] <mru> no [19:15:18] <BBB> peloverde, are you interested in aac encoder bugs? [19:15:51] <kshishkov> on the contrary, he is interested in bugfree encoder [19:16:07] <BBB> I could hand him bugs, he could then fix 'em [19:16:12] <BBB> .. [19:16:13] <BBB> profit! [19:16:47] <peloverde> kind of, i have plans for the AAC encoder but they involve some degree of re-architecting [19:17:09] <kshishkov> you are in charge of it anyway [19:17:55] <peloverde> I am, but its on the back burner at the moment [19:18:33] <kshishkov> indeed [19:19:01] * kshishkov is trying to sneak a codec into FFmpeg instead of improving AAC encoder too [19:19:47] <peloverde> In my defense HE-AAC dec has been on the wishlist for a while [19:20:10] <peloverde> plus there was well defined money on the table [19:21:21] <kshishkov> nobody care[sd] about Bink [19:21:41] <kshishkov> still, somebody has to RE those codecs [19:22:24] <peloverde> the RDFT for bink wound up being useful in SBR [19:22:33] <Dark_Shikari> I'm just surprised the price for HE-AAC was so low [19:22:42] <Dark_Shikari> by comparison there's probably at least $20k on the table for MBAFF support in x264 [19:22:47] <Dark_Shikari> and you could scrounge up more pretty easily [19:23:04] <kshishkov> someone should optimize it too - Bink audio decoder is usually thrice CPU-hungry as Bink video [19:23:41] <peloverde> The bulk of it was already written when i started on it [19:24:01] <kshishkov> IIRC Rob also got something for it [19:25:06] <peloverde> also it's essentially re-writing something under a more liberal license [19:25:28] <kshishkov> heh [19:25:37] <peloverde> Most people who need HE-AAC can use FAAD under the GPL or buy a commercial license [19:25:46] <BBB> peloverde, ok, so basically I gather from that that it's interesting, but no thanks? [19:25:57] <Dark_Shikari> well, faad sucks [19:26:07] <BBB> all external libs suck [19:26:09] <kshishkov> BBB: interesting but not now [19:26:09] * BBB winks @ x264 [19:26:15] <Dark_Shikari> btw, we have the x264 contribution agreements almost done [19:26:16] <BBB> kshishkov, got it [19:26:17] <Dark_Shikari> got almost all the rights [19:26:21] <peloverde> BBB: It'd be nice to see them but there are no guarantees on a timeframe for fixing them [19:26:27] <Dark_Shikari> so if we get sales going soon... maybe we could fund some aac improvements ;) [19:26:30] <BBB> http://www.wired.com/images_blogs/underwire/2010/02/googlesauron.png [19:26:46] <peloverde> I wouldn't spend a lot of time doign fancy bugreports but if you know the gist of something it'd be good to see [19:27:00] <BBB> nah, don't want to distract you too much [19:27:02] <BBB> I'd feel bad about it [19:27:12] <BBB> particularly because I'm not doing anything useful right now [19:27:37] <peloverde> If you want to make yourself useful write an SSE RDFT :) [19:27:37] <kshishkov> work on multirate RM ;) [19:28:21] * BBB cries [19:28:36] <BBB> I thought if I go into NGO-related stuff, I'd get rich and famous without any effort [19:29:20] <kshishkov> yes, just wait [19:29:47] * kshishkov could live without fame [19:45:21] <iive> BBB: if you want to get rich without any effort, make your own bank [19:55:18] <peloverde> I'd rather get rich working on FFmpeg [19:56:21] <peloverde> BBB: were these any of the patents you had been told about? http://www.0xdeadbeef.com/weblog/2010/02/some-additional-information-about-… [20:00:20] <Compn> kshishkov : did you get a chance to play disc golf in sweden? http://www.youtube.com/watch?v=nhxqHH6_2c0 [20:00:47] <kshishkov> Compn: I'm not into sports completely [20:03:22] <Compn> ah but this sport you can play by yourself ... [20:05:06] <kshishkov> there are more interesting things to do in Sweden [20:05:57] <pJok> kshishkov, like look at swedish girls? ;) [20:06:38] <BBB> peloverde, is that diego's thing? [20:06:52] <peloverde> Yeah, I just realized that [20:07:07] <BBB> peloverde, anyway, that's work-in-progress [20:07:26] <BBB> hopefully soon know more [20:07:36] <kshishkov> pJok: for we it's merely walking around. Swedish beauty is not limited to girls only. There's also scenery and architecture. [20:07:47] <pJok> true [20:07:53] <peloverde> I've never really understood the dates thing, when they bring out their list of MPEG patents they have stuff hat was filed well after the standard was published [20:08:05] <pJok> i should know, i live in a city older than many countries [20:08:48] <pJok> in two years they are celebrating the 600th year of Landskrona [20:09:07] <pJok> or was it three.. [20:09:15] <pJok> i think it was three actually [20:09:43] <kshishkov> here it was 350 years several years ago [20:10:04] <pJok> Helsingborg is even older [20:10:57] <kshishkov> my sources told me it's also better than Helsingor [20:11:04] <pJok> it is [20:11:33] <pJok> the only thing Helsingør is good for is cheaper liquor [20:11:55] <pJok> but the economics has put an end to that as well [20:20:32] <CIA-90> ffmpeg: vitor * r21900 /trunk/libavformat/dsicin.c: Fix memory leak for truncated frames [20:21:06] <CIA-90> ffmpeg: vitor * r21901 /trunk/libavformat/xa.c: Fix memory leak for truncated frames [20:43:59] <CIA-90> ffmpeg: stefang * r21902 /trunk/libavcodec/ (wmadata.h wma.h wmaenc.c Makefile wmadec.c): remove a Huffman table from WMA which also exists in AAC [20:45:56] <janneg> http://www.jannau.net/01_intro_01c.mkv first second of BBB in 2700x1440 for the videowall [20:49:08] <peloverde> hmm... the video isn't intelligible on my version of mpc [20:50:37] <janneg> doesn't play here either, xv overlay is limited to 2048x2048 [20:50:38] <peloverde> VLC doesn't seem to like it either [20:51:10] <janneg> I probably should upload the pngs [20:51:21] <peloverde> that would be nice [20:51:47] <Compn> can gl/gl2 handle it ? [20:51:51] <BBB> janneg? me? [20:51:57] * Compn doesnt remember gl max limit [20:52:00] <CIA-90> ffmpeg: daniel * r21903 /trunk/libavcodec/binkaudio.c: Fix compilation of binkaudio_rdft when dct is disabled [20:54:19] <janneg> http://www.jannau.net/peach_2700x1440/ [20:54:26] <_av500_> janneg: i have patched ffmeg for larger than 2048... [20:54:42] <janneg> BBB: no, sorry. Big Buck Bunny or peach [20:55:27] <_av500_> BBB: we also take video of you in 6x720p [20:56:03] <_av500_> janneg: wh 2700? [20:56:06] <_av500_> y [20:56:13] <Kovensky> Compn: IIRC gl depends on texture size limit; gl2 uses multiple textures [20:56:17] <janneg> Compn: -vo gl displays at least something, hard to say if it plays the video [20:56:57] <Compn> janneg : you probably need -vo gl:yuv=4 (with a modern video card) [20:57:31] <janneg> _av500_: 1440 / 2 / 4 * [20:57:33] <janneg> 5 * [20:57:45] <janneg> _av500_: 1440 / 2 / 4 * 5 * 3 = 2700 [20:57:56] <Compn> or latest svn mplayer might do autodetection, i forget now [20:58:15] <_av500_> janneg: it is 4:5? [20:59:57] <janneg> it's 15:8 which should be the aspect of the videowall, assuming the single displays are 5:4 [21:00:58] <_av500_> right [21:02:20] * _av500_ was confused [21:02:38] <_av500_> so, how long for 1s? [21:08:08] <janneg> 3 and a half hours real time on a core2duo 2GHZ, but the scene has low complexity [21:08:38] <CIA-90> ffmpeg: daniel * r21904 /trunk/libavcodec/Makefile: Declare CAF demuxer dependency on mpegaudio [21:08:43] <Dark_Shikari> how much memory did that need? [21:09:49] <janneg> scene 02 of the intro needs 20 minutes per frame on my phenom II quad 3GHz [21:10:36] <Kovensky> my computer can't render BBB, it would hit thermal shutdown before finishing a second :( [21:10:45] <janneg> Dark_Shikari: it wasn't oom-ed with 4G [21:11:13] <_av500_> janneg: i have a spare quad8800 here that is not used at all [21:11:28] <_av500_> and i7 can render at nights [21:12:07] <janneg> the commandline rendered has apparently better memory management [21:13:35] <CIA-90> ffmpeg: daniel * r21905 /trunk/libavformat/Makefile: AEA demuxer requires raw.o for pcm_read_seek [21:14:37] <janneg> _av500_: get the production files http://download.blender.org/peach/bigbuckbunny_production.torrent and install blender [21:15:38] <janneg> we need a way to coordinate who is rendering which scenes. I claim the intro [21:16:39] <peloverde> Do they not have any ultra high res reference renderings? [21:17:43] <peloverde> Also I see a few licensed Dolby E products so a spec must exist somewhere [21:21:20] * BBB goes crazy with all xchat pings on his screen [21:21:26] <BBB> can't they name that video something else? [21:21:49] <BBB> like CCC or so... or DDD [21:21:51] <CIA-90> ffmpeg: daniel * r21906 /trunk/libavcodec/Makefile: Declare WMV1 decoder dependencies [21:22:00] <janneg> we could try to use the code name "peach" [21:22:07] <iive> BBB: i thought you took your nick from it. [21:22:44] <janneg> OTOH BBB has tab completion [21:22:51] <janneg> ;) [21:23:41] <iive> isn't it about rabbit? [21:34:57] <BBB> av500, so did you get anything from that stream? [21:35:17] <Kovensky> so, what do you guys intend to do with BBB [21:35:36] <BBB> they want to cut me in pieces, then encode me with theora so I get all garbled up [21:35:39] <CIA-90> ffmpeg: daniel * r21907 /trunk/libavcodec/Makefile: msmpeg4v* encoders depend on h263dec [21:35:40] <BBB> or so [21:37:45] <Kovensky> BBB: D: [21:48:17] <kierank> <@peloverde> Also I see a few licensed Dolby E products so a spec must exist somewhere --> For many tens of thousands of dollars yes and with onerous licensing conditions [21:50:33] <kierank> I believe the licence forces you to use DRM on your decoder [21:53:36] <peloverde> once a spec is out there, you are going to start to find shoddy third party implementations with debugging symbols left on and whatnot [21:54:30] <Kovensky> one has to wonder if they don't do it on purpose [21:58:03] <kierank> They seem to be very selective about it. There are only 2 software decoders in existence afaik [21:58:43] <kierank> both with the same drm [21:58:48] <peloverde> There are probably 3 or 4 [21:58:55] <peloverde> the two third part ones [21:59:10] <kierank> there are ts analyzers that support it but i don't think they are full decoders [21:59:15] <kierank> third part? [21:59:22] <peloverde> *third party [21:59:32] <peloverde> and from what i understand when I was at 999 Brannan they should have at least two internal codebases [22:00:13] <kierank> because people from BBC i spoke to a while ago were looking for a software decoder but they said they could only find the two i know of [22:01:11] <peloverde> I think maybe we should skip dolby e and get a head start on dolby f [22:04:40] <kierank> wow there's an ac-2 [22:10:53] <CIA-90> ffmpeg: kostya * r21908 /trunk/libavformat/bink.c: Make Bink demuxer skip all zero audio tracks, not only the first one [22:14:08] <CIA-90> ffmpeg: kostya * r21909 /trunk/libavformat/Makefile: WavPack demuxer also depends on APE tag parser [22:20:02] <kierank> hmmm so there is a native dolby e decoder: http://www.dolby.com/professional/products/broadcast/test-and-measurement/d… [22:24:46] <CIA-90> ffmpeg: kostya * r21910 /trunk/libavcodec/apedec.c: 16l trocadero: don't forget to free frame data buffer in APE decoder [22:49:06] <elenril> nice, silent hill 2 videos now look ok [22:52:24] <_av500_> BBB: no, not yet, as u said 1st thing is to try to find out when this data is captions at all... [22:54:48] <jez9999> BBB: see patch9 to issue 1740. [22:55:01] <iive> there is something fishy in these commits. [22:56:19] <iive> kostya never stays that late at night [23:02:05] <BBB> jez9999, commented [23:02:23] <BBB> _av500_, right... so will you work on that? so I know where to focus my efforts :) [23:06:21] <_av500_> not sure i will have time these days [23:06:37] <_av500_> but are there many streamslike that? [23:11:10] <CIA-90> ffmpeg: rbultje * r21911 /trunk/libavformat/rtsp.c: [23:11:10] <CIA-90> ffmpeg: Make rtsp_close_streams() take a AVFormatContext instead of a RTSPState [23:11:10] <CIA-90> ffmpeg: argument, so we can use AVFormatContext->* here in the future. [23:11:10] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>. [23:12:49] <CIA-90> ffmpeg: rbultje * r21912 /trunk/libavformat/rtsp.c: [23:12:49] <CIA-90> ffmpeg: Use mode=receive instead of mode=play if in RTSP muxer (instead of demuxer) [23:12:49] <CIA-90> ffmpeg: mode. [23:12:49] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>. [23:14:13] <CIA-90> ffmpeg: rbultje * r21913 /trunk/libavformat/rtsp.c: [23:14:13] <CIA-90> ffmpeg: Only send out NAT-punching RTP/RTCP packets when we're in demuxer mode, i.e. [23:14:13] <CIA-90> ffmpeg: don't send them when acting as a RTSP muxer. [23:14:13] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>. [23:22:37] <CIA-90> ffmpeg: rbultje * r21914 /trunk/libavformat/rtsp.c: [23:22:37] <CIA-90> ffmpeg: Split out input-specific parts of rtsp_read_header() into its own, new, [23:22:37] <CIA-90> ffmpeg: function (rtsp_setup_input_streams()), as preparation for the upcoming [23:22:37] <CIA-90> ffmpeg: RTSP muxer. [23:22:37] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>. [23:24:31] <CIA-90> ffmpeg: rbultje * r21915 /trunk/libavformat/rtsp.c: [23:24:31] <CIA-90> ffmpeg: Split rtsp_read_header() into two functions, so that the main part (now also [23:24:31] <CIA-90> ffmpeg: known as rtsp_connect()) can be used in the RTSP muxer. [23:24:31] <CIA-90> ffmpeg: Patch by Martin Storsj? <$firstname $firstname st>.

1 0

IRC log for 2010-02-18
by irc＠mansr.com 19 Feb '10

19 Feb '10

[00:02:58] <Vitor1001> Hmm, there is something seriously miscompiled here :( [00:03:10] <BBB> ? [00:03:11] <Vitor1001> I'm getting a segfault for every wmavoice file [00:03:28] * BBB checks patch [00:04:10] * Vitor1001 try make distclean and rebuild [00:04:23] <Vitor1001> ccache is great [00:04:26] <BBB> did it play without the patch I just gave you? [00:05:04] <Vitor1001> yes. [00:05:36] <BBB> it might be the lamely named tables powtab, sintab, etc. [00:05:43] <BBB> I think lavc has other tables with the same name [00:05:50] <Vitor1001> I'll try gdb [00:06:05] <mru> it shouldn't link if there are name clashes [00:06:25] <Vitor1001> BBB: I think you are using FFT with unaligned buffers [00:06:39] <BBB> oh, my debug code? [00:06:54] <Vitor1001> probably [00:07:03] <BBB> comment it all out, it doesn't do anything [00:07:06] <BBB> in com_wmsapf.c [00:07:23] <BBB> search for rdft_calc [00:07:27] <BBB> and surrounding lines [00:07:35] * Vitor1001 tries [00:07:47] <Vitor1001> cool, working now [00:08:30] <BBB> you in jersey now? [00:09:03] <BBB> hm, .fr [00:09:07] <BBB> you're working odd hours [00:09:10] <Vitor1001> yeah [00:09:21] <Vitor1001> sleeplessness today :p [00:10:44] <Vitor1001> do you know the size of arr1? [00:11:13] <BBB> in which function? [00:11:23] <Vitor1001> DoSmoothFilter [00:12:40] <BBB> 0x80 [00:12:44] <BBB> or actually ox82 [00:19:50] * BBB decides to giv up and head home [00:20:02] <BBB> jez9999, I'm still waiting for a new patch on issue 1740 [00:20:12] <jez9999> BBB: hum [00:20:22] <jez9999> i cant RDC into my work machine, i'll update it tomorrow [00:20:26] <BBB> okies [00:20:30] <jez9999> but i have to say it seems pointless [00:20:37] <jez9999> the way i've done it is 100% fine [00:20:38] <jez9999> ;-) [00:20:41] <CIA-90> ffmpeg: michael * r21874 /trunk/ffplay.c: fix issue 1747 [00:22:04] <BBB> just for the sake of preventing mental insanity, let's just do as michael requested, I in fact agree with him [00:22:09] <jez9999> why? [00:22:22] <jez9999> even in the sense of multithreaded apps, wouldn't they all be using different filenames? [00:22:29] <jez9999> i can't see why they'd share that memory [00:23:05] <BBB> why would they use different filenames? [00:23:26] <jez9999> because they're triggered by different incarnations of av_open_* ? [00:23:29] <BBB> you could one 10 threads for h264 decoding in that file, plus one for aac and one main thread plus one for video playback and another for network buffering [00:23:55] <BBB> they might all want to access that pointer [00:24:08] <jez9999> but until the file was opened, none of them would try to access it [00:24:37] <BBB> how do you know? [00:24:48] <jez9999> because the alternative is opening the file multiple times [00:24:55] <jez9999> if that happens, i'd consider that behaviour to be the bug [00:25:51] * BBB omg's [00:27:12] * BBB decides again to go home [00:27:21] <jez9999> ... [00:27:22] <BBB> Vitor1001, thanks for helping, let's talk more tomorrow [00:27:34] <jez9999> so ffmpeg does open the file multiple times? :-) [00:27:53] <BBB> jez9999, I'm telling you a patch to get your patch applied... why are you being obstructive? [00:28:23] <jez9999> so copy filename to internal allocated memory, and pass that to open()? [00:28:29] <jez9999> filename must never change [00:28:42] <BBB> if open of filename with ? fails [00:28:43] <BBB> { [00:28:55] <BBB> char filename[..]; strcpy(filename, s->filename); [00:29:05] <BBB> '?' -> '/0'; [00:29:10] <BBB> open that; [00:29:11] <BBB> } [00:29:19] <jez9999> i was simply trying to explain why it almost seems counter-intuative to me to do that [00:29:24] <jez9999> unless i made a blunder somewhere [00:29:36] <jez9999> not trying to be argumentative for its own sake :-) [00:30:02] <jez9999> semantically, you're saying "multiple threads might want to open the file at the same time" [00:31:27] <BBB> not open [00:31:30] <BBB> access the pointer [00:31:34] <Vitor1001> BBB: I think I got one [00:31:37] <BBB> the pointer could be shared [00:31:43] <BBB> Vitor1001, that was quick [00:32:05] <Vitor1001> WMAVoiceRealForwFFT_INT() [00:32:09] <jez9999> BBB: the pointer to the filename or the fd? [00:32:15] <BBB> jez9999, the pointer to filename [00:32:24] <jez9999> ok [00:32:46] <Vitor1001> BBB: check your email [00:32:50] <BBB> Vitor1001, ok [00:34:08] <BBB> is this mathematica output? [00:34:32] <Vitor1001> yes, do you have the software? [00:34:35] <BBB> no [00:34:58] <BBB> so what does this mean? </silly> [00:35:11] <BBB> it means the function does fft(array)/sqrt(8)/ [00:35:12] <BBB> ? [00:35:21] <Vitor1001> it is just a real FFT with output [00:35:44] <Vitor1001> {Re[q0], Im[q0], Re[q1], Im[q1], ... } [00:35:57] <BBB> ah, re/im interleaved [00:36:11] <Vitor1001> yes, exactly [00:36:50] <Vitor1001> note that for rdft the way of outputting the real/imaginary part is a bit special [00:36:58] <Vitor1001> to make it fit in a single vector [00:37:18] <Vitor1001> see fft-example.c, it uses trivial complex fft to test rdft [00:37:39] <BBB> I can just change the argument to that function into struct { int re; int im; } x[0x41]; [00:38:05] <Vitor1001> not really [00:38:09] <Vitor1001> input is real [00:38:14] <BBB> hmm... [00:38:17] <BBB> right [00:38:20] <Vitor1001> output is struct {int re; int im;} [00:38:36] <Vitor1001> Well, really have to sleep now [00:38:41] <BBB> ok, thanks [00:38:41] <Vitor1001> 1h40 am [00:38:47] <Vitor1001> good luck! [00:38:51] <BBB> thanks [00:38:51] <BBB> bue [00:38:52] <BBB> bye [00:38:56] * BBB leaves also [00:38:56] <Vitor1001> bye [00:41:39] <Dark_Shikari> question about __attribute__((flatten) [00:41:45] <Dark_Shikari> if A calls B, and B calls C [00:41:47] <Dark_Shikari> and we flatten A [00:41:51] <Dark_Shikari> will C be inlined all the way into A? [00:43:19] <mru> hopefully not [00:43:21] <mru> try and see [00:44:23] <Dark_Shikari> basically I have the following [00:44:28] <Dark_Shikari> A calls X a lot, I want X inlined into A [00:44:33] <Dark_Shikari> A also calls B, and A is the only thing that calls B [00:44:38] <Dark_Shikari> B calls X a lot, but I don't want X inlined into B [00:44:48] <Dark_Shikari> because the calls to X from B are less important. [00:48:17] <Dark_Shikari> meh, didn't help, gcc didn't fully flatten it even one level. [00:48:18] <Dark_Shikari> blegh. [00:48:26] * Dark_Shikari ports ffmpeg-style partition tracking to x264 [00:50:54] <Dark_Shikari> mru: is there a way to have a function that is inlined if its arguments are constant, and a function call if they are not? [00:51:16] <Dark_Shikari> I have some variable-size fill_rectangles in my x264 code [00:51:18] <mru> that would be way too useful ;-) [00:51:21] <Kovensky> partition? [00:51:29] <Dark_Shikari> lol [00:51:49] <Dark_Shikari> the final hard part now: port the partition checks to deblocking [00:51:58] <mru> you can probably hack something up with flatten, always_inline, and builtin_constant_p [00:52:12] <mru> it won't be pretty... [00:52:13] <Dark_Shikari> lol [00:52:15] <Dark_Shikari> oh dears [00:53:42] <iive> i may sound very naive, but isn't pure simple `inline` supposed to that automagically? [00:54:33] <mru> plain inline is only a hint [00:54:45] <mru> it has no defined semantics [01:32:19] <Dark_Shikari> more cdecl nastiness [01:32:27] <Dark_Shikari> what do you call a pointer to a static const uint8_t[2][4][4]? [01:32:45] <Dark_Shikari> *(x)[2][4]? [01:33:25] <mru> static const (*x)[2][4][4] [01:33:35] <Dark_Shikari> er, but don't you not include the [2]? [01:33:53] <mru> in that case your question is wrong [01:34:09] <Dark_Shikari> ok, then I'll make it clearer [01:34:12] <Dark_Shikari> static const uint8_t mv_check[2][2][4][4] [01:34:16] <Dark_Shikari> const uint8_t *(mv_check)[2][4][4] = mv_check[sub8x8]; [01:34:38] <mru> the * goes inside the () [01:34:42] <Dark_Shikari> oh yeah [01:38:18] <Dark_Shikari> also, 4-D arrays are a great way to confuse people [01:39:33] <Kovensky> nothing like 5-D arrays though [01:46:41] <peloverde> bah that's kid's stuff, aliasing ParametricStereo on top of the SBR right channel and turning it back into the right channel when you are done through a union pun is a good way to confuse people [01:52:16] <Kovensky> what [01:52:34] <Kovensky> oshi- I just proved your point [01:58:12] <peloverde> something vaguely like "union { struct { SBRData data[2]; } stereo; struct { SBRData data; ParametricStereo ps; } mono; } channel_data;" [06:53:51] * elenril pokes KotH [07:00:19] <pJok> mornings [07:01:58] <kshishkov> goda morgnar [07:02:39] <thresh> moroning [07:05:24] <benoit-> hej [07:05:30] <kshishkov> hejsan [07:20:51] * KotH stabs elenril [07:20:59] <KotH> good morning, everyone else! [07:21:25] <kshishkov> god morgon [07:21:38] <elenril> sup BofH [07:21:46] <elenril> can i have access to incoming? [07:22:15] <KotH> what do you pay? [07:22:41] <elenril> a virtual cake? [07:22:49] <KotH> the cake is a lie [07:22:57] <KotH> anything else to offer? [07:23:18] <elenril> curse, my evil plan is foiled [07:23:46] <kshishkov> an eternal soul? preferably from somebody else [07:24:01] <KotH> i'd also take your first born [07:24:09] <thresh> i love to see our sport officials shit themself because of no results in Olympics [07:24:10] * elenril offers Kovensky's soul [07:24:44] <kshishkov> thresh: what about that Georgian guy? [07:24:47] <KotH> elenril: bah.. who'd take that soiled thing?!? [07:25:03] <thresh> kshishkov: mm? [07:25:45] <kshishkov> thresh: you should have heard - an accident on Olympics opening [07:26:44] <thresh> yes, i did [07:27:37] <kshishkov> anyway, there's always football [07:27:48] <thresh> what i really mean is the whole system is FUBAR, not only the sports one, and they try to put a brave face on a sorry business [07:28:05] <thresh> yeah, with no Guus our football is fubared as well :-) [07:28:22] <kshishkov> go suport Ukrainian football [07:28:26] <kshishkov> *support [07:31:50] <pJok> isn't handball big in ukraine? [07:32:09] <kshishkov> jo [07:32:29] * kshishkov does not know any sport Ukraine does not suck at [07:32:41] <pJok> hehe [07:33:14] <pJok> considering handball aparantly was invented (at least the current form of it) in denmark, im surprised that its not bigger in denmark [07:33:29] * elenril wonders if he's the only one who finds the concept of a nation failing at sport weird [07:35:06] <kshishkov> yes, in the beginning of XXth century there were many Englishmen living here, so our local football team was really great beck in 1920s [07:35:27] <kshishkov> *back [07:36:01] <kshishkov> the same reason why one of districts here is called "Neue Bayern" if translated from Ukrainian [07:36:10] <pJok> the only thing denmark seems to be good at at the moment is tennis [07:36:39] <pJok> considering Caroline Wozniacki is climbing up the world rank quite fast [07:37:12] <kshishkov> heh, but the most famous tennis player lived in Russia [07:37:59] <pJok> Kurnikova? [07:38:03] <kshishkov> Yeltsin [07:38:19] <pJok> shows what i know [07:38:20] <pJok> :) [07:38:57] <kshishkov> he was also famous Russian national sport player too [07:40:29] <thresh> vodking [08:12:17] <siretart> Dark_Shikari: FYI: https://launchpad.net/ubuntu/+source/x264/2:0.85.1442+gitfcf70c-1 [08:13:06] * siretart not really around, I'm at workshop, will return tonight very late [08:13:09] <Dark_Shikari> what's epoch? [08:14:21] <Dark_Shikari> oh btw, I've added a gpac version check locally to get rid of those nasty problems people have been having [08:14:46] <astrange> epoch numbers override versions so you can break the version numbering [08:14:47] <kshishkov> Dark_Shikari: it means their x264 is now in XXIst century [08:15:12] <Dark_Shikari> astrange: heh [08:18:38] <siretart> Dark_Shikari: epoch is the number before the ':' [08:18:46] <Dark_Shikari> ah. [08:20:25] <Dark_Shikari> siretart: did you get lavf input working properly btw? [08:20:35] <Dark_Shikari> or will that not be ready for lucid [08:55:18] <Dark_Shikari> kshishkov: did you bench the mode_list thing? [08:55:19] <Dark_Shikari> was it faster? [08:56:36] <Dark_Shikari> also, what's bink_scan[]? [08:58:04] <kshishkov> no difference in speed [08:58:13] <kshishkov> bink scantable, of course [08:58:38] * kshishkov was too unsure and lazy to permute quant matrices [08:59:12] <Dark_Shikari> wait, if no difference, why did you do it? >_> [08:59:53] <Dark_Shikari> and yeah, permute your quant tables. faster that way [09:00:12] <Dark_Shikari> also, why is it bink_scan and not scan? [09:00:16] <Dark_Shikari> do the quant order tables have a different scan order? [09:00:23] <Dark_Shikari> block[scan[idx]] = (block[scan[idx]] * quant[bink_scan[idx]]) >> 11; [09:01:32] <Dark_Shikari> btw, when measuring speed I assume you used START/STOP timer? [09:01:36] <Dark_Shikari> it's hard to get "no difference" with timer [09:02:25] <kshishkov> well, bink_scan[] is DCT scan order [09:03:04] <kshishkov> scan[] is permuted bink_scan[] so somebody may use optimized Bink IDCT with trasposed scan order ;) [09:03:24] <Dark_Shikari> either way, try to get everything permuted to minimize scan[] derefs [09:03:32] <Dark_Shikari> especially differing scan derefs [09:03:36] <Dark_Shikari> and add comments as to why they differ [09:03:53] <kshishkov> it's obvious [09:03:54] <Dark_Shikari> 1419-1432 [09:04:00] <Dark_Shikari> wasn't obvious to me [09:04:10] <Dark_Shikari> so, in those lines, the if( i+run check and the i+= run can be merged [09:04:17] <Dark_Shikari> i.e. move the i += run up to the top, after int run [09:04:37] <Dark_Shikari> furthermore, it looks like that if is duplicating the while() check too [09:04:50] <Dark_Shikari> not sure if that's factorable out or not [09:04:56] <Dark_Shikari> but either way you can at least factor out the i + run. [09:04:59] <kshishkov> ok [09:05:15] <Dark_Shikari> unclamped or nonclamped? I think unclamped is more correct english [09:05:56] <kshishkov> different meanings to me [09:06:05] <Dark_Shikari> unclamped == not clamped [09:06:10] <Dark_Shikari> nonclamped == not a word [09:06:22] <kshishkov> it sounds more like "it was clamped, now it's not" [09:06:28] <Dark_Shikari> lol [09:06:50] <Dark_Shikari> btw, that change I mentioned above should be done in both places [09:06:56] <kshishkov> done [09:07:07] <Dark_Shikari> also, I get the feeling in general that you might be able to template some of this code.... I mean the code duplication just eats [09:07:10] <Dark_Shikari> *just eats at me [09:07:11] <Dark_Shikari> it's annoying [09:07:16] <Dark_Shikari> but if there's really no better way, there's no better way [09:07:33] <Dark_Shikari> ... why do we do coordmap[*scan[]]? [09:07:36] <Dark_Shikari> that's a double-deref [09:08:31] <Dark_Shikari> double-derefs for every single iteration of a loop like that are inefficient [09:08:40] <Dark_Shikari> got to be a better way to do that [09:09:09] <kshishkov> [*scan & 7 + (*scan >> 3) * stride], scan++ [09:09:32] <Dark_Shikari> why not eliminate scan and just make the tables cover the scans [09:09:45] <Dark_Shikari> i.e. have coordmap include the scans [09:09:50] <Dark_Shikari> you have plenty of L1 cache [09:10:06] <kshishkov> scan order may be different for each block in that case [09:10:10] <Dark_Shikari> also, 1743-1745 has brackets but 1741-1742 doesn't [09:10:20] <Dark_Shikari> kshishkov: ? [09:10:41] <Dark_Shikari> so if there are X scantables [09:10:43] <Dark_Shikari> you have X coordmaps [09:11:25] <Dark_Shikari> ugh... [09:11:28] <kshishkov> 4*16*64 = 2K [09:11:28] <Dark_Shikari> I guess you should probably bench [09:11:32] <Dark_Shikari> i.e. see how common each block type is [09:11:43] <Dark_Shikari> to decide which ones you have to care about [09:12:32] <kshishkov> from my observations, both DCT and pattern blocks are quite common [09:12:49] <Dark_Shikari> and motion? [09:13:13] <Dark_Shikari> and residue? [09:13:21] <kshishkov> those too [09:13:45] <kshishkov> residue blocks are not that common though [09:14:16] <Dark_Shikari> btw, if you wanted to be silly and find some nice way to optimize pattern blocks [09:14:21] <Dark_Shikari> you could experiment with something like this [09:14:30] <Dark_Shikari> lets say the pattern is AABABBAA [09:14:47] <kshishkov> I know - two masks, multiply and combine [09:14:50] <Dark_Shikari> yeah [09:14:57] <Dark_Shikari> two 0x010101 ... masks [09:15:01] <Dark_Shikari> it'd basically be 64-bit only [09:15:21] <Dark_Shikari> to warn you, 64-bit multiplies on 32-bit tend to be pessimized by gcc [09:15:25] <Dark_Shikari> i.e. it won't split it into fast 32-bit code [09:15:30] <kshishkov> what isn't? [09:15:42] <Dark_Shikari> lol [09:15:58] <Dark_Shikari> a profile would be useful btw [09:16:04] <Dark_Shikari> like an oprofile or something [09:17:24] <Dark_Shikari> line 798-799: these can be merged with the declarations [09:17:25] <Dark_Shikari> i.e. [09:17:27] <Dark_Shikari> int bw = ... [09:18:13] <Dark_Shikari> + if (!b->cur_dec <--wtf is this for? [09:18:17] <Dark_Shikari> + b->cur_dec = NULL; \ etc [09:18:51] <kshishkov> for empty bundles [09:19:28] <Dark_Shikari> um, but if cur_dec is 0, we already returned [09:19:36] <Dark_Shikari> so how can it be NULL at the start? [09:20:38] <kshishkov> why? that's called several times per each plane [09:21:24] <Dark_Shikari> oh so you're saying there can be no motion values [09:21:25] <Dark_Shikari> no dcs [09:21:25] <Dark_Shikari> etc [09:21:35] <kshishkov> yes [09:21:37] <Dark_Shikari> k [09:21:54] <Dark_Shikari> ah, so there's one bundle per row of the frame? [09:22:26] <kshishkov> each bundle can have data for several rows [09:22:47] <kshishkov> but it's for multiple of rows, yes [09:22:50] <Dark_Shikari> wait then why is it run once per row? [09:23:11] <kshishkov> to fill it again if data depleted [09:23:50] <Dark_Shikari> that's a bit odd. [09:23:56] <Dark_Shikari> I guess it's like theora except less stupid [09:24:31] <kshishkov> it's closer to TM2 [09:24:56] <kshishkov> (which is Ducker TrueMotion 2, not Duck TrueMotion VP3) [09:24:59] <kshishkov> *Duck [09:28:35] <Dark_Shikari> either way--awesome decoder. [09:28:36] * Dark_Shikari sleeps [09:29:20] * kshishkov thinks it's appropriate to say "in your dreams" [10:17:07] <nfl> Hi. Is there any way to know if the current frame is even/odd numbered other than from avctx->frame_number? [10:28:28] <siretart> Dark_Shikari: no. I didn't look into that. didn't you say it just doesn't work with ffmpeg 0.5? [12:14:13] <CIA-90> ffmpeg: michael * r21875 /trunk/libavcodec/h264_cabac.c: Speedup decode_cabac_field_decoding_flag() by 9 cpu cycles. [12:16:25] <twnqx> i think michael should not just say how many cycles less he needs [12:16:39] <merbzt> ? [12:16:45] <twnqx> 9 out of 100 would be kinda impressive, 9 out of 10000... not so much [12:18:10] <merbzt> true, but you need to understand the context anyway [12:19:11] <twnqx> well, yes, but the cabac decoder takes a big amount of the resources in h264 decoding [12:19:16] <merbzt> cabac is used very much so even if it is only 9 out of 10000 it would matter [12:19:58] <twnqx> 0.09%? [12:20:27] <merbzt> what I'd like to get is a benchmark from before christmas and now [12:20:37] <twnqx> i certainly agree on that [12:22:14] <merbzt> 0.1% is faster, and I think is has come to a point where the these micro opts are the lowest hanging fruit [12:23:13] <pross-au> 9 cycles is still 9 cycles [12:38:32] <CIA-90> ffmpeg: michael * r21876 /trunk/libavcodec/h264.c: Simplify deblock_left/top condition for deblocking_filter=2 [13:09:01] * elenril facepalms [13:09:24] <elenril> broken id3 in asf [13:12:19] <kshishkov> what is it doing here in the first place? [13:12:37] <elenril> mypointexactly [13:14:02] <elenril> also the way it's stored is very funny [13:14:13] <elenril> the keys are utf-16 [13:14:43] <elenril> tags themselves are two utf-8 strings [13:15:11] <elenril> srsly, what mushrooms were they smoking [13:16:26] <kshishkov> MS Mushrooms Me [13:17:39] * elenril thinks the most correct solution would be to skip these tags [13:18:25] <kshishkov> yes [13:18:26] <Rathann|work> the simplest, maybe :) [13:21:05] <elenril> simple == good [13:23:12] <KotH> hey Rathann|work! [13:41:11] <CIA-90> ffmpeg: mru * r21877 /trunk/libavutil/intreadwrite.h: Add alias-safe union typedefs [13:41:11] <CIA-90> ffmpeg: mru * r21878 /trunk/libavutil/intreadwrite.h: Use alias-safe types in AV_[RW] macros [13:41:12] <CIA-90> ffmpeg: mru * r21879 /trunk/libavutil/intreadwrite.h: Use alias-safe types in AV_COPY/SWAP/ZERO macros [13:45:26] <CIA-90> ffmpeg: mru * r21880 /trunk/libavutil/intreadwrite.h: Add alias-safe aligned AV_[RW]N macros [14:40:04] <jez9999> BBB: morning [14:42:49] <jez9999> I see you've commented on patch5 for issue 1740 [15:03:50] <Compn> DonDiego: you should write up a rant on chilling effects. you could educate the masses. [15:04:27] <DonDiego> i've been thinking about getting that blog that mike offered me ages ago.. [15:05:15] <mru> blogs are actually more fun than I expected [15:15:03] <superdump> and it seems if you write intelligently, people read it [15:15:58] <kshishkov> no, you need either pr0n or cats pictures to attract some attention [15:16:44] <DonDiego> define "attention" [15:17:20] * Compn has to run afk, bbl [15:18:06] <kshishkov> a mental state which leads to an action comprising not closing the window with blog post, reading aforementioned article of text and comprehending it [15:19:35] <DonDiego> so you only read pr0n and cat pics? :) [15:19:55] <kshishkov> no, but I hint that majority of Internet users do [15:20:15] <DonDiego> as i said, define "attention".. [15:20:45] <DonDiego> rob and you do not appear to have the same kind of attention in mind [15:21:11] <mru> there are many kinds of attention [15:21:28] <mru> the two most important ones are from people with money and from girls [15:21:34] <mru> not necessarily in that order [15:21:48] <mru> so far my blog has only got me the former kind [15:22:08] <mru> you reckon cat pics would help with that? [15:22:44] <kshishkov> no, you need SEO for that [15:25:42] <BBB> dondiego: get a blog, it's fun [15:25:50] <DonDiego> do you have one? [15:25:53] <BBB> of course [15:26:03] <DonDiego> and yeah, i guess i will once i have a bit more time [15:26:03] <BBB> half of all ffmpeg devs have one [15:26:04] <kshishkov> a share of gnome blog actually [15:26:05] <BBB> if not more [15:26:10] <BBB> indeed [15:26:20] <BBB> alhough not really gnome-related anymore [15:26:25] <kshishkov> DonDiego: "once i have a bit more time" - won't happen ever [15:26:28] <BBB> but hey, it's free [15:26:37] <DonDiego> kshishkov: it will, after my exam [15:26:44] * BBB likes kostya's wild west blog [15:26:48] <kshishkov> BBB: mine is even more misleading [15:26:59] <kshishkov> named by Mike [15:32:16] <jez9999> BBB: why do you say to use 0 instead of '\0'? [15:32:27] <jez9999> i was always taught to use '\0' or NUL when setting the null terminator character [15:32:32] <mru> one char instead of 4 [15:32:44] <mru> they are exactly equivalent in C [15:32:46] <mru> but not in C++ [15:32:57] <mru> character constants have type int in C [15:34:03] <BBB> jez9999, as mru says, source code size is smaller [15:34:07] <BBB> that's a virtue in ffmpeg [15:34:23] <kshishkov> heh [15:34:30] <mru> code readability is important [15:34:42] <jez9999> also, that you support GCC 2.95 is beyond belief [15:34:54] <jez9999> it was released in July 1999 [15:34:56] <BBB> jez9999, if I don't complain, someone else with - get used to it :) [15:35:01] <jez9999> please tell me you were just being extra anal [15:35:03] <BBB> this is just how ffmpeg review works [15:35:05] <kshishkov> ask mmu_man why we support GCC 2.95 [15:35:09] <mru> jez9999: I suggest you stop bitching before we have to kick you [15:35:11] <BBB> jez9999, no, everyone would say that [15:35:16] <jez9999> :-\ [15:35:21] <BBB> don't kick him :) [15:35:22] <BBB> he's fine [15:35:29] <mru> if he stops bitching [15:35:34] <BBB> jez9999, our review is just a bit more anal, generally, than other projects [15:35:42] <BBB> but it leads to better code [15:35:44] <BBB> so it's ok [15:35:57] <jez9999> well support for an ancient compiler is debatably 'better' [15:35:58] <mru> it's not us being anal, it's them being lax [15:36:25] <BBB> mru: if you believe in relativity, then that's the same thing :) [15:36:27] <kshishkov> jez9999: unfortunately, there are OSes where it's standard compiler [15:36:33] <jez9999> such as? [15:36:37] <BBB> beos? [15:36:38] <kshishkov> BeOS [15:36:47] <BBB> :) [15:36:47] <jez9999> isn't that a dead OS? [15:36:51] <mru> DeadOS [15:40:43] <jez9999> BBB: anyway, the issues are addressed in patch6 [15:45:45] <DonDiego> does anybody know a quick way to grep for non-ascii characters? [15:46:16] <kshishkov> it should take octal [15:46:30] <kshishkov> or [^A-Za-z] [15:47:36] <mru> [^ -~] [15:47:46] <mru> that gives you 0x20 to 0x7e [15:47:47] * thresh survived boring corpo-meeting [15:47:51] <mru> I don't know what 7f is [15:48:22] <mru> it doesn't print here [15:55:11] <jez9999> what counts as an ascii character? [15:55:17] <jez9999> anything below 128? [15:55:50] <mru> and >= 32 [15:55:56] <mru> <32 are control characters [15:56:19] <kshishkov> why grep cannot use bitmasks? [15:57:59] * kshishkov found that grepping with awk sometimes is more convenient and significantly faster [16:02:06] <jez9999> grep with Perl [16:02:06] <jez9999> :-) [16:05:20] <DonDiego> mru: does not work :-/ [16:05:33] <mru> what are you trying to do? [16:05:33] <KotH> DonDiego: [[:ascii:]] ? [16:11:39] <Compn> oh DonDiego, i didnt know you were in the middle of exams, i wouldnt have bugged you if i knew ... [16:12:12] <Compn> s/knew/remembered [16:12:48] <DonDiego> Compn: np [16:17:40] <kshishkov> what a ridiculous MPlayer message "Cannot seek backward in linear streams!" [16:18:03] <mru> socket, pipe? [16:18:11] <kshishkov> yes [16:18:24] <mru> of course you can't seek backwards there [16:18:29] <mru> it's like seeking backwards in time [16:18:37] <kshishkov> are other streams curvy or non-euclidean? [16:19:55] <mru> rectangular [16:20:02] * KotH has seen hyperbolic streams [16:20:03] <mru> haven't you ever looked inside a file? [16:20:54] <kshishkov> yes, but that was wraparound [16:25:30] <CIA-90> ffmpeg: mru * r21881 /trunk/libavcodec/ (h264_loopfilter.c h264.c h264_mvpred.h h264.h h264_direct.c): [16:25:30] <CIA-90> ffmpeg: H264: use alias-safe macros [16:25:30] <CIA-90> ffmpeg: This eliminates all aliasing violation warnings in h264 code. [16:25:30] <CIA-90> ffmpeg: No measurable speed difference with gcc-4.4.3 on i7. [16:27:27] <mru> Dark_Shikari: ^^ [16:28:06] <CIA-90> ffmpeg: kostya * r21882 /trunk/libavformat/rtmpproto.c: Make RTMP client send bytes read report [16:28:07] <kshishkov> mru: does that mean we'll have all green on ARMv5? [16:28:23] <mru> we'll have all green on arm when arm release the next update [16:28:32] <mru> or if I install the test build they gave me [16:31:28] <lu_zero> hm [16:31:49] <lu_zero> irssi seems to be less than perfect for my usage... [16:32:50] <kshishkov> solution: use something else [16:32:58] <mru> no, fix it [16:33:11] <mru> irssi is quite customisable too [16:33:16] <kshishkov> mru: same can be said about Windows Me [16:33:27] <mru> in some cases fix == replace [16:33:40] <mru> in the winme case fix == annihilate [16:34:54] <kshishkov> well, svn commit -m "fix something" should be ideal description then [16:37:17] <BBB> Vitor1001, haven't looked at the fft yet, will do hopefully this weekend [16:37:31] <Vitor1001> BBB: ok, no hurry [16:37:44] <Vitor1001> do you have an idea of what the other func do? [16:39:02] <BBB> the bottom one? [16:39:06] <BBB> it's the inverse of the top one [16:39:19] <BBB> so most likely it's ifft re/im interleaved back to int[] [16:39:33] <BBB> I'll test that soon [16:40:00] <BBB> the functions in com_wmsapf.c don't do much complicated [16:40:39] <mru> kshishkov: http://cgit.openembedded.net/cgit.cgi/openembedded/tree/recipes/linux/linux… [16:42:00] <kshishkov> mru: yes, it was pretty obvious [16:44:37] <Vitor1001> BBB: I mean the wmsCcsFft_INT() [16:45:26] * Dark_Shikari sees aliasing patches applied [16:45:27] <Dark_Shikari> mru: awesome. [16:45:50] <Dark_Shikari> now we have to do it in other decoders/encoders [16:47:20] <kshishkov> for example? [16:47:27] <mru> ls *.c [16:48:03] <kshishkov> costablegen.c [16:48:17] <mru> top of the list [16:49:15] <Dark_Shikari> mru: lol [17:02:32] <elenril> o/ people [17:02:46] <elenril> anyone wants to apply nut metadata conv table for me? [17:06:58] <kshishkov> superdump: can you serve as a patch monkey? [17:07:09] <superdump> hmm? [17:07:29] <kshishkov> here's elenril and his nutty patch [17:07:38] * elenril is nuts [17:08:00] <elenril> kshishkov: what prevents you from applying it btw? =p [17:08:21] <kshishkov> elenril: laziness mostly [17:08:43] <kshishkov> especially effort needed to find your patch and obfuscate your email [17:09:30] <elenril> more effort than reverse engineering obscure codecs? ;) [17:09:41] <mru> less fun [17:09:47] <kshishkov> exactly [17:17:42] <elenril> so we should switch to git [17:17:53] <elenril> applying patches will be less effort [17:18:14] <Kovensky> git am elenril [17:22:17] <mru> git re codec [17:23:14] <kshishkov> okay, I retire then [18:01:57] <mattg> mru: i've added a new directory to FTP at /MPlayer/incoming/mattg_neon_green2/ which you may be interested in. i've supplied raw YUV outputs from the app running on mac, iphone with asm, iphone without asm. (320x242, YUV420P). [18:02:21] <mattg> green in both iphone cases, not green in the mac case. something strange is going on. [18:02:38] <mru> mattg: you might want to try latest svn [18:02:50] <mru> I've fixed some potential alignment problems [18:03:10] <Dark_Shikari> and aliasing >_> [18:03:24] <mattg> ah, yes, just spotted you have commited recently. i'll certainly go and check out the new version. thanks! i'll give you feedback (probably tomorrow) [18:03:35] <mru> Dark_Shikari: aliasing wouldn't be fixed by disabling asm [18:05:12] <Dark_Shikari> true. [18:05:16] <Dark_Shikari> In most cases. [18:06:03] <kshishkov> it should be fixed by disabling compiler optimizations ;) [18:06:27] <mattg> mru: note that i've actually found that it can't be the asm (apologies for saying that before) as YUV output is exactly the same with and without --disable-asm on iphone [18:07:02] <mru> hmpf [18:07:56] <mattg> i'm totally confused by it, but am getting somewhere and tomorrow am going to try new svn trunk and then if it's still broken for me, i'll step through the decoding on both mac & iphone and see where the green is coming from. [18:24:37] <CIA-90> ffmpeg: stefang * r21883 /trunk/libavcodec/cavs.h: [18:24:37] <CIA-90> ffmpeg: fix intra prediction modes with inter-MB neighbors, [18:24:37] <CIA-90> ffmpeg: the old sample clips are in violation of the 2006 spec [19:03:36] <BBB> [aac @ 0x1044600]channel element 0.0 is not allocated <- is that SBR again? [19:03:55] <superdump> not necessarily [19:04:03] <superdump> it's channel configuration stuff [19:04:05] <superdump> sample? [19:06:21] <BBB> http://archives.free.net.ph/message/20100203.025553.2fbf395b.en.html [19:06:29] <BBB> has a link to samples already in incoming/ [19:10:06] <superdump> oh that one [19:10:44] <superdump> BBB: https://roundup.ffmpeg.org/roundup/ffmpeg/issue1733 [19:15:37] <CIA-90> ffmpeg: mru * r21884 /trunk/configure: Suppress icc warnings about unknown attributes [19:40:43] <Dark_Shikari> siretart: ping, quick question [19:44:49] <siretart> Dark_Shikari: you're lucky, it seems umts is working right now [19:44:59] <Dark_Shikari> quick question about ubuntu releasing and all that [19:45:04] <siretart> 42 [19:45:45] <Dark_Shikari> lets say that we find some big bug in x264, and lucid's already out [19:45:49] <Dark_Shikari> can we get that bugfix pushed out? [19:46:37] <siretart> there is a process for that, so short answer: yes [19:47:25] <Dark_Shikari> k [19:47:33] <siretart> btw, my last x264 upload FTBFS on arm, just as you promised :-) [19:47:40] <Dark_Shikari> ? [19:47:45] <Dark_Shikari> FTBFS? [19:47:52] <siretart> fails to build from source [19:48:02] <Dark_Shikari> doesn't r1442 work? [19:48:05] <Dark_Shikari> it was supposed to [19:49:10] <siretart> https://edge.launchpad.net/ubuntu/+source/x264/2:0.85.1442+gitfcf70c-1/+bui… [19:50:15] <Dark_Shikari> common/arm/asm.S:21:20: error: config.h: No such file or directory [19:50:35] <Dark_Shikari> looks like something in your build environment is borked [19:50:42] <Dark_Shikari> Yuvi: ? [19:51:06] <siretart> I can retry the build [19:51:16] <Dark_Shikari> ./version.sh: line 2: git: command not found [19:51:22] <Dark_Shikari> er, git isn't installed on the build machine? [19:51:39] <thresh> why would you need it anyway [19:51:45] <Dark_Shikari> true, if you're customizing the version [19:52:03] <Dark_Shikari> siretart: something must be broken, because every DEFINE command in configure writes to config.h [19:52:11] <Dark_Shikari> so it would be very difficult for configure to succeed and config.h to not exist. [19:52:29] <thresh> let me see about arm on my test build [19:52:32] <siretart> a) why does this happen that late in the build process, and b) why only on arm? [19:52:52] <siretart> either the chroot is f'cked, or x264 :-) [19:53:38] <siretart> or hardware problems, of course [19:53:53] <Dark_Shikari> doubtful the last [19:54:22] <thresh> build seems ok here on latest git [19:55:52] <thresh> siretart: looks like it's some older version of git checkout [19:56:12] <thresh> i've had the same problem before last Dark_Shikari's (or whoever did it) push [19:58:45] <Dark_Shikari> forgot to make distclean? [20:01:17] <Yuvi> If it's an older x264, asflags didn't look in the right place for config.h [20:02:17] <Yuvi> Can't download the buildlog on my iPod though so I'm just guessing [20:04:15] <Yuvi> Btw, ubuntu will have a neon build in addition to the base armv5? [20:04:32] <Dark_Shikari> yeah, that's a major issue [20:04:35] <Dark_Shikari> a "base" build is 100% useless [20:04:38] <Dark_Shikari> far too slow to do anything [20:04:49] <Dark_Shikari> might as well not include x264 at all if it only has a base build [20:21:35] * elenril kicks mp4 specs [20:21:49] <elenril> anyone knows when will bcoudrier return? [20:48:11] <CIA-90> ffmpeg: stefano * r21885 /trunk/cmdutils.c: (log message trimmed) [20:48:11] <CIA-90> ffmpeg: FFmpeg is a collective effort so allowing a single name in a banner is [20:48:11] <CIA-90> ffmpeg: not nice/fair towards the community of developers. [20:48:11] <CIA-90> ffmpeg: Also this looks like the best way for resolving the debate about which [20:48:11] <CIA-90> ffmpeg: is the one person name to be put in the banner. [20:48:12] <CIA-90> ffmpeg: See the thread: [20:48:13] <CIA-90> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Replace "Fabrice Bellard" with "the FFmpeg developers" in the banner [21:20:38] * _av500_ tries to keep down the idle offtopic chatter... [21:20:43] <Dark_Shikari> lol [21:21:06] * _av500_ fails [21:21:32] <mru> this channel is like fosdem but without the beer [21:21:40] <Dark_Shikari> and without the freetards [21:22:51] <peloverde> The channel needs a video wall [21:23:11] <_av500_> libaa ftw [21:24:10] <mru> +---+---+---+ [21:24:10] <mru> | | | | [21:24:10] <mru> +---+---+---+ [21:24:10] <mru> | | | | [21:24:10] <mru> +---+---+---+ [21:24:35] <_av500_> -fps 25 [21:25:10] <mru> we used to do that with the chat system they had at uni [21:26:48] * _av500_ arranges 6 xterms with irrsi in the proper pattern [21:38:58] * mru looks at fate [21:39:10] <mru> looks like the anti-aliasing macros fixed a bunch of failures [21:39:17] <Dark_Shikari> nicwe [21:39:22] <Dark_Shikari> >antialiasing [21:39:24] <Dark_Shikari> hahahaha [21:39:33] <Dark_Shikari> so, what method do you prefer [21:39:37] <Dark_Shikari> supersampling? multisampling? [21:39:47] <astrange> what was the difference? [21:40:06] <Dark_Shikari> en.wikipedia.org [21:49:48] <CIA-90> libswscale: stefano * r30641 /trunk/libswscale/utils.c: [21:49:48] <CIA-90> libswscale: Merge two if conditions, allow to decrese the level of indentation of [21:49:48] <CIA-90> libswscale: the block. [21:49:48] <CIA-90> libswscale: stefano * r30642 /trunk/libswscale/utils.c: Vertically align a list of comparisons in sws_getCachedContext(). [21:49:50] <CIA-90> libswscale: stefano * r30643 /trunk/libswscale/utils.c: Reindent and fix brace placement. [21:54:13] <siretart> Dark_Shikari: I'm looking again at the buildlog for arm. AFAIUI, the failing gcc command line lacks a '-I.' flag. but that gcc call looks funky anyway [21:55:52] * janneg has started rendering BBB in 3640x2048 [21:56:08] <Dark_Shikari> lol [21:56:10] <Dark_Shikari> this might take a while [21:56:31] <peloverde> the person or the blender movie? [21:56:43] <_av500_> lol [21:57:07] <Dark_Shikari> how about elephant's dream [21:57:14] <_av500_> janneg: u got 50k render hours where? [21:58:29] <mru> janneg: you've got until june... [21:58:52] <_av500_> june this year [22:00:06] <_av500_> janneg: just the wireframe does not count.... [22:00:28] <janneg> just wanted to test how long a frame takes [22:01:31] <janneg> and ten days on a quadcore are already 1000 cpu hours [22:02:06] <mru> so how long does a frame take? [22:02:35] <_av500_> how can he know, he only started it yesterday [22:03:22] <janneg> no frame rendered yet. only a couple of minutes until blender gets killed [22:04:03] <mru> why does it get killed? [22:04:26] <_av500_> out of pixels [22:05:16] <janneg> out of memory [22:05:33] <_av500_> -EAREYOUNUTS [22:06:36] <Kovensky> -EFFFFFFFU [22:06:42] <mru> where are the source files? [22:06:44] <janneg> [114976.339948] Killed process 8126 (blender) vsz:3449520kB, anon-rss:2437324kB, file-rss:212kB [22:07:04] <Dark_Shikari> how much memory does a 4k render need [22:07:22] <janneg> apparently more than 3.5G [22:07:24] <_av500_> janneg: so how many kills in 10days on the quadcore? [22:07:35] <Dark_Shikari> hmm, I have a 6 gig I can try on [22:07:37] <mru> well, I have 12G [22:07:58] <janneg> mru: torrent, I'll seed with 10mbit [22:08:56] * _av500_ writes letter to boss, explaining the need for 24G [22:09:50] <mru> and where is the torrent file? [22:10:04] <janneg> http://download.blender.org/peach/bigbuckbunny_production.torrent [22:10:04] <mru> the one on bbb.org/download tries to use piratebay tracker [22:10:27] <mru> that's the one I'm trying [22:10:29] <Dark_Shikari> where's the torrent file for elephant's dream? [22:10:46] <mru> now it's trying dht [22:15:15] <janneg> http://93.220.64.28 [22:15:19] <janneg> mru: ^^^ [22:15:35] <mru> it's downloading now [22:28:45] <peloverde> I wonder If I will land SBR before next Thursday when Google will release VP8 and make FFmpeg completely irrelevant (or so says the prevailing opinion on the Internet) [22:29:02] <Dark_Shikari> lol vp8 [22:29:30] <Dark_Shikari> there was an on2 shareholder on doom9 complaining about how the corporate leadership cheated them out of their money [22:29:37] <Dark_Shikari> and used procedural BS to get votes for the merger [22:29:45] <Dark_Shikari> I'm laughing at the shareholders who thought on2 was worth more than 100m [22:29:59] <_av500_> mA, mV? [22:33:19] <BBB> peloverde, vp8 makes ffmpeg irrelevant? [22:33:19] <janneg> wtf: blender needs even for 640x512 3G [22:33:26] <BBB> peloverde, are you sure you didn't confuse ffmpeg and theora there? [22:33:37] <BBB> peloverde, otherwise I'm terribly confused [22:33:54] <peloverde> BBB: that's what people all over the internet are saying [22:34:25] <peloverde> remember fedora wont even ship an xiph only libffmpegsumo for chromium [22:34:26] <BBB> peloverde, people around me - scientists - all think we're going to decode all genomic diseases and grant us eternal life [22:34:53] <BBB> peloverde, fedora is irrelevant [22:35:04] <BBB> it has a desktop market share that is a hundredfold, if not thousandfold, below that of apple [22:35:22] <BBB> and apple is less than two handfingers in percentunits [22:35:25] <peloverde> FFmpeg seems to be just as hated as the MPEG codecs [22:35:53] <BBB> you listen too much to fanboys, zealots and other useless slashdot commenters [22:35:55] <janneg> of course, it has mpeg in its name [22:36:08] <BBB> you need to retract yourself from reading slashdot and such [22:36:32] <BBB> and convert to interacting with real people, e.g. bankers/traders, business owners, consultants, contracters, etc. [22:36:46] <BBB> they provide money and business [22:36:50] <BBB> not slashdot crowd [22:36:52] <microchip_> so they can steal all your money :p [22:37:07] <BBB> if I get ~1% of their money, I'll be terribly happy [22:37:26] <BBB> 1% of the money of the average slashdot loser is not very much, on the other hand [22:37:32] <peloverde> If you just follow the money Xiph managed to pull in $100K from Mozilla, On2 managed to pull in way too much from Google [22:38:16] <BBB> and you think ffmpeg won't be funded by google? [22:38:36] <Dark_Shikari> google's official policy is to refuse to admit they even use ffmpeg [22:38:48] <BBB> you seem a little down... do you live near new york? I'll offer you some free beer and better liquors [22:38:58] <Dark_Shikari> but yeah, peloverde, stop worrying so much [22:39:01] <peloverde> Dark_Shikari, lies [22:39:03] <BBB> Dark_Shikari, they admit using it in chrome [22:39:07] <BBB> or chromium [22:39:09] <Dark_Shikari> BBB: not for their backend though [22:39:14] <Dark_Shikari> for chrome obviously, they distribute it [22:39:16] <BBB> youtube? [22:39:24] <peloverde> for chrome they admit it as you said [22:39:41] <Dark_Shikari> yes e.g. youtube [22:39:45] <Dark_Shikari> btw [22:39:50] <Dark_Shikari> vimeo, hulu, facebook, and yotuube all use x264 now [22:39:53] <Dark_Shikari> let's see if we can get the entire top 10 [22:39:55] <BBB> we have no contact in their youtube team [22:40:03] <Dark_Shikari> yes we do. Pascal [22:40:05] <BBB> get a contact [22:40:06] <BBB> .. [22:40:07] <BBB> profit [22:43:06] <BBB> ask him if he uses ffmpeg :) [22:44:59] <Dark_Shikari> they do [22:45:01] <Dark_Shikari> but they can't say it publicly [22:45:04] <Dark_Shikari> for some weird reason [22:45:45] <BBB> blah [22:45:54] <BBB> I barely care [22:46:07] <BBB> peloverde, don't forget that vlc is downloaded enough times to make fedora irrelevant [22:46:21] <BBB> peloverde, point being; don't listen to the slashdot crowd [22:46:51] <peloverde> The VLC thing is kind of funny when VLC is so loved yet we are so hated [22:47:18] <Dark_Shikari> VLC is more popular than all linux distros combined [22:47:54] <astrange> if they admitted youtube could process proprietary game codecs i guess they think it'd lead to problems? [22:48:13] <Dark_Shikari> well so can facebook [22:48:14] <Dark_Shikari> and they admit it [22:48:16] <Dark_Shikari> and so can vimeo [22:48:18] <Dark_Shikari> and so can hulu [22:48:24] <BBB> peloverde, why do you think we're hated? [22:48:28] <BBB> peloverde, I don't quite understand [22:49:04] <Dark_Shikari> BBB: because he listens to a very very small vocal minority [22:49:06] <peloverde> All the comments on a recent Ars story [22:49:08] <Dark_Shikari> which is a minority of a minority of a minority [22:49:37] <Dark_Shikari> freetards are a minority of people who care about free software [22:49:46] <Dark_Shikari> people who care about free software are a minority of linux/osx/etc users [22:49:52] <Dark_Shikari> linux/osx users are a minority of computer users [22:50:17] <peloverde> A huge portion of the windows firefox users are drinking the coolaid now [22:50:34] <Dark_Shikari> "huge portion"? [22:50:44] <BBB> coolaid? [22:50:46] <Dark_Shikari> a "huge portion" of windows firefox users are grandmas who don't know what html is [22:50:59] * BBB smiles [22:51:15] <BBB> peloverde, if you're ever in new york, I'll get you free beers [22:51:25] <peloverde> BBB, thanks [22:57:36] <peloverde> I guess I'm just sick of hearing nutty shit like a high profile mozilla engineer claiming that even suggesting people use ffmpeg2theora is contributory infringement [22:58:12] <Dark_Shikari> lol [23:07:44] <CIA-90> ffmpeg: alexc * r21886 /trunk/libavcodec/aac.c: Add some AAC buffer overread checks. [23:15:31] <BBB> peloverde, I'm sorry you take it so badly, but from the number of people saying thanks every time we RE a new codec, I think we're doing allright [23:17:57] <peloverde> that's good to hear [23:22:06] <iive> i'm read /. daily, i haven't noticed tendency in hating ffmpeg there. But then again, i don't read comments with score -1 troll. [23:25:22] <iive> janneg: do you have idea why blender needs so much memory? [23:28:33] <mru> so... how do render it? [23:29:58] <iive> pixel by pixel :) [23:30:24] <janneg> blender scenes/01_intro/01.blend [23:30:41] <janneg> and F12 to render the current frame [23:34:09] <janneg> or blender -b scenes/01_intro/01.blend -f x to render frame x from command line [23:38:41] <CIA-90> ffmpeg: michael * r21887 /trunk/libavcodec/h264_cabac.c: [23:38:41] <CIA-90> ffmpeg: Move abs() from decode_cabac_mb_mvd() to the code that writes mvd_cache. [23:38:41] <CIA-90> ffmpeg: 4-8 cycles faster [23:40:45] <Dark_Shikari> ... fucking good idea michael [23:40:55] * Dark_Shikari thought of that one just the other day... [23:42:34] <mru> 3GB [23:42:40] <mru> 3.8 [23:43:19] <mru> seems to have leveled out [23:43:29] <mru> err [23:43:32] <mru> 4.1 [23:43:43] <mru> 4.5 [23:43:49] <mru> damn, this thing is hungry [23:43:55] <mru> 4 [23:43:55] <mru> 5 [23:44:46] <mru> and it's using 750% cpu [23:48:23] <mru> done [23:48:29] <mru> peaked at 5.2GB [23:48:48] <Dark_Shikari> but you have 12GB, so you laugh [23:53:49] <Dark_Shikari> ok, quick question, what's the best way to do a SWAR absolute value? [23:53:57] <Dark_Shikari> I know that you can do one easily for the case of (x<<16) + y [23:54:07] <Dark_Shikari> but that's a bit different than the case of two 16-bit values packed into a 32-bit [23:54:12] <Dark_Shikari> due to sign [23:54:29] <Dark_Shikari> and I need the latter, because I want to do an SWAR absolute value during a packed store [23:55:31] <janneg> commandline rendering seems to be more stable [23:57:59] <mru> Dark_Shikari: trivial on arm... [23:58:06] <mru> 3 insns [23:58:16] <Dark_Shikari> in C [23:58:22] <Dark_Shikari> i.e. using machine-independent ops [23:58:40] <mru> if you're going to be doing this a lot you should probably have asm for it [23:58:47] <Dark_Shikari> no, just in one place [23:59:43] <Dark_Shikari> I need to turn pack16to32(x,y) into pack16to32(abs(x),abs(y)) [23:59:49] <Dark_Shikari> preferably faster than the latter.

1 0