Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

April 2010

1 participants
30 discussions

IRC log for 2010-04-09
by irc＠mansr.com 10 Apr '10

10 Apr '10

[00:00:37] <mfg> nm, found it [00:00:39] <mru> greater than pcr [00:02:11] <mfg> I think i'm asking the wrong question. How should I be calculating the current length (in time) of a stream based on the data I've read so far in the http stream? [00:02:22] <mfg> this is for the shoutcast stuff I'm trying to get in [01:19:36] <Kovensky> "In 40770 I'm more concerned with ffmpeg's SSSE3 assembly, which should be dispatched to with cpuid" <-- I can't parse this sentence [01:19:55] <astrange> where? [01:25:54] <Kovensky> * @peloverde pulls hair at the response to crbug.com/39969 [01:29:54] <peloverde> some people are getting SIGILLs because they compile with "-march=pentium4 -msse2 -mfpmath=sse" [01:31:58] <Kovensky> lol @ -march=pentium4 [01:32:04] <Kovensky> I thought haruhi had retroactively unreleased it [01:32:22] * Kovensky pokes pengvado for explanations [01:33:41] <peloverde> So clearly the natural response is to manually set HAVE_SSSE3 and HAVE_LLRINT to 0 [01:33:59] <Kovensky> lulz [01:34:37] <janneg> with patches to config.h of course [01:34:44] * Kovensky wonders what's so hard in just using runtime cpu detect [01:35:01] <astrange> you can't turn runtime cpu detect off [01:35:11] <astrange> the configure option doesn't affect it [01:35:12] <Dark_Shikari> the solution is to be like x264 [01:35:15] <Dark_Shikari> don't have a HAVE_SSSE3 [01:35:17] <Dark_Shikari> then people can't get confused [01:35:42] <Kovensky> astrange: don't you have to turn it on in the first place (--enable-runtime-cpudetect) [01:35:56] <Dark_Shikari> that's for swscale [01:36:01] <peloverde> it says in config.h to not edit it manually [01:36:05] <astrange> no [01:36:11] <astrange> lavc does it no matter what [01:36:15] <Kovensky> oic [01:36:36] <Kovensky> weird option name / description then :v [01:38:40] <peloverde> why are the policies different? [01:40:11] <astrange> they were written separately and the swscale stuff was just stuck in ffmpeg configure at some point [01:40:14] <astrange> ...i think [01:40:34] <astrange> it should respect it, people keep trying to make ./configure --cpu disable stuff [01:40:43] <astrange> which makes no sense as long as runtime detection is on [01:42:05] <peloverde> it still makes sense [01:42:14] <peloverde> makes the binary smaller if its features you will never use [01:42:35] <peloverde> also maybe they are using buggy assemblers that don't support certain instruction sets [01:43:26] <astrange> you can save a lot more by disabling runtime detect so it only does sse2 instead of mmx+sse2 [01:46:46] <peloverde> can't we just not compile mmx when there is sse or sse2 on x86-64 by default? [01:47:10] <astrange> just disabling mmx doesn't work because some don't have newer versions [01:47:20] <astrange> well, and because --disable-mmx disables everything, but even if it didn't do that [01:48:43] <peloverde> yes, but can't we guard mmx when there is sse with !ARCH_X86_64? [01:49:21] <astrange> i think disabling cpudetect would be simpler [01:49:32] <astrange> too bad it depends on compiler optimization to delete the unused dsp functions [01:49:47] <peloverde> but then you can't use anything newer than sse2 reliably [01:50:04] <peloverde> I'm thinking about for instance distro packages for amd64 [01:50:32] <peloverde> not someone making an optimized swscale for their own system [01:50:52] <Dark_Shikari> well I don't think it's very important to care about gentoo users anyways [01:53:00] <peloverde> but we all know I'm an swscale hater [01:53:15] <peloverde> so i probably shouldn't be trusted on this manner [01:53:30] <peloverde> s/manner/matter/ [01:55:15] <peloverde> also the fact that they need sse in general to pass webkit layout tests makes me think they or webkit are doing something very wrong [01:56:33] <astrange> i thought webkit texts used text dumps and not pixel testing [01:56:35] <astrange> *tests [01:56:41] <astrange> maybe they print too much precision [02:00:33] <peloverde> jai, you were looking for me earlier? [02:26:34] <Dark_Shikari> what's a good way in bash to pick a random file (recursively) from inside a folder? [02:30:06] <Dark_Shikari> hmm, sweet, sort -R [02:35:50] <votz> Dark_Shikari: could also do something like create an array of the files and then index into it randomly [02:36:27] <Dark_Shikari> now I have a set of files and I need to name them 1.png, 2.png ... [02:36:28] <votz> something like: set -- *; numfiles = $#; echo ${$((RANDOM%numfiles))} [02:36:31] <Dark_Shikari> what's the easiest way to do that? [02:36:33] <votz> or something like that [02:36:46] <votz> this is why I stopped writing scripts in bash and started writing them in python :) [02:38:09] <votz> Dark_Shikari: I would just do this kind of stuff in python [02:38:27] <votz> I can never remember the syntax for bash and I spend more time looking up stuff exactly like this [02:38:36] <Dark_Shikari> oh this is fun [02:38:38] <Dark_Shikari> I can use bc [02:38:40] <votz> or choose your scripting language of choice [02:38:49] <votz> bc? [02:39:26] <Dark_Shikari> a = $(echo $a+1 | bc) [02:39:30] <Dark_Shikari> i.e. a++ [02:39:32] <Dark_Shikari> lol bash [02:41:16] <votz> lol [02:42:10] <relaxed> a=$(($a+1)) [02:43:31] <Dark_Shikari> I love how bash has five billion ways to do every single thing [02:43:35] <Dark_Shikari> none of which are really very clean [02:46:32] <relaxed> what are you trying to do? [02:47:06] <Dark_Shikari> make a loop that renames files to 0.png ... X.png [02:47:09] <Dark_Shikari> already done though [02:49:37] <Dark_Shikari> oh. ugh. I now need to reorder the frames. they got inadvertantly "sorted" [02:49:56] <Dark_Shikari> Guess I can abuse the same script. [03:14:27] <pengvado> <peloverde> can't we just not compile mmx when there is sse or sse2 on x86-64 by default? [03:14:30] <pengvado> not in general [03:15:07] <pengvado> there are plenty of functions for which we have mmx but not sse2 versions [03:15:32] <pengvado> so you can't globally disable lower levels, it has to be a function by function decision [03:17:38] <peloverde> that's exactly what I mean [03:17:40] <peloverde> *meant [03:17:47] <peloverde> doing it function by function [03:21:34] <Dark_Shikari> what's a good way to convert, say a 1920x170692 yuv file to bmp? [03:21:35] <Dark_Shikari> or png [03:25:01] <pengvado> ffmpeg -s 1920x170692 -i foo.yuv -y foo.png [03:25:14] <Dark_Shikari> Isn't swscale capped at 4k? [03:25:48] <Dark_Shikari> Or was that cap removed recently? [03:25:52] <pengvado> 4k width, and anyway I increase that define for my own builds [03:25:57] <Dark_Shikari> Aha! [03:25:59] <Dark_Shikari> it's width-only. [03:26:01] <Dark_Shikari> Nice. [03:27:36] <Dark_Shikari> are higher compression levels of zlib slower to decode? [03:27:38] <Dark_Shikari> or only encode [03:28:43] <pengvado> higher zlib levels should be faster to decode because bits cost time [03:29:24] <Dark_Shikari> ah k [03:30:24] <pengvado> higher png levels might be slower due to the spatial prediction, or not if the fast level consist of always using paeth instead of just sometimes. [04:44:43] <peloverde> was M_SQRT2 removed in c99? [04:46:20] <peloverde> I see it listed here: http://www.opengroup.org/onlinepubs/009695399/basedefs/math.h.html [04:46:33] <peloverde> but a simple test program fails with c99, but compiles fine with cc [04:47:02] <astrange> M_SQRT2 is in xsi, not c [04:47:15] <astrange> might need one of those -D_???_SOURCE things [04:47:38] <peloverde> Ahh, the |XSI> is nested funny [04:47:56] <peloverde> is there any reason why they couldn't have put it in C99, it's a fricken define [04:47:59] * peloverde hates C [04:48:35] <Dark_Shikari> wtf is M_SQRT2? [04:50:03] <peloverde> 1.4142135623730950488 [04:51:00] <peloverde> A constant in math.h [04:55:38] <Dark_Shikari> ah [04:56:05] <peloverde> can I just go and stick it in mathematics.h or do I need to submit a patch? [05:24:07] <merbzt1> peloverde: add it under ifndef [05:39:04] <peloverde> Do people want baseline PS first or should I just do the whole thing at once? [05:39:22] <merbzt1> peloverde: what is most easy for you ? [05:39:30] <Dark_Shikari> what is baseline ps? [05:39:36] <av500> peloverde: I never needed PS :) [05:40:13] <peloverde> baseline ps is ps with the 34 stereo bands tool mode turned off and ipd/opd turned off [05:40:29] <peloverde> it's more-or-less a strict subset [05:40:59] <Dark_Shikari> what do encoders actually use? [05:41:21] <peloverde> there are two ways of decoding the same file [05:41:53] <peloverde> level 3 decoders only require baseline [05:42:00] <peloverde> level 4 and 5 require full quality [05:42:45] <peloverde> i'm sorry 2, 3, 4 are allowed to use baseline [05:43:02] <peloverde> 5 must use full quality [05:43:34] <Dark_Shikari> ugh [05:43:36] <Dark_Shikari> I hate how aac does that [05:43:54] <peloverde> (there is no level 1) [05:46:02] <peloverde> AAC doesn't do that [05:46:07] <peloverde> only HE-AAC [05:46:22] <peloverde> (v1 and v2) [05:46:29] <Dark_Shikari> they're still aac though [05:46:50] <peloverde> then mp3pro is mp3 :) [05:47:28] <peloverde> AAC is actually a very clean and simple format [05:47:56] <peloverde> SBR is basically a big messing guided post-processor running in parallel [05:48:37] <Dark_Shikari> isn't the spec published by the same people? [05:48:59] <merbzt1> well published by iso, written by many [05:49:14] <merbzt1> ct did most of sbr iirc [05:49:53] <Dark_Shikari> I mean that's like saying that h264 high profile isn't h264... [05:50:08] <Dark_Shikari> just because it was published later under a slightly different nam [05:50:09] <Dark_Shikari> *name [05:50:09] <peloverde> no, SBR was developed independently [05:50:11] <Dark_Shikari> ah [05:50:43] <peloverde> AAC was mostly Sony, NTT, Dolby, FhG, and AT&T [05:51:09] <peloverde> Then CT showed up with their codec agnostic SBR [05:51:31] <merbzt1> NTT added their vqf low bitrate stuff [05:51:50] <merbzt1> Sony added SSR IIRC, abit like atrac [05:52:12] <peloverde> yes [05:52:31] <Dark_Shikari> aac seems like a giant mess [05:52:38] <merbzt1> ohh, indeed [05:52:51] <peloverde> AAC not a mess, MPEG-4 audio mess [05:53:03] <merbzt1> what peloverde said [05:53:47] <peloverde> there are a two or three awkward things about the AAC bitstream format but nothing seriously messy [05:54:19] <merbzt1> sbr signaling and what else ? [05:54:53] <peloverde> the PCE [05:55:16] <peloverde> zero-sized codebook sections [05:55:27] <kierank> what about that thing japanese tv does for changing between 2.0 and 5.1? [05:55:39] <peloverde> that's out of spec [05:55:47] <kierank> ah [05:56:49] <peloverde> and it's related to the PCE as well (unless they are using mpeg surround to do it) [05:57:13] <peloverde> The main profile predictor is messy [05:57:23] <peloverde> but no one uses main profile [05:57:49] <kierank> I wonder what the european aac channels do for 5.1->2.0 switching [05:58:23] <merbzt1> like the sprite thingy in mpeg4 video [05:58:35] <peloverde> I don't know, maybe send a new pce (out of spec behavior) [05:59:04] <merbzt1> is there no support for channel reconfiguration ? [05:59:13] <peloverde> one hack would be to just be to blank out the LFE, second CPE, and center channel [05:59:35] <peloverde> you can code an empty channel in AAC very efficiently [06:00:00] <peloverde> they could also use coupling to mix the same CPE into all 5 channels [06:00:04] <merbzt1> ac3 just change the channel configuration from one frame to another, can't aac do that too ? [06:07:22] <peloverde> there are some things that look they are there for that purpose, but it says that how to interpret them is undefined [06:09:42] <peloverde> See section "4.5.1.2 Program config element (PCE)" [06:12:30] <peloverde> It looks like if all PCEs are sent inband then you can change it with PCEs [06:12:53] <peloverde> we don't support that feature at the moment [06:16:32] <peloverde> I really need to look at boradcast use of AAC again at somepoint [06:16:46] <peloverde> living in the ATSC world it hasn't been a high priority [06:17:04] <kierank> do you have samples peloverde? [06:17:19] <saintd3v> wish the FTC would get out of the 90s [06:17:57] <peloverde> there may be one or two [06:18:20] <peloverde> some with a country name and the channel count change marked in the name would be good [06:18:57] <kierank> I have one japanese clip with a channel count change but you might well have fixed that [06:19:18] <peloverde> e.g. dvb_aac_jp_5.1_to_2.ts [06:31:55] <pJok> mornings :) [06:32:41] <kshishkov> goda morgnar [06:32:48] <kshishkov> (even if you have surgery) [06:34:03] <pJok> 3œ hours [06:35:26] <andoma> god morgon alltihopa! [06:35:44] <kshishkov> hej (-: [06:41:01] * peloverde pulls hair at crbug.com/39969 again [06:41:32] <peloverde> "ffmpeg.gyp seems to build sse2 source files unconditionally on ia32/x64 (like source/patched-ffmpeg-mt/libavcodec/x86/idct_sse2_xvid.c and source/patched-ffmpeg-mt/libavcodec/x86/vp3dsp_sse2.c)" REALLY?! [06:44:35] <aaronl> is this that chromium bug report again? [06:44:53] <aaronl> that blew my mind [06:46:49] <peloverde> Especially because runtime CPU check is explained once already in that bug [06:46:50] <superdump> peloverde: maybe they don't want it to build them if they're patented [06:46:56] <superdump> because they see xvid and vp3 or so [06:47:07] <peloverde> vp3 is theora [06:47:14] <peloverde> and the bug is about SIGILLs [06:48:19] <peloverde> and the note that it also impacts Celeron makes me think it's not because of extra code in the binary [06:48:30] <aaronl> i also read the linked bug #9007 report [06:48:31] <peloverde> (the complaint that is) [06:48:44] <aaronl> which was about SIGILLs due to -msse2 on ia32, back in march 2009 [06:48:52] <aaronl> and that report was even dumber [06:49:10] <peloverde> people are getting SIGILLs becasue of "-msse2 -mfpmath=sse", hacking up config.h and the make files wont save them from any of it [06:49:12] <aaronl> it looks like it took them months to stop blaming the ubuntu package maintainer, figure out that they were forcing -msse2, and decide what to do about it [06:50:26] <siretart> them? [06:50:49] <aaronl> the chromium devs [06:51:18] <peloverde> chromium devs and fta (the ubuntu maintainer) [06:52:28] <peloverde> basically chromium was SIGILLing on x86_32, so they turned off "-msse" and everyone was happy [06:52:52] <peloverde> then they started building ffmpeg with the chromium build system and people started getting SIGILLs again [06:53:13] <peloverde> because they are using the unmodified build system that has "-msse2" [06:53:40] <aaronl> and apparently they still don't realize it's not because sse asm is turned on in ffmpeg [06:54:02] <siretart> ah, I see. fun [06:54:11] <peloverde> so instead of turning that off in the build system again, the ubuntu maintainer started trying to turn off the asm in FFmpeg to fix it [06:54:19] <peloverde> I don't know whether to laugh or cry [06:54:25] <siretart> btw, does libswscale properly runtime detect sse2 these days? [06:55:02] <peloverde> I keep trying to catch the guy on IRC whenever he updates the bug [06:55:48] <peloverde> I don't know, I know runtime detect is off by default for swscale [06:56:04] <siretart> oh [06:56:07] * siretart makes a note [06:56:37] <peloverde> I don't know why it is off by default [06:59:27] <peloverde> I try not to think about swscale most of the time [07:04:13] <peloverde> do you have bugreports about SIGILL? :) [07:56:16] <KotH> hoi zäme [07:57:43] <scaphilo> hallo [07:58:28] <kshishkov> ÑÑÑÐŽÑÑ [07:58:33] <kshishkov> *shalom [07:58:42] <av500> moin [07:59:24] <thresh> ÑÑÑÐŽÑÑ ÑÐŸÐ¶Ðµ ÐœÐžÑÐµÐ³ÐŸ [08:00:03] <kshishkov> ÑÐŸÐ»ÑÐºÐŸ ÑÐ»ÐµÐ³ÐºÐ° Ð¿ÐŸ-Ð»ÐŸÑÐ°ÐŽÐžÐœÐŸÐŒÑ [08:03:20] <scaphilo> has anyone an idea why my motion compensation does not work anymore when i have dct-values instead of the dequanticed idct values in the picture data? when the motion vecor is zero everything works fine i have no clue why this happens perhaps its the dsputil-function wich changes my block [08:04:23] <scaphilo> is it possible to remove the averaging function which is used in the b frames (as discussed yesterday) [08:05:48] <KotH> kshishkov: http://translate.google.com/#auto|en|%D1%8B%D1%80%D1%84%D0%B4%D1%89%D1%8C [08:07:07] <av500> only slightly on a horse [08:07:30] <scaphilo> saved block in memory is: 255 128 128 128 128 128 128 128, 128 128 128 128 128 128 128 128 (7 times) white block But the bock i get is: 160 160 128 128 128 128 128 128, 160 160 128 128 128 128 128 128, 128 128 128 128 128 128 128 128 (6 times) [08:11:01] <kshishkov> KotH: http://translate.google.com/#auto|en|kveldsflyet%20fra%20Oslo [08:11:47] <KotH> rotfl [13:18:00] <jai> hey BBB [13:18:06] <BBB> howdy [13:18:43] <BBB> ah, audio conversion [13:18:44] <BBB> good task [13:18:48] <kshishkov> have you applied as a student yet? [13:18:57] <BBB> no, I don't think I'll have time [13:18:57] <jai> kshishkov: yeah :) [13:19:27] <jai> oh, i didnt know who it was directed towards [13:19:32] <jai> meh [13:20:45] <BBB> lol :) neither did I [13:20:49] <BBB> we have 7 students now [13:20:53] <BBB> more may come [13:20:55] <BBB> so that's ok [15:19:54] <scaphilo> short question: Where does a motionvector[forward][0][0]=-1 and motionvector[forward][0][1]=15 point to? frame based [15:20:25] <scaphilo> next mb in same row [15:20:54] <kshishkov> depends on MV resolution [15:21:17] <scaphilo> oh am i forgott mpeg2 [15:21:30] <kshishkov> could be (-1, 15) or (-1 1/2; 7 1/2) [15:21:36] <kshishkov> probably the latter [15:21:59] <kshishkov> err (-1 + 1/2; 7 + 1/2) [15:22:31] <mru> -1/2 [15:23:23] <scaphilo> i see, its a bit strange because i dont get the correct block back from the motion compensation [15:23:57] <kshishkov> it's interpolated because of those 1/2 [15:24:26] <scaphilo> oh no, hmm that could be the reason [15:24:30] <kshishkov> mru: correct, but it's more convenient to represent it that way for MC [15:25:21] <scaphilo> i dont know what the function in the dsputil.c does [15:25:37] <scaphilo> pix_op[0][dxy](dest_y, ptr_y, linesize, h); [15:27:15] <scaphilo> im not enough experienced in c unfortunately [15:28:37] <scaphilo> anyone knows where this interpolation is done? i want to have a look at the algorithm [15:29:32] <kshishkov> simple averaging IIRC [15:29:58] <mru> (a+b+1)>>1 [15:30:02] <kshishkov> I suspect it's OPNAME ## _pixels_xy2_c from dsputil.c in your case but good luck understanding it [15:32:00] <scaphilo> hmm shit this does not work with dct coefficients of cause [15:32:12] <scaphilo> hmm i have to finde an other way [15:32:53] <scaphilo> thx for help [15:35:14] <kshishkov> well, if you transform those blocks too you can average DCT coeffs ;) [15:39:57] <av500> kshishkov: its a linear transform, no? [15:40:44] <kshishkov> whatever, but T(a+b) = T(a) + T(b) in case of FFT and DCT [15:41:39] <mru> isn't that what linear means? [15:42:00] <kshishkov> but DCT is curvy [15:42:11] <mru> yes, linear curves [15:42:39] <KotH> kshishkov: DCT is just one point in hilbert space :) [15:42:42] <scaphilo> am yes the thing is you cant average half of a block [15:43:04] <scaphilo> when this half is empty [15:43:30] <scaphilo> or do i understand something wrong? its an average of a half block not of a half macroblock [15:43:51] <kshishkov> KotH: have I mentioned that I've forgotten all math long time ago? [15:44:07] <kshishkov> nope [15:44:22] <mru> everybody has [15:44:25] <mru> no need to mention it [15:44:26] <kshishkov> it's an average of block and block shifted by one pixel [15:44:39] * elenril never knew what dct is =p [15:44:48] <scaphilo> oh my god then its impossible to do with dct's [15:45:09] <mru> what are you trying to do? [15:45:11] <scaphilo> just imagin a white block is in dct just one value [15:45:13] <av500> to do what? [15:45:24] <scaphilo> well openloop transcoding [15:45:32] <scaphilo> i just wannet to make the mc [15:45:40] <scaphilo> no practical use at all [15:46:06] <KotH> scaphilo: you cannot perform mc on DCT values [15:46:18] <av500> maybe fc [15:46:20] <scaphilo> now i know [15:46:31] <KotH> scaphilo: well, you can.. but the math behind it is more complicated than just doing an iDCT [15:46:43] <av500> KotH: just redefine "motion" [15:47:21] <scaphilo> is it possible to only allow the encoder making movings of about 8 pixels or a multiplication of it [15:47:28] <KotH> av500: i'm not a mathematitian :) [15:48:03] <KotH> scaphilo: use 16pixel for 4:2:0 subsampled, 8x8 DCT based codecs [15:48:31] <KotH> scaphilo: otherwise the colour CrCb info will be shifted by 4 pixels [15:50:37] <scaphilo> ah i see ill try that just for test [15:50:45] <scaphilo> then it should work for my app [15:51:41] <KotH> hmm.. you are aware that motion vectors usually do not point to a single 8x8 DCT block? [15:52:00] * KotH wonders what exactly scaphilo is doing [15:53:20] <scaphilo> normaly the whole macroblock, right :-). The thing is, i want to test if i correctly made my changes in the code currently i transcode the video without idct dct dequantisation and quantisation [15:53:33] <av500> scaphilo: from what to what? [15:53:34] <scaphilo> to go is still motioncompensation and motionestimation [15:53:40] <scaphilo> mpeg2 to mpeg4 [15:53:45] <scaphilo> part2 [15:54:39] <scaphilo> dam i studied arround for 16 hours and didnt find out why it didnt work with this motion compensation :-( [15:54:56] <scaphilo> shit but i couldnt explain it befor [15:55:15] <KotH> scaphilo: nope, the MV point to a "random" place in half or quater pixel resolution. dh if you start shuffling around MV, you have to be carefull what happens when you involve partial macroblocks [15:56:12] <av500> KotH: dh? [15:56:18] <scaphilo> which means [15:56:24] <scaphilo> german [15:56:52] * av500 forgot scaphilo was compatible [15:57:19] <KotH> lol [15:57:24] <mru> when he's in that mode [15:57:31] <mru> in native mode he's only somewhat compatible [15:57:37] <mru> koth, that is [15:57:38] <KotH> please correct me someone, if i say something wrong [15:57:42] <scaphilo> :-) hmm ok KotH, ill leave this step and go on to the full open loop implementation [15:57:55] <mru> omg, someone is wrong on the internet!!! [15:58:11] <av500> keeps you awake at nights... [15:58:20] <KotH> scaphilo: die motionvektoren zeigen von ganzen makroblock auf regionen. es sind verschiebungsvektoren die irgendwo hin zeigen können [15:58:24] <scaphilo> very strange in here :-) [15:58:42] <KotH> scaphilo: bei mpeg2 haben diese vektoren eine auflösung von einem halben pixel, bei mpeg4/h.264 haben sie viertelpixel [15:58:49] <mru> motion? not bewegung or something? [15:59:04] <av500> denglish [15:59:06] <kshishkov> mru: is KotH summoning Satan or what? [15:59:15] <scaphilo> exacly [15:59:25] <KotH> av500: should i have said "bewegungsvektoren" ? :) [15:59:26] <av500> kshishkov: no, only Dark_Shikari [15:59:42] <scaphilo> KotH thank you very much, das hat jetzt schon noch geholfen. [15:59:50] <scaphilo> i have an other problem, the qscale is different [15:59:58] <scaphilo> but i fixed it to one [15:59:59] <mru> mpeg4 also allows MVs per block [16:00:06] <mru> where mpeg2 has them per MB [16:00:21] <av500> I guess mpeg4 allows all of them to be the same [16:00:26] <mru> of course it does [16:00:45] <scaphilo> it should work i think - well i hope it works :-) [16:01:10] <av500> hoffnung stirbt immer zuletzt... [16:01:24] <KotH> scaphilo: if you are in zh, you can drop by here and i give you a short tour trough video coding (as far as i know it, which is very little) [16:01:57] <scaphilo> im sure you know a little ;-) but a very little more than me [16:02:03] * KotH blames everyone here, including himself, for not working on BoW [16:02:54] <scaphilo> i think about that KotH thank you for inviting, do you still work on the ETH [16:03:05] <KotH> hmm.. maybe i should take my laptop with me this weekend and write a few lines during the train trip [16:03:15] <KotH> scaphilo: nope, i graduated long ago [16:03:19] * KotH is a very old fart [16:03:46] <kshishkov> KotH: well, compared to Dark_Shikari (and maybe superdump) we all are [16:03:58] <scaphilo> i work as an "assistent" at HSR [16:04:04] <scaphilo> since 2 years [16:04:10] <KotH> s/since/for/ [16:04:12] <KotH> ;) [16:04:18] <scaphilo> dam [16:04:18] <mru> since is correct [16:04:23] <KotH> is it? [16:04:30] <mru> oh yes [16:04:39] <KotH> mru: hmm.. do you want to tell me that all my english teachers were wrong? [16:04:50] <mru> it implies an ongoing activity that started 2 years ago [16:05:14] <KotH> hmm... ok [16:05:18] * KotH takes notes [16:05:24] <scaphilo> :-) im not [16:05:30] <mru> if you say "I worked ... for 2 years" it means it lasted for 2 years but is over now [16:05:30] <kshishkov> with "ago" missing it looks like somebody started working _when_ two years old [16:05:35] <KotH> scaphilo: you are most probably still younger than i am [16:05:44] <mru> kshishkov: wrong [16:05:55] <kshishkov> mru: I'd use "have been working for 2 years" [16:06:04] <mru> that's also correct [16:06:11] <av500> kshishkov: in ukraine? [16:06:17] <scaphilo> well i would really like to talk a little more but i gtg [16:06:35] <KotH> schös wuchenend und gnüss d'sunne! [16:06:43] <scaphilo> danke gliichfalls :-) [16:06:46] <scaphilo> at all [16:06:53] <scaphilo> or to [16:06:54] <mru> KotH: guess what, the sun is shining here too [16:07:03] <KotH> mru: that must be an illusion! [16:07:11] <KotH> mru: or you're still in .se :) [16:07:12] <mru> well, this isn't london... [16:07:18] <kshishkov> av500: that was an example, I have no intent of working here. And I'm not sure local wages justify using verb "working" anyway [16:07:20] <mru> no, I'm in southampton [16:07:42] <KotH> kshishkov: slavery? [16:08:17] <kshishkov> KotH: self-slavery sometimes [16:08:21] <peloverde> Also with "since" if you are using a duration (vs a specific time) you need an "ago" [16:09:11] <KotH> peloverde: "since 2 years ago" ? :) [16:09:23] <peloverde> yes [16:09:24] <kshishkov> KotH: yes [16:09:25] <KotH> er.. s/:)// [16:09:32] * KotH wonders where that smiley came from [16:10:36] * KotH wonders what he is still doing here [16:11:01] <Honoome> KotH: avoiding work! [16:11:07] <Honoome> that was an easy answer :P [16:11:11] * KotH wonders what effect school uniforms have on children [16:11:37] * KotH wonders why he is asking himself all these questions [16:12:04] <mru> uniforms make them all look alike [16:12:04] <kshishkov> LHC affecting brain cells? [16:12:11] <Honoome> maybe you considered the fact that female high-school uniforms have effects on adolescents ^^ -- yeah I'm the one avoiding work I guess [16:12:26] <KotH> mru: that's the outside effect, but what is the psychological effect on them? [16:12:28] <av500> no, me too [16:12:34] <mru> KotH: go to japan and see [16:12:45] <KotH> mru: been there, done that [16:12:55] <KotH> mru: missing reference schools [16:13:02] <av500> I thought school uniforms were invented by anime guys, no? [16:13:13] * KotH doenst know of any schools that do not have school uniforms in .jp [16:13:21] <KotH> av500: nope, they are older [16:13:31] <kshishkov> av500: no, Japanese school uniforms were borrowed from pre-WWI Germany [16:14:09] <KotH> av500: iirc japanese started using school uniforms in early meiji era (1870s), and used the preusian school uniforms as an example [16:14:11] <kshishkov> then probably Germans decided not to be associated with anime and ditched them (just a guess) [16:14:54] <KotH> kshishkov: i think it was that the allied forces in WWI forced the dissolution of preussian schools and their uniforms after WWI [16:15:42] <kshishkov> KotH: they may have anticipated anime and could not stand a thought of kawaii Germans [16:16:30] <Honoome> kshishkov: isn't that âŠ you know âŠ a oxymoron? :P [16:16:56] <kshishkov> Honoome: my point exactly [16:17:22] <Honoome> [quite sure next time Diego is going to kick me hard but âŠ :P] [16:17:45] <twnqx> what to you think the WWs *really* were about... [16:17:48] <twnqx> do* [16:18:10] <kshishkov> "German starts and loses" activity [16:18:34] <twnqx> true, but there must be areason people are so desperate to start a war! [16:19:15] <kshishkov> it's called "untermensch" - Serbs and Poles [16:19:41] <KotH> WWI was all about "HE SHOT MY SON!!!!einself" [16:22:16] <kshishkov> you know that German occupation plan for Ukraine in WW2 included building autobahns on its territory? Local people could not stand it and that's why Germans eventually lose [16:23:29] <kshishkov> building good roads in Ukraine is unhuman [16:36:06] <KotH> kshishkov: http://pics.nase-bohren.de/japan_vs_germany.jpg [16:37:20] <av500> school uniforms? [16:37:50] <kshishkov> KotH: be thankful you've not seen Russian cosplay [16:39:17] * KotH is [17:31:37] <kshishkov> BBB: haven't changed your mind yet? [17:31:46] <BBB> no [17:32:05] <BBB> I don't think I want to commit that much time to it while I should graduate [17:32:10] <kshishkov> fine [17:32:11] <BBB> better be a mentor [17:32:19] <kshishkov> :) [17:32:50] <jai> heh [17:33:24] <kshishkov> I admit it was hard to me to finish RTMP support while being in Stockholm [17:35:27] <kshishkov> still, I think you'll get better student this year [17:53:37] <CIA-1> ffmpeg: jai_menon * r22823 /trunk/ffplay.c: ffplay : Add 's' to the list of supported commands. [17:58:05] <BBB> oops [18:43:37] <nfl> BBB: I've decided to take up amr-wb [18:47:08] <_av500_> \\\ooo/// [18:47:58] <jai> _av500_: you actually use amrwb? [18:48:23] <_av500_> no [18:48:42] <_av500_> but i cheer up all gsoc students [18:50:52] <Honoome> it's all a revision closer to total world domination ;) [18:51:24] <jai> _av500_: ah, the burden of a mentor :) [18:52:26] <nfl> _av500_: thanks :) [19:11:35] <DonDiego> gtg, cu [19:12:33] <_av500_> jai: i like to see young innocent people submit themselves to ffpatch review system [19:13:06] <jai> _av500_: heh :) i see now [19:15:36] <elenril> av500: i _knew_ you were evil [19:15:45] <elenril> lol [19:16:01] <jai> heh [19:17:20] <drv> it builds character ;) [19:23:37] <pJok> char build; ? [19:27:40] <Honoome> build = rand() & 0xff; [19:32:20] <jai> Honoome: av_lfg_get ;) [19:36:56] <BBB> where is nfl? [19:37:06] <BBB> darnit :) we have another student applying for amrwb [19:37:22] <jai> BBB: mail him perhaps [19:37:27] <BBB> yeah [19:38:09] <jai> so how many qualified students so far? [19:40:19] <BBB> nfl is qualified, I think [19:40:23] <BBB> and zhentan / josh [19:40:53] <BBB> then 3 more where the qualification is progressing, afaics [19:41:30] <BBB> then yours, which I guess doesn't need a qual task [19:41:41] <BBB> and one more of a student but I don't know who he is, but he claims to be talking to kostya [19:44:46] <BBB> jai: did you talk to alex [19:44:47] <BBB> ? [19:52:30] <_av500_> yes!! http://www.swfme.com/view/1046212 [19:52:35] <_av500_> sorry, bad evil flash [19:52:56] <mru> hell? [19:54:39] <elenril> lol [19:55:44] <_av500_> yes, hell [19:56:01] <mru> flash sounds suitable for that... [20:11:02] <_av500_> lol, blink tag of death: http://www.zerodayinitiative.com/advisories/ZDI-10-031/ [21:34:01] <astrange> http://google-opensource.blogspot.com/2010/04/interesting-times-for-video-o… confused strategy there [21:39:28] <peloverde> How does TheorARM compare to fftheora on arm? [21:40:23] <astrange> fftheora surely beats regular libtheora on arm [22:26:34] <bcoudurier> hi guys [22:37:05] <Tjoppen> evening [22:40:08] <Tjoppen> bcoudurier: should I simply commit that fixed mov patch on the list? I assume so, since I changed the hexes to decimal [22:40:21] <bcoudurier> yes go ahead [22:40:31] <CIA-81> ffmpeg: michael * r22824 /trunk/libavformat/utils.c: [22:40:31] <CIA-81> ffmpeg: Dont try to compute AVPacket duration for possibly interlaced video codecs [22:40:31] <CIA-81> ffmpeg: when no parser is available. [22:40:31] <CIA-81> ffmpeg: This partly fixes the frame rate misdetection in issue1756. [22:40:34] <Tjoppen> ok. I'll do that tomorrow or monday then [22:41:01] <Tjoppen> depending on when I feel like going to work :o [22:45:16] <Tjoppen> btw, anyone have any good ideas of what to do during my visit to london in two weeks? a friend of mine is going over to watch chelsea, so I'm going to join him on a beer trip (and some football I guess) [22:45:36] <Tjoppen> imperial war museum is a must probably [23:30:40] <CIA-81> ffmpeg: alexc * r22825 /trunk/libavutil/mathematics.h: Add M_SQRT2 to the constants in mathematics.h. [23:42:34] <ramiro> Tjoppen: try searching for a british person... you'll see people from all around the world, but brits are hard to find there...

1 0

IRC log for 2010-04-08
by irc＠mansr.com 09 Apr '10

09 Apr '10

[00:57:53] <danielk22> How does everyone using MPEG as a base make sure there are no user_data collisions? Is there a registry? (I'm trying to clean up the MythTV CEA-608/708 caption decoding so it can be submitted upstream to ffmpeg). [00:59:07] <danielk22> We're interpreting user data beginning with 0x05,0x02 as CEA-608 captions, but I can't find the spec for it. [01:11:28] <bcoudurier> hi guys [01:12:37] <Dark_Shikari> hi bcoudurier's onjoin script [01:15:49] <DonDiego> http://lwn.net/SubscriberLink/382478/b5466c64dc29a115/ [01:15:57] <DonDiego> mru: reactions to your blog post about ogg [01:28:05] <Kovensky> "Neither the popular MP4 nor Matroska container formats are well-suited for streaming (particularly live streaming)" <-- wat [01:28:32] <Kovensky> what about mp4 fragments, and matroska works perfectly fine without an index [01:30:51] <peloverde> Can ogg even do silverlight style "smooth streaming"? [01:31:15] <Kovensky> "(for example, Matroska only recently added support for interleaving frames from different tracks)" <-- what [01:31:54] <Dark_Shikari> Kovensky: hit him [01:33:02] <Kovensky> I'm still trying to understand that comment, did he mean that matroska was a completely non-interleaved container format? [01:33:57] <DonDiego> i have a feeling that almost nothing from that article is correct.. [01:34:00] <Kovensky> it's just too baffling (and if I understood correctly blatantly wrong) >_> [02:09:19] <DonDiego> bcoudurier: btw, since the topic comes up repeatedly, what was the reason you never wanted to work on the overhead issue in the ogg muxer? [02:09:50] <bcoudurier> did I say that ? [02:10:27] <Dark_Shikari> DonDiego: respond with an article about how the author is an idiot? =p [02:10:49] <DonDiego> the author is not an idiot [02:11:04] <DonDiego> i think he just made an attempt to write a balanced summary [02:11:28] <DonDiego> however, when the issue is not balanced, the middle ground is not always the correct position [02:11:47] <DonDiego> bcoudurier: i remember some comments from you about the subject [02:11:51] <bcoudurier> I've spent some time adapting a patch from david, but I did not finalize it [02:12:16] <DonDiego> would it reduce muxing overhead? [02:12:35] <DonDiego> monty keeps complaining [02:12:46] <bcoudurier> yes, definitely [02:12:59] <Dark_Shikari> DonDiego: well, if he's so horribly wrong [02:13:03] <Dark_Shikari> he clearly has no idea what he's talking about [02:13:14] <Dark_Shikari> which doesn't make him an idiot, but writing about a topic when you don't know what you're talking about _does_ make you an idiot. [02:13:19] * Compn has evil thoughts of doubling ogg overhead [02:13:53] <DonDiego> and then he goes on to turn the argument around by claiming that it's ffmpeg's fault and that ogg does not, in fact, have high overhead [02:14:18] <DonDiego> bcoudurier: what about finishing that patch then? [02:14:29] <DonDiego> it would be awesome for 0.6 :) [02:14:40] <DonDiego> this reminds me.. [02:14:47] <DonDiego> yuvi has gone AWOL [02:14:48] <bcoudurier> mp4 overhead is independant of interleaving [02:15:09] <DonDiego> and his work blocks the 0.6 release [02:15:32] <bcoudurier> I have better things to do currently unfortunately [02:15:35] <DonDiego> Dark_Shikari: do you know if some of the ogg/theora/vorbis crashers you found might be exploitable? [02:15:42] <bcoudurier> but this is certainly welcome [02:15:48] <DonDiego> that's a pity [02:15:57] <Dark_Shikari> last thing I had, yuvi was investigating [02:16:03] <Dark_Shikari> :/ [02:16:22] <DonDiego> bcoudurier: remember, it's ffmpeg 0.6 "works with HTML 5" :) [02:16:32] <bcoudurier> DonDiego, besides you have to limit the packing to have good seeking accuracy [02:16:59] <bcoudurier> I don't remember ogg being part of html 5 [02:17:17] <bcoudurier> besides I'm not sure it's a good idea to go further on that road [02:17:25] <kierank> through xiph blinkers ogg IS html5 [02:17:33] <Dark_Shikari> hmm. I agree. [02:17:35] <peloverde> Do we have a plan for 0.6? there is always a feature around the corner [02:17:49] <Dark_Shikari> if anything, html5 is mp4 [02:17:56] <Dark_Shikari> given microsoft's announcement [02:18:01] <bcoudurier> I think we should let the philosophers fight [02:18:05] <DonDiego> bcoudurier: html 5 is both for the moment [02:18:19] <DonDiego> that's the point of the release [02:18:22] <Dark_Shikari> not really, html5 is canvas and all that [02:18:24] <Dark_Shikari> nobody uses <video> [02:18:26] <Kovensky> html5 is neither, until somebody picks one [02:18:32] <DonDiego> we have top-notch support for both codecs [02:18:55] <Kovensky> s/somebody/everybody/ [02:19:04] <bcoudurier> and many other :) [02:19:16] <DonDiego> peloverde: we appear to have security bugs open, we cannot release with that :( [02:19:22] <Dark_Shikari> what security bugs [02:19:53] <peloverde> we always have "security" bugs open if you blindly call any crasher a security bug [02:20:35] <Kovensky> how to crash ffmpeg: ffmpeg -i input.mkv -vcodec copy -acodec copy output [02:20:43] <DonDiego> i'm not blindly calling a crasher a security bug [02:20:44] <Kovensky> ok, it's not a crash, it's a "clean exit", but it's supposed to work :v [02:20:59] <peloverde> What's the bug number? [02:21:01] <Kovensky> (assuming the mkv has h264 video) [02:21:07] <DonDiego> there is no bug number [02:21:21] <DonDiego> umm, maybe there is [02:21:39] <DonDiego> it was Dark_Shikari discovering some bugs with a fuzzer [02:21:50] <DonDiego> and yuvi wanting to investigate [02:21:55] <Dark_Shikari> I don't think I found any security bugs [02:21:58] <Dark_Shikari> except possibly one in mkv [02:21:59] <Dark_Shikari> which was fixed [02:22:04] <Dark_Shikari> but I can't be sure [02:22:09] <DonDiego> and a comment "uh, oh, this might be exploitable" [02:22:09] <Dark_Shikari> but seriously: [02:22:18] <Dark_Shikari> 1) there are tons of bugs in ffmpeg. [02:22:19] <DonDiego> and that's why i'm asking.. [02:22:20] <Dark_Shikari> 2) tons crash ffmpeg. [02:22:23] <Dark_Shikari> 3) a lot are security holes [02:22:31] <Dark_Shikari> 4) we cannot get rid of all of them any time soon [02:22:39] <Dark_Shikari> 5) anyone who wants to write an exploit for ffmpeg _or_ libtheora probably can. [02:22:56] <Dark_Shikari> .... and this isn't a problem with ffmpeg per se [02:22:59] <Dark_Shikari> Quicktime, for example, is even worse [02:23:05] <Dark_Shikari> it has holes up the wazoo [02:23:09] <DonDiego> all points conceded [02:23:10] <Dark_Shikari> a friend of mine made it crash with about two bytes of input data [02:23:15] <Dark_Shikari> potentially exploitably too [02:23:23] <peloverde> There are a huge number of crashers not worth dealing with just because of the padding situation [02:23:33] <Dark_Shikari> and yeah that [02:23:42] <Kovensky> what padding situation? [02:23:56] <bcoudurier> I don't understand the padding situation [02:24:03] <DonDiego> but it's all slightly besides the point [02:24:11] <bcoudurier> there should be a mode when it's being checked [02:24:47] <DonDiego> what do you make of a comment "uh, oh, this might be exploitable, will check + fix" and then going AWOL? [02:25:39] <Kovensky> he was kidnapped by a cracker that doesn't want the exploit to be fixed [02:25:40] * Kovensky ducks [02:25:53] <Dark_Shikari> anyways don't let me or yuvi block release. [02:26:17] <bcoudurier> definitely [02:27:07] <DonDiego> well, now you have said that it's likely not exploitable [02:27:17] <peloverde> The padding situation is currently that on many codecs, ever read must be checked in to prevent segfaults [02:27:29] <bcoudurier> how is that possible ? [02:27:40] <DonDiego> i remembered a slightly different statement, so put yourself in my shoes [02:27:55] <peloverde> we only use 8 bytes of input buffer padding [02:28:15] <Dark_Shikari> ideally it should be codec-specific [02:28:18] <peloverde> and most of that is for the bitstream reader itself [02:29:20] <Kovensky> <@Dark_Shikari> ideally it should be codec-specific <-- that would prevent allocating buffers on stack [02:29:24] <Kovensky> but I guess that's for the best ._. [02:30:07] <bcoudurier> I don't remember so many problems related to padding before [02:30:08] <peloverde> Kovensky: alloca [02:30:11] <bcoudurier> suddently it's a big dea [02:30:34] <peloverde> bcoudurier, a bunch of crashers were found with fuzzing tools [02:30:55] <bcoudurier> AFAIK zzuff found a bunch as well [02:31:07] <bcoudurier> and increasing padding was never considered [02:31:21] <peloverde> those ones were fixed manually [02:31:39] <peloverde> then a new batch cropped up, that can't be fixed without very invasive buffer checking [02:31:40] <bcoudurier> or are you saying that aac is specific on this matter ? [02:31:46] <peloverde> no, not just aac [02:31:56] <bcoudurier> interesting [02:32:12] <Kovensky> <@peloverde> Kovensky: alloca <-- oh, completely forgot about that func [02:32:48] <bcoudurier> what codecs are particularly vulnerable [02:32:54] <bcoudurier> or is it implementation related [02:34:47] <peloverde> I would argue that for most codecs something could be generated at sufficient bitrate, particularly when VLCs are decoded in a speed critical inner loop [02:35:17] <Dark_Shikari> measure the maximum size of a maliciously constructed block [02:35:21] <Dark_Shikari> double it to make sure. [02:35:30] <peloverde> indeed [02:35:50] <peloverde> find the basic block size unit where checking is reasonable [02:36:19] <peloverde> Then find the maximum size that block could be maliciously sized [02:36:21] <bcoudurier> we are talking about audio right ? [02:36:35] <peloverde> no, not just audio [02:36:58] <peloverde> It seems perfectly reasonable that we could make crashes like these for video [02:37:28] <bcoudurier> it seems mpeg2 decoder checks every dct coeefs [02:37:43] <bcoudurier> I wonder how can this _ever_ crash [02:39:08] <peloverde> that's because current buffering is designed around mpeg2 [02:39:27] <bcoudurier> here comes the design excuse ;) [02:39:59] <peloverde> I've been told checking per-coef in AAC is unreasonable [02:40:27] <bcoudurier> I don't know and you are the best to tell [02:40:27] <peloverde> there is a fairly large family of codecs structured similarly to aac [02:40:43] <bcoudurier> vorbis ? [02:42:05] <peloverde> vorbis, wma [02:43:49] <peloverde> we probably could get some speed gains out of mpeg2 if we checked at the block level and not the coef level [02:44:11] <bcoudurier> well block index > 63 and boom [02:45:35] <bcoudurier> anyway [02:45:44] <bcoudurier> the code shouldn't fail padding or not [02:46:00] <bcoudurier> I mean I'm pretty sure people using the libs don't know about padding :) [02:46:24] <peloverde> then they risk crashing on valid streams [02:46:29] <ohsix> or if they'll run out of "free frames" :> [02:46:33] <peloverde> when the bitstream reader repopulates [02:46:56] <bcoudurier> at the end of the frame you mean ? [02:47:08] * Kovensky suggests making the max frame size define already include padding and having a real max frame size define with the old max frame size value [02:47:28] <bcoudurier> we are talking about the input here [02:47:41] <Kovensky> (or not making a "real max frame size" and instead subtract the padding define) [02:48:14] * Kovensky was talking about library users [02:48:21] <bcoudurier> I'd say add checks and fix the crash, a crash is worst than slowdown [02:48:34] <bcoudurier> different subject ? [02:48:44] <Kovensky> not very different, but yes [02:48:52] <bcoudurier> input is kind of different [02:48:53] <Kovensky> it's in response to <@bcoudurier> I mean I'm pretty sure people using the libs don't know about padding :) [02:48:56] <Kovensky> =p [02:49:06] <bcoudurier> that is not really padding, it's allocating [02:49:10] <peloverde> or we could add a small amount of padding and have neither a crash nor a slowdown [02:49:21] <bcoudurier> that is in every demuxer you must allocate more than needed [02:49:35] <bcoudurier> if the demuxer does not, then you must realloc what it gives you [02:49:55] <peloverde> we have a define for padding size [02:49:59] <bcoudurier> I personally find that annoying, so I guess some users do as well [02:50:08] <peloverde> it should be used when allocating buffers [02:50:19] <bcoudurier> it's like the DECLARE_ALIGNED for audio output buffer [02:50:24] <peloverde> when it's not used the user is breaking the API and all bets are off [02:50:33] <bcoudurier> hopefully this will be changed when audio decoders use get_buffer [02:50:56] <bcoudurier> yes [02:51:02] <bcoudurier> I just find the API annoying [02:51:07] <DonDiego> gnite [02:51:20] <bcoudurier> does quicktime have padding constraints as well ? [02:51:26] * Kovensky sleeps too [02:51:30] <bcoudurier> gnite DonDiego [02:51:37] <peloverde> av_malloc(size+FF_INPUT_BUFFER_PADDING_SIZE) is hardly annoying [02:52:11] <peloverde> looking at mpeg2 I'm sure I can generate oob reads [02:52:18] <bcoudurier> I'm more talking about people using other demuxers [02:52:41] <peloverde> libavcodec is a lowlevel API, and the padding thing is documented [02:52:54] <bcoudurier> yes [02:53:06] <bcoudurier> I'm just telling you that it _is_ annoying to me [02:53:26] <peloverde> then make a malloc macro [02:53:29] <bcoudurier> and I'm not asking to change the API [02:53:44] <bcoudurier> how clever [02:53:46] <peloverde> and increasing the size shouldn't make it any more annoying than it already is [02:54:33] <peloverde> unless you mean there are fewer cases where you can "get away with" abusing the API [02:54:58] <bcoudurier> I say that small overread should not crash [02:55:10] <bcoudurier> page is yours after all [02:55:11] <peloverde> I agree [02:55:24] <astrange> quicktime doesn't have anything about padding in the api [02:55:31] <bcoudurier> see [02:55:33] <astrange> if you need it you need to memcpy the input [02:55:42] <bcoudurier> I find that better for the user [02:55:43] <peloverde> I don't think we should be making design decisions based on what quicktime does [02:55:58] <peloverde> (unless we are talking about apple codecs) [02:56:00] <astrange> that quicktime api hasn't changed since 1990 though [02:56:07] <bcoudurier> defintely not, but it gives you an idea about how other people do [02:56:15] <peloverde> QtKit existed in 1990 ? [02:56:28] <bcoudurier> besides I know for sure that many SDK does not require it either [02:56:54] <peloverde> I'm guessing that those are vulnerable to buffer bugs [02:57:04] <peloverde> or do wastful reallocs internally [02:57:04] <bcoudurier> probably [02:57:29] <bcoudurier> in short I believe the padding is not really an issue [02:57:44] <bcoudurier> add checks, and we should be fine :) [02:58:14] <peloverde> I've been told more than once that such checks would not be acceptable [02:58:22] <peloverde> And I don't like them either [02:59:11] <astrange> i'm about to write the quicktime bug report asking for padding so i don't have to memcpy [03:03:24] <bcoudurier> you can code safe also [03:04:14] <bcoudurier> peloverde, so no checks and no padding increase ? that looks like a dead end to me [03:04:29] <peloverde> yes that is a dead end [03:04:38] <peloverde> that is the current situation [03:07:53] <bcoudurier> what's the plan then ? [03:12:51] <peloverde> there is no plan [03:13:44] <bcoudurier> how would you like to fix that ? be able to specify the padding size per codec ? [03:21:24] <peloverde> that would seem sufficient [03:21:36] <peloverde> (also I'm seeing illegal reads in mpeg-2) [03:28:39] <bcoudurier> I guess adding .padding to AVCodec should be easy to do [03:29:53] <bcoudurier> I'm off [03:29:59] <bcoudurier> bye [04:47:55] <peloverde> PS files decoding properly! what has the world come to! [04:51:27] <pJok> peloverde, xiph being considered actual coders? ;) [05:05:31] <jai> peloverde: nice [05:05:35] <jai> peloverde++ [05:14:00] <peloverde> hmm... when the spec is ready literally, heirarchical backwards compatible PS seems impossible [05:16:58] <saintd3v> peloverde: \o/ [05:25:21] <jai> ok superdump is here, lets do this one more time [05:25:44] <jai> peloverde: nice work on PS support [05:25:56] <superdump> :) [05:26:05] <peloverde> it's not all done yet, i have the minimal case working [05:26:14] <superdump> \o/ [05:26:16] <peloverde> but it means that I can work incrementally from this point forward [05:26:33] <peloverde> which psychological is far better [05:27:08] <superdump> i dunno [05:27:21] <superdump> it's a psychological boost to get something working [05:28:41] <peloverde> I always find writing big chunks of non-verifiable code frustrating [05:28:49] <peloverde> and misunderstands propagate [05:37:26] <thresh> morning [05:37:32] <thresh> yeaah i did it right [05:39:07] <jai> thresh: whoa [06:05:23] <CIA-1> ffmpeg: alexc * r22816 /trunk/libavcodec/mpeg4audio.c: [06:05:23] <CIA-1> ffmpeg: Fix ext_object_type. [06:05:23] <CIA-1> ffmpeg: In the case of explicit non-backwards compible PS, the extension object [06:05:23] <CIA-1> ffmpeg: type should be set to SBR. See 14496-3:2009 (fourth edition). [06:05:23] <CIA-1> ffmpeg: alexc * r22817 /trunk/libavcodec/mpeg4audio.c: Use get_bits_left() in the sync extension check. [06:05:24] <CIA-1> ffmpeg: alexc * r22818 /trunk/libavcodec/ (mpeg4audio.h mpeg4audio.c): Add support for PS sync extensions. [06:09:26] <Dark_Shikari> wait holy shit, ps is already done? [06:09:41] <kshishkov> no, those are only preparations [06:09:44] <Dark_Shikari> ah [06:10:06] <kshishkov> (but PS is already devised by those in corresponding comittee) [06:12:03] <kshishkov> looks like the future of audio is SAOL-like - encode 8kHz mono sound and enhance it to 48kHz 5.1 with flags and parameters (and no real coded frequencies) [06:13:23] <kshishkov> I'd call it "VP3 way", can't say why though [06:14:20] <kierank> What's silly is trying to save bitrate by using he-aac for 5.1 in dvb-t2. save a few hundred kilobits/s yet use a crappy h.264 encoder nonetheless [06:15:15] <kshishkov> it's an interesting paradox - audio takes less bits but is harder to compress [06:16:05] <kierank> he-aac was deliberately pushed into the national standards because there's money to be made with stb licensing [06:16:35] <kierank> but in my opinion the sbr ruins the sound anyway [06:16:45] <merbzt1> well something better then layer2 was needed [06:16:59] <merbzt1> but using sbr might not be to wise [06:17:01] <kshishkov> and layer2 is better than layer3 IMO [06:17:09] <kierank> aac at 256kbps or the like imo [06:17:25] <kierank> svt is quite good though; ac3 at 640kbps [06:17:48] <merbzt1> I guess at 5.1 also [06:18:57] <Dark_Shikari> imo celt has the right approach for dealing with HF [06:19:11] <Dark_Shikari> the energy-preserving VQ is just perfect [06:19:17] <merbzt1> elaborate [06:19:31] <kshishkov> cons: it will be in Ogg container [06:19:34] <Dark_Shikari> 1) explicitly code the energy for each band [06:19:40] <Dark_Shikari> (predicted based on the last packet's energy) [06:19:45] <Dark_Shikari> normally costs 0-1 bits per band [06:19:58] <Dark_Shikari> 2) the quantizer is a VQ calculated on the fly _such that_ energy is preserved [06:20:08] <Dark_Shikari> so no matter how you quantize the band, energy is conserved [06:20:12] <Dark_Shikari> even if you quantize to zero [06:20:22] <Dark_Shikari> this results in coding HF bands taking near-zero bits [06:20:28] <Dark_Shikari> yet still sounding good [06:20:53] <Dark_Shikari> basically it's the best of both worlds: you get the HE-AACness without _actually_ lowpassing it to 22khz [06:21:03] <Dark_Shikari> so if there is real HF detail, you can code it [06:21:35] <merbzt1> anyway VQ is awesome [06:21:50] <Dark_Shikari> and yes that. [06:22:11] <kshishkov> merbzt1: some video codecs authors have discovered that long time ago [06:24:39] <Dark_Shikari> but unlike a normal VQ [06:24:41] <Dark_Shikari> it's calculated on the fly [06:24:48] <Dark_Shikari> i.e. if you actually made it into a table it'd contain a billion plus elements [06:25:01] <Dark_Shikari> so it effectively searches a table that doesn't actually exist in full [06:25:05] <superdump> so how does it work? [06:25:10] <Dark_Shikari> there's a paper on it somewhere [06:25:12] <Dark_Shikari> and a presentation [06:25:28] <superdump> and what bit rates is celt intended for? [06:25:41] <superdump> very low voice i'm guessing [06:25:43] <Dark_Shikari> no [06:25:46] <Dark_Shikari> stereo at ~64kbps per channel [06:25:57] <Dark_Shikari> the main schtick is that it has extraordinarily small packet sizes [06:26:00] <Dark_Shikari> and is hard-CBR [06:26:07] <Dark_Shikari> so you can get 5ms latency [06:26:19] <Dark_Shikari> http://www.celt-codec.org/presentations/ covers some of the math [06:26:34] <Dark_Shikari> at least the xiph guys know how to do audio. [06:26:49] <kshishkov> superdump: just think if channel supplied number of possible elements and decoder generated codes for all tuples (0..N-1; 0..N-1; ...) [06:27:18] <Dark_Shikari> it's like a 50-dimensional VQ [06:27:26] <kshishkov> Dark_Shikari: actually all Xiph guys did is Vorbis, everything else is acquired [06:27:43] <Dark_Shikari> they're doing celt =p [06:27:51] <Dark_Shikari> speex isn't that good. silk beats the shit out of it [06:28:06] <Dark_Shikari> largely because silk is an independently-developed Celt-alike [06:28:12] <Dark_Shikari> except designed more for speech than music [06:28:24] <CIA-1> ffmpeg: alexc * r22819 /trunk/libavcodec/aacsbr.c: [06:28:24] <CIA-1> ffmpeg: Print an error and skip PS when PS is found but explicitly found but [06:28:24] <CIA-1> ffmpeg: signaled to be absent. [06:28:25] <CIA-1> ffmpeg: alexc * r22820 /trunk/libavcodec/aacsbr.c: Reindent read_sbr_extension. [06:30:51] <superdump> there's low delay aac [06:30:58] <superdump> not sure how low delay it is though [06:31:06] <Dark_Shikari> not nearly that low [06:31:14] <superdump> probably not [06:31:14] <kshishkov> lossless AAC too [06:31:17] <Dark_Shikari> celt does packet sizes down to like 128 samples [06:31:29] <Dark_Shikari> at 256-sample packet size + 128kbps + stereo it's transparent to source for me [06:31:37] <Dark_Shikari> which is really impressive, in large part because of transients [06:31:46] <Dark_Shikari> hard CBR + small packet size + transients == AGHHHHHHH [06:34:08] <andoma> do I sense a faint smell of AAC-PS? [06:34:29] <kshishkov> not only you [06:36:11] <peloverde> Is CELT bitstream frozen yet? [06:36:17] <kshishkov> nope [06:37:27] <peloverde> Then it seems like bad news that debian/ubuntu are packaging it [06:39:05] <andoma> Dark_Shikari: does periodic intra refresh in h264 rely on a specific profile, or is it just a way of how MB types and frames are arranged? [06:44:30] <Dark_Shikari> latter [06:44:34] <Dark_Shikari> peloverde: lol, that's ridiculous [06:44:37] <Dark_Shikari> they're changing the bitstream every week [06:49:22] <Dark_Shikari> someone should whine to siretart about that [06:59:28] <siretart> about what? [07:01:33] <kshishkov> about including experimental software with unstable bitstream format into distributions [07:01:39] <Dark_Shikari> Celt is apparently in ubuntu [07:01:43] <Dark_Shikari> the bitstream format changes EVERY WEEK [07:01:53] <Dark_Shikari> by the time the distro ships it already won't even do anything [07:19:22] <Tjoppen> git svn clone seems to take quite some time. useful though [07:27:38] <superdump> Dark_Shikari: quite an interesting video that [07:28:05] <kshishkov> indeed [07:31:45] <kierank> does seeking work in that video? [07:32:03] <Dark_Shikari> it's ogg, what do you think the answer is ;) [07:32:21] <kierank> lol it's garbled in srware iron [07:33:27] <kierank> hmm works in firefox thogh [07:33:30] <kierank> though* [07:34:13] <kshishkov> so what? I think we can forget about Firefox in several years [07:34:41] <kierank> half-working implementations are annoying [07:36:52] <kshishkov> still better than no implementation [07:50:03] <merbzt1> Tjoppen: you can clone from git.mansr.com [07:50:34] <Tjoppen> ok. I'll try that [07:51:26] <merbzt1> accoarding to peloverde dcommit works from that tree [07:51:43] <peloverde> yes it does [07:52:12] <Tjoppen> merbzt1: what's the full URI? [07:53:00] <Tjoppen> oh, wait. /ffmpeg probably [07:53:21] <Tjoppen> there we go [07:53:41] <peloverde> git://git.mansr.com/ffmpeg [07:54:15] <Tjoppen> yeah, git: seems a lot faster than http [07:54:35] <peloverde> then do "git svn init -T svn://svn.mplayerhq.hu/ffmpeg" [07:54:52] <peloverde> then "git update-ref refs/remotes/trunk origin/master" [07:55:32] <wbs> what's the difference between mru's git-svn repo compared to the one on git.ffmpeg.org, that allows this to be done? [07:56:01] <Tjoppen> the one on ffmpeg.org is read-only [07:56:42] <wbs> ahem.. in which sense? you can't push to mru's repo either [07:57:06] <Tjoppen> hm. good question [07:57:20] <Tjoppen> maybe git.ffmpeg.org could be set up to automagically use git-svn somehow? [07:57:32] <wbs> git.ffmpeg.org _USES_ git-svn [07:57:55] <wbs> I'd like to know what's different in its setup that makes it impossible to do that trick on clones from that one [07:58:13] <astrange> the svn url included in the commit message is different [07:58:25] <peloverde> The svn url must match exactly [07:58:38] <wbs> aah, I see [07:58:43] <peloverde> git.ffmpeg.org was cloned with a file:/// url [07:59:47] * peloverde shakes fist at valgrind [08:00:27] <kshishkov> peloverde: non-linux OS is a best way against valgrind [08:01:37] <av500> rpm -e valgrind works as well [08:01:37] <peloverde> linux is the only OS I have that valgrind supports [08:02:03] <kshishkov> av500: not on debian/ubuntu/slackware [08:02:09] <kshishkov> peloverde: exactly [08:02:19] <peloverde> I want to know WHY it thinks this value is uninitialized (and I tried --track-origins=yes) [08:03:50] <peloverde> my problem is that valgrind is usually smarter than I, and I'm going to have to track down the same bug in gdb sooner or later if I don't fix it now [08:04:31] <kshishkov> it prints line where value is used [08:04:48] <kshishkov> so you can try matching its initialisation with access [08:05:00] <peloverde> yes and all the values on that line seem properly initialized [08:05:02] <kshishkov> i.e. if all indices are the same/whatever [08:05:31] <peloverde> It tracks it backwards to a stack allocation at the top of the function, but doesn't tell me which one [08:05:55] <astrange> it should be able to read debuginfo and give a line number [08:06:18] <astrange> it could give more but the --read-var-info implementation never seemed to do anything for me [08:06:40] <KotH> moin girls [08:07:07] <kshishkov> KotH: wrong place for girls [08:07:40] <KotH> well, i know of at least one confirmed girl who was in this channel [08:07:45] <KotH> there ought to be more :) [08:07:58] <kshishkov> one fluctuation is not a proof [08:08:08] <twnqx> measuring error. [08:08:18] <KotH> ^^' [08:09:01] <KotH> Lasciate ogni speranza, voi ch'entrate! [08:09:41] <kshishkov> Swiss Italian? [08:10:33] <KotH> nope, italian italian [08:14:24] <Tjoppen> time to commit my seek patch. ran tests for good measure, which still pass [08:14:42] <Tjoppen> or rather, probe patch. I'll commit the seek patch later [08:15:17] <kshishkov> whatever [08:18:44] <pJok> Morgon, kshishkov [08:19:00] <av500> gm [08:20:06] <kshishkov> god morgon, pJok [08:20:44] <pJok> Inte god idag ;) [08:21:41] <pJok> Waiting at a hospital [08:21:50] <kshishkov> oh [08:21:59] <kshishkov> nothing serious I hope [08:22:37] * kshishkov usuallly does not have enough health to go to local hospitals [08:22:40] <pJok> Only minor surgery tomorrow, today is just preparation [08:23:18] <kshishkov> good luck anyway [08:24:08] <siretart> kshishkov: so you propose to remove x264 from ubuntu? [08:25:08] <kshishkov> siretart: x264 produces into _stable_ bitstream format [08:25:30] <kshishkov> CELT produces something that can't be decoded with any different version of CELT [08:25:59] <siretart> what is celt? [08:26:21] <kshishkov> siretart: next decent audio codec from Xiph [08:26:29] <ohsix> except for 0.7.0 and 0.7.1 [08:26:55] <superdump> Version 0.7.1 has been released, with improvements to the packet loss concealment (PLC). It is the first release not to break bit-stream compatibility with the previous release (0.7.0). But I promise not to do it again, the next CELT release will likely break compatibility once again. [08:27:14] <superdump> :) [08:27:14] <pJok> What? Anything decent from xhiph? Unpossible [08:27:59] <pJok> Xiph* [08:28:02] <kshishkov> pJok: Vorbis is not bad per se [08:28:17] <siretart> kshishkov: oh, you're talking about the 'celt' source package. that's taken unmodified from debian, and I hardly can take responsibility of all debian packages. [08:28:33] <Dark_Shikari> superdump: they already broke it in trunk ;) [08:28:38] <kshishkov> siretart: of course, we blame you only for multimedia packages [08:28:38] <Dark_Shikari> twice. [08:29:08] <siretart> kshishkov: I'd suggest to whine to 'submit(a)bugs.debian.org' [08:29:19] <pJok> Who needs compliant bitstreams anyways... [08:29:34] <siretart> kshishkov: I see. I haven't worked with ron so far [08:30:16] <kshishkov> somehow Vorbis is the only good thing from Xiph so far [08:31:04] <pJok> Shame it is in a silly container [08:31:07] <peloverde> cdparanoia, flac? [08:31:12] <Dark_Shikari> flac isn't from xiph [08:31:15] <Dark_Shikari> clet is good though [08:31:17] <Dark_Shikari> *celt [08:31:27] <peloverde> flac is xiph now [08:31:36] <ohsix> its actually the speex guy [08:32:27] <kshishkov> peloverde: cdparanoia is good but it has nothing to do with the rest of Xiph business [08:32:48] <Dark_Shikari> peloverde: it isn't as if it got better after it was adopted by xiph [08:32:55] <Dark_Shikari> ffmpeg's encoder and decoder are still better [08:33:18] <kshishkov> Dark_Shikari: but we got Flac-in-Ogg then! [08:33:27] <peloverde> <Dark_Shikari> peloverde: it isn't as if it got better after it was adopted by xiph <-- you could say the same thing about theora ;) [08:34:47] <Dark_Shikari> Oh, but it did [08:34:51] <Dark_Shikari> have you SEEN On2's VP3 encoder? [08:34:56] <Dark_Shikari> it was hilariously awful [08:35:01] <Dark_Shikari> the dct and idct didn't even match [08:35:29] <av500> nitpicker! :) [08:35:36] <Dark_Shikari> woohoo, just wrote my first multipass optimizing compiler [08:35:51] <Dark_Shikari> ... for a toy language. but hey [08:36:20] <av500> ffcc ftw! [08:36:25] <superdump> make toys [08:36:54] <Dark_Shikari> it took like a couple hours [08:36:58] <Dark_Shikari> haskell is \o/ [08:37:02] <pJok> Ffos [08:38:54] <ohsix> class http://wiki.xiph.org/MailOgging [08:40:13] <peloverde> Let's start a campaign asking apple to support H.264 and AAC on the iPod... [08:40:23] <pJok> wonder when ffmpeg will come with its own compiler [08:41:02] <kshishkov> pJok: eventually it should [08:41:16] <kshishkov> GCC is already shows tendency on turning into Java [08:41:59] <pJok> Slow, big and bulky? [08:42:05] <kshishkov> that too [08:42:37] <kshishkov> I mostly mean treating programmer as an idiot who does not know what he writes and needs constant guiding [08:42:51] <pJok> Is clang worth anything? [08:43:03] <kshishkov> not yet [08:43:33] <bilboed-pi> apart for static analysis [08:43:50] <kshishkov> not suitable for that too (yet) [08:44:17] <bilboed-pi> the static analysis in 2.7 (to be released RSN) is way better than 2.6 [08:44:28] <bilboed-pi> actually does checks *across* functions [08:44:37] * av500 lols at http://wiki.xiph.org/MailOgging [08:45:06] <kshishkov> "char *ptr = ctx->smth; ptr[0] = 42;" results in "dead assignment" in clang. Next! [08:45:49] <pJok> But it is dead! [08:46:15] <pJok> GCC killed it [08:46:38] <peloverde> Sometimes I like having dead assignments [08:46:41] <kshishkov> well, GCC tries to get to the level of useless warnings, true [08:47:38] <kshishkov> like in lavc/dca.c is warns about too high array index while in reality it's always in bounds [08:48:03] <ohsix> wgat about space rays [08:48:10] <pJok> "Warning: Programmer knows what he is doing. Turning on annoyance mode" [08:48:10] <kshishkov> or that famous warning in liavc/vc1.c [08:48:23] <Dark_Shikari> -Wshadow should always be enabled imo [08:48:27] <Dark_Shikari> it catches real bugs [08:49:00] <kshishkov> -Wthedarkness [08:49:14] <ohsix> are you threatened/imasculated by a compiler? heh [08:50:00] <KotH> -Whomelandsecuirty [08:50:21] <kshishkov> well, if C compiler tell me you can't use logical and bitwise operands in the same expression not turning it into Lisp then you can throw that garbage compiler away [08:50:33] <pJok> -Wparanoid [08:50:42] <kshishkov> KotH: -Wsecuritytheatre [08:52:08] * KotH wonders, whether the architects of homeland security got their ideas from b5's nightwatch [08:53:36] <pJok> I know britain got their security manual from 1984 [08:53:40] <pross-au> -Wtsa [08:53:49] <pross-au> it's all for show [08:54:05] <kshishkov> -Wbushrangers [08:54:33] <pross-au> that option has been deprecated kshishkov [08:55:09] <kshishkov> good for you [08:55:37] <pross-au> it's now -Wmr-plod [08:55:55] * kshishkov fails to sing "who'll do a-waltzing matilda with gcc" [08:56:17] <pross-au> hmm [08:56:29] <pross-au> been practicing for the citizenship test? [08:56:47] <kshishkov> nope [08:57:04] <pross-au> i believe those sort of questions are on it [08:58:49] <kshishkov> "who you should shot at first sight: a) sheep b) crocodiles c) rabbits d) pooftas" [08:59:09] <pross-au> all of the above [08:59:18] <kshishkov> and politics! [09:00:54] <kshishkov> I heard your country is the only one where prime minister goes to jail right after he's elected [09:01:11] <kshishkov> (there are many countries where they should do so, including Ukraine) [09:03:19] <CIA-1> ffmpeg: thardin * r22821 /trunk/libavformat/ (aviobuf.c utils.c avio.h): Reusing the probe buffer to rewind the ByteIOContext in ff_probe_input_buffer() instead of seeking back to the start of the file. Once exhausted, the size of the buffer is reduced. [09:04:28] <Tjoppen> there we go [09:05:13] <kshishkov> yay [09:07:20] <wbs> Tjoppen: grattis. :-) [09:08:53] <KotH> wbs: it's not gratis, there is always an implied and hidden cost ;) [09:09:06] <kshishkov> KotH: learn Swedish [09:10:42] * KotH knows was grattis measn [09:11:04] <kshishkov> and what does it mean? [09:11:23] <KotH> equivalent to tack :) [09:11:33] <kshishkov> no, "congratulations" [09:11:41] <KotH> oh.. ok [09:11:43] <wbs> (con)grat(ti)s ;P [09:11:48] * KotH corrects his memory [09:13:07] * Tjoppen recommends "mastering swedish" [09:14:18] <superdump> Tjoppen: is that a book or...? [09:14:21] <Tjoppen> ah, found it: http://www.youtube.com/watch?v=66fULfwb2X4 [09:14:39] <superdump> ah [09:14:41] <superdump> yeha [09:14:47] <superdump> merbzt1 pointed me to that [09:16:04] <KotH> Tjoppen: i'm not into learning swedish.. at least not yet [09:16:16] <KotH> Tjoppen: first i'd like to master japanese before starting another lang [09:17:15] <superdump> KotH: this is more for amusement than learning anything [09:17:17] <superdump> http://www.slayradio.org/mastering_swedish.php [09:17:21] <superdump> full set are there [09:24:12] <Tjoppen> now I'll just commit that skip-by-discarding patch and a whole heap of formats can be piped to ffmpeg/ffplay [09:24:47] <superdump> woot [09:24:49] <superdump> nice [09:25:13] <Tjoppen> or more precisely, I'm replacing the "skip no more than 64 KiB" check with "skip, but don't SEEK_END unless forced" [09:26:18] <KotH> apropos languages, does anyone know a good introductory book on linguistics? [09:32:00] <Dark_Shikari> KotH: "master japanese before starting another lang" [09:32:04] <Dark_Shikari> guess you'll never be starting another lang then [09:33:59] <KotH> Dark_Shikari: depends on the definition of "master" :) [09:34:20] <Dark_Shikari> do you know enough to read books, etc? [09:35:25] <KotH> not yet [09:36:27] <Dark_Shikari> then you have a long way to go ;) [09:36:38] <KotH> exactly :) [09:37:44] <KotH> hmm... another question, this times about c: [09:37:56] <Dark_Shikari> yeah, c> japanese ;) [09:38:04] <Dark_Shikari> easier to tokenize [09:38:05] <KotH> i have an constant array of a struct [09:38:37] <KotH> now i need indices into this array and i'd like them to be some meaningful constants/macros [09:38:49] <KotH> any idea how i can achieve that? [09:39:04] <KotH> oh yes, it should be defined at compile time [09:40:23] <KotH> i'd like to have the indices coupled to the array, so if anyone changes the order in the array, that the indices imediatly reflect that, w/o manual editing of the indice values [09:48:23] <CIA-1> ffmpeg: thardin * r22822 /trunk/libavformat/aviobuf.c: Seeking forward in non-seekable media by discarding data, regardless of how far to seek. Won't SEEK_END unless forced though. [09:55:39] <Tjoppen> makes AVI, MXF, DV, MOV etc. work on stdin [09:56:25] <kshishkov> Dark_Shikari: I've started learning Swedish after I knew some bits of Japanese language and I hope to master it eventually [09:56:41] <wbs> Tjoppen: don't forget to reply with "applied" on the appropriate threads on the ML, btw, when you're done applying [09:56:44] <kshishkov> preferably in native speakers environment [09:57:27] <av500> kshishkov: master japanese in sweden? [09:58:03] <KotH> where else would you go to master japanese? [09:58:27] <kshishkov> I've met one foreighner in Stockholm who specially went to Sweden to learn Japanese [09:58:28] <av500> neuschwanstein? [09:59:39] <kshishkov> av500: last summer I saw and heard Japanese at every tourist attraction or airport - including Boryspil [10:04:25] <kshishkov> speaking of tourist attractions, http://www.phoronix.com/vr.php?view=14747 [10:07:59] <av500> is it me or doth that phoronix nix load? [10:09:05] <av500> ah, now it does [10:10:29] <kshishkov> slashdotted [10:12:29] <av500> eew [10:12:56] <av500> and you did not link to the sushi article? [10:13:47] <superdump> kshishkov: i read the phoronix thing about chernobyl and another account of a motorcyclist who was riding through there taking photos [10:13:50] <superdump> interesting stuff [10:24:52] <kshishkov> Ukraine is famous for its places [10:25:01] <kshishkov> Chernobyl is known worldwide [10:25:49] <kshishkov> Swedes try not to know about Poltava where the pinpoint battle Great Northen War was held [10:26:12] <kshishkov> Polish people think of Kharkov usually in the same context as Katyn [10:27:05] <kshishkov> Yalta with its conference was not very pleasant to some Baltic states [13:55:27] <nfl> a decoder with CODEC_CAP_SUBFRAMES set should check whether the packet has enough data, right? [13:55:46] <BBB> it should always do that [13:55:47] <kshishkov> any decodr should [13:55:57] <BBB> CODEC_CAP_SUBFRAMES means the input can contain multiple decodable units [13:56:05] <BBB> so the input could be 100 bytes, but the decoder only consumes 10 [13:56:18] <BBB> and then the caller should call the decoder again with the remaining 90 bytes in the next round [13:56:18] <nfl> is this why a parser is more desirable? [13:56:33] <BBB> no, a parser is just a different way to achieve the same thing [13:56:40] <BBB> but for speech codecs, a parser makes little sense imo [13:56:49] <BBB> so we tend to use CODEC_CAP_SUBFRAMES for all speech decoders [13:57:09] <kshishkov> and parser sucks when decoder actually consumes 73 bits instead of 10 bytes [13:57:39] <nfl> ok [13:57:55] <BBB> oh right that was another reason [13:58:01] <BBB> so a parser wouldn't work anyway [13:58:25] <av500> why not? [13:58:30] * BBB should still write a generic bit-caching mechanism for all wma decoders [13:58:43] <BBB> av500: how would the parser tell the decoder that the frame starts at bit 3 of byte 3? [13:58:48] <BBB> instead of bit 0 [13:59:03] <av500> the parser would shift the bits of course [13:59:13] <BBB> kills performance [13:59:14] <BBB> bad idea [13:59:17] <av500> maybe [13:59:25] <BBB> it's suboptimal and therefore incorrect [13:59:26] <av500> but it would be a parser for that bitstream format [13:59:36] <BBB> but we don't want it anyway ;) [13:59:43] <av500> thats another thing :) [13:59:52] <BBB> fair enough [14:01:17] <nfl> btw, is merbzt1 the real merbzt? [14:01:47] <mru> no, that's his evil twin [14:02:31] <nfl> riite! :) [14:03:52] <merbzt1> I'm the real mccoy [14:04:19] <mru> prove it [14:04:42] <merbzt2> now who's the real one? [14:04:45] <superdump> would the real merbzt1 please stand up [14:05:21] <BBB> nfl: what would you rather work on, g723.1 or amr-wb? [14:09:58] <nfl> my first preference would be g723.1 now that i've worked bit on it. (plus the spec is much shorter ;) ). but wouldn't mind amr-wb either since i'm a bit familiar with it too. [14:10:10] <nfl> *a bit [14:10:32] <jai> nfl: btw, good luck for gsoc [14:10:55] <nfl> jai, all thanks to you :) [14:12:28] <BBB> nfl: well, I think from our perspective (purely speaking for myself here), amr-wb might be more attractive because it is far better-known [14:13:14] <jai> we still can't drop libopencore though [14:13:31] <jai> but there is always another gsoc so meh [14:13:43] <merbzt1> for g723.1 you would need to implement an encoder also [14:13:46] <superdump> but if people wanted just decoding, they could maybe drop opencore [14:14:03] <superdump> if float is acceptable [14:14:15] <wbs> now that you guys are relatively familiar with those codes - how much work is an amr-nb encoder? [14:14:20] <wbs> codecs, even [14:14:36] <BBB> we don't want an amr-nb encoder, I think [14:14:41] <BBB> we want a "generic speech coding system" [14:14:46] <BBB> and then an amr-nb bitstream maker [14:15:01] <BBB> so that plugging in a wb/anything encoder is a piece of cake [14:15:23] <jai> sounds like a lot of work :) [14:15:23] <BBB> just like acelp_*/celp_*.[ch] are mostly generic speech coding functions [14:15:29] <BBB> a good encoder is a lot of work [14:15:54] <jai> of course, but we already use this "approach" for flac and alac [14:16:31] <jai> that reminds me, the alac encoder doesnt output 24 bps yet [14:18:10] * nfl is thinking... [14:19:54] <BBB> we still need more students by the way [14:20:01] <BBB> we don't have all that many so far [14:20:13] <jai> lol [14:20:21] <av500> #beagle is overflowing with students [14:20:32] <av500> but from what I have seen, you dont want them :) [14:20:35] <jai> if last year's trends hold up, then you should get quite a lot towards the end [14:21:05] <jai> av500: sir can i haz beaglborde gsoc [14:21:43] <av500> jai: how do you knwo? [14:21:46] <BBB> jai: you sure you don't want to do a soc project this year? [14:22:19] <BBB> bilboed-pi: how's your applications? [14:22:21] <av500> jai: the "sir" is mandatory, yes :) [14:22:41] <bilboed-pi> BBB, low tbh (both in gstreamer and wine) [14:22:48] <jai> av500: of course, we wouldn't get anywhere without the overt politeness :) [14:22:52] <superdump> bilboed-pi: how many for gst now? [14:23:06] <superdump> we have one more than the other day, though we knew about this person anyway [14:23:29] <jai> BBB: would have loved to, but i can live without the flames ;) [14:23:39] <BBB> hmm... [14:23:42] <bilboed-pi> superdump, 8 so far [14:23:55] <jai> but with people like nfl, you needn't worry :) [14:24:13] <av500> all new ffgsoc, 100% fflame free... [14:24:19] <nfl> jai, hey! [14:24:20] <bilboed-pi> BBB, GNOME has quite a few... but they're like 20 times the same proposal ... of very poor quality [14:24:22] <BBB> jai: you should really consider applying, I mean, assuming you have time and so on [14:24:27] <jai> BBB: anyone show up for the dts encoder? [14:24:32] <BBB> jai: not that I know [14:24:45] <jai> oh [14:25:14] <jai> bilboed-pi: same goes for gentoo [14:25:23] <bilboed-pi> jai, :( [14:25:38] <jai> infact people who don't know that gentoo is a source-based distro have sent in applications [14:25:38] <bilboed-pi> jai, and from echoes, GNU also has very few proposals [14:25:45] <bilboed-pi> jai, ROFL :) [14:31:20] <BBB> jai: again, consider, we have many places left right now... otherwise I will have to resign as admin to be a student [14:31:31] <bilboed-pi> ahahaha :) [14:31:35] <kshishkov> BBB: do it! [14:31:38] <bilboed-pi> that would be fun though [14:31:41] <jai> BBB: do it!! [14:31:43] <jai> srsly [14:31:45] <BBB> it'd be kind of weird, because I handle the payment also ;) [14:31:51] <BBB> maybe they won't notice [14:31:56] <jai> yes, less overhead ;)\ [14:32:11] <kshishkov> you can use one inflatable Mike dummy for payment handling ;) [14:32:19] <jai> BBB: so slots have been allocated already? [14:32:20] <superdump> BBB: didn't you register as project admin though? [14:32:26] <BBB> superdump: I can resign [14:32:30] <superdump> mmm [14:32:36] <BBB> or make a fake ID under my student email addy [14:32:38] <BBB> or so [14:32:40] <BBB> hmm... [14:32:43] <wbs> agh, how to convince people that creating headers for sending over the wire using bitfield structs isn't really the way to go - especially not if they're trying to fill out fields using if (htonl(foo) == foo) do something; else do something else... [14:32:54] <jai> wbs: fflames ;) [14:33:00] <BBB> wbs: just say "patch rejected, don't do that" [14:33:03] <superdump> BBB: you have to have some google account to apply i think, not sure though [14:33:13] <BBB> wbs: when I saw that I just didn't know what to say [14:33:21] <jai> superdump: he can always create a throwaway account [14:33:25] * av500 is still a student, will not apply though [14:33:28] <wbs> BBB: heh :-) [14:33:38] <BBB> av500: apply, apply! [14:33:49] <jai> i personally would have very high expectations from a BBB driven "RTSP layer improvements" or somesuch ;) [14:33:49] <wbs> it took me quite a while to figure out wtf the htonl(off) >> 8 was meant to do [14:34:08] * kshishkov is not a student anymore, so he'll do stuff for free (as usual) [14:34:22] <BBB> I don't think htonl(off)>>8 does anything predictable [14:34:32] <BBB> as in, arch-independent [14:34:34] <BBB> does it? [14:34:40] <wbs> nope [14:34:43] <jai> no [14:34:56] <BBB> maybe he meant htonl(off>>8) [14:35:07] <wbs> nope, that actually does the right thing on little-endian [14:35:15] <wbs> albeit obfuscated beyond recognition [14:35:21] <BBB> or he meant ntohl(off)>>8? [14:35:29] <mru> htonl == ntohl [14:35:34] <BBB> I know [14:35:47] <BBB> but you distinguish so you know which variables are network-ordered and which are host-ordered [14:35:58] <BBB> otherwise your code becomes completely ununderstandable [14:36:11] <wbs> it byte flips the value off to big endian, but since it's a 32-bit value in "opposite endian" that he's going to store into a 24 bit bitfield, he shifts it 8 bits right, so that it fits perfectly ;P [14:36:45] <wbs> AV_WB24 would be all too easy. ;P [14:36:45] <BBB> just reject the patch ;) it didn't use dynamic payloader handlers anyway [14:39:12] <jai> BBB: again on the topic of gsoc, which are the "high priority" tasks right now? [14:39:35] <kshishkov> the ones with students ;) [14:39:55] <Tjoppen> is there a good field in AVStream to/from which to get an estimate for the number of packets that will be muxed/demuxed? nb_frames works well for video, but for audio less so [14:40:42] <Tjoppen> I've managed to have the MOV muxer write the moov tag before the mdat tag, but it needs an estimate for the number of packets in each stream. atm I'm just using nb_frames, but that seems a bit ugly [14:40:50] <jai> kshishkov: i meant what would be the "zomg must have in 0.6" tasks :) [14:41:53] <av500> Tjoppen: estimate and then padding? [14:42:59] <Tjoppen> I can generate an OK estimate from the demuxer's nb_frames by dividing with AVCodecContext::frame_size (unless PCM). also, I automagically get some extra padding because I estimate the size of the moov tag in the most pessimistic manner [14:43:20] <merbzt1> Tjoppen: Baptiste will shred you :) [14:43:34] <jai> Tjoppen: why does this sound like something qtfaststart does :) [14:43:41] <Tjoppen> indeed :) [14:44:03] <av500> Tjoppen: your estimate must be very pessimistic, otherwise you can end up with having to rewrite the whole file at the end [14:44:27] <av500> well, you can always declare the front moov as skip and append one :) [14:44:40] <Tjoppen> well, I just write the moov tag to the end in that case, and make the one at the start a skip tag [14:44:47] <av500> :) [14:44:59] <av500> jai: because qtfaststart reads the whole file [14:45:09] <kshishkov> jai: LATM, we have added everything else from the list [14:45:10] <av500> so it knows how much is needed for the moov, no? [14:45:23] <Tjoppen> I've tested it with > 4 GiB files, in which case the estimate is fairly accurate [14:45:54] <av500> Tjoppen: with all supported codecs? [14:46:23] <Tjoppen> it passes the regression tests, but then again I haven't made ffmpeg.c make use of this [14:48:29] <Tjoppen> with a small piece of code that flushes the moov tag periodically one can even play a file that is being written, which is useful when importing to final cut pro [14:49:16] <jai> kshishkov: hmm, latm sounds doable [14:49:42] <Tjoppen> I think I'll post it as an RFC on the list. the patch I just posted is fairly benign though [14:51:22] * KotH blames DonDiego [14:51:51] <BBB> jai: anything you like, I'd love wvp2 but it's a lot of work [14:52:00] <BBB> there's easier tasks also, depends on what you're looking for [14:56:47] <DonDiego> http://lwn.net/SubscriberLink/382478/5ba427f93097f8da/ [15:02:50] <KotH> this is becomming a full blown battle [15:04:55] <av500> but we cannot call it a "war", due to insurance reasons! [15:05:31] <DonDiego> as i predicted, this is not about just technical arguments [15:05:42] <mru> it never was [15:05:46] <mru> it's about freeeeedom [15:05:55] <mru> freedom to do as "they" say [15:06:05] <DonDiego> no, and painting it that way will not help [15:06:26] <DonDiego> do you guys have lwn.net accounts? [15:06:30] <mru> no [15:06:37] <mru> it's impossible to argue with freetards [15:06:43] <DonDiego> time to create one? :) [15:06:58] <DonDiego> this is not about the freetards [15:07:06] <mru> what then? [15:07:07] <DonDiego> it's about the neutral bystanders [15:07:23] <av500> think about the children! [15:17:02] <jai> also, isn't mru's name spelt wrong [15:17:13] <mru> close enough [15:17:46] <mru> it's actually the official spelling in some places [15:17:57] <twnqx> what's wrong exactly with the above article? [15:18:23] <mru> apart from the misunderstandings and lies, not much [15:18:25] <DonDiego> yeah, let's start making a list and put it into the comments :) [15:21:21] <av500> "...but Xiph should immediately improve/change Ogg for, breaking millions of hardware decoders..." [15:21:29] * av500 wonders what these are [15:21:42] * mru never saw one [15:21:55] <av500> I think he refers to mp3 players playing vorbis [15:22:09] <av500> xiph can keep ogg for vorbis [15:22:43] <av500> but I saw no PMP yet that plays theora [15:23:03] <mru> not even yours? [15:23:12] <av500> nope [15:23:18] <av500> no customer demand :) [15:23:36] <av500> customers want us to play H264HP and DTS or AC3 [15:23:38] <kshishkov> av500: then monty hasn't got your mail address ;) [15:23:45] <av500> no, he is nto a customer [15:24:40] <av500> we added vorbis some time ago because people asked for it [15:24:54] <DonDiego> vorbis in ogg? [15:24:58] <av500> yep [15:25:08] <DonDiego> do you support mkv? [15:25:10] <av500> yes [15:25:16] <av500> vorbis in that one too :) [15:26:27] <av500> but as there is no theora decoder for the DSP, I never bothered to even think about suppoting it [15:27:16] <av500> hint to xiph/mozilla: take your $5million that you dont want to pay to MPEGLA and use it to write DSP codecs [15:28:25] * kshishkov thinks about Mozilla DSp for decoding Theora [15:28:41] <kshishkov> will it take 5A and occasionally explode? [15:28:47] <av500> kshishkov: no [15:28:55] <av500> it just needs to be DONE [15:29:00] <jai> Tjoppen: do you have other patches for the mov muxer as well? [15:29:23] <av500> kshishkov: there was this gsco project to do it -> fail [15:29:29] <DonDiego> i think they're working on that.. [15:29:30] <av500> there was neuros doing it -> fail [15:29:41] <kshishkov> why? [15:29:42] <av500> DonDiego: well, how long will it take? the time is now [15:29:59] <av500> show the world that theora is there on e.g. omap3 [15:30:04] <kshishkov> C-to-silicon compilers can't take Xiph code? [15:30:31] <av500> kshishkov: I am not talking about hw decoders [15:31:10] <av500> where are the xiph patches to android to support ogg/theora? [15:31:19] <bilboed-pi> errr... http://www.schleef.org/blog/2009/11/11/theora-on-ti-c64x-dsp-and-omap3/ [15:31:44] <av500> "...he Theora decoder plays 640×360 24fps at slightly more than 100% speed on average..." [15:31:46] <mru> is that the one that's slower than plain c on arm? [15:32:41] <bilboed-pi> the difference being : he actually did something, you're just rambling :P [15:32:54] <bilboed-pi> and that was 6 months ago [15:33:09] <av500> yes, and what happened since then? why did they not followed up with funding? [15:33:14] <av500> I am not rambling [15:33:14] <mru> look, I don't give a rat's arse about theora [15:33:21] <mru> I'm doing other things [15:33:39] <DonDiego> please, this used to be about ogg.. [15:33:47] <DonDiego> maintain the topic [15:33:53] <av500> jaja [15:33:55] <bilboed-pi> :) [15:34:02] <av500> ogg sucks! [15:34:05] <av500> better? [15:37:11] <kshishkov> av500: ogg sucks better than what? [15:44:36] <janneg> ms vacuum cleaner [15:48:06] <danielk22> Is there a preferred way to flip bit order in a byte in ffmpeg (i.e. macro,lookup table,function) ? [15:48:27] <kshishkov> out[i] = ff_reverse[in[i] [15:48:38] <mru> we should wrap that in an asm-able macro [15:48:51] <danielk22> kshishkov: thx [15:49:41] <kshishkov> mru: and on what arch it will give any benefit? [15:49:53] <mru> arm for starters [15:49:59] <mru> anything with a bitrev instruction [15:50:19] <kshishkov> I understand that and ask for specific examples [15:50:41] <mru> well, arm is one [15:50:44] <mru> most DSPs have it too [15:51:23] <kshishkov> do we support any DSPs but Blackfin? [15:51:29] <mru> we want to [15:52:38] <kshishkov> is that possible without major efforts? [15:53:03] <mru> it's certainly possible with acceptable efforts [15:53:14] <kshishkov> C64+? [15:53:22] <mru> comes to mind [15:53:22] <av500> efforts [15:53:35] <av500> blackfin runs linux on the dsp itself [15:53:47] <mru> unfortunately gcc for blackfin sucks [15:53:52] <mru> probably more even than ogg [15:53:57] <kshishkov> s/for blackfin/ [15:54:07] <av500> / [15:54:15] <mru> gcc blackfin suckage is in a class of its own [15:54:28] <mru> seriously [15:54:41] <mru> arm at same cpu speed runs ffmpeg several times faster than bfin [15:54:46] <mru> the instruction set isn't that bad [15:55:25] <DonDiego> i'm at work, any good music suggestions for hacking? [15:55:36] <av500> silence works for me [15:55:41] <mru> guns n' roses [15:55:50] <kshishkov> John Cage's 4'33" [15:57:28] * kshishkov usually listens at whatever at hand [15:57:54] <jai> brown noise [15:59:10] <jai> BBB: ping [16:01:56] <danielk22> kshishkov: looks like it is av_reverse.. [16:02:09] <BBB> jai: pong [16:02:40] <kshishkov> danielk22: yes, IIRC it's been renamed recently. But you found it anyway [16:08:17] <jai> peloverde: ping [16:28:30] <DonDiego> btw, have you seen monty's response to the lwn article? [16:33:21] <av500> Im still trying to compile the files he linked to :) [16:49:37] <DonDiego> av500: ? [16:51:25] <av500> http://lwn.net/Articles/382603/ [16:51:44] <av500> this one? it has links to .c files, no? [16:54:12] <DonDiego> you're seriously trying to compile that tarkin stuff? [16:54:20] <av500> no :) [19:05:06] <merbanan> saste: -> superdump and accept the invite [19:05:17] <merbanan> I've got the power also [19:42:55] <bcoudurier> hi guys [19:43:11] <_av500_> Dark_Shikari: ping [19:47:00] <BBB> bcoudurier: thanks for the email [19:49:48] <bcoudurier> BBB, you're welcome, thanks for pushing this through [19:55:38] <Dark_Shikari> _av500_: pong [19:56:15] <_av500_> Dark_Shikari: about mpeg2 to mpeg4 transcoding [19:56:39] <_av500_> in compressed domain, i heard several times that it does not work [19:57:01] <_av500_> but did ppl try to use the MVs as hints for the encoder MV search? [19:57:06] <Dark_Shikari> mpeg2->mpeg4 works [19:57:09] <Dark_Shikari> mpeg2->H264 doesn't work [19:57:19] <_av500_> ah [19:57:37] <bcoudurier> wasn't there a paper about this ? [19:58:09] <mru> for some values of work [19:58:20] <mru> mpeg4 has many more mv modes than mpeg2 [19:58:27] <Dark_Shikari> mru: you don't have to use them [19:58:36] <mru> no, but they might give better compression [19:58:44] <Dark_Shikari> yes, but if you're doing comrpessed-domain transcoding [19:58:44] <mru> I suspect that's why they added them [19:58:48] <Dark_Shikari> you already don't give a shit about compression [19:59:03] <mru> why would anyone do compressed-domain transcoding? [19:59:12] <_av500_> speed? [19:59:13] <mru> the only reason I can think of is to write an academic paper about it [19:59:28] <Dark_Shikari> a target device that handles X but not Y? [19:59:30] <Dark_Shikari> Y -> X [19:59:52] <mru> how often do you see a device that does mepg4 but not mpeg2? [19:59:56] <mru> the opposite is common [20:00:12] <superdump> ipod? [20:00:13] <mru> but you can't transcode in that direction [20:00:14] <_av500_> Dark_Shikari: assume i downscale, would the downscaled MVs help the enc? [20:00:30] <Dark_Shikari> not really that much [20:00:43] <Dark_Shikari> at fast settings, more time is spent in qpel refine than in fullpel ME [20:00:46] <Dark_Shikari> at least in x264 [20:00:47] <_av500_> in order to limit the search space? [20:01:01] <_av500_> ah ok [20:01:55] <_av500_> mru: we were talking over lunch to do some transcoding on the omap3 [20:02:31] <_av500_> decode on arm, encode on dsp [20:03:36] <_av500_> hence the idea of reusing the MVs for downscaled transcoding [20:05:19] <Dark_Shikari> here's x264 on low-latency superfast encoding settings. no idea how their encoder compares [20:05:22] <Dark_Shikari> http://pastebin.org/141858 [20:05:30] <Dark_Shikari> consider where the time is spent. [20:15:52] <dgt84> Can someone explain how asm functions are used in libavcodec/dsputil.c? It seems there is e.g. vsad16_c defined there then vsad16_mmx and vsad16_mmx2 defined in the x86 folder. Is there a way to call one but have it set the best option at compile time magically? Is that what it does when making ffmpeg? [20:17:20] <superdump> function pointers... [20:20:52] <dgt84> superdump, sure, but how do I go about using them to have the correct function chosen at compile time for those particular functions? I don't know the internals of libavcodec all that well... [20:21:10] <_av500_> configure script [20:34:15] <BBB> dgt84: you init a dspcontext [20:34:39] <BBB> dgt84: that gives you a struct with filled-in optimal function pointers to whichever vsadXX*() is best for your cpu [20:34:51] <BBB> then you call ctx->vsadXX*() [20:34:53] <BBB> and you're done [20:35:29] <dgt84> BBB, thanks, I was just reading that in the code, but it seems to also need an AVCodecContext to be setup, going to see how easy that is [20:35:59] <mru> that's only used for flags [20:36:06] <mru> and the codec id in a couple of cases [20:36:16] <mru> those should really be fixed [20:42:49] <dgt84> Thanks guys, I have it working nicely. Those MMX/SSE instructions are considerably faster for block comparisons [20:43:25] <Dark_Shikari> what are you using them for [20:43:27] <mru> no kidding [20:45:10] <Dark_Shikari> "considerably faster" is a tad of an understatement [20:46:20] <Dark_Shikari> theory says 21.33x faster for SAD block comparisons on aligned data [20:46:26] <Dark_Shikari> benchmark says 21.35x faster. [20:46:57] <dgt84> Just messing around. I wrote a libavfilter for deshake/depan/stabilize and wanted to see the difference that some assembly could make in the speed of it. Now I can deshake a live video feed from my camera which is neat, but something isn't quite right with the way I'm using the dsputil functions, gotta fix that. [20:47:14] <Dark_Shikari> isn't that just a global motion estimation problem? [20:47:24] <Dark_Shikari> it sounds like the best way to do that is to use hierarchical motion estimation [20:47:53] <dgt84> I have one of those crappy handheld cams that fit in your pocket and was hoping to stabilize them a bit. I'm a complete n00b when it comes to encoding and motion estimation, been trying to read a bit and messing around on my own. [20:48:05] <Dark_Shikari> so here's the simple way [20:48:15] <dgt84> I have it working in my filter nicely, it's just slow and I'm doing exhaustive searches FTL [20:48:18] <Dark_Shikari> 1) Let there be a function that downscales the image by a factor of 2 (and pads the edges accordingly) [20:48:32] <Dark_Shikari> Let's call this function Image DownSize( Image i ); [20:48:41] <Dark_Shikari> takes an image, returns an image downscaled by 2 and padded to mod16 in both directions. [20:49:23] <Dark_Shikari> 2) Run this on the image repeatedly, storing the result each time. So you have 1x (original), 2x downscaled, 4x downscaled, etc. [20:49:38] <Dark_Shikari> 3) Do this until you have a very low res one on the bottom. Say, 64x64. [20:49:55] <Dark_Shikari> 4) Perform a dead-simple diamond motion estimation, using the entire frame as your block size. [20:50:16] <Dark_Shikari> subpel is highly recommended. [20:50:36] <Dark_Shikari> 5) Double the length of the MV in the horizontal and vertical directions. Go to the next-lowest-resolution version. Repeat, except start at the MV from the previous one (doubled, as mentioned). [20:50:40] <dgt84> Won't downscaling the image a few times take a while? [20:50:45] <Dark_Shikari> 6) Repeat until you reach the full res version. [20:50:49] <Dark_Shikari> 7) You're done. [20:50:57] <Dark_Shikari> only the first downscaling step is slow [20:51:01] <Dark_Shikari> each one is 4 times faster than the previous [20:51:11] <Dark_Shikari> and "slow"... not really [20:53:13] <Dark_Shikari> the downscale can be a REALLY fast downscale, like x264's [20:53:31] <Dark_Shikari> which has the amusing property of being like 25x faster in asm than C (40x on altivec) [20:53:45] <dgt84> Right now my algorithm is: split image into blocks, discard low contrast blocks, do full motion search by x pixels in any direction on rest with SAD block comparison, figure out which mv is most common and the most likely global mv, shift image [20:54:11] <Dark_Shikari> probably best to just search the whole image. though you could cheat and ignore low complexity blocks in my method too [20:54:17] <Dark_Shikari> though the way I'd skip is by checking their SAD [20:54:23] <Dark_Shikari> and checking against some threshold [20:54:35] <Dark_Shikari> probably a threshold based on the overall sad of the frame [20:54:55] <dgt84> yeah I wasn't sure what to make the threshold and tried several values but it's tough to get it working nicely on all samples [20:55:08] <Dark_Shikari> this is why you use hierarchical estimation [20:55:10] <dgt84> The contrast threshold I do now seems to work okay [20:55:26] <iive> Dark_Shikari: x264 uses multiple downscaling ? [20:55:32] <dgt84> Do you think your method would be faster and/or more accurate? [20:56:06] <Dark_Shikari> iive: no [20:56:13] <Dark_Shikari> dgt84: more accurate definitely [20:56:13] <iive> only once? [20:56:22] <Dark_Shikari> faster, not sure but you won't need anything more than diamond search [20:56:23] <Dark_Shikari> no exhaustive [20:56:25] <Dark_Shikari> iive: for lookahead [20:56:38] <Dark_Shikari> it's also not a "real" downscale: it outputs 4 planes, for "hpel" [20:56:46] <Dark_Shikari> i.e. given: [20:57:20] <iive> that's more like upscale [20:57:23] <Dark_Shikari> it does both [20:57:30] <Dark_Shikari> FX XFX XF [20:57:40] <Dark_Shikari> X X X X X [20:57:51] <Dark_Shikari> FX XFX XF [20:57:53] <iive> the middle pixel is downscaled version... [20:58:00] <Dark_Shikari> "F" are source pixels [20:58:10] <Dark_Shikari> or wait, that's wrong too [20:58:26] <Dark_Shikari> the formula is easier to post. [20:58:33] <iive> don't i got the idea [20:58:44] <Dark_Shikari> the formula is actually sorta important to see _why [20:58:58] <Dark_Shikari> #define FILTER(a,b,c,d) ((((a+b+1)>>1)+((c+d+1)>>1)+1)>>1) dst0[x] = FILTER(src0[2*x ], src1[2*x ], src0[2*x+1], src1[2*x+1]); dsth[x] = FILTER(src0[2*x+1], src1[2*x+1], src0[2*x+2], src1[2*x+2]); dstv[x] = FILTER(src1[2*x ], src2[2*x ], src1[2*x+1], src2[2*x+1]); dstc[x] = FILTER(src1[2*x+1], src2[2*x+1], src1[2*x+2], src2[2*x+2]); [20:59:04] <Dark_Shikari> lol line breaks disappeared. [20:59:10] <Dark_Shikari> anyways, the idea is that it only requires "pavg" [20:59:20] <Dark_Shikari> every single operation is (x + y + 1)>>1 [20:59:40] <Dark_Shikari> and you can use it for hierarchical search [20:59:49] <Dark_Shikari> you run it on source, giving you Lowres plane + hpel [20:59:54] <Dark_Shikari> you run it on lowres, giving you ultra-lowres + hpel [20:59:55] <Dark_Shikari> etc [21:00:05] <Dark_Shikari> the hpel is useful for, well, subpel search. [21:01:44] <dgt84> Dark_Shikari, thanks for the tips I'll try and read up a bit more on this stuff and put it into my todo to try and figure out how to go about implementing it [21:02:12] <Dark_Shikari> see http://wiki.videolan.org/SoC_x264_2010#GPU_Motion_Estimation_2 [21:02:20] <Dark_Shikari> your algorithm would be the same except that the whole frame has only one MV [21:02:24] <Dark_Shikari> no blocks. [21:37:43] * peloverde pulls hair at the response to crbug.com/39969 [21:39:50] <Dark_Shikari> it's frank barchard [21:39:53] <Dark_Shikari> he is a COMPLETE moron [21:40:08] <Dark_Shikari> every time he's on irc he has demonstrated that he knows absolutely nothing about multimedia or software development [21:40:19] <Dark_Shikari> I have no idea how the fuck he got google to hire him [21:40:41] <Dark_Shikari> he is one of those people who is not merely ignorant, but also a _fool_ [21:43:45] <peloverde> In this case the problem appears to be the ubuntu packager [21:55:49] <mchinen> Hi, is Baptiste around? [21:56:42] <Dark_Shikari> bcoudurier: ^ [21:59:02] <bcoudurier> yes [23:41:48] <pengvado> Dark_Shikari: I'd describe x264's algorithm as a lowpass, not a downscale [23:43:13] <pengvado> you can then subsample the lowpassed image, or not [23:59:45] <mfg> what is dts and pts in a stream?

1 0

IRC log for 2010-04-07
by irc＠mansr.com 08 Apr '10

08 Apr '10

[01:06:18] <CIA-1> ffmpeg: koorogi * r22813 /trunk/ (4 files in 2 dirs): [01:06:18] <CIA-1> ffmpeg: Add unsharp video filter. [01:06:18] <CIA-1> ffmpeg: Contributed by Daniel G. Taylor (dan/at/programmer-art/dot/org) [04:18:39] <peloverde> Is there a cast to const-of-whatever-the-base-type-already-is? [04:19:35] <peloverde> eg float** to const float**, int** to const int** [04:22:15] <astrange> only as a gcc extension [04:27:04] <peloverde> well only gcc seems to warn about such things so that seems like a wash, no? [05:27:56] <peloverde> astrange, re: "Do you really need three books on C? Or any books on C? It seems like it'd be easier to just write a test program than look anything up at that point", too much behavior is implementation dependent, you may wind up with non portable code... or code that behaves differently with optimizations turned on [05:30:01] <astrange> i don't think they're that advanced [06:33:18] <superdump> morning [06:33:34] <superdump> merbzt1: sleep well? :) [06:34:16] <av500> Stockholm still in one piece? [06:34:24] <kshishkov> morrow [06:34:29] <superdump> just about i think [06:34:38] <kshishkov> av500: Sweden is a civilised country unlike Germany [06:35:39] <superdump> yeah, they serve beer and cider in 0.3l glasses and charge lots for it [06:36:01] <kshishkov> don't forget Systembolaget [06:36:11] <superdump> and the licensed alcohol outlet is closed on sunday and closes early on saturday [06:36:16] <superdump> ^ [06:36:34] <kshishkov> and they don't sell to drunked people [06:36:57] <superdump> i was in the supermarket a couple of sundays ago and an american woman came up to the checkout that i was at [06:37:13] <superdump> she asked the cashier if they sold wine [06:37:38] <superdump> the cashier wasn't quick with her response so i said "no, you have to go to the systembolaget down the road" [06:37:45] <superdump> "is it open on sundays?" [06:37:47] <superdump> "no" [06:38:45] <kshishkov> that's one of the reasons why I love Sweden [06:38:47] <superdump> it seems the main consequence of these opening hours is that on friday evening, after work, everyone goes to the systembolaget to stock up for the weekend [06:39:03] <kierank> [07:38] <@superdump> yeah, they serve beer and cider in 0.3l glasses and charge lots for it --> haha [06:39:12] <superdump> well yes, if you don't drink i guess it's better to have less drunkards about [06:39:34] <superdump> and less drinking related accidents/crimes as a consequence i expect [06:39:39] <merbzt1> superdump: yeah, woke up at 0600 and took a swim [06:39:43] <superdump> :) [06:39:48] <superdump> impressive [06:40:04] <superdump> i woke up at 0700 and dozed for half an hour [06:42:24] * kshishkov tries to guess which of those two drank alcohol last night [06:42:49] <merbzt1> lol [06:43:02] <merbzt1> actually I had one glass of cider [06:43:18] <superdump> i had a few more :) [06:43:32] <merbzt1> how long did you stay ? [06:43:34] <superdump> and then we went to an irish bar where they at least served 0.5l glasses [06:43:42] <superdump> i left there at about 0045 [06:43:57] <superdump> to make sure i got the t-bana home [06:44:01] <merbzt1> ok :) then I was firmly in bed [06:44:17] <andoma> hi! [06:44:18] <superdump> hehe [06:44:22] <superdump> god morgon andoma [06:44:25] <andoma> :) [06:44:26] <kshishkov> hej (: [06:44:37] <superdump> hur mÃ¥r pontus idag? [06:44:42] <KotH> grüezi [06:44:44] <andoma> bra, ingen feber [06:44:49] <superdump> \o/ [06:45:04] <superdump> (that's swedish for woohoo) [06:45:25] <kshishkov> nej, det Ã€r inte [06:45:34] <KotH> has "idag" anything to do with "ideg" ? :) [06:45:48] <superdump> probably [06:45:52] <superdump> if it means today [06:46:13] <andoma> iDag is <tm>ed by Apple [06:46:29] <superdump> :) [06:47:01] <kshishkov> andoma: at least they aren't into furniture business, otherwise one logo would have been changed [06:47:30] <andoma> :) [06:49:07] * kshishkov looks at the wikipedia page for the strongest locomotive called MTAB iOre that drives trains with ... [07:10:35] <kshishkov> good Tetris at xkcd [07:43:53] <superdump> ___gb___: ping? [07:48:18] <benoit-> moin [07:48:29] <andoma> hello [10:41:27] <Dark_Shikari> mru: AGHHGHGHGHG [10:41:31] <Dark_Shikari> a guy is trying to run x264 on an arm9 [10:41:34] <Dark_Shikari> *headdesk* [10:42:13] <bilboed-pi> well... if it's for QCIF at 5fps... could be doable, no ? :) [10:42:17] <Dark_Shikari> Probably not. [10:55:39] <av500> Dark_Shikari: there are very fast arm9 these days [10:55:51] <av500> like that stuff that marvell makes [10:56:33] <Dark_Shikari> still has no simd [10:56:40] <av500> true [10:57:26] <av500> maybe they will reach 3ghz soon.... [12:15:39] <av500> wrt animated gifs: http://code.google.com/p/android/issues/detail?id=3422 [12:21:12] <scaphilo> does anyone have a good documentation on how motion vectors in mpeg2 are encoded? i dont really understand why there are such a large amount of values in the MpegEncContext->mv in my understanding there should only be a direction, a x-value and y -value [12:22:19] <Dark_Shikari> you mean motion_val? [12:22:28] <Dark_Shikari> Looks exactly like that to me [12:23:30] <scaphilo> a just a sec, motion_val is a little bit different i think [12:29:10] <scaphilo> no they are quite similar, but i dont understand why there are so many values: i mean motion_val[0][0][0] is the x and motion_val[0][0][1] is the y of the mb_xy=0 but why is there still one level of array? [12:29:29] <scaphilo> i dont understant the documentation in the code [12:29:35] <Dark_Shikari> list0 vs list1 MVs [12:30:55] <scaphilo> there are more than one mv for one mb possible? hmm i really dont understand this part of mpeg2 [12:31:04] <Dark_Shikari> You don't understand what a b-frame is? [12:31:31] <scaphilo> not enough it seems [12:32:04] <scaphilo> do they refer two frames in the same time? [12:32:16] <Dark_Shikari> .... [12:32:25] <Dark_Shikari> they refer to a past frame and a future frame [12:32:37] <Dark_Shikari> this is basic textbook stuff [12:32:55] <scaphilo> yes i know but i didn expect they refer from both at the same time [12:33:35] <scaphilo> hmm is there no better doc than the standard? [12:33:48] <Dark_Shikari> ... referring to both at the same time is _THE ENTIRE POINT_ of b-frames [12:33:57] <andoma> B-type macroblocks predicts from two different (past and future) each with a different x,y motion vector [12:34:54] <scaphilo> ah shit, sorry for this question but how are they calculated then? is it some kind of "mean" of both [12:35:06] <scaphilo> or you mean field based frames [12:35:21] <scaphilo> where the top can refer to a futur and the bottom to a past for example [12:35:27] <Dark_Shikari> it's an average [12:35:29] <Dark_Shikari> that's what biprediction is [12:35:34] <Dark_Shikari> read an introductory textbook [12:37:23] <scaphilo> they normaly dont discuss this things dark_shikari i currently only found the mpeg2 standard do you perhaps have ref to a book i could read? [12:38:31] <scaphilo> when i want to disable all bf in a mpeg2 video is it possible to ffmpeg-i input -bf 0 -vcodec mpeg2video output ? [12:38:31] <Dark_Shikari> well, I've only seen one video compression textbook [12:38:36] <Dark_Shikari> and it sure as hell covers this [12:38:45] <Dark_Shikari> sure, obviously you can re-encode the video and not use b-frames. [12:38:58] <Dark_Shikari> http://www.mediafire.com/download.php?auxd23m2snw here's a textbook [12:39:06] <scaphilo> thank you very much [12:40:53] <KotH> that book isnt that good either [12:41:12] * KotH knows 3-4 text books on video coding and all suck [12:41:31] <andoma> KotH: well.. it's better than nothing. i picked up a few things in that one [12:42:13] <KotH> yeah.. [12:42:15] <scaphilo> i tried som as well, but most of them do only explain how it works in a very abstract way. [12:42:40] <Dark_Shikari> KotH: yes they all suck [12:42:50] <Dark_Shikari> that one's half-decent [12:43:15] <scaphilo> and of couse an other thing is i dont understand english perfectly [12:43:26] <scaphilo> and there absolutly no german book for this things [12:43:37] <Dark_Shikari> nobody understands english perfectly [12:43:47] <KotH> http://www.amazon.com/Video-Coding-Introduction-Standard-Telecommunications… <- this one is better than the above, but quite dated (stops at mpeg2) [12:44:03] <KotH> scaphilo: learn english [12:44:25] <Dark_Shikari> he obviously knows english just fine [12:44:34] <scaphilo> of couse but i dont have time to lern english and then work on my project ;-) [12:44:37] <KotH> scaphilo: there is no way you will be able to participate in OSS in generall and ffmpeg in special w/o half decent english skills [12:44:49] <Dark_Shikari> And there's no way he would be having this conversation without half-decent english skills >_> [12:45:01] <scaphilo> KotH: you mean c-OSS [12:45:03] <Dark_Shikari> I hate how people underestimate their skills [12:45:09] <Dark_Shikari> they go running around whining about how their english sucks [12:45:11] <KotH> well.. you're here chatting... that's the best way to learn a half decent engrish :) [12:45:11] <Dark_Shikari> ... in english ... [12:45:15] <Dark_Shikari> and conversating and chatting.... in english... [12:45:34] <Dark_Shikari> the best part are the japanese who tell you in near-flawless english that their english is bad. [12:45:47] <KotH> Dark_Shikari: well.. my english sucks, i make a lot of mistakes... but at least i can communicate in it :) [12:46:01] <KotH> Dark_Shikari: lol [12:46:11] <KotH> Dark_Shikari: japanese are very humble people.. unlike usians [12:46:25] <scaphilo> ok but i cant read the standard in english thats the thing i dont understand it. I dont know if i would understand it in german [12:46:31] <Dark_Shikari> KotH: US is in the middle [12:46:34] <Dark_Shikari> if you want the opposite of japan, try india. [12:47:03] <Dark_Shikari> japan: I am just a lowly programmer, I'm not good at this stuff! india: I am the best programmer in the world! I can write your website top quality no problem! [12:47:21] <scaphilo> lol [12:47:44] <jai> :) [12:47:45] <KotH> scaphilo: if you dont understand something in one of these books, just ask here [12:47:57] <KotH> scaphilo: we've enough german speaking people here to help you out [12:48:00] <Dark_Shikari> yes, don't be afraid to ask questions =p [12:48:08] <Dark_Shikari> und deutsch ist nicht so schwer [12:48:18] <Dark_Shikari> es ist englisch mit mehr lange Worten [12:48:24] <KotH> jo, s'isch ganz eifach.. sogär i chas räde :) [12:48:30] <scaphilo> :-) right thx for help [12:48:39] <pJok> deutsch, svenska, dansk, english and a lot of other languages [12:48:44] <KotH> nihongo mo [12:48:46] <scaphilo> shit even swiss german [12:48:51] <Dark_Shikari> lol [12:49:57] <KotH> wait a sec [12:49:59] <KotH> you're swiss [12:50:03] <scaphilo> right [12:50:10] <KotH> from where? [12:50:13] <KotH> what school? [12:50:21] <jai> ..and the inquisition begins [12:50:30] <scaphilo> HSR (Rapperswil) [12:50:34] <KotH> jai: nobody expects the swiss inquisition ;) [12:50:36] <pJok> evenings jai :) [12:50:41] <jai> KotH: heh :) [12:50:44] <jai> ohai pJok [12:50:54] <pJok> KotH, nobody expects the swiss navy ;) [12:51:15] <KotH> pJok: i guess you've never seen me in full gear? :) [12:51:15] <scaphilo> thats right but why do you know that there is one? [12:51:24] <pJok> KotH, i haven't [12:52:01] <Dark_Shikari> http://en.wikipedia.org/wiki/Merchant_Marine_of_Switzerland [12:52:55] <scaphilo> so where are you from KotH? ETH [12:56:14] <av500> Dark_Shikari: book is good, has ffmpeg logo on page 84 [12:56:20] <av500> scaphilo: yes [12:58:14] <scaphilo> by the way i have a problem with the FF_COMMON_FRAME->uint8_t *data; its only 8 bit but i need at least an int for my application i want to write. What would you say is the better way: Changing the type of this variable or creating a new one? i want to transfer the dct coefficients directly from decoder to the encoder without idct/dequant [12:59:14] <av500> and int? for a pointer to data? [12:59:20] <Dark_Shikari> av500: wait what? [12:59:32] <av500> Dark_Shikari: zigzag pattern :) [12:59:34] <Dark_Shikari> lol [13:00:17] <scaphilo> am no i mean the data itself is 8 bit not the pointer to it [13:01:10] <scaphilo> sorry name of variable is wrong ... [13:01:16] <Dark_Shikari> there's already a way in the api to export dct coefficients afaik [13:01:44] <av500> scaphilo: what is your project about? [13:01:48] <scaphilo> Dark_Shikari: ? [13:01:51] <av500> compressed domain transcoder? [13:02:02] <scaphilo> no openloop transcoder mpeg2 to mpeg4 [13:02:15] <Dark_Shikari> that's what he just said [13:03:00] <scaphilo> Dark_Shikari how do i export them? [13:03:17] <nfl> merbzt1, ping [13:04:49] <scaphilo> FF_COMMON_FRAME->dct_coeff perhaps? [13:04:59] <scaphilo> is this variable not used somwhere else? [13:25:15] <KotH> scaphilo: ex-eth [15:00:35] <lu_zero> hi [15:00:41] <lu_zero> wbs: you around? [15:35:23] <Tjoppen> I think I managed to import Diego's key into seahorse and sign it with my own key. time to send some mail [15:37:00] <kshishkov> also don't forget to mention your IRC nick to him [15:37:15] <kshishkov> if you're FFmpeg dev you get op status here for free [15:37:25] <Tjoppen> sweet [15:37:57] <kshishkov> (others can bribe us with useful patches to get voice status here) [15:38:34] <Tjoppen> time to pick a username I guess. tjoppen, tomss, tomash and thardin are all good choices [15:38:40] <Tjoppen> *tomas [15:39:00] <kshishkov> not "tomash" [15:39:11] <kshishkov> sounds like Polish name [15:39:19] <Tjoppen> good point [15:39:46] <kshishkov> Tjorven? [15:40:01] <Tjoppen> nein [15:40:12] <av500> MrT? [15:40:13] <kshishkov> just pulling your leg [15:41:22] <kshishkov> av500: I think he'll pity you fool then [15:42:16] <Tjoppen> poor Måns, always being called Mans [15:42:27] <av500> I call him mru :) [15:42:33] <kshishkov> no, some of us call him MÃ¥ns [15:43:36] * elenril throws http://en.wikipedia.org/wiki/UTF-8 at Tjoppen [15:44:54] <Tjoppen> http://xn--n3h.net/ [15:45:26] <Tjoppen> or <snowman>.net, but screen and/or irssi doesn't seem to handle that very well [15:46:31] * KotH wonders how that glyph ended up in unicode [15:46:44] <kshishkov> dingbats copy-paste [15:46:46] * KotH also wonders, whether there is a character for totem [15:47:00] <KotH> s/ t/a t/ [15:48:26] * av500 throws http://en.wikipedia.org/wiki/Baudot_code at elenril [15:49:38] <kshishkov> runes, anyone? [15:49:51] <kshishkov> it's traditional and Swedish anyway [15:54:04] * KotH writes his name with the blood of his enemies [15:54:21] <Tjoppen> maybe I should pick "räksmörgås" as username [15:55:40] <kshishkov> yes, give admin a hard time :) [15:55:50] <elenril> srsly what's up with people using obsolete encodings =p [15:56:05] <jai> prawn sandwich? [15:56:24] <kshishkov> seems so [15:56:29] <KotH> Tjoppen: denied! [15:57:05] <kshishkov> ostsmÃ¶rgÃ¥s eller skinkasmÃ¶rgÃ¥s men ej rÃ€ksmÃ¶rgÃ¥s [15:57:14] <KotH> elenril: it's the superior way to troll you and rich :) [15:57:41] * elenril feeds the troll [15:58:00] * KotH eats elenril [15:58:29] * kshishkov uses a herd of goats on KotH [15:58:39] <jai> -_- [15:58:47] <elenril> ãŠãã³ãŒã! [15:59:41] <Tjoppen> bah, I'm going with thardin. time to send mail [16:01:06] <KotH> kshishkov: cool! fresh and still packaged meat! [16:01:41] <kshishkov> KotH: you're too illiterate to know what exactly billygoats do to trolls [16:03:58] <KotH> kshishkov: my norse is inexistent [16:04:05] <KotH> kshishkov: beside, that was one incompetent troll [16:16:20] <dgt84> Is it possible / easy for me to use a block comparison function from e.g. libavcodec in a filter, including the MMX/SSE optimized versions? I'm doing some motion estimation and compensation in a filter and it's dog slow, but I don't know the libavcodec code well enough... [16:17:14] <dgt84> dsputil seems to have some references to different comparison functions but I'm not sure how I'd go about using them myself [16:17:51] <merbanan> it is possible [16:17:57] <merbanan> but might not be easy [16:36:24] <Tjoppen> durr [16:36:42] <Tjoppen> Evolution saved my encrypted mail using Diego's key, not mine. how very useful :o [16:37:28] <DonDiego> moin [16:38:40] <kshishkov> grÃŒss dich [16:43:45] <hyc> adios [17:05:17] <DonDiego> Tjoppen: try leaving and rejoining the channel [17:11:08] <Tjoppen> \o/ [17:27:24] <KotH> has anyone here read the ACTA draft? [17:29:36] <av500> is that a speech codec? [17:31:05] <astrange> copyright treaty [17:31:11] <KotH> nope, the international treaty proposal, that might kill the internet as we knew it and would make it possible that any data storing device might be seized at borders [17:32:16] <BBB> these stupid idiot politicians think that they can make some bunch of paper rules and things will go juuuuuuuuust fine [17:32:21] <BBB> just how will they enforce these rules? [17:33:07] <KotH> even if they are just partially enforced, the rights that the intellectual property right holders get trough it is ridiculous [17:34:16] <KotH> the proposal goes so far that if you are sued by the mpaa/riaa for infriging on some copyright, you have to fully compensate for the potential damage, pay for the court fees of both parties and pay the atorneys of the wining party [17:35:04] <KotH> or, that the customs officier at the border might seize any object that might be infringin on any rights [17:35:31] <KotH> (eg ipods, phones, laptops with data on them, as they might contain illigaly copied material) [17:35:45] <av500> it will all be in ze cloud :) [17:36:13] <elenril> human brains? [17:36:17] <av500> KotH: 1st rule to make a police state is to declare everybody a criminal [17:36:26] * elenril seizes av500's brain [17:36:28] <KotH> oh yes.. any third party that is helping in distribution of these violating goods, is fully liable too (eg. your isp is liably for you sharing files) [17:36:38] <KotH> s/liably/liable/ [17:37:01] <av500> KotH: it is all a scheme to close the internet and drive people back to mon&pop brick&mortar stores [17:37:35] <BBB> KotH: again, how will it be enforced? [17:37:45] <BBB> an ipod is no evidence [17:37:56] <BBB> there is no difference between an illegaly copied mp3 or a legally duped one from a cd [17:37:56] <av500> BBB: selectively, enough to create "fear" [17:38:00] <BBB> it is no evidence [17:38:05] <BBB> you guys exxagerate [17:38:13] <BBB> (spelling?) [17:38:28] <KotH> BBB: it is enough that you are _suspected_ to have illegally copied material [17:38:36] <KotH> BBB: there does not need to be a prove [17:38:43] <BBB> the fact that they go after bittorrent downloaders of illegal moies is completely logical [17:38:46] <BBB> and I have nothing against that [17:39:03] <KotH> BBB: later in court, they need to prove that you illegally copied the stuff, but for seizing them, a hunch is enough [17:39:04] <elenril> well downloading movies is perfectly legal here [17:39:04] <av500> BBB: take airport strip searching, it does not increase security but makes me not want to fly, mission accomplished [17:39:24] <KotH> BBB: downloading movies is legal in more countries than you'd think [17:39:27] <BBB> elenril: every download requires an upload [17:39:33] <BBB> the upload is illegal in europe, too [17:39:42] <BBB> anyway, they won't seize your ipod [17:39:42] <KotH> BBB: nack [17:39:46] <av500> BBB: no, in some BBS you get a 10:1 ratio :) [17:39:46] <BBB> because they cannot get evidence from it [17:39:50] <BBB> yoiu're taking it too far ;) [17:40:11] <av500> BBB: they can sieze and lose it :) [17:40:11] <BBB> if they *could* get evidence from an ipod, that'd be amazing and they would surely try [17:40:12] <KotH> BBB: my bt clients do not upload, for exactly that reason :) [17:40:13] <BBB> but they cannot [17:40:13] <av500> 4) profit [17:40:27] <BBB> av500: they cannot seize it out of your sight, if you read correctly [17:40:29] <twnqx> why can't they get evidence? you can access any ipod [17:40:34] <BBB> they may inspect [17:40:34] <BBB> b [17:40:40] <BBB> ut they must leave it within your sight [17:40:48] <av500> that is written there? [17:40:50] <BBB> twnqx: so there's an mp3 on it. now what? [17:40:55] <thresh> KotH: my whiney ISP asked me to stop using torrents because i DLed some episode of show that is not even on air in Russia [17:40:55] <av500> I am very short sighted [17:40:55] <twnqx> play it [17:40:57] <BBB> av500: if you go beyond slashdot :) [17:41:05] <BBB> twnqx: it's britney spears, now what? [17:41:22] <av500> BBB: -> 10 years jail for britney [17:41:24] <elenril> thresh: since when does russia care about copyright? [17:41:25] <twnqx> now the burden of proving that it's legit is on you. [17:41:27] <av500> no question asked [17:41:30] <BBB> twnqx: nope [17:41:37] <BBB> twnqx: I downloaded it from amazon is all you have to say [17:41:37] <KotH> BBB: i dont see any such provision in the current draft [17:41:45] <BBB> KotH: you read too much slashdot [17:41:52] <thresh> elenril: that's what i asked by ISP [17:41:54] <BBB> it's not as crap as you think :) [17:41:57] <thresh> elenril: and they didnt reply me ;-) [17:42:01] <KotH> BBB: slashdot? [17:42:04] <BBB> for god's sake, stop reading slashdot guys :) [17:42:08] <KotH> BBB: i have the acta draft infront of me [17:42:12] * av500 doth not read /. [17:42:25] <KotH> BBB: and i dont read slashdot, teh SNR is too low :) [17:42:28] <BBB> KotH: is it authentic? :) [17:42:43] <KotH> BBB: nobody claimed otherwise yet :) [17:42:47] <elenril> anyways, at least EP is against acta [17:42:55] <KotH> BBB: http://www.laquadrature.net/en/0118-version-of-acta-consolidated-text-leaks [17:43:00] <BBB> KotH: lol :) [17:43:40] <av500> elenril: EP is a joke [17:44:00] <elenril> av500: well yeah, but it's better than nothing [17:44:20] * av500 is not sure in this case [17:44:23] <av500> :) [17:45:13] <av500> KotH: cool, that ACTA draft is and adventure [17:45:26] <av500> at each paragraph, I decide what country to follow [17:47:18] * av500 imagines immigration lines with ipod dock connectors next to fingerprint scanners [17:47:48] * av500 imagines people struggling to explain to customes guy that their mp3 player is not from apple [17:48:22] <mru> easy, ban non-ipods [17:48:33] <av500> and non-ibooks [17:48:39] <KotH> BBB: i dunno how much experience you've with reading law texts, but here in .ch such a text like this would be torn apart at any voting, because of it's ambigouty, broadness and collateral damage [17:48:59] <av500> KotH: that has not stopped other laws in the past [17:49:13] <KotH> yes... [17:49:18] <BBB> KotH: I interact a lot with sflc, I've seen law texts [17:49:21] <KotH> but it stopped quite a few [17:49:32] <BBB> like I Said, I'm not a slashdot lawyer [17:49:38] <BBB> I'm someone actually involved in legal stuff [17:49:45] <KotH> BBB: legal text or law text? there is a difference :) [17:49:56] <BBB> they are similar in writing :) [17:50:37] <KotH> yes, but one has a a-priory context, while the other has a-posteriori context ;) [17:50:43] <KotH> s/ry/ri/ [17:50:51] <av500> KotH: they talk about personal goods within the duty free allowance not to be checked... how many GB are duty free? :) [19:31:47] <matth> hi there, any guys working on supporting bcm crystal hd ? [19:31:55] <lu_zero> somebody is [19:31:59] <lu_zero> somehow [19:32:04] <matth> cool [19:32:09] <matth> any public page ? [19:32:19] * lu_zero would be happier to get everthing into libva [19:32:54] <lu_zero> matth: I think you could check mike blog for pointer and/or xbmc [19:35:58] <matth> mmh let me find who's mike [19:36:45] <superdump> mike melanson [19:36:54] <superdump> multimedia.cx/eggs [19:36:56] <superdump> i think [19:37:43] <matth> oh ok tx [19:41:38] <CIA-1> ffmpeg: banan * r22814 /trunk/libavformat/spdif.c: [19:41:39] <CIA-1> ffmpeg: Don't write an empty spdif header in spdif muxers write_header function before actual data starts. [19:41:39] <CIA-1> ffmpeg: Patch by Elupus. [19:42:12] <superdump> another swede eh? [19:42:17] * superdump wonders who Tjoppen is [19:42:58] <superdump> ah, just threads i haven't read :) [19:43:01] <superdump> welcome [19:43:08] <Tjoppen> yeah, I was just about to say :) [19:43:41] <superdump> whereabouts in se? [19:43:53] <Tjoppen> hopefully I'll be able to commit that seek/probe stuff tomorrow in a clean fashion [19:43:56] <Tjoppen> umeå [19:44:47] <superdump> myself, merbanan and andoma are in sthlm [19:45:04] <superdump> though i'm british and don't know much swedish yet :) [19:45:19] <merbanan> you are assimilated already [19:45:29] <superdump> heh [19:45:29] <merbanan> resistance is futile [19:45:31] <andoma> yu p :) [19:46:31] <Tjoppen> lived there 04-06 [19:47:10] <Tjoppen> but meh. studying in kista sucked [19:48:16] <superdump> it's only about 20 minutes from the center, no? [19:48:21] <superdump> on the subway [19:48:55] <Tjoppen> not from vällingby [19:49:37] <superdump> oh [19:49:49] <superdump> did you have to go in and come out again? [19:50:10] <superdump> no buses between them? [19:50:43] <Tjoppen> only bus. ~50 min to school, compared to around 5 now [19:51:03] <merbanan> Tjoppen: ha [19:51:06] <superdump> :/ [19:51:08] <merbanan> I live there now [19:51:08] <superdump> urgh [19:51:17] <superdump> i live nowhere! [19:51:23] <superdump> :) [19:51:31] <lu_zero> ^^ [19:51:47] <superdump> apart from uncovering a fraud, so far my searches have proven unsuccessful [19:51:57] <Tjoppen> also, no one lives where anyone else lives in stockholm, unlike umeå where everyone lives in ålidhem [19:51:57] <KotH> fucking ieee [19:52:11] <KotH> sends mails telling me i'm a criminal [19:52:35] <merbanan> Tjoppen: true [19:53:16] <av500> KotH: we will visit you in jail [19:53:43] <merbanan> KotH: and laugh at you [19:54:04] <KotH> dont worry, what i do is perfectly legal in .ch [19:54:20] <av500> what did you do? [19:54:24] <KotH> it's just the ieee who doesnt want that anyone who isnt a member sees any ieee document [19:55:00] <KotH> and they send a mail out telling every ieee member that they _ARE_NOT_ALLOWED_TO_ share any of the documents with any of their collegues [19:55:05] <av500> lol [19:55:13] <KotH> so much for "advancing technology for humanity" [19:55:21] <av500> the true academic spirit [19:55:28] <KotH> yeah [19:55:35] <KotH> i send a pretty angry mail back [19:55:38] <av500> they also ask you to burn your ieee books?= [19:55:45] <av500> before somebody reads them [19:56:34] <av500> 1st rule of ze interwebs: treat all customers are criminals [19:56:50] <KotH> yeah.. [19:56:57] <lu_zero> ... [19:57:10] <KotH> and i pay them 500 fucking USD each year! [19:57:16] <lu_zero> all customers are criminal you included [20:01:44] <superdump> Tjoppen: but but but, if i lived in hÃ€sselby, i could have an apartment like this for 6500/mÃ¥ : http://www.andrahand.se/Apartment/images/11443/ [20:06:55] <CIA-1> ffmpeg: banan * r22815 /trunk/ffserver.c: Add DynamicACL support for FFserver. [20:16:30] <Tjoppen> indeed

1 0

IRC log for 2010-04-06
by irc＠mansr.com 07 Apr '10

07 Apr '10

[00:53:05] <bcoudurier> hi guys [04:01:13] <troy_s> Is it possible that using setColorspaceDetails and then a subsequent sws_scale is not working on interlaced (either progressive stored in interlaced format or traditional interlaced) material? I can't seem to get it to trip for interlaced content. [04:24:21] <kshishkov> mru: here? [04:27:28] <kshishkov> looks like Norway thinks too much of itself - try "kveldsflyet fra Oslo" in Google Translate [05:31:37] <thresh> moroning [05:31:55] <thresh> i thought i was typing 'morning' and then this came out :-( [05:33:06] <kshishkov> and that happens every day [05:34:02] <thresh> in putin russia, you don't choose between mornings [05:34:20] <kshishkov> like you could choose in Soviet times [05:35:30] <thresh> in fact, in soviet times my life was really cool [05:35:53] <thresh> they feed me, took me to a kindergarten where i could sleep as much as i would [05:35:57] <thresh> play games etc [05:41:13] <pJok> god morgon, kshishkov :) [05:46:14] <kshishkov> goda morgnar, pJok [05:55:02] <pJok> i wonder when the first requests for help compiling ffmpeg on ipad will come [05:55:27] <kshishkov> probably iPhone way will work as bad on iPads [05:55:45] * kshishkov waits for requests on help compiling FFmpeg for iMats [05:55:53] <pJok> considering its pretty much the same hardware and software [05:55:58] <pJok> just scaled up [05:57:10] <pJok> i did underestimate the market for an oversize ipod touch [05:57:32] <pJok> i didn't think apple would be able to ship 300k units [05:57:35] <pJok> but i was wrong [05:57:37] <kshishkov> it's all about glamour, you know [05:59:04] <pJok> i could see some use for it if it was a bit more powerful [05:59:14] <kshishkov> or more open [05:59:25] <pJok> or open [05:59:26] <pJok> yes [06:00:02] <pJok> sadly the ipad means that there will now me 1000 clonepads with various configurationss of the atom processor [06:01:18] <av500> yep [06:01:29] <kshishkov> eww [06:01:33] <pJok> be* [06:02:05] <pJok> if we are lucky, some of them will have a decent arm processor [06:02:09] <pJok> but i doubt it [06:02:14] <kshishkov> since Intel sold its ARM division, it can be safely buried now [06:02:38] <kshishkov> Chinese seem to produce overgrown PocketPCs based on ARMs for ages [06:02:39] <saintd3v> maybe someone will be smart and use a snapdragon [06:03:06] <pJok> saintd3v, too expensive [06:03:22] <pJok> you can't compete with apple on the margins if you use a snapdragon [06:03:43] <kshishkov> pJok: you can try stealing one of tablet/netbooks based on OMAP3 from av500 [06:03:45] <saintd3v> i said smart, not profitable [06:03:46] <pJok> apple didn't even bother putting a better processor in the A4 [06:04:03] <pJok> hehe [06:04:33] <av500> choise of 256MB only is most puzzling to me [06:04:58] <kshishkov> should be enough to compile FFmpeg [06:05:08] <pJok> at least OPAM3 is fairly decent [06:05:12] <pJok> OMAP3* [06:05:37] <av500> what is in the ipad is more or less the same, 1ghz A8, 3d gfx core [06:06:42] <pJok> yeah, but the didn't bother scaling it up much from the iphone/ipod touch [06:07:19] <pJok> and it doesn't run flash [06:07:25] <av500> so? [06:07:34] <kshishkov> good for it [06:07:36] <av500> I have the iphone and android phones and I never missed flash [06:07:39] <saintd3v> or maybe even heaven forbid a tegra2 [06:07:44] <pJok> hehe [06:07:58] <av500> I even run my main webbrowser sans flash [06:08:08] <saintd3v> i thought adobe had an arm build of flash [06:08:16] <av500> sure [06:08:20] <pJok> but the people who are most likely to buy an ipad are also most likely to play all those stupid games on facebook [06:08:38] <saintd3v> pJok: farmville!!1!one [06:08:41] <saintd3v> :P [06:08:46] <pJok> exactly [06:08:48] <kshishkov> av500: "I even run my main webbrowser sans flash" - that's the reason browser ran smoothly [06:08:53] <av500> pJok: once they realize that, I hope there will be a ton of 2nd hand ipads for cheap [06:09:10] <pJok> av500, its apple hardware... apple hardware was never cheap [06:09:14] <pJok> and never will be [06:09:25] <av500> pJok: http://imagebin.org/91858 [06:09:30] <av500> 499 vs 549 [06:09:34] <av500> ipad is cheaper [06:09:39] <pJok> even powerbooks are still fetching a high pricetag despite not really being worth anything [06:10:18] <kshishkov> pJok: hardware is cheap, you pay for glamour [06:10:23] <pJok> i know :) [06:10:26] * pJok has a mac [06:10:41] <av500> actually, 10" mutlitouch screen is not cheap at all [06:13:07] <pJok> av500, it will be now [06:13:21] <av500> kshishkov: btw, I find that when I use youtube, I always klick pause immediately and wait for 5 min for the video to buffer, I guess Buffering Inc. realized that years ago :) [06:13:52] <kshishkov> av500: get a better channel [06:14:26] <kshishkov> my 1 megabit line is enough to play it almost without buffering [06:14:31] <Dark_Shikari> kshishkov: unrelated [06:14:34] <Dark_Shikari> youtube intentionally throttles [06:15:41] <kshishkov> ah [06:16:00] <kshishkov> maybe they don't throttle low-quality videos that much [06:16:22] <Dark_Shikari> well it's just that the videos are throttled depending on their bitrate [06:16:25] <Dark_Shikari> youtube isn't stupid. [06:26:44] <pJok> YourTub [06:27:27] <kshishkov> it all changes for those who get Google ISP [06:30:33] <superdump> i don't normally let it buffer the whole way [06:30:46] <superdump> but i do let it buffer more than they say [06:31:43] <superdump> sometimes i let some sites buffer the whole way because it seems updating the progress bar eats cpu time and makes the video playback (higher resolution stuff) chooppy(/ier) [06:31:52] <av500> for me, it has to do with the fact that I usually have to fast forward to almost the end to skip all the boring bits [06:32:37] * av500 thinks ppl that upload to youtube should be forced to at least watch what they uploaded once completely [06:33:03] <superdump> i don't watch that much youtube stuff really [06:33:15] <kshishkov> there's youtube-dl.pl for the rest of us anyway [06:33:18] <superdump> only actually interesting things that people are pasting around [06:33:43] <av500> superdump: same here, but sadly utube clips have replaced .jpg and .png a lot... [06:33:59] <av500> so very often I need to fire up utube to see one still image [06:34:06] <kshishkov> better than animated gifs though [06:34:15] <av500> kshishkov: they load faster [06:34:27] <kshishkov> and usck differently [06:34:28] <Dark_Shikari> the fact that animated gifs still exist is hilarious [06:34:31] <kshishkov> *suck [06:35:07] <superdump> Dark_Shikari: better than having youtube videos for avatars on forums [06:35:27] <Dark_Shikari> animated gif avatars should be bannable [07:12:22] <KotH> salut [07:12:27] <kshishkov> shalom [07:27:02] <pJok> saintd3v, http://www.engadget.com/2010/04/06/icds-tegra-2-powered-gemini-is-the-most-… [07:29:42] <av500> pJok: yes, an android running tablet makes sense [07:30:19] <pJok> he just mentioned tegra2 ;) [07:32:41] <superdump> you mean a tabelt running android [07:32:51] <superdump> tablet* [07:34:47] <superdump> pJok: haha, uberphone [07:35:32] <pJok> superdump, it had to come ;) [07:36:12] <kshishkov> well, with hands-free set phone does not matter much [07:36:39] <kshishkov> without it trying to speak to brick-sized gadget is silly [07:38:29] <pJok> kshishkov, nokia's n-gage? ;) [07:38:39] <kshishkov> it was smaller [07:39:02] <kshishkov> but using it as a phone gave an impression you had an enourmous ear [07:39:16] <pJok> it was smaller, yes, but the way you were supposed to hold it was hillarious [07:40:07] <kshishkov> IIRC it had microphone in the edge [07:40:23] <pJok> http://i16.photobucket.com/albums/b12/al_oasis1/ngagephone.jpg [07:43:52] <kshishkov> that's why my phone is Nokia 1110 [07:44:17] <kshishkov> (and really I hardly need any cellphone at all) [07:49:23] <KotH> kshishkov: i'd have expected that you have an 8110 :) [07:50:35] <superdump> 810? [07:51:23] <kshishkov> KotH: in those times everything cellphone-related was quite expensive. I had 5110 for some time last year though [07:52:36] <KotH> superdump: also known as "the banana" :) [07:52:50] <KotH> kshishkov: ah.. the times! [07:53:11] <superdump> ah :) [07:53:11] <saintd3v> pJok: 8D [07:53:55] <kshishkov> KotH: I said "last year" and "for some time", then returned it to original owner [07:56:31] <saintd3v> I have an 8850 somewhere [07:56:51] <saintd3v> i so wanted a 8110, but silly nokia only released them in .au :( [07:57:33] <saintd3v> so i got the minaturized non-spring loaded counterpart :P [08:00:13] <pJok> 8210 <3 [09:21:26] <mru> superdump: are you in stockholm? [09:21:46] <superdump> yes [09:21:50] <superdump> are you? [09:31:34] <mru> will be tonight [09:37:32] <mru> do you have a .se phone? [09:39:33] <andoma> mru: for how long are you in town? [09:53:33] <CIA-1> ffmpeg: benoit * r22811 /trunk/libavcodec/utils.c: [09:53:33] <CIA-1> ffmpeg: Fix segfault when encoder initialization fails. [09:53:33] <CIA-1> ffmpeg: Patch by Craig Thomasson $(name) dot $(surname) ripcode com [10:09:01] <j-b> hello [10:10:04] <kshishkov> hej [10:10:46] <mru> andoma: only until tomorrow pm [10:12:22] <kshishkov> mru: have you tried translating "kveldsflyet fra Oslo" in Google Translate? [10:14:55] <mru> not yet [10:50:51] <Tjoppen> lo [10:57:00] <kshishkov> vad? [10:57:50] <Tjoppen> *hello [11:00:10] <kshishkov> I understood that archaic English form of "hello" and I'm curious what is going to follow it [11:01:09] <kshishkov> (it actually doubles as general expression of surprise IIRC) [11:03:14] <Tjoppen> benjamin instructed me to join, probably since I seem to be getting write access [11:03:23] <Tjoppen> also, good idea to stick around here as well [11:03:50] <kshishkov> Ã€r du Thomas HÃ€rdin frÃ¥n UmeÃ¥? [11:06:03] <Tjoppen> jajjamän [11:06:11] <Tjoppen> *Tomas [11:07:35] <kshishkov> good, another small step in FFmpeg Swedish section domination [11:08:17] <merbzt1> soon we really need #ffmpeg-devel-swe [11:08:24] <kshishkov> javisst! [11:10:10] <peloverde> One day I'll lead FFmpeg Ohio to new glory.... and maybe I'll even work normal ohio hours [11:10:17] <Tjoppen> :) [11:11:44] * kshishkov has never had any hopes on FFmpeg Ukraine though [11:12:57] <mru> merbzt1: plans for tonight? [11:13:19] <merbzt1> sauuuna [11:13:26] <peloverde> you'd be surprised, you just have to coerce some minions [11:13:40] <merbzt1> at 18 then nothing [11:14:23] <merbzt1> mru: when are you free ? [11:14:27] <kshishkov> merbzt1: I thought that sauna is only for Ãsterland people [11:14:53] <mru> I'm in sthlm all night [11:14:58] <kshishkov> peloverde: that's easy but you won't get anything worth committing to FFmpeg that way [11:15:10] <mru> no specific plans [11:15:58] <merbzt1> kshishkov: well I do come from the norther part of sweden [11:16:18] <merbzt1> mru: we'll eat some dinner then [11:16:25] <kshishkov> merbzt1: yes, even more to the north than Toman [11:16:28] <kshishkov> *Tomas [11:17:03] <merbzt1> actually I've lived in UmeÃ¥ when I was little [11:17:53] <merbzt1> and I have quite alot of relatives there [11:21:17] * kshishkov has never been to the north of GÃ€vle [11:22:15] <Tjoppen> damn snow refuses to go away [11:23:24] <kshishkov> here it's buried under mud [11:34:15] <superdump> mru, merbzt1, andoma : ok, so want to meet for food and drinks tonight? [11:40:15] <merbzt1> yey \o/ [11:40:49] <superdump> :) [11:41:25] <superdump> we can go anywhere [11:41:30] <superdump> stockholm is our oyster [11:41:50] <av500> stockholm is doomed [11:42:06] * superdump chuckles [11:42:12] <superdump> an evil chuckle [11:44:27] <KotH> .o0(drastic my soul) [11:46:31] <kshishkov> you can try some place at Rinkeby or SkÃ€rholmen for change :P [11:49:11] <andoma> superdump: I can't attend, gotta get home and take care of Pontus [11:49:23] <superdump> shame [11:49:28] <andoma> yup :( [11:49:32] <superdump> is he any better today? [11:49:56] <superdump> if we went somewhere quiet, you could bring him with you [11:50:06] <superdump> i'd be happy to sit with him :) [11:50:17] <andoma> nah, i think it's better to keep him at home :) [11:50:22] <superdump> probably [11:50:49] <kshishkov> those set of microbes may come in handy later though... [11:55:11] <mru> ok, so there's 4 of us, my friend michael is coming along too [11:56:16] <superdump> cool [11:56:32] <superdump> was here there when kostya came? [11:58:43] <mru> yes [11:59:31] <kshishkov> was that your "mad" friend? [11:59:59] <mru> all my friends are mad [12:00:04] <superdump> i don't think any of them were particularly mad [12:00:07] <superdump> :) [12:00:16] <superdump> maybe that says something about me then :p [12:00:24] <kshishkov> superdump, that's _your_ point of view [12:00:27] <mru> see, it's all relative [12:00:34] <superdump> :) [12:01:02] <kshishkov> here it's so mad that even local mad people say it's mad [12:01:26] <superdump> that's mad [12:01:47] <kshishkov> exactly [12:02:45] <peloverde> kshishkov, I'm convinced it can't be as distortion as you make it out to be [12:02:48] <kshishkov> it was especially funny at university where people whose signatures I had to collect said either "why do you need that?" or "but you don't need that paper at all!" [12:02:57] <peloverde> I mean [12:03:27] <kshishkov> peloverde: come here and see [12:03:36] <peloverde> UK is withholding the new Dr. Who from the USA and you don't see us complaining ;) [12:04:02] <av500> peloverde: how does "withholding" and "the internet" coexist? [12:04:21] <kshishkov> you forgot to capitalize next to last word (as UK did with Dr.Who series in US ;) [12:05:01] <peloverde> Well they withhold it but we find alternate means [12:05:36] <kshishkov> i.e. torrents and/or YouTube [12:05:56] <av500> can't have ohio without a proper doctor, now can we? [12:06:35] <mru> just lile we have to do to see latestUS shows [12:06:53] <kshishkov> do they have any good shows anyway? [12:06:57] <superdump> uk doesn't have hulu :( [12:07:08] <peloverde> I'm unconvinced about Matt Smith (11th doctor (they are getting dangerously close to 13))... but Karen Gillan is quite the looker [12:07:19] <ohsix> boioioing [12:07:22] <mru> kshishkov: beside the point [12:07:25] <KotH> kshishkov: s/good shows/any show worth watching/ [12:07:30] <kshishkov> peloverde: I've heard expression "gone to Cleveland" [12:07:51] <kshishkov> KotH: that's "good" in my definition [12:08:15] <kshishkov> I'd still prefer British shows filmed before nineties though [12:08:17] <KotH> kshishkov: for me good means that it's not only worth your time, but you should actually have a look [12:08:30] <ohsix> if you're hard up, dr who is on eztv an hour or two after broadcast; sometimes before [12:08:43] <KotH> before bcast? [12:08:47] <KotH> that's fast! [12:08:54] <kshishkov> depends on timezone [12:09:05] <av500> tardis an all, easy to do... [12:09:34] <ohsix> only in event of a leak; but in the US some shows are sent on satellite backhaul quite a bit before their broadcast; and people snag them [12:10:25] <av500> 3vil people [12:10:36] <KotH> raubkopierer! [12:10:45] <av500> terrorists! [12:11:03] <kshishkov> av500: and that says a man from the country of mad scientists! [12:11:18] * av500 thought kshishkov was from the all mad place [12:11:20] <kshishkov> KotH: yes, in German that's even more funny [12:11:21] <peloverde> Yeah, I think that's like 12 strikes, you are hereby banned from the internets 4 times over [12:11:46] <kshishkov> av500: my place is mad but your contry gave the world Nicola Tesla [12:11:56] <av500> :) [12:12:18] <av500> he was not mad, he was just genius :) [12:12:52] <peloverde> I hear he preserved is brain waves as standing waves on the AC grid [12:14:23] <kshishkov> and I've heard there were some mad scientists from Germany too [12:14:39] <kshishkov> (except the ones named Wehrner) [12:14:47] <av500> he was just brown [12:14:54] <KotH> lol [12:15:12] <KotH> av500: i dont think brown has the same conotation here as it has in german :) [12:15:15] <kshishkov> I meant either Heisenberg or Siemens [12:15:34] <av500> Siemens? the banking house? [12:15:56] <kshishkov> no, the guy who got some electricity unit named after him [12:16:09] <kshishkov> he invented tram [12:16:14] <av500> yes, they named a bank after him :) [12:17:11] <kshishkov> and some company still producing trams [12:17:40] <av500> yeah, like Nokia once did rubber boots, Siemens once did electircal stuff.... but it will all be gone soon... [12:18:07] <kshishkov> Sharp did pencils [12:18:23] <kshishkov> but I think that ICE3 is not such a bad tram [12:18:34] <av500> it's ok [12:20:50] <kshishkov> and here everything good moving on rails was made in Czechoslovakia in 60-70s [12:26:09] <peloverde> everything you need to know about cleveland: http://www.youtube.com/watch?v=ysmLA5TqbIY [12:27:27] <kshishkov> what I need to know about it beside the fact it has(had?) federal reserve bank? [12:28:28] <peloverde> It still has [12:28:39] <av500> kshishkov: look closer, it also has a train [12:28:44] <peloverde> We lead the nation in drifters... and there used be industry [12:29:05] <kshishkov> av500: if I'd like to look at trains I'd go to Tomteboda [12:29:09] <superdump> peloverde: i feel enlightened for watching that video [12:29:28] <superdump> kshishkov: gnome something [12:29:56] <ohsix> is that the "we're not detroit" video? [12:30:19] <kshishkov> superdump: not "gnome" exactly and it's the major railroad point (near Karlsberg station) [12:30:36] <peloverde> ohsix, The worst part is that amongst great lakes cities on the US side, Cleveland is only second to Chicago [12:32:00] <kshishkov> and Chicago also has federal reserve bank (and lots of winds) [12:32:30] <pross-au> Dr Detriot [12:32:43] <peloverde> and various background scenes from Ferris Bueller's Day Off [12:33:45] <kshishkov> could be worse - look at Arkham or Innsmouth reputation (and they don't even exist) [12:34:10] <peloverde> or Dunwich [12:34:38] <kshishkov> yep, close [12:35:41] <superdump> http://www.informationweek.com/shared/printableArticle.jhtml;jsessionid=5KN… [12:36:10] <kshishkov> yuck, what a horrible URL (and idiotic suffix for JSP) [12:37:41] <KotH> peloverde: what are drifters in that context? [12:38:05] <mru> any suggestions for restaurants? [12:38:22] <KotH> mru: dont start walking around in search for a restaurant ;) [12:38:33] <av500> http://www.ece.ncsu.edu/arpers/Papers/MMT_IPDPS10.pdf [12:38:44] <peloverde> drifters are vagrants that move from city to city usually by hiding in rail freight cars [12:38:55] <superdump> mru: i dunno, i don't live here yet, ask merbzt1 [12:39:06] <superdump> or andoma [12:39:24] <mru> and I don't live there anymore... [12:40:06] <KotH> av500: is taht paper any good? [12:40:18] <KotH> av500: the names of the authors do not look promising [12:42:19] <kshishkov> is that approach any good? It sounds more like "let'smake crappy software run a bit better instead of urging authors to rewrite it in better way" [12:44:18] <av500> KotH: no idea, it is the pdf behind that long url above [12:44:31] <KotH> av500: ah.. [12:44:41] <KotH> av500: then it's not worth it... infoweek isnt know for good articles [12:47:12] <astrange> the paper sounds like a use of futures [12:47:51] <astrange> which can be beneficial, but larger workloads are better [13:32:12] <BBB> spyfeng: where's your soc proposal? :) [13:40:53] <mru> superdump: merbzt1: what time are you available for dinner? [13:41:07] <superdump> whenever really [13:41:16] <superdump> i'll work 'til 1700 [13:41:49] <superdump> how hungry are you? [13:44:34] <mru> I'll live... [13:46:12] <superdump> merbzt1: how hungry are you? [13:46:29] <superdump> mru: we could just say 1900 or something [13:48:15] <BBB> superdump: what happened to that guy that was going to do the amr-wb decoder soc project? [13:48:44] <superdump> marcelo responded and sent some code and it's being discussed [13:49:13] <mru> superdump: fine by me [13:50:05] <superdump> BBB: nfl who keeps popping in and out of this channel who did the yop stuff was going to work on g 729.1 or something [13:50:21] <superdump> i haven't checked what applications we've had [13:50:31] * superdump has a look [13:51:17] <superdump> oh dear [13:51:22] <superdump> we have 3 applications [13:51:36] <superdump> i think the deadline is the 9th isn't it? [13:52:04] <superdump> yup [13:52:08] <superdump> 9th at 1900 UTC [13:52:17] <BBB> yeah it's very little [13:52:20] <superdump> those 3 applications are from 2 people [13:52:20] <BBB> zhentan is writing his also [13:52:24] <superdump> good [13:52:27] <BBB> that's still only 3 [13:52:29] <BBB> we need more [13:52:33] <superdump> lots more [13:52:36] <superdump> and qualified too [13:52:38] <BBB> advertise people! [13:52:44] <BBB> blog about it [13:52:46] <superdump> otherwise we're going to have a very small presence this year [13:52:50] <BBB> yup [13:53:02] <kshishkov> it's too late [13:53:36] <bilboed-pi> tbh... the number of proposals is also smaller/poorer in other orgs compared to last year. you ain't alone :( [13:53:57] <kshishkov> that's no excuse anyway [13:54:17] <bilboed-pi> just pointing out it seems to be a general trend [13:54:24] <kshishkov> or maybe the word got out that Google pays money only if there are visible results? [13:54:33] <bilboed-pi> kshishkov, ahahahahah :) [13:54:46] <mru> are the applications so far any good? [13:56:46] <superdump> bilboed-pi: how much smaller? [13:57:11] <superdump> we're looking at about 10x smaller atm [13:57:34] <bilboed-pi> 2-5x for gst/wine/gnome [13:58:04] <bilboed-pi> but then again... there's still 3 days.. and students are slackers, so I'm guessing they'll all post their proposals at 18:50 on the 9th [13:58:11] <superdump> hehe [13:58:14] <superdump> we'll see [13:58:25] <BBB> mru: they're ok [13:58:43] <BBB> mru: josh is already qualified, zhentan is also imo (I'm mentoring him) [13:58:50] <BBB> and the third one is nfl [13:58:53] <kshishkov> superdump: maybe they also on't require qualification tasks unlike FFmpeg [14:01:53] <superdump> BBB: who's josh? [14:02:02] <mru> beagleboard has 4 iirc [14:02:16] <BBB> superdump: works on rtsp [14:02:21] <superdump> BBB: zhentan's done work in previous years - if he was qualified then and did well in his projects, he's qualified now [14:02:34] <BBB> superdump: he did the theora/rtp depacketizer as qualification task [14:02:53] <superdump> cool [14:02:53] <BBB> or well, he really actually wrote it, then merged the vorbis one into it and removed the vorbis one, which is quite cool [14:03:11] <superdump> marcelo should qualify too if he manages to do what i've asked [14:03:15] <BBB> nfl wrote a gsm depacketizer, I think, but it's not in svn yet [14:03:31] <superdump> he did the yop stuff as well [14:03:36] <superdump> seems eager and willing [14:03:37] <BBB> yeah, he'll qualify [14:03:38] <BBB> I guess [14:03:39] <merbzt1> and g723.1 also [14:03:45] <BBB> g723.1 is gsm, no? [14:03:47] * mru has piles if things not in svn [14:03:49] <merbzt1> no [14:03:52] <BBB> oh [14:03:52] <BBB> oops [14:03:56] <BBB> I thought it was [14:03:57] <superdump> then mru is not qualified [14:03:59] <superdump> ;) [14:04:07] <merbzt1> we need to form a nice task for him though [14:04:19] <superdump> merbzt1: a nice task for... nfl? [14:04:24] <merbzt1> yes [14:04:25] <BBB> a doable task [14:04:27] <superdump> mmm [14:04:36] <BBB> he seems good, but I don't know if he can write a full decoder in 3 months [14:04:48] <BBB> but anything would be good, we can always finish it later [14:04:50] <BBB> like amrnb [14:04:51] <superdump> well that's doable with reasonable specs [14:05:11] <BBB> would amrwb be complicated? [14:05:16] <superdump> but iirc merbzt1 said the g723.1 specs were... bad [14:05:17] <BBB> it'd be cool, so we can remove opencore dependency [14:05:33] <superdump> amrwb should be ok i think as we have a fair base of code existing [14:05:36] <merbzt1> BBB: for that we would need an encoder [14:05:55] <BBB> I'll write a framework for generic speech encoding [14:06:05] <BBB> then we can reuse that for all encoders with slightly different bitstream ;) [14:06:09] <BBB> they're all the same anyway [14:06:13] <merbzt1> yeah [14:06:16] <superdump> it may need generalising a bit and adding stuff to handle some bits that are different in wb [14:06:19] <superdump> indeed [14:06:33] <superdump> so many, so similar, mostly crap and obfuscated differences [14:06:35] <merbzt1> superdump: 19:30 works better for me [14:06:39] <BBB> but I first want to write a video decoder or so, or learn optimizations [14:06:41] <superdump> sure, that's fine [14:06:43] <superdump> mru: ^ [14:06:50] <mru> ack [14:07:11] <BBB> is ramiro on irc? [14:07:20] <kshishkov> BBB: WVP2 is waiting for you ;) [14:07:31] <BBB> I know, I've debugged the binary quite a bit, I have the functions [14:07:33] <BBB> I need time [14:07:39] <BBB> like, a few weeks to just sit and do it [14:07:45] <kshishkov> don't we all [14:07:48] <BBB> I want to graduate first [14:07:55] <BBB> so it'll have to wait a bit [14:08:13] <superdump> aac psy model, new x86 arch simd, celp encoders are all interesting i suppose [14:08:17] <kshishkov> fine, take your time [14:08:23] <mru> BBB needs to get his priorities sorted [14:08:28] <superdump> if we have a wb encoder, we beat opencore [14:08:33] <av500> as if he will have time to code after graduation.... [14:08:37] <superdump> but having nb and wb decoders to start with is nice [14:10:07] <kshishkov> av500: I had time _during_ graduation and enrolling to postgrad, he just has lousy university where people actually study [14:10:08] <mru> reality still beat both to obsolescence [14:10:58] <kshishkov> no encoders needed then? [14:11:24] <superdump> BBB: we did post on the ML about applying, right? [14:11:31] <superdump> maybe a reminder message would be good [14:12:15] <kshishkov> speex seems to be stable enough to be consumed by FFmpeg too [14:12:16] <av500> superdump: preferably in a blog post bashing ogg, these get a lot of attention these days :) [14:13:16] <kshishkov> "Theora and Ogg sucks! Don't forget to apply to FFmpeg project at this GSoC to find out why" [14:15:42] <KotH> lol [14:16:29] <BBB> we should blog about it [14:16:32] <BBB> maybe people thenr ead it [14:16:40] * BBB copies bilboed-pi 's blogpost and reposts under own name [14:16:55] <bilboed-pi> eh ? :) [14:19:40] <av500> kshishkov: there: http://twitter.com/av500/status/11700466138 [14:20:46] <superdump> http://rob.opendot.cl/index.php/2010/04/06/ffmpeg-google-summer-of-code-201… [14:21:29] <kshishkov> the best way was to pout it to site news along with new improvements [14:21:45] <kshishkov> av500: danke [14:22:09] <av500> kshishkov: you made me make a 2nd tweet in my life, if I get addicted, I blame you! [14:22:56] * kshishkov is proudly has scored 0 tweets so far and not counting [14:24:13] <KotH> av500: it's your own fault to have a twitter account in the first place [14:24:53] * KotH still doesnt get why people use twitter [14:24:55] <av500> KotH: I know [14:25:19] * KotH wonders whether twitter has lsd or something in it to make people addicted [14:25:47] <kshishkov> KotH: pandora box effect [14:26:48] <KotH> kshishkov: what's that? [14:27:52] <kshishkov> KotH: curiosity that makes people do even lethal things [14:28:45] <KotH> like buying android phones? [14:28:52] <kshishkov> yes [14:28:59] <kshishkov> or like tasting oysters [14:29:26] <BBB> superdump: all done [14:29:48] <BBB> superdump: and thanks for the blogpost! [14:30:15] <av500> kshishkov: yummy [14:30:39] <pJok> kshishkov, i thought xiph was top of the line ;) [14:31:10] <kshishkov> pJok: no, it has nothing to do with curiosity [14:34:05] <pJok> kshishkov, then what? ;) [14:34:20] <kshishkov> hype and stupidity [14:34:40] * av500 likes his android phone [14:35:12] <superdump> av500: what do you have? [14:35:19] <av500> superdump: G1 and N1 [14:35:40] <superdump> i've worked with android a little [14:35:55] * BBB loves his iphone [14:35:56] <av500> IÃve worked against it a lot [14:36:00] <superdump> with some of the underlying C++ stuff [14:36:04] <superdump> haha [14:36:08] <BBB> the funnest thing is that I can download tons of ffmpeg applications for the iphone [14:36:12] <BBB> it almost makes me feel useful [14:37:16] <kshishkov> try improving lavf RM demuxer next [14:37:48] <superdump> in terms of general performance and usability, even all this time after its initial release, the iphone is still the one to beat [14:38:26] <superdump> it seems other phone manufacturers would rather churn out N bad phones than make one really good one [14:39:08] <kshishkov> superdump, ever heard of Korean syndrome? [14:39:18] <superdump> no [14:39:54] * av500 has heard that in korea only old people use email [14:40:02] <kshishkov> it means releasing alpha product to market and fix everything in later patches. Guess phone companies from what country suffer most from that? [14:40:07] <BBB> it's true, all these silly android phones suck in one way or another [14:40:11] <BBB> usually multiple ways at once [14:40:19] <BBB> which is sad, because android is really cool [14:40:22] <superdump> right [14:40:46] <BBB> several friends here work at google, and they're a little too droidy [14:40:50] <kshishkov> BBB: something made on Java is cool? [14:40:52] <superdump> and it actually has an application marketplace (which people seem to care about) that doesn't suck quite as hard as ovi [14:41:00] <BBB> always positive about products, not liking criticism, and especially not listening to criticism [14:41:03] <BBB> unfortunate [14:41:05] <av500> so far N1 sucks to me for lack of kbd, but that is me on irc al the time... [14:41:24] <superdump> i must admit, i do love having a full keyboard [14:41:33] <superdump> i hate texting on a number pad [14:41:38] <superdump> i'd rather swap the sim out [14:41:44] <superdump> (uk/se) [14:42:09] * av500 loves the G1 for the kbd, if it only had more mips/mem [14:42:49] * pJok gives av500 a MIPS phone [14:43:00] <av500> and a cart? [14:43:04] <superdump> the n900 is pretty decent hardware [14:43:22] <av500> superdump: sure, nokla is building phones for years [14:43:24] <superdump> ovi sucks sooo much (there's nothing useful on it for the n900 really) [14:43:28] * kshishkov glues Ukrainian SIM card to Gdium and gives it to av500 [14:43:28] <pJok> i want a phone with an i7 [14:43:34] <superdump> it's a bit of a brick though [14:43:38] <superdump> and battery life sucks [14:43:45] <kshishkov> pJok: it'll burn your hands off [14:43:51] <superdump> but hey, it's linux :) [14:44:17] <pJok> kshishkov, who cares... its not like i need my hands for anything ;) [14:44:33] <av500> superdump: I still fail to see where nokia is heading [14:45:02] <kshishkov> pJok: and battery life for ~2 minutes of work? Portable nuclear generator will finish you [14:45:07] <KotH> superdump: the only cool thing about the n900 is its kbd [14:45:18] <av500> KotH: it should run android just fine [14:45:23] <KotH> superdump: everything else is pretty much standard.. and it's too thick [14:45:34] <superdump> av500: apparently nokia execs didn't think much of the n900 when it was released either [14:45:40] <KotH> av500: yeah.. unfortunately, they dont sell it with android [14:45:44] <superdump> KotH: true [14:45:48] <pJok> kshishkov, i was thinking of stealing one of those from a russian lighthouse ;) [14:45:50] <KotH> av500: and maemo is dead... killed by nokia and google [14:45:57] <av500> KotH: is is open, port is easy [14:46:00] <superdump> though some of the software is pretty good :) [14:46:09] <KotH> av500: easy != already done [14:46:14] <av500> true [14:46:16] <av500> gsco! [14:46:25] <KotH> av500: if i buy a phone, i want it to work, out of the box, no fiddling installing and compiling [14:46:27] <superdump> but it's definitely still very much an it could be good if... <list of stuff that needs improving> [14:46:34] <av500> KotH: right [14:46:36] <KotH> av500: if i want a box to play with, i get my self a beagle board [14:46:55] <bilboed-pi> superdump, the advantage is that you don't need to jailbreak or ask Nokia's permission to do wtf you want with the phone [14:46:57] <av500> nah, you finish that gfx card 1st... [14:47:02] <bilboed-pi> superdump, unlike... well... any other smartphone [14:47:22] <superdump> bilboed-pi: yeah, but i don't have the time :D [14:47:50] <bilboed-pi> superdump, sure, but anyone can put a .deb on their website and people can download it on their phone... without going through oshit store [14:47:56] <bilboed-pi> sorry, I guess I meant ovi [14:48:08] <superdump> no no [14:48:11] <superdump> you were right the first time [14:48:14] <bilboed-pi> :) [14:48:28] <av500> bilboed-pi: arent you supposed to type apt-get install on the phone? [14:48:30] <superdump> to be fair, i have got a few free games fro ovi [14:48:34] <superdump> and they're pretty polished [14:48:43] <bilboed-pi> av500, nope, browser detects it fine, and pops up the application manager [14:48:58] <superdump> but they're probably all on the iphone, or clones that are as good or better [14:49:03] <av500> what? there is a GUI? how lame [14:49:17] <superdump> av500: you can use a terminal if you want [14:49:22] <bilboed-pi> av500, oh there's apt alright on it :) [14:49:28] <av500> bilboed-pi: I know [14:49:44] <av500> I spent the day on the #meego channel when it was announced, most fun irc day in my life [14:49:48] <superdump> but there is an annoyingly slow (due to the way it operates) ui as well [14:50:13] <bilboed-pi> superdump, don't get me started on that [14:50:29] <av500> bilboed-pi: and it is not apt any more, it is rpm-foo now :) [14:50:44] <superdump> eat cpu for ten seconds, allow to select a menu, eat cpu some more, blah blah [14:50:49] <superdump> oh, it installed something [14:50:53] <bilboed-pi> av500, gah, fsck, right :( [14:51:03] <superdump> present a popup that prevents input if you have another task focused [14:51:09] <superdump> it's marvellously implemented [14:51:11] <superdump> :) [14:51:16] <av500> superdump: but it is linux!!! [14:51:24] <av500> and think about the children! [14:51:27] <bilboed-pi> it's *actually* linux, unlike android :) [14:51:28] <superdump> lol [14:51:39] <av500> the children! [14:51:58] <merbzt1> superdump/mru: hÃ¶torget around 1930 [14:52:02] <superdump> android is Gloiongulxe [14:52:20] <superdump> merbzt1: righto [14:52:40] <superdump> pick an exit [14:53:07] <merbzt1> away from the city to the left [14:53:27] <merbzt1> we'll locate some restaurant there [14:53:35] <superdump> ok [14:55:54] <superdump> merbzt1: http://maps.google.co.uk/maps?f=q&source=s_q&hl=en&geocode=&q=h%C3%B6torget… here? [14:56:37] <av500> it is next to "PUB" [14:56:54] <av500> damn, this pub has no beer [14:57:42] <merbzt1> ok [14:58:31] <superdump> mru: ^ [14:58:39] <andoma> close to my office [15:37:57] <mru> merbzt1: ack [17:47:49] <astrange> http://svn.rockbox.org/viewvc.cgi/trunk/apps/codecs/ some codecs escaped into here [17:48:03] <astrange> they're gross of course, every one seems to have its own different version of bitstream.h [17:48:55] <kshishkov> yes, RB devs are a bit strange [18:19:22] <_av500_> astrange: some of the players they run on are barely able to achieve realtime [18:19:40] <_av500_> so they tweaked some codecs a lot to get there [18:19:51] <_av500_> i guess beauty was secondary goal [18:20:35] <kshishkov> one of those devs has been explaining all that once [18:20:43] <kshishkov> should be in public logs somewhere [18:30:38] <Compn> Optimization for cook codec. Rework sample output to be able to use highly optim... [18:30:39] <Compn> heh [19:37:24] <troy_s> thresh: You around? [19:38:22] <thresh> yes [19:39:14] <troy_s> thresh: On the setcolorspace front, I was wondering if you know if it is working or not with interlaced formats? I can't seem to get it to trigger properly on interlaced sources. [19:40:12] * thresh has no idea why troy_s is asking him [19:40:35] <troy_s> Sorry... You forwarded me a patch ages ago regarding the 601 luminance scaling. [19:42:28] <thresh> uh, i don't even remember doing that [19:42:44] <thresh> and even if I did, the patch wasnt done by me =) [19:43:08] <troy_s> thresh: Okie. Apologies. Do you have any idea who might have an authoritative answer? [19:43:39] <thresh> nothing to apologize about, really. and no, I don't know. [20:36:11] <BBB> does anyone want to help with the blind qcelp test? [20:36:22] <BBB> (see mailinglist, thread "QCELP postfilter") [20:54:39] <BBB> where is baptiste? [21:18:46] <astrange> why isn't the postfilter test deterministic? [21:20:17] <BBB> the decoder is not bitexact [21:20:42] <Dark_Shikari> but it should be _deterministic_ [21:21:16] <BBB> I might not completely follow [21:21:44] <Dark_Shikari> deterministic == same result every time [21:21:59] <Dark_Shikari> mpeg-2 isn't bit-exact, but it is deterministic [21:22:11] <BBB> it is [21:42:20] <drv> BBB: i listened to your audio test thing, but it's hard to tell, because the source is not that great to begin with [21:45:05] <BBB> I know, I don't have a great source because I lack the encoder... [21:45:52] <drv> ah [21:57:59] <BBB> but still, mail the list about what you find :) [21:58:56] <drv> well, i have been comparing the part at the beginning ("hey listen") [21:59:07] <drv> and i haven't been able to tell a real difference [21:59:30] <BBB> "they all sound crappy" vs. "they all sound fine" makes a big difference [22:01:50] <drv> i think i've convinced myself that 3 is the worst [22:01:54] <drv> i should really set up some ABX thing [22:32:53] <CIA-1> ffmpeg: stefano * r22812 /trunk/libavutil/fifo.h: Clarify doxy for av_fifo_alloc(). [23:33:09] <mariusz_> hi [23:33:48] <mariusz_> should the qualification task for gsoc project be completed before application deadline?

1 0

IRC log for 2010-04-05
by irc＠mansr.com 06 Apr '10

06 Apr '10

[00:41:27] <pentan0l> mru it stat without optimisations, but crashed in the same place but more late [07:06:19] * Terminating due to: TERM [07:06:34] * /join #ffmpeg-devel ... [07:06:36] *** TOPIC: Welcome to the FFmpeg development channel. That is, development of FFmpeg, not using FFmpeg, nor libav*. | Users should redirect their questions to #ffmpeg | FFmpeg 0.5.1 has been released! | this chat is now publicly logged. [07:06:36] *** TOPICINFO: superdump!~rob@unaffiliated/superdump, 1267604523 [07:06:56] <kshishkov> looks like this channel is selectively logged now [07:09:14] <Dark_Shikari> selectively? [07:09:39] <kshishkov> yep, since bot joined this channel only four minutes ago [07:11:02] <_av500_> it was on easter vacation [08:11:02] <superdump> do we have a template for the lgpl header somewhere? [08:12:45] <peloverde> copy a random source file? [08:13:26] <kshishkov> yep, either that or ask Diego [08:51:54] <pentanol> mru here dump this func on i386 http://codepad.org/TZ8xlTMb will try compile gdb to my camera [08:52:39] <mru> x86 dump is useless [09:09:13] <KotH> moin [09:10:58] <kshishkov> shalom [09:18:16] <KotH> .o0(stupidity prevails) [09:24:16] <kshishkov> KotH: that's this world official motto [09:25:11] <KotH> guess so [09:25:49] <KotH> a guy asks to remove a mail he send to mplayer-users because he mentioned zshare which seems to be a client of them. and this client doesnt want to be mentioned on mailinglists [09:26:11] <KotH> i told him politely that it's not worth the effort to remove it because -users is mirrored on a dozen other websites [09:26:30] <KotH> his answer simply was "i dont care about the other websites, just remove it" [09:57:51] <pross-au> Hi [10:00:27] <KotH> haudi! [10:00:43] <pross-au> Giday [10:14:33] <kshishkov> pross-au: mate, check this out - http://shishkov.homeunix.net/WILDCAT.avi [10:19:21] <pross-au> i am on dialup [10:19:29] <pross-au> will check it out tomorrow [10:19:38] <kshishkov> it's 900k [10:19:49] <kshishkov> but no worries [10:32:13] <pross-au> That video is not familar to me kshishkov [10:32:32] <kshishkov> yep, but is seems a bit australian to me [10:33:07] <pross-au> It does [10:33:20] <pross-au> Bouncng kangaroos and what looks to be a tasmanian tiger [10:34:10] <kshishkov> that's one of the logos from Discworld II game [10:34:29] <pross-au> Ah [10:34:34] <pross-au> I never got into those [10:34:37] <kshishkov> converted with quick port of decoder from ScummVM to lavc [10:34:40] <pross-au> Nice [10:34:56] <kshishkov> but here it's content that matters [10:35:20] <pross-au> Yep! [10:35:27] <pross-au> Decoder looks good [10:35:30] * kshishkov wonders if dangling corks are really good against flies [10:35:42] <pross-au> Yes [10:36:44] <pross-au> The flies not do much harm. You can learn to ignore them [10:36:48] <kshishkov> ok, I'll inform you if there's any progress with BIKb decoder [10:37:55] <pross-au> No worries [10:37:59] <kshishkov> :) [10:38:03] <pross-au> Mate [10:38:17] <pross-au> I hacked together a Siren7 decoder today [10:38:23] <kshishkov> good [10:40:12] * kshishkov curses that larrikin who wrote TAK [10:42:53] <pross-au> You're doing well with the aussie slang kshishkov [10:43:13] <pross-au> I reckon you'd ace the citizenship test [10:43:32] <kshishkov> unlikely - I don't drink beer [10:43:52] <pross-au> Ah. But do you eat vegemite? [10:44:19] <kshishkov> never got that stuff here [10:44:39] <pross-au> Do you want some? [10:45:13] <kshishkov> nay [10:46:17] <kshishkov> you seem to grow other good stuff though - like macadamia nuts [10:46:26] <kshishkov> or beans [10:46:47] <superdump> vegemite ftw [10:47:01] <pross-au> superdump knows best!!! [10:47:05] <superdump> :) [10:47:13] <superdump> well, we have a variant called marmite in the uk [10:47:28] <superdump> but i have had vegemite before [10:47:30] <pross-au> We have that here too superdump. At it tastes like shit. [10:47:32] <superdump> it's basically the same [10:47:54] <pross-au> As somebody who eats that stuff daily, there is most certainly a difference [10:48:57] <superdump> :) [10:49:09] <superdump> i only had them with a fair degree of separation [10:49:19] <superdump> what's the difference in your opinion? [10:49:35] <pross-au> vegemite has a sharper taste, more salty [10:49:55] <kshishkov> the only known British food here is porridge [10:50:04] <pross-au> no fish and chips? [10:50:18] <kshishkov> not at all [10:50:35] <thresh> you can buy some at pubs here, really overpriced though [10:51:14] <kshishkov> like everything [10:52:43] <kshishkov> I'd rather eat Swedish food anyway [10:53:06] <pross-au> Wouldnt we all [10:53:28] <kshishkov> looks like Swedes prefer Italian food ;) [11:04:01] <pJok> köttbullar och stuvade makaroner :) [11:05:15] <kshishkov> lax eller strÃ¶mming med potatis :P [11:06:19] <pJok> :) [11:06:30] <pJok> har inte prövat strömning [11:08:24] <kshishkov> du bor inte nÃ€ra ÃstersjÃ¶n [11:08:43] <kshishkov> och strÃ¶mming Ã€r bÃ€ttre an sill [11:08:52] <kshishkov> (tror jag) [11:09:54] <pJok> sill är bra [11:10:22] <kshishkov> javisst [11:10:33] <pJok> och jag bor nära innfarten till östersjön... :P [11:11:51] <kshishkov> men faktiska ÃstersjÃ¶n ligger mellan Sverige och Finland/Ingermanland [11:23:38] <superdump> kshishkov: what have you been using to learn swedish? [11:24:24] <kshishkov> superdump: lexin.nada.kth.se for dictionary and some found textbooks on Swedish gammar [11:24:28] <kshishkov> *grammar [11:24:39] <superdump> ah [11:24:53] <pJok> lexin is nice [11:25:02] <pJok> i use that for words mostly [11:26:36] <pJok> grammar i just learn over time [11:27:07] <pJok> but you're quite good at swedish, kshishkov [11:27:40] <kshishkov> that's because you've never heard me speaking Swedish :P [12:16:13] <elenril> http://lwn.net/Articles/381794/ what, svn is still alive? [12:18:10] <janneg> I've heard svn is still used for the official ffmpeg repo [12:19:02] <kshishkov> yes, that rumour keeps popping here and there [12:19:49] <elenril> probably an evil lie [12:34:31] <KotH> like everyone using utf-8 around here! [13:48:36] <BBB> nfl: please already put your application in the GSoC database, if you haven't already [13:48:39] <BBB> spyfeng: same for you ;) [13:52:15] <BBB> wbs: do you know if our h263 rtp depacketizer outputs rfc2429 or 4629? [13:59:42] <kshishkov> BBB, have you applied for WVP2 already? [14:00:26] <BBB> I'm not applying ;) [14:00:29] <BBB> I'm mentor, not student [14:00:53] <kshishkov> I'm neither :P [14:07:08] <BBB> you should apply, still [14:07:57] <kshishkov> I'm not a student [15:29:59] <nfl_> i'm supposed to pay for a "state of the art 4Mbps" connection. and this is what i get [15:30:08] <nfl_> BBB, you were saying? [15:30:38] <kshishkov> well, that only means your art is not so decent [15:31:20] <nfl_> apparently :( [15:32:03] <nfl_> so what did i miss? [15:32:24] <nfl_> i believe you were saying something concerning me [15:32:57] <kshishkov> no, there was nothing addressed to you after "<@BBB> nfl: please already put your application in the GSoC database, if you haven't already" [15:36:13] <nfl> kshishkov, you mean google's database? [15:36:34] <kshishkov> yes [15:36:47] <kshishkov> socghop.googleapps.com or something IIRC [15:38:02] <andoma> mru: ping? [15:39:10] <BBB> nfl: yes, the google database [15:39:38] <BBB> nfl: google will allocate preliminary slots in a few days, we'd want to give them a good idea of how many we need [15:39:49] <BBB> the more applications we have, the better we can justify asking for more slots [15:40:17] <nfl> does this mean i'm qualified from ffmpeg's side now?! [15:53:37] <mru> andoma: pong [16:05:40] <DonDiego> BBB: can you do me a favor and add 4 characters to libavformat rtpdec.h please? [16:05:49] <BBB> of course [16:05:56] <DonDiego> write 'void' into the empty parentheses at line 143 [16:06:11] <DonDiego> and then commit [16:06:16] <DonDiego> this will fix a warning [16:10:08] <BBB> why don't you do it? ;) [16:12:32] <BBB> you have my permission to commit :-p [16:12:53] <kshishkov> BBB: because all FFmpeg devs are lazy, even non-programmers [16:12:57] <BBB> hm... [16:12:58] <BBB> ok [16:12:59] <BBB> will commit [16:13:00] <BBB> 1 second [16:13:58] <BBB> fixed [16:14:40] <CIA-1> ffmpeg: rbultje * r22803 /trunk/libavformat/rtpdec.h: [16:14:40] <CIA-1> ffmpeg: Add void to a function prototype that takes no arguments. Fixes a potential [16:14:40] <CIA-1> ffmpeg: compiler warning. [16:35:13] <DonDiego> BBB: thx [16:35:34] <BBB> np [16:35:39] <DonDiego> BBB: my point was also to point out that there was an (ignored) compiler warning in code you maintain.. [16:38:12] <BBB> actually, Luca Abeni is responsible for the RTP code [16:38:15] <BBB> but I get your point [16:38:21] <BBB> I didn't actually see the compiler warning [16:48:27] <DonDiego> doesn't ffmpeg have -Wstrict-prototypes in CFLAGS now? [16:57:46] <wbs> BBB: the h263 depacketizer is rfc 4629, the other one is deprecated.. don't know how widely used the old one is today [16:58:35] <BBB> thanks, it was a question on libav-used@ [16:58:39] <wbs> ah [16:58:40] <BBB> *user [16:58:56] <wbs> i'm not subscribed to that one, and just browse it every now and then [17:02:45] <BBB> don't worry, I'll forward relevant questions :) [17:03:14] <wbs> good, good. :-_) [17:13:28] <BBB> wbs: oh, and I was trying to tempt you into cleaning up RTP/AAC, but if you don't want, I'll do it ;) [17:13:47] <wbs> BBB: hah :-) yeah, I've got it on my low priority todo list, too [17:14:05] <BBB> sounds familiar ;) [17:14:08] <wbs> it isn't really broken, it's just horribly structured compared to other formats :-) [17:14:21] <BBB> right [17:14:35] <wbs> but finding that it allocs and leaks one buffer per packet was quite an interesting surprise [17:14:36] <BBB> and you're probably right, it's most likely historical, i.e. this code was there before we added rtpdynamicpayloarhandler [17:14:47] <BBB> if you tested that patch, it's ok for now [17:14:51] <BBB> I think [17:14:54] <BBB> let me look at it [17:15:16] <wbs> tested it with valgrind, seems to work as intended [17:16:33] <BBB> you shouldn't need au_headers_allocated [17:16:51] <BBB> oh right, I see [17:16:55] <BBB> it's for the sequence 4-2-3 [17:17:07] <BBB> so you don't reallocate (unnecessarily) when going from high-to-low-back-to-high [17:17:30] <BBB> I'd make it a copy of nb_au_headers [17:17:34] <BBB> so remove the * sizeof(...) [17:17:39] <BBB> decreases code size [17:18:09] <BBB> also, does it need a zero check? [17:18:19] <BBB> I mean, can au_headers_length be zero? [17:18:26] <BBB> or nb_au_headers [17:18:31] <wbs> don't think so [17:18:45] <BBB> ok, so if you remove the * sizeof(), patch is ok with me [17:18:48] <wbs> ok [17:26:31] <CIA-1> ffmpeg: mstorsjo * r22804 /trunk/libavformat/ (rtpdec.h rtpdec.c): Fix leaks in the AAC RTP depacketizer [17:26:32] <CIA-1> ffmpeg: mstorsjo * r22805 /trunk/libavformat/rtpdec.c: Reindent [17:27:14] <BBB> \o/ [17:27:25] <BBB> I wonder why we never noticed this memleak [17:27:29] <BBB> it's pretty massive [17:28:13] <kshishkov> too much free RAM? [17:28:30] <wbs> luckily, i try to test most of my major (and most minor, too) changes with valgrind [17:28:50] <wbs> and it's annoying to see leaks and/or errors in other parts than the one I'm working on :-) [17:33:47] <j-b> hello peopl [17:36:32] <kshishkov> hej [17:40:45] <BBB> hi j-b [18:03:26] <BBB> wbs: good catch by the way, indeed, the whole rtp_.. file isn't needed in this case, just changing the codec payload in the rtp standard table should be enough to make it work [18:39:36] <relaxed> the ffvhuff license is covered here -> libavcodec/huffyuv.c, correct? [18:46:07] <astrange> yes [18:46:18] <astrange> er [18:46:52] <astrange> if you're distributing ffmpeg then the license of ffmpeg is the important part, try not to copy random parts of code out of it [18:51:14] <elenril> anybody can apply a few patches for me? [18:51:30] <Compn> they been tested? [18:51:43] <Compn> but not me :D [18:52:13] <elenril> =p [18:53:33] <relaxed> astrange: right, there was someone asking about it in #ffmpeg. I told them to come here and ask to be sure. [18:58:18] <BBB> elenril: tell me which and then I can [18:59:34] <elenril> BBB: thread 'add AV_METADATA_DONT_OVERWRITE flag' [19:00:09] * elenril hopes nobody bumped lavf version since then [19:07:03] <dgt84> Does anyone know how easy it would be to get motion vectors for a frame with a single ref frame in a libavfilter filter using existing motion estimation code in libav*? [19:07:31] <dgt84> Or would it be better to try and rewrite some of that in the filter itself? [19:07:38] <Dark_Shikari> well imo we need a motion estimation api [19:07:51] <Dark_Shikari> look at what mplayer's vfs do [19:07:54] <Dark_Shikari> they ENCODE VIDEO [19:07:58] <Dark_Shikari> and steal the MVs [19:08:02] <Dark_Shikari> that's horrible [19:08:16] <dgt84> yeah that was my thought here, but it does seem horrible [19:10:27] <astrange> motion estimation for filters might need a "truemotion" mode instead of rd-optimal [19:11:55] <dgt84> I'm afraid most of this stuff is still above my head - I was hoping for an easy way to get a list of mv's for each block in the frame and then do various things with them in my free time, such as motion compensation [19:14:24] <Dark_Shikari> astrange: that too [19:14:29] <Dark_Shikari> mvtools is something good to look at [19:17:01] <pengvado> Dark_Shikari: you mean other than CODEC_FLAG2_MEMC_ONLY [19:18:44] <Compn> dgt84 : there is lavc debug modes [19:19:07] <Compn> dgt84 : with mplayer they can be displayed using -lavdopts debug=... [19:19:21] <Compn> note that there is little documentation on such things [19:19:37] <Compn> i seem to remember something about motion or macroblocks or so [19:38:49] <Dark_Shikari> pengvado: ahhh, didn't realize it did that [19:43:07] <BBB> elenril: working on it... [19:47:45] <CIA-1> ffmpeg: rbultje * r22806 /trunk/ (doc/APIchanges libavformat/metadata.c libavformat/avformat.h): [19:47:45] <CIA-1> ffmpeg: Add a flag to not overwrite existing tags [19:47:45] <CIA-1> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [19:48:25] <BBB> damn it [19:51:37] <CIA-1> ffmpeg: rbultje * r22807 /trunk/libavformat/avformat.h: [19:51:37] <CIA-1> ffmpeg: Actually add flag (somehow got lost in my previous patchset?), fixes broken [19:51:37] <CIA-1> ffmpeg: r22806. [19:54:16] <CIA-1> ffmpeg: rbultje * r22808 /trunk/ffmpeg.c: [19:54:17] <CIA-1> ffmpeg: Don't overwrite user-supplied metadata with metadata mapped from an input file. [19:54:17] <CIA-1> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [19:55:10] <CIA-1> ffmpeg: rbultje * r22809 /trunk/ffmpeg.c: [19:55:10] <CIA-1> ffmpeg: Simplify writing stream metadata. [19:55:10] <CIA-1> ffmpeg: Patch by Anton Khirnov <wyskas gmail com>. [19:55:20] <elenril> BBB: thanks [19:55:42] <BBB> np [19:56:00] <CIA-1> ffmpeg: rbultje * r22810 /trunk/doc/APIchanges: Add actually correct rXXXXX here. [20:10:35] <mru> btw, anyone in stockholm tomorrow night?

1 0

IRC log for 2010-04-04
by irc＠mansr.com 05 Apr '10

05 Apr '10

[05:09:16] <_av500_> Christos voskres! [05:13:46] <pentanol> sup sup [07:19:01] <CIA-1> ffmpeg: siretart * r22795 /trunk/libavcodec/zmbv.c: [07:19:01] <CIA-1> ffmpeg: Avoid division by zero [07:19:01] <CIA-1> ffmpeg: Based on clang-scan report http://permalink.gmane.org/gmane.comp.video.ffmpeg.devel/107290 [08:01:34] <KotH> salut [10:27:35] <twnqx> koth: vhdl looks so bloated [10:28:29] <peloverde> I always much prefered the verilog [10:32:14] * KotH hates verilog [10:32:40] <KotH> vhdl is very verbose and you've to type quite a bit of info twice, but at least the language is consistent (unlike verilog) [10:32:48] <twnqx> umm [10:32:55] <twnqx> it uses /= where != belongs [10:33:05] <KotH> that's because it's not c [10:33:11] <twnqx> and & as concatenation is a terrible choice in a logic language [10:33:14] <KotH> vhdl's origins are in ada, not c [10:33:21] <KotH> no it's not [10:33:35] <KotH> it's only because you are used to c derived languages [10:33:36] <twnqx> i was wondering for quite some time why he'd AND the constants... [10:34:08] <KotH> forget whatever you know about c, java, etc when you work with vhdl [10:34:19] <KotH> 1) it's ada based (which is a totally different beast than c) [10:34:24] <KotH> 2) it's a dataflow language [10:34:36] <KotH> 3) it's a simulation, not a hardware design language [10:35:49] <twnqx> mh [10:36:33] <twnqx> so why do people use if for hardware design? [10:36:43] <KotH> because they can :) [10:37:23] <KotH> back in the days, when vhdl and verilog were conceived, nobody thought about using them for building hardware, but rather to simulate and verify their designs [10:37:41] <KotH> there werent any synthesis tools, everything was done by hand [10:38:31] <KotH> ie, you'd first simulate your device on various levels (behavioural, rtl, gate, transistor) and verify that your design worked as you expect it to, then draw single transistors and gates in a different tool [10:38:38] <twnqx> indexOut <= (B"0" & T) + (B"0" & Y); <-- he's adding a zero in front of T and Y, so the addition doesn't overflow? [10:39:03] <KotH> direct synthesis out of vhdl/verilog started iirc in early 90s [10:39:40] <KotH> no, he is adding a 0 infront of T and Y because indexOut is a longer signal than T and Y [10:39:49] <twnqx> yeah, i know... so you'd use vhdl as the behavioural, then verilog as the RTL? [10:39:57] * twnqx always wrote both in verilog [10:39:58] <KotH> unlike C, vhdl does not do any type casting [10:40:30] <KotH> actually, it cannot do type casting because the simulator/synthesiser does not know what types your signals represent [10:40:47] <twnqx> i would not want "types" in my circuits anyway [10:41:04] <KotH> no, you do behavioral and rtl in the same language. [10:41:18] * twnqx uses integers in verilog only for test layers [10:41:23] <KotH> it's just that verilog was designed for pretty much the same use as vhdl was a few years earlier [10:42:12] <KotH> twnqx: ok, then think about what would happen if you'd write indexOut <= T + Y; [10:42:49] <twnqx> well, i know that in verilog you'd end up qith 1+1=0 :D [10:43:28] <KotH> .o0(another reason why i hate verilog: it doesnt tell me when i'm doing something wrong) [10:43:39] <twnqx> it's just like C [10:43:45] <KotH> it's worse than c [10:43:47] <twnqx> it does what you tell it, and leasves the thinking to you :P [10:43:53] <KotH> c is 99% consistent [10:43:55] <KotH> verilog isnt [10:43:58] <peloverde> 2'b1 + 2'b1 [10:44:31] <KotH> actually, verilog is what you get if you beat c until you can model hardware with it [10:44:32] <twnqx> rather {1'b0, T} + {1'b0, Y} [10:44:34] <twnqx> :) [10:45:12] <twnqx> KotH: well... yeah [10:45:17] <KotH> vhdl is what you get if you take people who know ada (a lot of goverment people were involved back then) and let them design a new language from scratch [10:45:43] <twnqx> which just happens to suck if you like C's syntax :) [10:46:05] <KotH> twnqx: stop using the same hammer... try another one [10:46:22] <KotH> as i said, forget everything you know about c based languages [10:46:34] <KotH> it'll get just in your way anways (even if you do verilog) [10:47:29] <pentanol> it's a bug or I'm silly? http://codepad.org/wpBPNdZk [10:47:49] <KotH> pentanol: if in doubt, you're silly [10:47:50] <KotH> ;) [10:48:32] <pentanol> heh, but it works on i386 [10:48:45] <pentanol> and won't on arm [11:05:10] <twnqx> ah well. so far is is supposed to work, just have to turn the separate input and output busses into a bidirectional tristate bux using xilinx buffers. i waonder if i can wrap that with verilog :] [12:00:30] <KotH> pentanol: could be that 1) av_next_option returns an invalid value (possibly due to memory corruption), 2) *opt is not correctly alligned 3) your compiler is broken [12:10:03] <mru> pentanol: where does it fail? [12:12:25] <pentanol> mru there newest http://codepad.org/nUH1CWWe [12:21:02] <CIA-1> ffmpeg: michael * r22796 /trunk/libavformat/avformat.h: [12:21:02] <CIA-1> ffmpeg: Allow AVFormatContext.duration to be set if no individual stream duration is known. [12:21:02] <CIA-1> ffmpeg: Demuxers already do this ... [13:26:31] <pentanol> mru no ideas? both arm and i386 in same little-endian [13:51:23] <CIA-1> ffmpeg: stefano * r22797 /trunk/ffmpeg.c: Rename av_encode() to av_transcode(), the new name is more meaningful. [13:51:24] <CIA-1> ffmpeg: stefano * r22798 /trunk/ffmpeg.c: Reindent. [14:22:25] <CIA-1> ffmpeg: stefano * r22799 /trunk/libavformat/file.c: [14:22:25] <CIA-1> ffmpeg: Implement support to the AVSEEK_SIZE operation in file_seek(). [14:22:25] <CIA-1> ffmpeg: Avoid the need to use seeking for getting the file size, use fstat [14:22:25] <CIA-1> ffmpeg: instead, which is significantly faster. [14:22:25] <CIA-1> ffmpeg: See thread: [14:22:25] <CIA-1> ffmpeg: Subject: [FFmpeg-devel] [PATCH] Add support to AVSEEK_SIZE to the file protocol seek callback [14:22:26] <CIA-1> ffmpeg: Date: Fri, 2 Apr 2010 13:13:27 +0200 [14:24:38] <mru> pentanol: compiler? flags? [15:36:48] <CIA-1> ffmpeg: diego * r22800 /trunk/doc/general.texi: [15:36:48] <CIA-1> ffmpeg: Document minimum binutils requirements on Unix-like platforms. [15:36:48] <CIA-1> ffmpeg: based on a patch by Michael Kostylev, michael.kostylev gmail com [20:57:36] <pentanol> mru here http://codepad.org/0XtJGThF also I tries different optimisations, anyway got a segfaul, but for -O2 earliest then -O3 [20:58:21] <twnqx> did you ever run it in a debugger? [21:02:09] <mru> pentanol: what gcc is the arm one? [21:02:33] <mru> please post output of armv5l-gcc -v [21:02:48] <pentanol> gcc version 4.1.2for arm [21:03:12] <pentanol> on my camera I've had strace [21:03:47] <mru> and the -v output? [21:06:33] <pentanol> http://codepad.org/qPw6vs7v -v out [21:09:36] <mru> pentanol: add -v to the command line compiling the .c file and post the output [21:11:32] <pentanol> ok http://codepad.org/y4ZM1Tag [21:15:12] <pentanol> twnqx trace on camera... but there nothing unusual http://codepad.org/IrvGZMsy [21:16:13] <pentanol> afk, will be here [21:21:04] <mru> pentanol: can you post a disassembly of the function where it crashes? [21:21:29] <mru> do you get a core dump? [21:21:43] <mru> if so, gdb info registers will be useful [21:59:58] <CIA-1> ffmpeg: mstorsjo * r22801 /trunk/libavformat/rtsp.c: [21:59:58] <CIA-1> ffmpeg: Zero-initialize the reply struct [21:59:58] <CIA-1> ffmpeg: The status_code field is read in the fail codepath, where it could be [21:59:58] <CIA-1> ffmpeg: read uninitialized earlier. Found by clang. [22:20:32] <CIA-1> ffmpeg: michael * r22802 /trunk/libavformat/utils.c: [22:20:32] <CIA-1> ffmpeg: Fix rounding direction for calculation of AVPacket.duration. [22:20:32] <CIA-1> ffmpeg: Fixes issue1579

1 0

IRC log for 2010-04-03
by irc＠mansr.com 04 Apr '10

04 Apr '10

[09:33:33] <merbanan> http://tranquillity.ath.cx/clang/2010-04-02-1/ [09:35:10] <Dark_Shikari> http://tranquillity.ath.cx/clang/2010-04-02-1/report-86RU2v.html#EndPath [09:35:12] <Dark_Shikari> this is definitely a real bug [09:36:10] <Dark_Shikari> merbanan: how easy would it be to run one of those on latest x264? I assume the reason we're getting a ton of new ffmpeg warnings is that clang has gotten better, so I figure it can't hurt to do another x264 run [09:37:10] <Dark_Shikari> definitely a lot of real bugs in that list, from a quick random sampling. [09:37:46] <Dark_Shikari> I can't understand why it bitches about float loop counters though... [09:38:24] <merbanan> most of them don't trigger, but I agree that the code is wrong and crafted bitstreams would break it sometimes [09:38:36] <merbanan> just a security thing [09:38:58] <Dark_Shikari> why is it a security thing though? [09:39:03] <Dark_Shikari> what's more insecure about floating point loop variables [09:39:12] <Dark_Shikari> http://tranquillity.ath.cx/clang/2010-04-02-1/report-zd6QfP.html#EndPath <---holy fuck how did something this stupid get in the code [09:39:31] <Dark_Shikari> there's even a comment saying it's supposed to work, but it doesn't. [09:39:32] <merbanan> the floats are not exact reason [09:40:37] <Dark_Shikari> http://tranquillity.ath.cx/clang/2010-04-02-1/report-ipOdkV.html#EndPath <---ok this is a clang bug [09:40:40] <merbanan> I think all compilers are ok with it [09:41:22] <merbanan> but it is an API violation [09:41:57] <merbanan> ops :) [09:42:02] <merbanan> 2 of me [09:42:07] <merbanan> that cant be good [09:42:15] <Dark_Shikari> there are WAY too many bugs in there. seriously, post that to the ML or something [09:43:13] <merbanan> ./configure --disable-optimizations --cc=ccc-analyzer ; scan-build -o /var/www/clang -analyze-headers make [09:43:32] <CIA-1> ffmpeg: diego * r22788 /trunk/Changelog: minor spelling fixes [09:43:45] <merbanan> that is what is basically needed for a ffmpeg compile run [09:44:11] <merbanan> you need a working llvm install also [09:44:20] <Dark_Shikari> as I said, post that to the ML [09:44:22] <Dark_Shikari> too many bugs. [09:45:01] <merbanan> will do [09:46:32] <merbanan> some issues are not really bugs but it wouldn't hurt to fix those anyway [09:46:36] <CIA-1> ffmpeg: diego * r22789 /trunk/doc/general.texi: [09:46:36] <CIA-1> ffmpeg: Group Unix-like platforms together in the platform documentation. [09:46:36] <CIA-1> ffmpeg: patch by Michael Kostylev, michael.kostylev gmail com [09:54:31] <DonDiego> oh, who is going to fix those clang error reports? [09:54:45] <Dark_Shikari> I just glanced through them [09:54:51] <DonDiego> and? [09:54:54] <Dark_Shikari> a quick sample of a half dozen suggests a large percentage are actual bugs [09:55:04] <Dark_Shikari> (ignoring the "dead X" ones which are 99% useless always) [09:55:15] <DonDiego> maintainers to the front! [09:55:19] <Dark_Shikari> Pretty much [09:55:28] <Dark_Shikari> a lot of them are just outright _stupid_, some are very good catches [09:55:38] <Dark_Shikari> a "stupid" example was a function that explicitly says that it works fine on null input [09:55:44] <Dark_Shikari> and then proceeds to call a memcpy on a null pointer [09:55:50] <Dark_Shikari> despite the comment saying otherwise [09:57:13] <merbanan> Dark_Shikari: I think the comment was about the format of the string [09:57:29] <Dark_Shikari> er... [09:57:31] <Dark_Shikari> /* NOTE: str == NULL is accepted for an empty string */ [09:57:34] <Dark_Shikari> seems straightforward to me [09:57:57] <Dark_Shikari> ok, so yes it will never crash on a real system [09:57:59] <Dark_Shikari> but it's still a bug [09:58:03] <merbanan> agree [09:58:22] <merbanan> an if (str) should fix that [09:58:27] <Dark_Shikari> yeah [09:58:52] <merbanan> might even compile to the same code [10:11:40] <Dark_Shikari> merbanan: with your command I get a lot of stuff like [10:11:40] <Dark_Shikari> Can't exec "clang-cc": No such file or directory at /usr/bin/ccc-analyzer line 216. [10:12:12] <merbanan> /home/banan/llvm/tools/clang/utils:/home/banan/llvm/Release/bin [10:12:29] <Dark_Shikari> ? [10:12:31] <merbanan> I have that in my path [10:12:55] <merbanan> it is needed [10:14:26] <Kovensky> Dark_Shikari: using clang+llvm svn? [10:14:49] <Dark_Shikari> emerge [10:15:08] <merbanan> use svn [10:15:13] <Dark_Shikari> :effort: [10:15:57] <Kovensky> 2.6 is too old [10:16:07] <Kovensky> and it only produces the 'clang' binary [10:16:21] <Kovensky> it also miscompiles ffmpeg (though svn also did last time I checked) [10:16:30] <Dark_Shikari> 2.6 what [10:16:49] <Dark_Shikari> oh, llvm [10:17:17] <Kovensky> 2.7 will be released on my bday, but for now you need svn =p [10:17:38] <Dark_Shikari> birthday? [10:17:40] <Dark_Shikari> when's that [10:18:30] <Kovensky> the 12th [10:18:39] <_av500_> on the day that 2.7 comes out [11:31:09] <pengvado> are we somehow marking the issues that have been determined to be clang's mistakes? [12:01:14] <Compn> pengvado : you can enter each one into roundup if its valid of course ... [12:01:27] <Compn> err [12:01:29] <Compn> clang mistakes [12:01:32] <Compn> no idea :) [12:01:37] * Compn cant read [12:04:18] <lu_zero> good morning [12:05:43] <lu_zero> j-b_afk: yesterday I had a chat with christian racca and among the rest you went in the discussion, do you still need a server? He would be glad to help in case [12:17:22] <CIA-1> ffmpeg: mstorsjo * r22790 /trunk/libavformat/rtsp.c: Remove a redundant assignment, found by clang [14:15:53] <CIA-1> ffmpeg: stefano * r22791 /trunk/ (17 files in 3 dirs): [14:15:53] <CIA-1> ffmpeg: Replace all remaining occurrences of AVERROR_NOMEM with [14:15:53] <CIA-1> ffmpeg: AVERROR(ENOMEM). [14:15:53] <CIA-1> ffmpeg: AVERROR_NOMEM is deprecated and will be dropped at the next libavutil [14:15:53] <CIA-1> ffmpeg: major bump. [15:05:06] <CIA-1> ffmpeg: vitor * r22792 /trunk/libavcodec/ (binkaudio.c fft-test.c): Make code using 1d-DCT consistent with the API change [15:06:15] <CIA-1> ffmpeg: vitor * r22793 /trunk/libavcodec/fft-test.c: Add help for (I)RDFT test in fft-test [15:24:09] <hyc> clang stuff sounds familiar http://www.symas.com/blog/?p=53 [15:24:32] <hyc> sometimes you don't just need smarter tools, you need smarter programmers... [15:30:37] <CIA-1> ffmpeg: koorogi * r22794 /trunk/libavfilter/avfilter.c: Remove variable whose value was never read. Found by clang. [15:31:40] <Kovensky> koorogi? [15:34:40] <jai> bobby

1 0

IRC log for 2010-04-02
by irc＠mansr.com 03 Apr '10

03 Apr '10

[00:12:05] <ramiro> maybe he's sleep-typing... [01:04:28] <CIA-1> ffmpeg: michael * r22770 /trunk/libavutil/attributes.h: av_builtin_constant_p() [01:08:00] <CIA-1> ffmpeg: michael * r22771 /trunk/libavcodec/ (motion_est_template.c motion_est.c): [01:08:00] <CIA-1> ffmpeg: slice dice, inline and outline cmp() [01:08:00] <CIA-1> ffmpeg: motion_est.o is now less than half its previous size. [01:08:00] <CIA-1> ffmpeg: No speedchange meassureable. [01:10:01] <Dark_Shikari> lol [01:10:09] <Dark_Shikari> It sounds like michael is reading irc [01:12:57] <hyc> I wish someone could explain this new read_seek2 API [01:13:41] <hyc> considering that the patch I posted exactly duplicates the current avformat_seek_file() behavior, and still michael says it results in wrong behavior... [01:15:17] <CIA-1> ffmpeg: michael * r22772 /trunk/libavcodec/motion_est.c: Move comment that belonged to cmp() back to cmp(). [03:47:02] <pengvado> neural network range coder <-- aka paq [03:48:48] <Dark_Shikari> lol, true [03:49:04] <Dark_Shikari> doesn't it have a ton of separate contexts which it mixes via NN or something like that? [03:49:37] <pengvado> yes [04:20:26] <pengvado> ffv2 should be faster than ffvhuff overall, but not due to the entropy coder [04:21:06] <pengvado> even with all my optimizations, the block-based coder is no faster than just coding 2 samples per token. [04:22:10] <pengvado> though 2 samples per token is slightly faster than ffvhuff's emulation of 2 samples per token in a format that really uses only 1 [04:23:37] <pengvado> I could speedup ffvhuff by building vlc tables that aren't coherent huffman trees (i.e. prefix-full), but that's not a priority now [04:23:44] <Dark_Shikari> explain? [04:26:11] <pengvado> ffvhuff decoder uses tables that represent 2 or more independent consecutive vlc coded samples, in order to reduce the number of vlc tokens processed. [04:26:23] <pengvado> but those tables are currently limited to the standard init_vlc api [04:26:51] <pengvado> namely, that if I specify an x bit long code, then when that code is recognized, all x bits will be removed from the bitstream [04:27:57] <Dark_Shikari> so why is ffv2 no faster? [04:28:20] <pengvado> I don't put all possible pairs of samples in the table. that would be too large (and a pair can be up to 64 bits long, while the vlc only supports 32) [04:29:33] <pengvado> so if A,B fits in the chosen table size, but A,C doesn't, I have to choose between including A alone, or including A,B and A,C [04:30:07] <Dark_Shikari> so what about ffv2? [04:30:19] <pengvado> whereas if I could build inconsistent tables, I could include A,B and A,C but make A,C's length equal to just A, so that the next bit6stream read reads C [04:30:33] <pengvado> ffv2 adds a bunch of branches. [04:30:42] <pengvado> fewer vlc tokens in total, but not faster [04:31:02] <Dark_Shikari> didn't we make it so there was only one branch per 2x2? [04:31:05] <Dark_Shikari> using a mega switch? [04:31:31] <pengvado> there's one unpredictable jump table per 2x2 [04:31:48] <Dark_Shikari> and that's bad enough to cut performance back down? [04:32:14] <pengvado> and one unpredictable branch per 2x2 in the CBP (changing it to a jump table per 8x2 didn't help) [04:32:24] <Dark_Shikari> 8x2 sounds expensive, isn't it exponential? [04:32:28] <Dark_Shikari> i.e. 16 possible jumps per 2x2 [04:32:32] <Dark_Shikari> would be 16^4 per 8x2 [04:32:37] <Dark_Shikari> oh, you mean the cpb [04:32:51] <Dark_Shikari> wait, isn't an uncoded 2x2 block rather rare? [04:32:58] <Dark_Shikari> i.e. rare enough that the jump table wouldn't be worth it [04:33:05] <Dark_Shikari> and it's better to have a mostly-well-predicted branch [04:33:17] <pengvado> 8x2 is 4 CBP flags [04:33:24] <Dark_Shikari> yeah, got that [04:33:48] <pengvado> if it were that rare, I wouldn't bother with CBP at all [04:34:17] <Dark_Shikari> how about use a linked-list-like method [04:34:19] <Dark_Shikari> i.e. instead of saying [04:34:27] <Dark_Shikari> if( coded ) { get 2x2 block } [04:34:28] <Dark_Shikari> do [04:34:37] <Dark_Shikari> nextblock = somefunction of cbp [04:34:50] <Dark_Shikari> so if there are 5 uncoded, then 1 coded [04:34:53] <Dark_Shikari> it still only takes one step [04:35:10] <Dark_Shikari> thus, decoding a cbp is O(number of coded blocks) not O(number of blocks in cbp) [04:36:08] <Dark_Shikari> you could even make every cbp have a list of blocks IDs associated with it [04:37:05] <Dark_Shikari> for( int i = 0; cbptable[CBP][i]; i++ ) { nextblock = cbptable[CBP][i] ... } [06:08:33] <astrange> http://oss.slysoft.com/CloneDVDmobile/2009-06-15/patch-2009-06-14.patch [06:09:22] <Dark_Shikari> heh, they added the lpthread that we _still_ haven't fixed [06:10:14] <Dark_Shikari> hmm. they added -pass 3 [06:10:50] <Dark_Shikari> LOL, they fixed libx264 parameter handling [06:10:54] <Dark_Shikari> they just added a string API [06:11:00] <Dark_Shikari> and used x264_param_parse [06:11:03] <Dark_Shikari> I like these guys! [06:38:16] <hyc> http://www.theinquirer.net/inquirer/news/1599506/free-html5-ipad [06:38:26] <hyc> with any luck rtmp will be obsolete soon. [06:38:31] <hyc> oddly enough, thanks to Apple... [06:39:05] <kshishkov> I'd be in the first million to welcome the demise of RTMP [06:39:21] <hyc> lol. you and me both. [06:40:11] <hyc> crappy inefficient protocol [06:40:54] <hyc> with security designed by morons... the internet will work a lot better when it's gone [06:41:23] <Dark_Shikari> what does the ipad have to replace it? [06:41:27] <Dark_Shikari> that horrific segmented mpeg-2 protocol? [06:41:28] <hyc> htm5 [06:41:30] <hyc> html5 [06:41:34] <Dark_Shikari> html5 is not a protocol [06:41:37] <hyc> true [06:41:52] <hyc> but all people care about is getting movies onto their screens [06:41:54] <Dark_Shikari> last I heard, apple still had their own equally custom equally stupid protocol [06:42:03] <Dark_Shikari> which is incompatible with every other browser out there [06:42:12] <Dark_Shikari> and will not work on anything but ipods and iphones [06:42:23] <Dark_Shikari> Making it potentially even more obnoxious than rtmp. [06:42:34] <hyc> hadn't heard about that. but this article is about streaming to iPads using html5 [06:42:41] <Dark_Shikari> that isn't streaming [06:42:43] <Dark_Shikari> that's progressive download [06:42:45] <hyc> and I dunno, could Apple's be worse than silverlight? [06:42:49] <Dark_Shikari> MP4 _cannot_ be streamed [06:43:02] <kshishkov> it can [06:43:07] <hyc> sure it can, you just need to send the moov index first [06:43:13] <Dark_Shikari> hyc: that's progressive download [06:43:14] <Dark_Shikari> not streaming [06:43:21] <hyc> fine [06:43:25] <Dark_Shikari> there is no moov atom in a live source [06:43:29] <hyc> end users don't care about the difference [06:43:33] <Dark_Shikari> um, yes they do [06:43:37] <Dark_Shikari> they care about the difference between a live football game [06:43:41] <Dark_Shikari> and a recording a week later [06:43:50] <hyc> heh, ok, fair point [06:44:02] <hyc> but mp4 isn't being used anyway, it's all h.264 [06:44:08] <Dark_Shikari> um, it's h264 _in mp4_ [06:44:10] <astrange> http://74.125.113.132/search?q=cache:_2owRSuiYjUJ:tools.ietf.org/html/draft… [06:44:36] <Dark_Shikari> astrange: yes, that's apple's MPEG-TS based streaming protocol, right? [06:45:17] <astrange> yeah [06:45:25] <astrange> hm, is that why quicktime x supports ts? [06:46:09] <hyc> mpeg-ts is hardly obscure - you mean Apple is pushing some other streaming tech too? [06:46:31] <Dark_Shikari> hyc: the playlist protocol [06:46:34] <Dark_Shikari> it's not standard TS [06:46:37] <Dark_Shikari> see the above link [06:47:31] <Dark_Shikari> or better said, it's standard TS, but wrapped in a nonstandard protocol that every app will have to add support for. [06:48:17] <hyc> ah well. Apple has always been one to do things the stupid way [06:48:41] <_av500_> beats me why they chose ts over mp4 [06:48:48] <_av500_> and m$ uses mp4 [06:48:52] <_av500_> over asf [06:49:58] <kshishkov> well, they also have Flip4Mac to store asf in mov :) [06:50:24] <_av500_> but that is not from aapl itself [06:50:26] <Dark_Shikari> _av500_: mp4 can't stream [06:51:00] <_av500_> Dark_Shikari: if ts can stream, why do they segment and wrap it in a playlist? [06:51:20] <_av500_> err, wait, ogg can stream!!! :) [06:51:23] <Dark_Shikari> because they are apple and they have to do everything in a nonstandard way [06:51:33] <Dark_Shikari> Now, more reasonably, because it allows easier bitrate adaptation [06:51:41] <_av500_> right [06:51:41] <Dark_Shikari> so the client can tell the server what bitrate it wants for the next chunk [06:51:59] <_av500_> but in that case, the chunk can be mp4 as well [06:52:04] <hyc> everyone should just transfer in ASN.1 DER .... [06:52:08] <_av500_> so, why ts? [06:53:07] <astrange> mp4 has to be faststarted [06:53:18] <astrange> maybe the segmenting is for seeking? [06:53:33] <_av500_> the segmenting is for bitrate adaption [06:53:38] <_av500_> as Dark_Shikari said [06:53:47] <_av500_> but once you have 10s segments [06:54:02] <astrange> the playlist file does not seem to contain alternate bitrate urls [06:54:07] <_av500_> the segment itself can be almost any container [06:54:25] <_av500_> astrange: it does in the M$ case, which uses mp4 :) [06:54:37] <Dark_Shikari> astrange: the server can update the playlist in realtime [06:54:40] <Dark_Shikari> and actually yeah [06:54:43] <Dark_Shikari> microsoft uses mp4 for that [06:54:45] <Dark_Shikari> segmented mp4 [06:54:46] <Dark_Shikari> "smooth streaming" [06:55:34] <_av500_> right, the player constanly polls the playlist file [06:55:47] <kshishkov> WMP also can buffer as good as RealPlayer too [06:55:53] <Dark_Shikari> "as good as realplayer" [06:56:03] <hyc> oh boy, polling the playlist, there's a great idea [06:56:24] <_av500_> hyc: u just need to be on goog gige :) [06:56:33] <hyc> lol [06:56:54] <Dark_Shikari> html5 is such a catastrophe [06:56:56] <hyc> why doesn't the server just send a status msg when the playlist changes [06:56:59] <Dark_Shikari> they design it to do progressive download and not streaming [06:57:03] <Dark_Shikari> and so everyone realizes "shit, we need streaming" [06:57:06] <hyc> oh well [06:57:10] <Dark_Shikari> and they all come up with mutually incompatible shitty ways of doing it [06:57:13] <Dark_Shikari> none of which will be in the spec [06:57:19] <_av500_> ack [06:57:40] <_av500_> so far seeking in html5 is as broken as in flash [06:57:48] <Dark_Shikari> more broken [06:57:50] <Dark_Shikari> flash actually works [06:58:10] <_av500_> yes [06:58:17] <Dark_Shikari> html5 is really pathetic because they noted a ton of shitty things about flash, went off to make something to replace it, and then managed to make a system _even worse_. [06:58:27] <_av500_> but i guess u can always put flash://url.swf in the video tag [06:58:32] <Dark_Shikari> LOL [06:59:03] <Dark_Shikari> that is bad and you are bad [06:59:15] <_av500_> i know [06:59:17] <hyc> http is probably the wrong transport for streaming anyway [06:59:29] <Dark_Shikari> http works fine with flash [06:59:38] <Dark_Shikari> it's rather barebones, without the flexibility of rtmp [06:59:40] <Dark_Shikari> but it _works_ [06:59:42] <hyc> yes but as you say, that's just a progressive download [06:59:44] <Dark_Shikari> no [06:59:47] <Dark_Shikari> you can use it for actual streaming [07:00:04] <Dark_Shikari> that's how you use ffserver to stream to flash [07:00:35] <kshishkov> well, for me flash plugin reliably crashes firefox [07:00:43] <Dark_Shikari> kshishkov: for me, firefox reliably crashes firefox [07:00:57] <hyc> lol. I run my own builds of seamonkey [07:01:05] <hyc> but yeah, it still crashes too often [07:01:12] <kshishkov> dillo segfaults sometimes too [07:01:21] <kshishkov> elinks works the best [07:01:36] <_av500_> hyc: seamonkey ftw! [07:01:50] <hyc> ;) [07:02:19] <hyc> I could never get javascript working in elinks [07:02:33] <hyc> otherwise I would have stuck with that [07:02:55] <astrange> i wanted to port links to webkit [07:03:08] <astrange> i guess that would make it crash more often, though [07:03:14] <hyc> lol [07:04:09] <hyc> fortunately I don't actually need to run anything with flash any more [07:04:21] <Dark_Shikari> I don't need to, but it's sure damn nice. [07:04:25] <hyc> get_flash_videos + rtmpdump gets anything I want to see [07:04:34] <hyc> everything else, I didn't want to see... [07:04:50] * Dark_Shikari likes flash animations though [07:04:58] <kshishkov> happy tree friends? [07:05:46] <Dark_Shikari> whatever 東方ＰＶs are out this week [07:06:23] <Dark_Shikari> Flash actually does a pretty good job at what it was originally designed to do, you know =p [07:06:42] <kshishkov> replacing SVN Animation? [07:06:46] <kshishkov> *SVG [07:06:52] <Dark_Shikari> SVG didn't even exist at the time [07:06:59] <Dark_Shikari> and I've never even _seen_ an SVG animation [07:07:16] <Dark_Shikari> I also doubt they're even as fast as flash, given that merely _static_ SVGs lag out my firefox [07:07:24] <hyc> heh [07:07:25] <Dark_Shikari> (thanks wikipedia) [07:07:43] <Dark_Shikari> now, what I really hate is when people post Flash videos as video files instead of SWFs [07:07:44] <hyc> yeah I have an emblem I saved as an SVG, it looks like an animation when it renders, slowly... [07:07:50] <Dark_Shikari> they're larger, lower quality, not scalable [07:07:59] <Dark_Shikari> just plain stupid [07:08:08] <Dark_Shikari> (er, flash _animations_) [07:10:40] <kshishkov> Dark_Shikari: todays XKCD seems to be strangely related to your words [07:10:54] <Dark_Shikari> meh, xkcd. [07:13:14] <kshishkov> bbl [09:51:06] <ods15> hmm, from "ps aux" while compiling binutils... make "DESTDIR=" "RPATH_ENVVAR=cant_touch_this_nah_nah_nah" [09:51:37] <ods15> ah, it's a gentoo thing [09:52:01] <kshishkov> hello, colleague [09:52:50] <ods15> heh [09:53:12] <kshishkov> guess who has very lousy audio encoder in FFmpeg that everybody kicks? [09:59:21] <Dark_Shikari> vorbis or aac? [10:00:23] <kshishkov> AND! [10:03:18] <bilboed> that bad ? [10:03:59] <Dark_Shikari> bilboed: http://saintdevelopment.com/files/tests.zip [10:04:02] * kshishkov refrains from comparing it to gstreamer [10:04:37] <bilboed> kshishkov, you're comparing apples and pears :) [10:05:05] <bilboed> kshishkov, btw, you're an organist (in ref to blogpost) ? [10:05:46] <kshishkov> bilboed: on the contrary - I mentioned I don't play any instruments [10:06:47] * bilboed facepalms [10:06:53] <bilboed> yes, I should read entirety of blogposts [10:07:42] <ohsix> or no blogs :] [10:08:31] <bilboed> kshishkov, anyway, yes, that piece is a bitch to play... but JSB came up with harder pieces to play than that [10:08:49] <kshishkov> bilboed: BTW it's mentioned in the same post [10:08:59] <kshishkov> bilboed: for example? [10:09:34] <bilboed> one sec, grabbing my scores [10:11:49] <ods15> kshishkov, we have an aac encoder?... [10:11:57] * ods15 is so out of date [10:12:16] <kshishkov> ods15: yes, on par with your vorbis encoder currently [10:12:59] <bilboed> ohsix, 3rd movement (vivace) of the Trio Sonata #3 in D minor (527) [10:13:01] <ods15> obviously not a very good par.. [10:13:02] <bilboed> gah [10:13:09] <bilboed> s/ohsix/kshikov/ [10:13:32] <ods15> i always said psychoacoustics is not my thing, i was wondering if anyone improved my vorbis encoder in the last few years, saw that noone did... [10:14:13] <kshishkov> bilboed: well, that explains why I haven't heard triosonatas for organ performed live [10:14:25] <ods15> kshishkov, what are these files? test1.wav etc. [10:14:32] <Dark_Shikari> ods15: from my link? [10:14:36] <ods15> hmm, no, Dark_Shikari [10:14:36] <ods15> yes [10:14:39] <Dark_Shikari> one of them is FF-AAC [10:14:41] <Dark_Shikari> at 160kbps [10:14:44] <Dark_Shikari> another is FAAC at 160kbps [10:14:46] <Dark_Shikari> another is the source [10:14:49] <Dark_Shikari> see if you can figure out which is which [10:14:53] <ods15> which is which... am i suppose to tell? [10:14:57] <Dark_Shikari> You will know. [10:14:58] <Dark_Shikari> you WILL know. [10:15:16] <Dark_Shikari> also, ods15, it's really worse than that. ff-vorbis is not merely not psy-optimized, it's utterly atrocious buggy garbage. But don't worry! Because you're no longer alone! [10:15:55] <ods15> i can definitaly tell that 2 of them are different from the other, but my hearing is so bad i can't confidentaly say which one is BETTER than the other [10:15:56] <bilboed> kshishkov, and if you don't know it (and I'll end this parenthis here) ... Vierne's 6th symphony... *that* is the hardest piece I know of. [10:16:17] <Dark_Shikari> ods15: ok, your hearing can't possibly be that bad [10:16:21] <Dark_Shikari> 2 are basically identical, one is utterly awful [10:16:36] <ods15> wait, ok... [10:16:54] <ods15> yes i see now [10:17:08] <ods15> dude, i could have sworn that test1 was the original until you said that [10:17:13] <Dark_Shikari> go to 0:18 in test1 [10:17:18] <Dark_Shikari> and listen until the end [10:17:19] <kshishkov> bilboed: for my ear Passacaglia by Max Reger is technically more difficult to perform than JSB but it does not sound like music to me [10:17:26] <Dark_Shikari> it will HURT YOUR EARS [10:17:43] <Dark_Shikari> there are entire chunks of the frequency spectrum that just disappear there [10:17:43] <ods15> ahh, yeah, that's bad [10:17:51] <Dark_Shikari> remember, this is 160kbps! [10:17:57] <ods15> heh [10:18:07] <Dark_Shikari> as I said, your vorbis encoder now has competition [10:18:19] <bilboed> kshishkov, speaking of which... organ recordings are a very good test for audio encoders :) [10:18:25] <ods15> competition for being worse? which? the aac encoder? [10:18:30] <Dark_Shikari> ods15: yes [10:18:40] <Dark_Shikari> Actually I should totally test it. [10:19:03] <ods15> something you said didn't make sense [10:19:07] <ods15> 13:14:39 <@Dark_Shikari> one of them is FF-AAC [10:19:07] <ods15> 13:14:41 <@Dark_Shikari> at 160kbps [10:19:07] <ods15> 13:14:44 <@Dark_Shikari> another is FAAC at 160kbps [10:19:07] <ods15> 13:14:46 <@Dark_Shikari> another is the source [10:19:11] <ods15> dont you mean vorbis? [10:19:19] <Dark_Shikari> no. yours is not in that test. [10:19:30] <Dark_Shikari> I was just saying that ff-aac is so bad that it's competitive with ff-vorbis. [10:19:30] <kshishkov> bilboed: depends on music and performer. Some don't even suspect that organs have pedal and more than one manual not mentioning registers [10:19:37] <ods15> i hadn't realized that ffvorbis is buggy as well as being bad... [10:19:46] <Dark_Shikari> ods15: well, imo anything that can sound bad at 300kbps is buggy [10:19:47] <ods15> whats faac? [10:19:53] <Dark_Shikari> because even optimizing for psnr won't be that bad [10:19:56] <Dark_Shikari> faac is test_3 [10:19:59] <Dark_Shikari> source is test_2 [10:20:01] <Dark_Shikari> ff-aac is test_1 [10:20:02] <bilboed> kshishkov, obviously :) [10:20:30] <ods15> Dark_Shikari, incomplete might be a better term... [10:20:39] <Dark_Shikari> also, ff-vorbis seems to ignore my bitrate [10:20:43] <peloverde> Why are we discussing ffaacenc again,it's been less than a week since last time we brought up what was wrong with it? [10:20:43] <ods15> there's just no effort for compression at all [10:20:43] <Dark_Shikari> I gave it 160kbps, it encodes to 84 [10:20:52] <Dark_Shikari> peloverde: it is worse than ff-vorbis [10:20:55] <ods15> afaik it only uses -aq or something [10:20:56] <Dark_Shikari> I just tested it [10:21:00] <Dark_Shikari> ffvorbis sounds better at 80kbps [10:21:08] <Dark_Shikari> than ff-aac at 160 [10:21:09] <ods15> hey! ;D [10:21:15] <kshishkov> bilboed: well, from three constant organists here only one can play Passacaglia. [10:21:18] <ods15> not a great triumpth [10:21:39] <Dark_Shikari> oh wow, at 160kbps ff-vorbis sounds decent [10:21:47] <ods15> Dark_Shikari, you used -aq? [10:21:50] <Dark_Shikari> yes [10:21:54] <Dark_Shikari> ok, ods15, you win [10:21:58] <Dark_Shikari> ffvorbis is actually usable [10:21:58] <ods15> yey! [10:21:59] <peloverde> It's not a good comparison unless you override the filter with something sane [10:22:18] <Dark_Shikari> it's transparent to my ears at 160kbps. [10:22:46] <ods15> Dark_Shikari, there's a really stupid trial-and-error formula i used there for possibly better compression, but i'm too clueless to know if it really works or is the right approach [10:23:02] <ods15> i'm actually pretty sure it isn't [10:23:04] <Dark_Shikari> er, not transparent I guess, "almost transparent" [10:23:14] <kshishkov> peloverde: I think that filter is not that bad. Maybe cutoff ratio calculation gone bad? [10:23:15] <Dark_Shikari> like 96kbps mp3 I guess. [10:23:24] <ods15> got to the ending? [10:23:31] <peloverde> kshishkov, yes I mean the cutoff ratio [10:23:33] <Dark_Shikari> ? [10:24:07] <ods15> you corrected yourself on "transparent", i guess because you just got to the ending of that sample... [10:24:11] <kshishkov> peloverde: maybe debug print it, lame does so too [10:24:18] <ods15> vorbis_enc.c:685 - average *= pow(tot_average / average, 0.5) * pow(1.25, position/200.); // MAGIC! [10:24:25] <Dark_Shikari> Yeah [10:24:44] <ods15> hmm, exponential multiplied by sqrt... humbug [10:24:57] <Dark_Shikari> peloverde: really, rather than bitch at people who complain about it [10:25:00] <Dark_Shikari> why not just fix it if it's so easy [10:25:15] <Dark_Shikari> I think you are missing how #ffmpeg-devel works [10:25:19] <Dark_Shikari> this is troll-driven development [10:25:23] <Dark_Shikari> we troll people until they fix problems [10:25:26] <ods15> haha [10:25:30] <peloverde> I would rather have it be clear that it is a toy than have it be just mostly bad [10:25:34] <Dark_Shikari> It worked with michael and ffh264 [10:25:47] <Dark_Shikari> now ffh264 is much faster and better. [10:25:52] <Dark_Shikari> so we must troll everyone else too. [10:25:54] <ods15> is h264 decent? is it faster than coreavc? [10:26:01] <Dark_Shikari> no way, it was a full 50% slower prior [10:26:06] <Dark_Shikari> (where "100% slower" means "half speed") [10:26:13] <ods15> right [10:26:14] <Dark_Shikari> or, better said, coreavc was 50% faster. [10:26:21] <Dark_Shikari> I think the gain since then has been 20%, maybe a bit more. [10:26:26] <ods15> no, coreavc was 33% faster?... [10:26:28] <Dark_Shikari> so we've covered a bit under half the ground. [10:26:29] <peloverde> trolling me before PS is done is only just distracting me, I'm not giving either enough attention to make a dent anymore I spend most of my time modeswitching [10:26:46] <Dark_Shikari> ods15: 50% faster with identical asm [10:26:48] <Dark_Shikari> on arm [10:27:08] <ods15> Dark_Shikari, how recent was this? i'm wondering if the videos i'm barely playing now will play with updated mplayer? [10:28:03] <ods15> Dark_Shikari, how does ffvorbis sound at 80? [10:28:13] <Dark_Shikari> what is "80%"? [10:28:22] <Dark_Shikari> how recent was what [10:28:41] <ods15> err [10:28:49] <ods15> recent - michael h264 speedups [10:28:57] <ods15> 80 - 80kbps [10:28:57] <ods15> 13:21:00 <@Dark_Shikari> ffvorbis sounds better at 80kbps [10:29:09] <Dark_Shikari> it sounds pretty awful at 80, unlistenable [10:29:12] <Dark_Shikari> but slightly better than aac I think [10:29:24] <Dark_Shikari> michael h264 speedups? past 2-3 months or so. [10:29:25] <Dark_Shikari> since january. [10:29:33] <Dark_Shikari> they're the reason vlc released 1.0.5. [10:29:50] <ods15> ah [10:30:37] <ods15> MPlayer SVN-r30131-4.3.4 (C) 2000-2009 MPlayer Team [10:30:44] <ods15> looks like i haven't been using it then [10:35:23] <peloverde> Really, according to vlc credits they haven't updated ffmpeg in three years [10:38:32] <Dark_Shikari> no, they update with every release [10:38:33] <kshishkov> hmm, that's when RV3/4 decoder started working.... [10:38:55] <peloverde> "FFmpeg - Copyright (c) 2000-2007 Fabrice Bellard, et al." [10:39:18] <peloverde> that is from 1.0.5 [10:39:31] <Dark_Shikari> that's called LAZY [10:39:38] <Dark_Shikari> aka "somebody didn't update the credits message" [10:45:27] <hyc> I recall whining about H264 on ARM a few months back too [10:45:49] <hyc> er, August-September, mor ethan a few months ago [10:46:03] <Dark_Shikari> well ffmpeg has pretty much the best arm asm out there [10:46:06] <Dark_Shikari> if by arm you mean neon [10:46:10] <Dark_Shikari> and ARM7 [10:46:12] <hyc> the NEON stuff was a big boost [10:46:14] <Dark_Shikari> er, ARMv7 [10:46:27] <hyc> yeah. OMAP3, AI TouchBook [11:00:03] <thresh> http://www.rfc-editor.org/rfc/rfc5841.txt btw [11:03:16] <hyc> cute [11:05:20] <thresh> hyc: oh, while you're here. any plans on making librtmp shared library on linux? [11:07:20] <CIA-1> ffmpeg: michael * r22773 /trunk/libavcodec/motion_est.c: [11:07:20] <CIA-1> ffmpeg: Reduce the size of the bidir refine hashtable from 4096 to 256 and [11:07:20] <CIA-1> ffmpeg: change the hash function to something more sane and simple. [11:07:20] <CIA-1> ffmpeg: about 1/3 faster, no meassureable change in psnr or size and i gues [11:07:20] <CIA-1> ffmpeg: its even same md5 with my test file but i forgot testing that. [11:07:27] <hyc> thresh: hadn't made any plans, no [11:07:52] <kshishkov> then make some to please him [11:08:08] <hyc> all it needs is -fPIC in the CFLAGS [11:08:09] <kshishkov> or a truckload of C4 shipped to Adobe [11:08:46] <thresh> hyc: well, it is not only a matter of invoking ld in proper way but ensuring proper sonames, changing those when some API changes etc [11:09:03] <thresh> not sure this should be done in a separate patchset [11:09:08] <hyc> heh. sounds like you've made some plans. feel free to submit a patch. [11:09:21] <thresh> well, i'm just looking from a packager POV [11:09:22] <thresh> okay [11:09:58] <hyc> I generally only concern myself with releasing code that compiles. installing/packaging is not my concern [11:11:21] <hyc> and I certainly don't want to be responsible for configre/Make rules to do packaging for all the Linux distros plus all the BSD variants plus Windows from 7 back to 95 or whatnot [11:11:54] <hyc> that's a distro's job... [11:12:09] <Dark_Shikari> also, look at the effectiveness of troll driven development [11:12:17] <Dark_Shikari> seriously, I just bitched about motion_est being bloated [11:12:20] <Dark_Shikari> amd bam, michael goes and improves it [11:12:28] <thresh> hyc: if you say so [11:12:31] <Dark_Shikari> it's magic! ;) [11:13:06] <hyc> Dark_Shikari: phooey. quit distracting him until he finishes reviewing my rtmp/flv seek patches [11:13:12] <hyc> :P [11:13:19] <Dark_Shikari> lol [11:14:59] <iive> Dark_Shikari: yeh, it's much simpler to make michael do it, instead of you :P [11:15:12] <Dark_Shikari> iive: well, he knows his code much better than I do [11:15:19] <Dark_Shikari> and he can commit unilaterally in 2 minutes [11:15:28] <Dark_Shikari> instead of posting patches that take 3 days to review [11:16:26] <hyc> my flv duration patch seemed pretty non-controversial [11:16:32] <peloverde> Review latency can be a killer, especially when stuff gets lost [11:16:55] <Dark_Shikari> yeah :/ [11:17:00] <Dark_Shikari> the LATENCY is the real problem, not throughput [11:17:14] <peloverde> And that's not just michael (for when he read this) [11:17:22] <hyc> On OpenLDAP all committers just commit. We review after the fact. [11:17:44] <hyc> Or complain when make test breaks... [11:18:03] <kshishkov> peloverde: but you don't do RT*P code, why complain about latency? [11:18:36] <kshishkov> it's in nature of OpenLDAP :) [11:18:51] <hyc> it's frequently easier to make sense of the actual code, than the diffs [11:19:16] <Dark_Shikari> hyc: lol [11:19:16] <peloverde> I've at one time or another touched some big chunks of FFmpeg that I don't maintain [11:19:25] <Dark_Shikari> I like the x264 approach [11:19:28] <Dark_Shikari> commit once every 2 weeks or so [11:19:32] <peloverde> As well as some stuff that I'm defacto maintainer of [11:19:35] <Dark_Shikari> yay for git [11:19:44] <peloverde> I wish we had git :( [11:19:47] <Dark_Shikari> you do. [11:20:04] <peloverde> As I've said before the current git-svn setup is lacking [11:20:24] <peloverde> specifically the lack of dcommit [11:20:49] <peloverde> and swscale living in it's own swscale hole but being mandatory [11:21:10] <J_Darnley> Speaking of patch latency: I would like to hint at my patch for VorbisComment writing in ogg-vorbis files [11:21:13] <Dark_Shikari> dcommit? [11:21:46] <peloverde> Nothing is more fun that trying to track down an audio regression and having the post bisect make fail due to a VIDEO scaler being out of sync [11:21:59] <Dark_Shikari> oh god swscale [11:22:06] <peloverde> http://www.kernel.org/pub/software/scm/git/docs/git-svn.html [11:22:22] <hyc> what's up with swscale anyway, why is it off on its own? [11:22:28] <Dark_Shikari> for "historical reasons" [11:22:31] <peloverde> It used to be part of mplayer [11:22:34] <Dark_Shikari> aka bikeshed [11:22:36] <peloverde> but didn't postproc? [11:22:58] <hyc> hard to imagine what's worse though. could be network-manager, where the bug reports get hundreds of "this is broken for me too" comments but they still refuse to fix [11:23:22] <peloverde> In general living by itself slows me down one time unit and complaining about it slows me down two [11:23:55] <Dark_Shikari> I would argue that the "commit cycle" and the "test cycle" are the two most important things in development speed [11:24:00] <hyc> I vaguely recall a time before libpostproc was around... [11:24:06] <Dark_Shikari> 1) being "how fast can I get something committed so I can go work on something else? [11:24:18] <Dark_Shikari> 2) being "how fast can I go from a code modification to tests on that modification being done?" [11:24:40] <hyc> right, but 2 usually doesn't require waiting on someone else [11:25:21] <Dark_Shikari> but it's still important [11:25:25] <Dark_Shikari> it's why long build cycles are DEADLY [11:27:03] <peloverde> The ongoing split up of dsputil has been helpful [11:27:39] <peloverde> I've definitely not bothered to do things because the result will be changing dsputil.h and therefore clobbering all of avcodec [11:28:00] <kshishkov> that's why MN builds without dependencies [11:28:07] <Dark_Shikari> >_> [11:28:12] <Dark_Shikari> and because he has a pentium 2 [11:28:19] <hyc> yeesh [11:28:22] <peloverde> That is not a real solution to the problem [11:28:36] <hyc> long build times: 16 core server, make -j, no problem. [11:28:52] * kshishkov remembers half an hour builds on his PII-266 [11:29:21] <peloverde> I remember long builds on my P1-200 [11:29:30] <Dark_Shikari> hyc: it's hard to get build times fast enough with ffmpeg to be nice though [11:29:33] <Dark_Shikari> if only because of the slow link step [11:29:48] <peloverde> Dark_Shikari, gold plus make -j4 [11:29:53] <Dark_Shikari> gold? [11:30:09] <kshishkov> gnu-off ld ? [11:30:17] <Dark_Shikari> ? [11:30:17] <peloverde> The new GNU ELF LD [11:30:20] <Dark_Shikari> ah [11:30:23] <Dark_Shikari> it's not slow as fuck? [11:30:33] <peloverde> It's much faster than ld.bfd [11:31:38] <peloverde> Though it is written in c++ which makes bootstrapping so much more fun [11:31:49] <kshishkov> peloverde: it's better here - overall slow system + overall slow developer [11:31:58] <hyc> http://www.airs.com/blog/archives/38 [11:32:12] <hyc> but he's wrong, a linker's job is not uninteresting [11:32:31] <hyc> it's the only practical place to implement global optimization [11:32:39] <peloverde> Also it uses less RAM when I only had 2G I couldn't link chrom(e|ium) with ld.bfd but could with gold [11:32:47] <hyc> I hacked global optimization into M68K gnu-ld ages ago... [11:33:15] <Dark_Shikari> global optimization is pretty useless in my experience [11:33:19] <Dark_Shikari> gcc is too dumb to do anything with it [11:33:29] <Dark_Shikari> hell, gcc can't even remove unused arrays from a _single C file_ [11:33:34] <Dark_Shikari> let alone do some sort of global cleanup [11:33:40] <hyc> well, that's the point. you can't do it in gcc, you have to do it in the linker. [11:33:53] <CIA-1> ffmpeg: mstorsjo * r22774 /trunk/libavformat/rtpdec_xiph.c: [11:33:53] <CIA-1> ffmpeg: Change a case of CODEC_TYPE_ into AVMEDIA_TYPE_ [11:33:53] <CIA-1> ffmpeg: This was accidentally overwritten in the recent merge of the theora/vorbis codepaths [11:33:56] <Dark_Shikari> you need communication between the compiler and linker for global optimization [11:34:10] <Dark_Shikari> and if the compiler can't even globally optimize a _single C file_ [11:34:16] <Dark_Shikari> surely they have no chance of doing all your C files [11:34:52] <kshishkov> ld is not linker, it's link _editor_, hence replace it with Emacs [11:34:55] <hyc> I did pretty basic stuff - garbage collection, jump optimization, and global register allocation [11:35:16] <hyc> all of that can be done blind, no C compiler cooperation needed [11:35:35] <Dark_Shikari> global register allocation requires re-generating code for every function [11:35:39] <Dark_Shikari> at least if you want good results [11:36:10] <hyc> it was no big deal on M68K [11:36:13] <Dark_Shikari> lol, true [11:36:22] <hyc> movem.l <reglist> [11:37:17] <hyc> really most of the hoops we have to jump thru today are due to crap x86 ISA [11:37:30] <hyc> on any sane ISA you can do a lot of cool stuff without much effort [11:38:14] <Dark_Shikari> global optimization should really be done in the compiler though [11:38:17] <Dark_Shikari> it affects things like inlining decisions [11:38:19] <peloverde> x86 has sane parts, like sse [11:38:22] <Dark_Shikari> which you can't really do in a linker [11:38:59] <hyc> but that kind of breaks the programming model, compile one source file and move on to the next [11:39:07] <Dark_Shikari> who says you have to do that? [11:39:09] <hyc> you have to accumulate a bunch of state instead [11:39:24] <Dark_Shikari> "how the compiler works" and "how the programmer writes" don't have to be the same [11:39:52] <hyc> I suppose [11:41:10] <hyc> Anyway, certainly linkers can waste a lot of time. I liked the AIX linker, it was incremental and reasonably fast after several revisions [11:41:32] <hyc> and their object file format didn't need to distinguish between .o, .a, or exe [11:42:02] <kshishkov> arm from arse? [11:42:10] <hyc> You could compile a library with however many functions in a single source file and .o, the linker would only extract what it needed. [11:42:47] <peloverde> As long as they aren't using Mach-O, mach-o is one of those dumb reasons why I will never consider OS X [11:42:51] <hyc> in contrast you look at the source for e.g. glibc and see thousands of 30 line source files... [11:43:15] <hyc> just because dumb unix linkers always pull in entire .o files [11:43:33] <peloverde> bullshit, the GNU license header is longer than 30 lines ;) [11:43:37] <Dark_Shikari> lol [11:43:38] <hyc> lol [11:44:45] <hyc> but being able to relink an exe against itself was cool. ld -o exe exe patchedfile.o [11:44:46] <kshishkov> time to switch to WTFPL2? [11:46:12] <hyc> Hm, I remember watching a talk at Usenix about Mach-o but I didn't pay enough attention to remember any of its features [11:46:51] * kshishkov does not care much since toolchain always finds a way to screw something else [11:50:02] <hyc> My first several years in open source were maintaining GNU M68K toolchain [11:50:09] <hyc> and later i860 [11:50:38] <hyc> Kind of a drag when you want to write some other program but first you need to create the tools to get there... [11:50:52] <kshishkov> and my first several years in open source were contributing to FFmpeg [11:52:11] <hyc> even more of a drag, I think the last bits of my code in gcc disappeared when gcc 2.x became 3.0 [11:52:15] <hyc> :P [12:34:59] <CIA-1> ffmpeg: michael * r22775 /trunk/libavcodec/motion_est.c: [12:34:59] <CIA-1> ffmpeg: Change bidir refine hash code so we only need to perform a single [12:34:59] <CIA-1> ffmpeg: hash calculation for the whole function. [12:34:59] <CIA-1> ffmpeg: negligibly faster (about 0.1%) [12:39:14] <Kovensky> is motion_est.c still the biggest file in libavcodec? [12:39:25] <kshishkov> too lazy to check it? [12:39:35] <kshishkov> I thought it was vqf tables or something [12:41:36] * Kovensky remembers it taking aeons to compile [12:42:51] <kshishkov> ah, in compilation time it still should be outstanding [12:43:43] * Kovensky wonders if/how it compiles in a system with 128mb ram [12:46:02] <kshishkov> slowly [12:46:20] <kshishkov> it was the reason I upgraded RAM on my notebook from 64M to 192M [12:46:33] <pJok> mmmmh, 192M [12:46:41] <pJok> that reminds me of 1997 [12:47:11] * thresh had 48M till 2001 [12:47:36] <pJok> thresh, i think i had at least 1G in 2001 [12:48:04] <thresh> so it is true what communists say about capitalists [12:48:27] <pJok> more is better? ;) [12:48:57] <pJok> well, to be fair, i had dialup til september 2001 [12:49:25] <thresh> till 2004, i think [12:50:22] * Kovensky had dialup until 2005 [12:51:05] <thresh> in 2004 i paid 0.25$ per megabyte on 2MB/sec line [12:51:29] * Kovensky had 8mb until 98, 16mb until 2002, 64mb until 2004, 128mb until 2006, 256mb until 2007, 512mb until 2008, 1gb until 2009, 2gb now ._. [12:51:38] <Kovensky> well, 2gb minus the 256mb that this sis crap insists on stealing [12:51:46] <pJok> hehe [12:52:01] <pJok> my netbook has 2g [12:52:37] <Kovensky> the *best* gpu I've had so far has been an fx5200 =p [12:53:00] <pentanol> hi, why I've got Error: bad immediate value for half-word offset while compilation to arm uClib without flag ---disable-asm? [12:53:06] <ohsix> thats a drag, 4/5 series were stinkers [12:53:30] <pentanol> armv5tejl [12:53:43] <pJok> Kovensky, that could actually run WoW ;) [12:53:54] <Kovensky> pJok: at low fpses [12:54:03] <Kovensky> ohsix: before the fx5200, I had an mx4000 :> [12:54:04] <pJok> i managed about 25fps [12:54:09] <pentanol> it depend uClib entries? [13:15:52] <pJok> yum [13:16:05] <pJok> ibm thinkpad pentiums with 64mb ram [13:18:13] <kshishkov> my case exactly [13:18:52] <pJok> i wonder if you could use a 80386 as a microcontroller these days [13:19:06] <kshishkov> too damn expensive [13:19:17] <kshishkov> but it's used in space for that even now [13:20:25] <pJok> thats because the paperwork for getting a new part certified isn't worth it [13:21:22] <kshishkov> no, IIRC BAE produces space-proof PowerPC-based chips [13:22:35] <pJok> that would mean rewriting software also [13:22:47] <kshishkov> indeed [13:23:14] <kshishkov> but it's better for software to be rewritten time from time [13:23:45] <BBB> hello [13:23:55] <kshishkov> hejsan [13:34:39] <CIA-1> ffmpeg: mstorsjo * r22776 /trunk/libavdevice/beosaudio.cpp: Replace the last occurrance of CODEC_TYPE_ with AVMEDIA_TYPE_ [13:37:05] <BBB> lu_zero: thanks! [13:38:49] <BBB> and I see now seeking is indeed broken, we should fix that (by fixing the utils.c overflow, ideally) [13:38:54] <BBB> I'll work on that [14:00:41] <BBB> wbs: I sent a reply to an old email of yours, we should get that patch in [14:02:01] <Kovensky> CODEC_TYPE_ was deprecated? [14:02:52] <kshishkov> replaced [14:03:09] <wbs> BBB: ok, great. :-) I'll try to read up on the lavf infrastructure involved soonish [14:03:19] <BBB> thanks [14:03:22] <kshishkov> let Xiph call subtitle a codec, we call it "media" [14:03:31] <Kovensky> heh [14:04:48] <BBB> anyone here want to participate in a blind test for quality in qcelp decoder? [14:05:06] <CIA-1> ffmpeg: michael * r22777 /trunk/libavcodec/motion_est.c: [14:05:06] <CIA-1> ffmpeg: Optimize bidir_refine a bit. [14:05:06] <CIA-1> ffmpeg: compiled code is less tham 1/4 the size. [14:05:06] <CIA-1> ffmpeg: a tiny bit faster [14:05:22] <kshishkov> I'd participate only in deaf test [14:05:51] <BBB> ? [14:06:31] <kshishkov> i.e. without actually hearing anything [14:08:25] <BBB> you may use audacity to look at soundswaves also [14:08:27] <BBB> if you so prefer [14:09:42] <kshishkov> nah, I'll stay away from audio for a while [14:09:45] <CIA-1> ffmpeg: michael * r22778 /trunk/ (25 files in 5 dirs): Change default for bidir_refine to 1. [14:10:26] <BBB> will you mentor vc1-interlaced for soc? [14:10:50] <kshishkov> co-mentor at most [14:10:57] <BBB> you know, we have only one soc proposal so far [14:11:01] <BBB> that's not very good ;) [14:11:30] <kshishkov> proposal for what? [14:11:35] <BBB> rtsp [14:11:43] <BBB> from j0sh [14:12:03] <kshishkov> ah, maybe you should learn more Hindi to attract proposals [14:12:10] <BBB> I was thinking about that [14:14:14] <kshishkov> okay, recruit jai for organizing next gsoc [14:20:28] <CIA-1> ffmpeg: alexc * r22779 /trunk/libavcodec/psymodel.c: [14:20:28] <CIA-1> ffmpeg: aacenc: Don't lowpass the input unless specifically requested. [14:20:28] <CIA-1> ffmpeg: The heuristic for estimating a good cutoff is busted. [14:20:30] <peloverde> I just dcommited from a git clone! [14:20:46] <merbanan> \o/ [14:20:50] <wbs> \o/ [14:20:55] <iive> aacenc have been committed ? [14:21:44] <BBB> long time ago [14:21:44] <peloverde> The trick is to use git.mansr.com as your upstream and not git.ffmpeg.org because git.ffmpeg.org abuses local file access [14:21:47] <BBB> but it's experimental [14:22:13] * BBB wishes he understood git [14:22:43] <iive> BBB: it's easy. imagine big can of worms. [14:23:20] <peloverde> sigh, now I'm actually doing to have to work on ffmpeg instead of sitting around and complaining about svn :/ [14:24:14] <BBB> peloverde: is that the bug that caused weird buzz-noises at certain high-pitch, high-amplitude input? [14:24:28] <BBB> (whatever you call that in real terms) [14:24:46] <peloverde> No that is most likely a scalefactor selection issue [14:24:59] <peloverde> possibly with bad input from the psymodel [14:25:09] <peloverde> This is a general lack of high frequencies [14:26:42] <BBB> oh ok [14:27:13] <peloverde> Scalefactor selection what what i discussed in the IRC 03-27 e-mail thread [14:28:50] <merbanan> hybrid [14:30:58] <BBB> wooh! this is the first time since years that SVN compiles straight out of the box without the need for any nopic hacks [14:31:04] <BBB> (on macosx) [14:39:34] <merbanan> http://tranquillity.ath.cx/clang/2010-03-30-1/ [14:39:41] <merbanan> clang wasn't as happy [14:42:03] <peloverde> clang is usually unhappy about many things [14:42:08] <BBB> hm... [14:42:13] <BBB> rmdec.c is an actual bug [14:42:42] <merbanan> fix it [14:43:02] <merbanan> well rm is a bug even [14:43:06] <merbanan> hard to fix that [14:44:00] <kshishkov> yeah, go on! [14:49:42] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/ i got a lot more warnings than you [14:49:58] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r21814/report-I1qORD.html#EndPath is this one real? [14:50:57] <merbanan> astrange: my build failed to compile thus only ~90 issues [14:53:29] <BBB> kshishkov: please review my rmdec.c patches ;) [14:54:11] <merbanan> look at that, bugs in the atrac code [14:55:58] <CIA-1> ffmpeg: rbultje * r22780 /trunk/libavformat/rdt.c: Remove dead initialization. [14:57:10] <merbanan> astrange: looks like a valid bug [14:57:43] <kshishkov> BBB: done [14:57:47] <CIA-1> ffmpeg: rbultje * r22781 /trunk/libavformat/rmdec.c: Remove dead initialization. [14:58:18] <merbanan> unless the macro does something funky [14:58:26] <BBB> ty [14:58:34] <kshishkov> np [14:58:52] <CIA-1> ffmpeg: rbultje * r22782 /trunk/libavformat/rmdec.c: [14:58:53] <CIA-1> ffmpeg: Fix uninitialized value in codepath. [14:58:53] <CIA-1> ffmpeg: See http://tranquillity.ath.cx/clang/2010-03-30-1/report-40QvF3.html#EndPath [15:00:00] <CIA-1> ffmpeg: rbultje * r22783 /trunk/libavformat/rmdec.c: [15:00:00] <CIA-1> ffmpeg: Another uninitialized value. [15:00:00] <CIA-1> ffmpeg: See http://tranquillity.ath.cx/clang/2010-03-30-1/report-e6KUTb.html#EndPath [15:01:12] * kshishkov suspects he saw that tranquillity webserver with his own eyes [15:03:02] <merbanan> you did :) [15:03:12] <merbanan> but it has an older brother now [15:03:19] <merbanan> the fit-pc2 [15:05:05] <kshishkov> s/older/yngre/ ? [15:06:43] <merbanan> well ok [15:06:51] <merbanan> he got a more powerful brother [15:07:07] <kshishkov> a sequel ;) [15:08:17] <peloverde> What is the ordering scheme in libavcodec/options.c? [15:08:52] <superdump> have any of us ever been contacted by the mpeg-la with demands that we license codecs from them? [15:08:54] <kshishkov> I suspect its' chronological [15:09:10] <kshishkov> or grouped and chronological [15:09:19] <merbanan> superdump: not that I know of [15:09:24] <superdump> i didn't think so [15:09:34] <kshishkov> superdump: just don't claim you use it and you'll be okay [15:09:34] <merbanan> superdump: and it's not what they do [15:09:38] <janneg> KotH: ^^^^ [15:09:52] <peloverde> The get their money when people productize FFmpeg [15:10:23] <peloverde> my guess is they consider ffmpeg proper just r&d [15:10:44] <BBB> kshishkov: "And it has functions for zeroing or copying arrays of floats written quite poorly and nowhere near as good as plain memcpy/memset." - you know each dll has that [15:10:59] <BBB> kshishkov: you'd be surprised how many (yes, there's multiple) of those I found in wmavoice ;) [15:11:17] <janneg> apparently they changed their mind. [15:12:39] <merbanan> janneg: ? [15:12:42] <superdump> so, apparently Chutt (lead dev of mythtv) has received a request for licensing from the mpeg-la for various mpeg codecs [15:13:04] <Chutt> nice big set of docs [15:13:16] <superdump> and requests for lots of money i expect [15:13:35] <Chutt> to go along with the licenses, i'd assume [15:13:37] <Chutt> heh [15:13:42] <superdump> just to verify, you don't personally ship any products using mythtv do you? [15:13:42] <kshishkov> BBB: WM codecs are known for duplicating every common function (like get_bits()) but this is worse [15:13:45] <Chutt> no [15:13:58] <janneg> not even binaries [15:14:01] <superdump> then i wonder why they sent it to you [15:14:04] <Chutt> i'm hardly involved in the project, even [15:14:15] <BBB> Chutt: can you forward it to me? [15:14:17] <Chutt> i own the domain name, probably the easiest way to contact "the project" [15:14:23] <BBB> Chutt: I've tried for a while to get my hands on such requests [15:14:25] <Chutt> BBB, a physical document? :p [15:14:32] <BBB> oh, it's not email? [15:14:34] <Chutt> no [15:14:38] <BBB> yes, I'd love the physical document [15:14:39] <superdump> Chutt: BBB (Ronald Bultje) has handled most of our involvement with the SFLC [15:14:40] <merbanan> but I guess myth supplies binaries [15:14:42] <kshishkov> BBB: memcpy should use "rep movsd", not whole idiotic loop "mov eax, [src]; mov [dst], eax; add src, 4; add dst, 4;" [15:14:45] <Chutt> fedex [15:14:52] <Chutt> merbanan, we do not supply binaries [15:14:53] <iamlindoro> merbanan: source only [15:14:54] <BBB> Chutt: I'd love to get a copy of the documents, if you can [15:15:01] <Chutt> BBB, sure, happy to [15:15:07] <BBB> Chutt: I'll make sure out lawyer gets them and we'll be on it [15:15:11] <Chutt> well, i wouldn't want to send _all_ this [15:15:17] <Chutt> i mean, it's heavy [15:15:18] <Chutt> heh [15:15:22] <superdump> bit of a tome is it? :) [15:15:24] <merbanan> superdump: is there more info about this ? [15:15:30] <superdump> ask Chutt [15:15:31] <BBB> Chutt: I can reimburse shipping expenses [15:15:33] <superdump> :) [15:15:37] <Chutt> BBB, would you need the individual licenses? [15:15:46] <BBB> Chutt: basically anything they sent you ;) [15:15:48] <Chutt> that's most of the package [15:16:11] <Chutt> basically, i got a cover letter [15:16:23] <Chutt> then packets for mpeg2, h264, and mpeg4 [15:16:31] <BBB> ah, right, I see [15:16:33] <Chutt> short overview doc for each [15:16:38] <BBB> do you have a scanner? [15:16:52] <Chutt> yeah [15:16:58] <BBB> can you scan the coverletter? [15:17:02] <Chutt> certainly [15:17:09] <BBB> I'll discuss briefly with the lawyer whether he's interested in doing some fun stuff with this [15:17:15] <superdump> :) [15:17:21] <BBB> then we can discuss what we need to receive in order to continue [15:17:21] <Chutt> awesome. [15:17:39] <BBB> superdump: thanks for the hint ;) I've always wanted to get my hands on this ;) [15:17:52] <superdump> i thought someone here might be interested [15:17:59] <superdump> and now we have contacts.... [15:18:24] <KotH> janneg: ? [15:18:28] <BBB> Chutt: send it to rsbultje gmail com [15:18:41] <merbanan> BBB: you are such a masochist [15:19:13] <BBB> merbanan: only when I dislike the person I'm inflicting pain upon ;) [15:19:21] <janneg> have you received love letters from mpeg-la with requests for licensing their patents [15:19:51] <KotH> janneg: not that i know of [15:19:52] <merbanan> when you get the coverletter repost on legal [15:19:54] <superdump> i don't think any of us ever have [15:20:55] <superdump> oh, this channel is logged btw :) [15:21:33] <BBB> merbanan: ok [15:22:34] <KotH> janneg: why do you ask? [15:22:40] <janneg> KotH: I somehow thought you are the Registrant of ffmpeg.org [15:22:50] <janneg> but it's fabrice [15:23:44] <KotH> so far, we only got a couple of cease and desist from on2 [15:24:00] <KotH> nothing else, not even adobe [15:24:40] <superdump> i think mike would be pretty pissed if adobe tried to take us down [15:24:43] <superdump> considering his roots [15:25:14] <superdump> and we'd kick up a big fuss if they did [15:26:09] <Chutt> sorry, scanning's taking a bit of effort [15:26:15] <BBB> that's ok [15:26:22] <Chutt> haven't used this thing in a couple years [15:26:29] <BBB> Chutt: can you reply to my privmsg? I'm forwarding messages from my lawyer ;) [15:26:38] <Chutt> i haven't gotten a privmsg [15:26:48] <merbanan> switched to a wireless card that works [15:28:57] <kshishkov> merbanan: what do you think of my short tourist guide to Sweden at http://codecs.multimedia.cx/?p=276 ? [15:30:06] <merbanan> nice [15:30:17] <merbanan> read it a few days ago [15:30:46] * superdump has a look [15:31:51] <superdump> kshishkov: s/moose/elk/ [15:32:22] <kshishkov> s/elk/älg/ [15:32:50] * kshishkov curses certain country with earls instead of counts [15:33:48] <Kovensky> use Moose; [15:33:51] <superdump> :) [15:33:53] <superdump> i was going to go älg spotting with my girlfriend's dad when we were down there visiting them at the beginning of the year, but we ran out of time :/ [15:34:25] <kshishkov> I spot several at Skansen, it was not that hard [15:35:04] <superdump> not the same as seeing them wild [15:35:43] <kshishkov> yes, at least not for Peugeots [15:36:41] <janneg> or Mercedes Benz [15:37:06] <kshishkov> no, Daimler Benz produces cars [15:37:26] <kshishkov> not some laughable parodies any elk can crash [15:37:57] <janneg> kshishkov: http://de.wikipedia.org/wiki/Elchtest [15:39:11] <iamlindoro> http://en.wikipedia.org/wiki/Moose_test [15:39:47] <peloverde> Hmm... options.c does not like me reusing the same flags variable for audio and video [15:41:09] <kshishkov> janneg: have I mentioned that I've seen several Trabants here? Says a lot about country. [15:42:43] <janneg> kshishkov: I still see Trabants in Berlin [15:44:30] <kshishkov> of course, it's ex-DDR [15:45:11] <kshishkov> which is a good punishment for welcoming guys with nicknames 'Lehnin' [15:45:28] <janneg> I'm not talking about museums [15:45:47] <kshishkov> I also talked about streets [15:45:58] <kshishkov> can't see that BMW 321 anymore though [15:46:49] <janneg> I would have expected that they had vanished from the streets by now. it's 20 years [15:47:32] <kshishkov> well, majority of cars here are clones of some "Fehler in Alle Teilen" car from sixties [15:47:36] <merbanan> BBB: good work [15:47:45] <BBB> this could be fun :) [15:49:38] <kshishkov> do they really employ weasels for lawyers? [15:51:18] <gbee> BBB: glad someone's having fun ;) [15:51:36] <BBB> kshishkov: it's like the mpaa going after students [15:51:41] <BBB> I mean, if you're gonna sue random people [15:51:50] <BBB> why on EARTH would you sue the poorest of the poor? [15:52:22] <BBB> it's completely illogical [15:52:37] <peloverde> because they are trying to scare people into compliance [15:52:44] <kshishkov> like Crocodile Dundee 2 movie "I you touch me I'll sue you to your last dollar! *hit* Here it is" [15:52:58] <gbee> BBB: now don't be unreasonable, you can't start bringing logic into the argument ;) [15:53:03] <janneg> to make an example [15:53:13] <iamlindoro> Of the visible projects using libav*, MythTV may be the least able to defend itself at the moment [15:53:31] <iamlindoro> They may assume they'll get less of a fight than they would from XBMC/etc. and can establish favorable case law [15:53:40] <kshishkov> FFmpeg does not have a strict owner, good luck suing whole swarm [15:54:08] <janneg> and the the poorest of the poor have the probably not enough for a proper defense [15:54:49] <kshishkov> in times like this I'm proud to be not an American citizen! [15:55:00] <peloverde> ffmpeg.org is what is actually distributing it and according to whois it belongs to fabrice, so we can all hide behind him [15:56:06] <janneg> I think it would make more sense to go after the isp/owner of the server [15:56:09] <peloverde> also if they shut us down they would probably actually lose money (beyond legal costs) [15:56:09] <kshishkov> you mean Gerard Lantau? [15:58:25] <kshishkov> and it won't really make us stay shut too [16:27:03] <CIA-1> ffmpeg: alexc * r22784 /trunk/libavcodec/aacenc.c: aacenc: Error when an unsupported profile is requested [16:52:48] <peloverde> siretart, What's the libmp4v2 status in debian/ubuntu? [16:54:24] <peloverde> And why does that other project like to take a bunch of files with incompatible licenses and mash them together? [16:54:53] <pJok> peloverde, isn't license violation the new thing these days? [16:55:30] <peloverde> Most of these violations are pretty old and nobody noticed them for a long time [17:02:27] <janneg> who are the mailing lists mods for -legal? please approve my subscription request [17:03:13] <kshishkov> KotH maybe [17:03:40] * KotH is only a free loader on -legal [17:04:21] <kshishkov> mru then? [17:05:06] <KotH> dunno [17:05:13] <KotH> but i doubt it [17:05:20] <KotH> ml admins are mostly not root [18:00:29] <siretart> peloverde: what do you mean with 'status'? [18:01:43] <peloverde> siretart, The concept of moving to the mp4v2 google code fork was presented and then the MPL/GPL issue came up [18:02:01] <siretart> peloverde: debian doesn't ship it at all AFAIR, ubuntu builds it from the mpeg4ip source package [18:02:37] <peloverde> Doesn't the mpeg4ip source have the same license issue and is super ancient? [18:08:12] <siretart> peloverde: puh, I have to admit that I didn't follow the situation closely [18:09:00] <peloverde> I have noticed that the number of packages depending on libmp4v2 has substantially decreased [18:09:14] <siretart> hm. last update december 2007. [18:09:23] <siretart> upstream update, not last upload [18:09:39] <siretart> peloverde: what would you suggest? [18:10:26] <peloverde> siretart, either moving to this fork: http://code.google.com/p/mp4v2/ or dropping the library entirely [18:10:58] <peloverde> which I think was the original consensus in the fall [18:12:44] <siretart> seems that only 3 other packages "use" mpeg4ip: easytag-aac, kid3 and faac [18:13:09] <siretart> seems like faac is going away anyway, and hopefully the other two can be compiled against that fork [20:15:52] <CIA-1> ffmpeg: rbultje * r22785 /trunk/libavformat/rtsp.c: ETIME -> ETIMEDOUT. Patch by Sam Gerstein <sgerstein bluefinlab com>. [22:04:43] <troy_s> Hey folks. Trying to get sws_scale to generate fullRange instead of 16-235. What do I do before I call sws_scale? [22:06:03] <troy_s> It looks like I need to make sure that the ColorspaceDetails is properly set in srcRange, is that correct? [22:09:47] <CIA-1> ffmpeg: rbultje * r22786 /trunk/libavformat/httpauth.c: [22:09:47] <CIA-1> ffmpeg: Fix buffer size; should hold 2 32-bit integers in hex = 16 chars + terminating [22:09:47] <CIA-1> ffmpeg: zero, so should be 17 bytes, not 9. [22:43:44] <mru> w [22:44:24] <mru> wm [22:44:48] <drv> aw, i was busy cutting and pasting some `w` output to make a joke ;) [22:47:31] <mru> overzealous android softkbd [22:48:27] <hyc> I think the proper followon would havce been "tf" [22:49:56] <drv> i amuse myself by responding to people who type things like 'ls' into their irc clients [22:50:21] <pasteeater> mru: talking about android, did you get my message? [23:09:08] <Dark_Shikari> http://mirror05.x264.nl/Dark/loren.html updated. [23:09:14] <CIA-1> ffmpeg: cehoyos * r22787 /trunk/ffmpeg.c: Use AVDISCARD_DEFAULT for 0 where appropriate. [23:10:47] <Dark_Shikari> <pengvado> nv12 c finished. now to update the asm... [23:10:47] <Dark_Shikari> <kemuri-_9> when do you expect to get that done pengvado? [23:10:48] <Dark_Shikari> <pengvado> how am I supposed to be a deadly multimedia ninja if people go and *expect* me? [23:15:34] <Dark_Shikari> peloverde: thanks for fixing the lowpass. [23:16:54] <peloverde> np [23:17:10] <peloverde> lowpass can still be specified manually with -cutoff [23:18:20] <peloverde> I'm try to drag the stuff that doesn't break anything and doesn't add significant complexity out of my tree [23:18:55] <peloverde> a window size switching option is next on the list [23:19:08] <Dark_Shikari> it doesn't do that automatically? [23:19:28] <peloverde> It does, but turning it off can help track down bugs [23:20:04] <Dark_Shikari> ah k [23:20:53] <peloverde> There are some weird dependencies between short windows that can help bugs creep in [23:21:36] <peloverde> ideally we (me) fix the psymodel and coefficient coder for long windows first then track down short window bugs and window decision bugs [23:21:55] <saintd3v> peloverde: now i have to update my tests :( [23:23:08] <peloverde> If anything I think the AAC encoder is a victim of its own complexity a bunch of half finished features went in and they need to be turned off temporarily to make debuging tuning sane [23:32:11] <saintd3v> peloverde: and don't work on the encoder on account of my tests. I'd really much rather have PS than a working aac encoder ;) [23:34:55] <peloverde> The spec is much worse than I expected, even for mpeg audio [23:35:21] <peloverde> Though I suppose it's not as bad as SLS [23:43:30] <peloverde> PS is underspecified, SLS is (was?) just plain wrong [23:44:16] <troy_s> Dark_Shikari: Can I ask you a question sir? [23:44:51] <Kovensky> Satellite Landing System? [23:44:56] <peloverde> I think you've proven that you can [23:45:04] <peloverde> Scalable to Lossless [23:53:37] <Dark_Shikari> troy_s: don't ask to ask, just ask [23:54:11] <troy_s> WRT to 16-235 scaling for broadcast, is the best way to avoid that by calling sws_scale with the proper colorspace bits set? [23:54:32] <Dark_Shikari> I have no idea how swscale handles fullrange vs tv range [23:54:37] <troy_s> As in setting color_range AVCOL_RANGE_JPG [23:54:40] <troy_s> Hrm. Ok. [23:54:55] <troy_s> Who in your opinion is likely the best one to ask regarding how sws_scale deals with it> [23:54:56] <troy_s> ?

1 0

IRC log for 2010-04-01
by irc＠mansr.com 02 Apr '10

02 Apr '10

[00:59:18] <mru> lol, youtube has libaa rendering [01:03:26] <astrange> i'm not seeing it yet, is it timezoned? [01:03:48] <kierank> astrange: does the logo look like it's libaa rendered? [01:05:29] <astrange> same as always, except for the new page design [01:05:44] <astrange> the new design somehow causes my flash blocker to download video.mp4 whenever i go to a video page [01:05:48] <kierank> then i guess it's time delayed [01:05:53] <astrange> i think that might be more convenient than actually using youtube [01:06:21] <kierank> "By using text-only mode, you are saving YouTube $1 a second in bandwidth costs. " [01:08:05] <Dark_Shikari> wait. so is the new youtube interface an april fools' or not? [01:08:08] <Dark_Shikari> it's not silly enough [01:08:22] <kierank> no [01:08:34] <kierank> the "text mode" is the april fools thing [01:08:47] <Dark_Shikari> where is that [01:08:56] <kierank> presumably time-delayed [01:09:29] <Dark_Shikari> ah [02:15:56] <Dark_Shikari> oh wow, I just realized michael already fixed my weightb + mbaff bug [02:15:58] <Dark_Shikari> yesterday [02:16:05] <Dark_Shikari> he's fast as hell [04:21:05] <Dark_Shikari> hmm. is ffmpeg's sync engine supposed to generate a different number of video frames if -an is specified? [04:21:08] <Dark_Shikari> because it really shouldn't [04:21:13] <Dark_Shikari> (this without using -r, just straight encoding) [04:21:34] <Dark_Shikari> a customer of mine is reporting different number of frames in each pass (thus x264 breaks) when they use -an on the first pass. [05:09:57] <pentanol> hi there, could anybody argue this behaviour on arm uClib? http://codepad.org/N0zpCzLq [05:14:01] <av500> pentanol: what toolchain/system? [05:15:37] <elenril> google is down today? [05:15:51] <elenril> http://www.mail-archive.com/uclibc@uclibc.org/msg04954.html << first result for uclib log2f [05:19:48] <pentanol> av500 cross-compiler-armv5l [05:20:34] <pentanol> on my camera elder uclib, thefore I wanna compile it static... [05:22:02] <pentanol> also log and exp sumbols exist there... http://codepad.org/eodnbg41 [05:34:49] <thresh> moroning [05:34:58] <kshishkov> as always [05:38:56] <thresh> yep, that's why they call us Konstantins [05:39:03] <mru> morning [05:39:36] <kshishkov> god morgon [05:39:57] <av500> hi guys [05:40:27] <kshishkov> hi bcoudurier onjoin script reused by av500 [05:40:55] <elenril> av500: copyright ifringement!!!!11one [05:47:55] <pentanol> elenril hm, I tries in that way, but fails [05:57:13] <pentanol> also readelf said about log2f exist there http://codepad.org/wLy8jAuK [06:00:20] <av500> 0 NOTYPE GLOBAL DEFAULT UND log2f [06:00:26] <av500> UND=undefined [06:42:09] <CIA-1> ffmpeg: koorogi * r22753 /trunk/ (libavcodec/avcodec.h doc/APIchanges libavcodec/utils.c): Add function to export EDGE_WIDTH from libavcodec. [06:42:09] <CIA-1> ffmpeg: koorogi * r22754 /trunk/ffplay.c: Hook decoder up to libavfilter's direct rendering for ffplay [06:42:10] <CIA-1> ffmpeg: koorogi * r22755 /trunk/ffplay.c: Don't create unnecessary refereces to pictures [06:42:10] <CIA-1> ffmpeg: koorogi * r22756 /trunk/ffplay.c: Cosmetics: indentation [07:40:38] <KotH> hey boys! [07:41:19] <kshishkov> hey what? [07:41:28] <KotH> hey you! [07:41:46] * kshishkov is not here anyway [07:41:52] <KotH> and an awfull, post-communist, horrible morning to you! [07:42:07] <kshishkov> at last you got it right! [07:54:03] <kshishkov> KotH: BTW, isn't it 1st of April aka Theora Users Day? [07:54:48] <Dark_Shikari> http://www.videolan.org/ [07:54:52] <Dark_Shikari> videolan is bought out by realnetworks [07:55:09] <kshishkov> less rivals for FFplay! [07:55:33] <av500> at least they will get buffering support [07:55:43] <kshishkov> BTW, when FFmpeg is ported to unixkcd? [07:55:51] <astrange> it hasn't changed for me [07:55:59] <astrange> oh [07:58:43] <elenril> unixkcd ftw! [08:03:12] <CIA-1> ffmpeg: benoit * r22757 /trunk/libavformat/flvdec.c: [08:03:13] <CIA-1> ffmpeg: Fix flvdec start-of-frame. [08:03:13] <CIA-1> ffmpeg: Patch by Howard Chu hyc highlandsun com [08:09:22] <hyc> cool, thanks for the commit benoit [10:49:03] <ramiro> kshishkov: nice trackback... [11:00:54] <av500> ? [11:04:00] <bilboed-pi> kshishkov, btw, I blame you for making me want to learn the Passcaglia :) [12:04:41] <KotH> interesting... someone at ST micro seems to be interested in ogg [12:09:23] <av500> ogg the container? [12:10:24] <CIA-1> ffmpeg: michael * r22758 /trunk/libavformat/utils.c: Limit probing to probesize. [12:15:05] <KotH> the guy downloaded all our ogg/vorbis samples [12:15:17] <av500> ah [12:15:38] <av500> he might be preparing a law suit :) [12:38:53] <superdump> lol [14:16:21] <jez9999> BBB: looks like you didn't get very far with issue 1740 :-P [14:16:28] <BBB> ? [14:16:34] <BBB> oh, I've been busy with other things, yes [14:17:47] <BBB> I should probably put it in my local tree so I don't forget about it... [14:17:48] <BBB> hmm... [14:31:29] <roozhou> hi, who maintains the avi demuxer? [14:31:51] <kshishkov> default maintainer does [14:32:20] <roozhou> then who? [14:32:25] <av500> mn? [14:32:34] <kshishkov> of course [14:32:39] <roozhou> does he use irc? [14:32:42] <av500> no [14:32:48] <av500> but he reads the logs [14:35:08] <jez9999> he does? heh [14:35:11] <jez9999> how boring [14:35:38] <kshishkov> why does that bother you? [14:36:01] <jez9999> doesnt bother me [15:34:56] <pengvado> does anyone know a sigmoid function that can be computed quickly with integer math? [15:35:56] <kshishkov> uh, maybe you ask three easier questions? [15:38:27] <bofh__> pengvado: wouldn't arctan(x) work for that? [15:38:45] <pengvado> since when is arctan fast? [15:39:37] <pengvado> in SSE, x/(abs(x)+1) takes 5 uops per 4 elements [15:39:59] <pengvado> but I'm looking for something that can be bit-exact on archs other than SSE [15:41:00] <pengvado> the baseline is simply a bit-exact C emulation of the SSE ops (dunno how fast I can make that) [15:41:07] <superdump> is this for ffv2? [15:41:10] <pengvado> yes [15:42:07] <kshishkov> Lagarith shows that floating-point math in lossless codecs is a good idea [15:43:08] <pengvado> Lagarith used float because the developer was lazy. there was absolutely no reason not to do that with something exact. [15:43:45] <pengvado> I'm asking whether there is any way to do this in int that isn't 2 orders of magnitude slower than float. [15:44:04] <kshishkov> dpends on your input [15:44:33] <kshishkov> but in general - unlikely [15:54:08] <CIA-1> ffmpeg: benoit * r22759 /trunk/libavcodec/libx264.c: [15:54:09] <CIA-1> ffmpeg: Fix typo: CODEC_FLAG2_SSIM is in flags2, not in flags. [15:54:09] <CIA-1> ffmpeg: Patch by Takashi Mochizuki mochi (A) da2 (.) so (dash) net (dot) ne (.) jp [15:56:12] <BBB> hwo do i know yasm was enabled? [15:56:17] <BBB> I did --enable-yasm [15:56:23] <BBB> but configure shows no messages [15:56:27] <janneg> BBB: configure should print it [15:56:33] <kshishkov> grep config.mak ;) [15:56:39] <BBB> I don't think it did... [15:56:55] <BBB> YASM=yasm [15:56:58] <BBB> is all I find there [15:57:01] <kshishkov> or make and look if those libavcodec/x86/*.s files were compiled ;) [15:57:07] <kshishkov> good [15:57:27] <janneg> BBB: make config | grep -i yasm [15:57:28] <janneg> yasm yes [15:59:39] <BBB> ok it did work [15:59:39] <BBB> thanks [16:11:07] <BBB> oh wait let me guess [16:11:17] <BBB> all yasm code is under --enable-gpl right? [16:13:08] <pengvado> no [16:28:46] <BBB> holy shit that fft is fast [16:29:15] <kshishkov> compared to what? [16:29:15] <BBB> my decoding just went to under a second for 4 files together compared to several seconds for one file before [16:29:28] <BBB> with fft optimizations enabled, I suppose [16:29:30] <kshishkov> good [16:31:20] <Dark_Shikari> pengvado: what is atan useful for in ffv2? [16:32:17] <pengvado> nerual net spatial prediction [16:32:43] <pengvado> (and nnedi mc, but that would be overkill) [16:32:51] <Dark_Shikari> .... how much does it help? [16:32:58] <pengvado> dunno yet [16:33:15] <Dark_Shikari> You can test it without having a portable version >_> [16:33:38] <pengvado> don't have a nonportable version either, I just know this issue will come up if it ever works [16:33:46] <Dark_Shikari> lol [16:53:05] <CIA-1> ffmpeg: reimar * r22760 /trunk/libavcodec/x86/h264dsp_mmx.c: Convert two "m" constraints to MANGLE to fix compilation with some compilers. [17:12:37] <CIA-1> ffmpeg: reimar * r22761 /trunk/ (9 files in 2 dirs): Change/simplify the tableprint/tablegen API. [17:55:06] <CIA-1> ffmpeg: reimar * r22762 /trunk/libavcodec/ (pcm_tablegen.h Makefile pcm.c pcm_tablegen.c): Allow hardcoding of ulaw and alaw tables. [18:52:02] <CIA-1> ffmpeg: michael * r22763 /trunk/libavcodec/ffv1.c: [18:52:03] <CIA-1> ffmpeg: Store range coder state transition table. [18:52:03] <CIA-1> ffmpeg: Use a better table, 2% compression gain for foreman [18:52:20] <Dark_Shikari> oh shi- some competition for ffv2 [18:52:25] <Dark_Shikari> wait. doesn't that break compatibility? [18:53:35] <Dark_Shikari> hmm, I guess it does. [18:55:44] <bcoudurier> nope [18:55:46] <bcoudurier> it extends [18:55:54] <bcoudurier> ffv1 stores ac in the bitstream [18:55:58] <bcoudurier> he added ac 2 [18:56:15] <Dark_Shikari> Yeah I know [18:56:16] <bcoudurier> + put_symbol(c, state, f->ac, 0); [18:56:16] <bcoudurier> + if(f->ac>1){ [18:56:18] <Dark_Shikari> saw that [18:56:48] <bcoudurier> well anyway ffv2 should outperform everything :) [18:57:16] <bcoudurier> if that's the case I will switch to it as an archive format as soon as it's stable [18:57:33] <Dark_Shikari> yeah, we worked pretty hard on the design [18:57:41] <Dark_Shikari> and it should be really really freaking fast [18:57:42] <Dark_Shikari> it has no arithcoding [18:57:56] <bcoudurier> can you make it support 4:2:2 early ? :> [18:58:05] <Dark_Shikari> should be trivial to support 4:2:2, it codes each chroma plane separately [18:58:15] <bcoudurier> nice [18:58:22] <bcoudurier> intra only efficient ? [18:58:31] <Dark_Shikari> intra only will be pretty efficient but no way as good as ffv1 [18:58:37] <Dark_Shikari> but probably reasonably close [18:58:37] <bcoudurier> oh :( [18:58:46] <Dark_Shikari> because you can't possibly beat ffv1 through normal methods [18:59:00] <Dark_Shikari> the only way to beat ffv1 is a more complicated predictor imo [18:59:08] <Dark_Shikari> i.e. neural net prediction or something, or LPC [18:59:16] <Dark_Shikari> the goal of ffv2 is to be fast while remaining useful [18:59:21] <Dark_Shikari> so it won't use such insane things [18:59:38] <Dark_Shikari> also, why intra only? decoding one gop of ffv2 is probably faster than decoding one frame of ffv1 (for a gop size of, say, 12) [19:04:36] <jai> wow [19:04:37] <jai> nice [19:05:35] <bcoudurier> my favorite combo is mov+ffv1+pcm [19:05:44] <bcoudurier> I can address any frame instantly [19:07:50] <bcoudurier> but yeah I guess that using a small gop size and decoding a gop should be ok [19:07:53] <Dark_Shikari> jai: it should be faster than _huffyuv_ [19:08:13] <Dark_Shikari> it's designed from the ground up to make the prediction SIMDable [19:08:19] <Dark_Shikari> and to merge as many values as possible into one VLC code [19:08:30] <Dark_Shikari> It also has really, really, really big VLC tables. [19:08:47] <jai> Dark_Shikari: well, i'd definitely like to use that for archival :) [19:08:49] <Dark_Shikari> basic structure in short: [19:08:54] <Dark_Shikari> 1) 8x8 block size only [19:09:05] <Dark_Shikari> 2) motion vectors are hpel, median-predicted [19:09:28] <Dark_Shikari> 3) pixels are median-predicted. on the edges of inter/intra boundaries, the edge pixels are recalculated [19:09:40] <Dark_Shikari> i.e. for predicting an inter block from an intra block, you recalculate the intra predictions as if they were inter [19:09:49] <Dark_Shikari> and vice versa [19:09:57] <Dark_Shikari> without this, mixing intra + inter is impossible [19:10:12] <Dark_Shikari> 4) groups of 2x2 pixels are coded as a single VLC [19:10:24] <Dark_Shikari> e.g. a VLC might say [-2,1,0,ESC] [19:10:33] <Dark_Shikari> where ESC means "one escape code is written after this VLC" [19:10:51] <Dark_Shikari> 5) groups of 8x4 pixels are coded as a single Coded Block Pattern (to say which groups of 2x2 are coded) [19:11:20] <Dark_Shikari> 6) MB types are coded as VLCs of groups of 4 blocks, so 4 MB types per VLC [19:11:42] <Dark_Shikari> each row of blocks is padded to a multiple of 4 for this purpose (not in terms of pixels, just how many are written--the last element may have a junk data value or two added for this purpose) [19:12:00] <Dark_Shikari> mb types are inter + delta MV, intra, and inter + no delta MV [19:12:14] <Dark_Shikari> 7) each syntax element is coded per row. i.e. you have all the mb types, then all the mvs, then all the cbps... [19:12:30] <Dark_Shikari> 8) the pixels are arranged in a Very Curious Fashion so as to allow median prediction in SIMD. [19:13:02] <Dark_Shikari> delta MVs are, of course, yet another VLC table. [19:13:22] <Dark_Shikari> Basically every single syntax element no matter what is an adaptive VLC table written every once in a while to the stream. [19:14:09] <Dark_Shikari> oh yeah, and 9) there are 8 different VLC tables for 2x2 block codes, chosen based on the sum of the absolute deltas (with escapes clipped to 2) of the top and left 2x2 blocks. [19:14:14] <Dark_Shikari> i.e. same as CAVLC. [19:14:49] <Dark_Shikari> FFV2 will probably be scalable, i.e. we can add new optional features to improve compression at the cost of speed. [19:15:20] <Dark_Shikari> Possibilities: qpel, eighthpel, LPC prediction, NNet prediction, median5 prediction (only useful for intra), etc. [19:16:48] <Dark_Shikari> (any other ideas are of course welcome) [19:59:28] <astrange> if you finish ffv2 i'll add encoding support to perian and support it [20:00:18] <astrange> i'm uncomfortable with supporting other formats though (some because they're clearly proprietary and some because i don't think i can design a ui good enough to hide mpegvideoenc complexity) [20:00:19] <Dark_Shikari> and I'll harass the ffdshow guys to do it [20:00:55] <astrange> oh, and if it has an rgba mode actually implement the alpha support [20:02:22] <astrange> is adding weird predictors really better for compression than range coding? [20:02:34] <Dark_Shikari> what weird predictors? [20:02:48] <astrange> neural net [20:02:56] <Dark_Shikari> there's no reason not to combine them [20:03:01] <Dark_Shikari> they're separate [20:03:21] <Dark_Shikari> well, hmm, maybe you're right [20:03:36] <Dark_Shikari> but a neural network range coder would be sorta hard to construct [20:39:16] <BBB> lu_zero: what was the ogg/vorbis rtsp test on feng again? [20:45:12] <bcoudurier> astrange, do you know how peloverde interpolates dts from mkv in perian, does it use code for each audio and video codec ? [20:49:30] <BBB> lu_zero: or can you please set one up? [20:50:37] <bcoudurier> how can I get the corresponding svn rev in x264 ? [20:51:52] <Dark_Shikari> ./version.sh [20:57:20] <CIA-1> ffmpeg: cehoyos * r22764 /trunk/ (doc/ffplay-doc.texi ffplay.c): [20:57:20] <CIA-1> ffmpeg: Add -t option to ffplay. [20:57:20] <CIA-1> ffmpeg: Patch by Robert Kr?ger, krueger signal7 de [20:59:52] <bcoudurier> how do you retrieve an old one ? [21:00:43] <bcoudurier> forget it [21:00:52] <Dark_Shikari> suppose the latest is revision X. the one you want is revision Y. [21:00:59] <Dark_Shikari> git checkout HEAD~(X-Y) [21:01:04] <Dark_Shikari> so 1490 would be HEAD~20. [21:06:00] <astrange> bcoudurier: yuvi not peloverde [21:06:15] <bcoudurier> right, sorry [21:07:10] <astrange> it's all in http://trac.perian.org/browser/trunk/MatroskaImportPrivate.cpp#L1076 and doesn't seem to consider any codec specially [21:07:17] <astrange> of course, i can't guarantee it's correct [21:07:27] <Dark_Shikari> can probably look at mkvmerge's code [21:07:37] <Dark_Shikari> though mkvmerge has a lot of per-codec stuff solely because of parsers [21:07:39] <astrange> specifically it completely fails to import mpeg-2 generated by MakeMKV, i haven't investigated yet [21:07:42] <Dark_Shikari> which is a given for any app [21:08:01] <astrange> about ffv2 again, can you get away with sticking the h.264 vui in it somewhere? [21:08:23] <astrange> otherwise it will be difficult to use for archival outside mov, because mov is the only container that has colorspace info tags [21:08:48] <astrange> and about that, can we get colr/pasp atom writing in movenc? i'm going to do it sometime but it may take me a while [21:08:49] <bcoudurier> don't use h264 vui [21:08:51] <Dark_Shikari> talk to pengvado about it, I think such flags would be useful [21:08:55] <Dark_Shikari> not exactly the h264 vui [21:08:57] <Dark_Shikari> but at least something similar. [21:09:00] <bcoudurier> yes [21:09:13] <Dark_Shikari> you could even have an mkv-like or xml-like tag header with arbitrary strings [21:09:15] <astrange> the vui has all the right fields, it's the lazy way to do it. but as long as it can do all the same values it's ok [21:10:27] <bcoudurier> astrange, yes about colr pasp [21:10:47] <bcoudurier> if right information is there :> [21:10:52] <Dark_Shikari> so we need timebase, aspect ratio, colorspace, etc? [21:11:09] <bcoudurier> timebase if you want raw I guess [21:11:13] <bcoudurier> so yes [21:11:28] <astrange> clap (clean aperture) is "mandatory" in mov and exists in mp4, but i don't think we have the information for that [21:11:38] <bcoudurier> how mandatory ? [21:12:00] <Dark_Shikari> IMO it would be nice to make the header extensible [21:12:04] <Dark_Shikari> so that more fields can be easily added [21:12:16] <Dark_Shikari> hence the arbitrary strings idea [21:12:28] <Dark_Shikari> all information can be considered metadata [21:12:28] <bcoudurier> optional in iso for sure [21:12:31] <astrange> http://developer.apple.com/quicktime/icefloe/dispatch019.html says "always required", but the default is trivial and qt auto generates it [21:12:38] <Dark_Shikari> "title" would have the same status as "transfer coefficients" [21:12:43] <bcoudurier> yes [21:12:45] <bcoudurier> for uncompressed [21:12:55] <bcoudurier> and for ycbcr [21:13:01] <bcoudurier> like the document title [21:13:11] <bcoudurier> otherwise clean aperture == codec resolution [21:13:26] <bcoudurier> besides apple is fucked up [21:13:44] <bcoudurier> it keeps trying to think that HD clean aperture is not the codec resolution [21:13:49] <Dark_Shikari> I wonder if we can push ffv2 as a standard lossless format [21:13:59] <astrange> colr/nclc is easy to generate from avcodeccontext, you just have to decide if you want to write "unknown" when it's not set or guess from the resolution [21:13:59] <Dark_Shikari> it would be really nice because it's basically better than any current ones [21:14:06] <bcoudurier> while experts explicitely declared that for HD the production aperture is the one encoded [21:14:30] <bcoudurier> experts ie SMPTE [21:15:21] <astrange> quicktime people really want you to write colr in your mov files, at wwdc as soon as i introduced myself they asked me to do it [21:15:35] <bcoudurier> that's because of the mac fucked up display [21:15:49] <astrange> system gamma changed to 2.2 in 10.6 [21:15:49] <bcoudurier> that changed with snow leopard hopefully [21:15:58] <bcoudurier> so it's not needed anymore :> [21:16:01] <bcoudurier> it should not [21:16:40] <kierank> [22:14] <@Dark_Shikari> I wonder if we can push ffv2 as a standard lossless format --> that would make it VC-4 I think [21:16:59] <Dark_Shikari> sounds good [21:17:01] <bcoudurier> the thing is, I'd prefer to avoid writing contradicting infos [21:17:29] <bcoudurier> it's such a pain that so many mkv have different ar in mkv and h264 bitstream for ex [21:17:40] <Dark_Shikari> well, being able to parse raw ffv2 would be nice [21:18:10] <astrange> ffmpeg could complain about more values being different in codec/container values [21:18:24] <astrange> though the timebase warning isn't very useful because nobody cares [21:27:27] <bcoudurier> yes [21:42:00] <CIA-1> ffmpeg: rbultje * r22765 /trunk/libavformat/ (6 files): [21:42:00] <CIA-1> ffmpeg: Rename rtpdec_theora.[ch] to rtpdec_xiph.[ch], as a preparation for merging [21:42:00] <CIA-1> ffmpeg: the Vorbis / theora depacketizers. [21:42:00] <CIA-1> ffmpeg: Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>. [21:42:42] <CIA-1> ffmpeg: rbultje * r22766 /trunk/libavformat/ (rtpdec_xiph.c rtpdec_xiph.h): [21:42:42] <CIA-1> ffmpeg: Rename functions / comments from "Theora" to "Xiph" where relevant. [21:42:42] <CIA-1> ffmpeg: Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>. [21:42:42] <CIA-1> ffmpeg: rbultje * r22767 /trunk/libavformat/rtpdec_xiph.c: [21:42:42] <CIA-1> ffmpeg: Reindent after r22766. [21:42:43] <CIA-1> ffmpeg: Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>. [21:44:19] <CIA-1> ffmpeg: rbultje * r22768 /trunk/libavformat/ (6 files): [21:44:19] <CIA-1> ffmpeg: Merge Vorbis / Theora depayloaders. [21:44:19] <CIA-1> ffmpeg: Patch by Josh Allmann <joshua DOT allmann AT gmail DOT com>. [22:29:41] <peloverde> alex [22:35:19] <CIA-1> ffmpeg: stefano * r22769 /trunk/ (cmdutils.c ffmpeg.c cmdutils.h): [22:35:19] <CIA-1> ffmpeg: Implement cmdutils.c:read_file(), and use it in ffmpeg.c for reading [22:35:19] <CIA-1> ffmpeg: the second pass encoding log file. [23:48:33] <superdump> peloverde: is your password alex or something? :) [23:49:49] <hyc> almost as good as 1 - 2 - 3 - 4 - 5 [23:51:21] <Compn> 12345? thats the same password i hav... [23:51:58] <hyc> Funny, you don't look druish to me...

1 0

IRC log for 2010-03-31
by irc＠mansr.com 01 Apr '10

01 Apr '10

[00:11:07] <Dark_Shikari> mru: well, it seems my "readahead grep" works [00:11:31] <Dark_Shikari> on a 12 gigabyte folder with ~1000 subfolders, each with ~1000 subfiles, with files that were written in random order and size from 0 to 30kb [00:11:35] <Dark_Shikari> on a machine with 6gb of ram [00:11:44] <Dark_Shikari> grepping with my grep takes about 30 minutes [00:11:53] <Dark_Shikari> grepping with unpatched grep takes about 90 minutes [00:12:12] <Dark_Shikari> what's the easiest way to see what filesystem the system is using? [00:12:25] <mru> cat /proc/mtab [00:12:30] <mru> err, /proc/mounts [00:13:07] <Dark_Shikari> which one do I care about? there's a lot, and "/" isn't listed [00:13:23] <Dark_Shikari> oh nvm. every actual filesystem runs reiserfs [00:13:36] <Dark_Shikari> Now, that's interesting, reisefs is supposed to have awesome performance on small files. [00:13:50] <mru> haha [00:13:51] <mru> very funny [00:13:56] <Dark_Shikari> what? [00:14:06] <Dark_Shikari> that was one of the selling points of reiserfs [00:14:11] <mru> selling, yes [00:14:15] <Dark_Shikari> much better performance on tons of small files than, say, ext2 [00:14:18] <mru> did anyone ever say it delievered? [00:14:20] <Dark_Shikari> it did [00:14:26] <Dark_Shikari> all the benchmarks I saw, it crushed ext* [00:14:28] <Dark_Shikari> which isn't _hard_ [00:14:38] <Dark_Shikari> since, at least at the time, ext* sucked horrifically on small files [00:14:49] <mru> most of those benchmarks were done on ext* w/o b-tree dirs [00:14:58] <mru> and that _really_ sucked [00:15:33] <Dark_Shikari> when were those added? [00:15:39] <mru> many years ago [00:15:46] <mru> but after reiserfs gained traction [00:16:31] <mfg> I want to add something to ffplay that prints the chapter metadata whenever a new chapter is reached (to demonstrate the shoutcast chapters stuff). Is this something people would want added to ffplay, and if so, in what way? I have it logging the into out (after making dump_metadata public), but the way we write the current pos to stdout and then flush makes it look bad. Any thoughts? [00:16:31] <Dark_Shikari> http://www.gurulabs.com/archive/ext3-reiserfs/ [00:16:34] <Dark_Shikari> interesting [00:16:40] <Dark_Shikari> it's heavily filesize dependent [00:16:51] <mru> reiserfs has the tail packing thing too [00:16:51] <Dark_Shikari> just adjusting the params on postmark can make ext3 or reiser win by large margins [00:17:14] <mru> tail packing is good for space but bad for performance [00:17:31] <Dark_Shikari> they find that on small files, ordered journaling in ext3 suuuuuuuuuucks [00:17:44] <Dark_Shikari> http://www.gurulabs.com/archive/ext3-reiserfs/page5.html [00:17:54] <Dark_Shikari> (that's the test reiser wins on) [00:18:06] <Dark_Shikari> also, by using reiserfs, you can make jokes about partitioning wives [00:18:23] <hyc> ugh [00:18:39] <mfg> booo [00:18:40] <hyc> I still use reiserfs for most of my machines [00:18:50] <mru> I never used it on my machines [00:18:56] <hyc> hey, anyone have time to comment on my seek patch? https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-March/086166.html [00:18:59] <mru> I don't trust people like him [00:19:09] <mru> even if they're not murderers [00:19:14] <hyc> I trust ext4 even less [00:19:39] <hyc> I used to use xfs for everything [00:19:43] <mru> ext4 is just a knee-jerk we-need-an-extN-with-extents design [00:19:46] <hyc> but it seems to only be good for large files [00:19:53] <mru> xfs is wonderful for large files [00:20:04] <mru> and it's not too shabby with small ones either [00:20:15] <mfg> does it still have that grub problem? [00:20:16] <Dark_Shikari> btfs! [00:20:18] <Dark_Shikari> *btrfs [00:20:25] <mru> but beware of how the large files are written [00:20:27] <Dark_Shikari> it sounds like a dairy product so it must be good [00:20:34] <hyc> lol [00:20:52] <mru> if you mmap a large, empty file and write to it in random order, it gets horribly fragmented and very slow [00:21:00] <mru> like bittorrent tends to do [00:21:07] <mru> if you pre-allocate the space it's fine [00:22:04] <Dark_Shikari> utorrent preallocates space for that reason [00:22:25] <mru> rtorrent does it with special xfs calls that don't actually write anything [00:22:29] <mru> at least with my patch :-) [00:22:33] <Dark_Shikari> lol [00:22:35] <Dark_Shikari> utorrent does it nearly instantly [00:22:39] <Dark_Shikari> so I suspect it does something similar [00:22:46] <Dark_Shikari> it also supports sparse files in NTFS, but that's off by default [00:22:52] <Dark_Shikari> because it's worse for somewhat obvious reasons [00:26:29] <hyc> also, anyone familiar with the flv demux? why does it "start" a frame at the last 4 bytes of the previous frame? [00:26:42] <hyc> why doesn't it start at the actual start of the frame? [00:42:27] <CIA-1> ffmpeg: michael * r22739 /trunk/doc/ffmpeg-doc.texi: Better documentation of -vsync [00:42:59] <hyc> don't all speak up at once now ... ;) [00:45:09] <peloverde> hyc, Michael is the flv maintainer [00:45:24] <peloverde> so you probably are best of sending an e-mail to ffm-devel [00:45:33] <hyc> peloverde: thanks [00:45:47] <hyc> I already have 2 emails outstanding there [00:45:54] <hyc> guess I'll just have to wait [00:46:25] <astrange> rtorrent's ui freezes for very long times on os x if it has to create a new blank file, i never checked what it was doing [00:46:59] <hyc> rtorrent has a nasty habit of re-checksumming files even when they were just created [00:50:20] <mru> I never noticed that [00:52:45] <hyc> hm, are we talking about the same rtorrent? there are two [00:53:00] <mru> I've only used one [00:53:05] <mru> an ncurses thing [00:53:14] <hyc> rakshasa? [00:53:20] <mru> ? [00:53:37] <hyc> libtorrent.rakshasa.no [00:53:56] <hyc> http://libtorrent.rakshasa.no/wiki [00:54:06] <mru> yes, apparently [00:54:17] <hyc> maybe it's been fixed in later versions [00:54:28] <hyc> I haven't actually torrented anything since I started working on rtmp [00:55:09] <hyc> hmm. I don't see how stream->index_entries gets populated [00:55:22] <hyc> where does that happen? [00:56:18] <hyc> oh, I got it [00:56:22] <hyc> av_add_index_entry [00:56:34] <drv> there are two libtorrent, i think - only one rtorrent [00:57:33] <bcoudurier> hi guys [01:03:56] <Kovensky> hi bcoudurier's onjoin [01:20:14] <hyc> [aac @ 0x1348a10]Transition from an ONLY_LONG or LONG_STOP to an EIGHT_SHORT sequence detected. If you heard an audible artifact, please submit the sample to the FFmpeg developers. [01:20:32] <hyc> got this message while seeking around in an flv [01:21:24] <hyc> I'm guessing that this can be ignored in this situation... [01:21:37] <mru> yes, probably [01:22:04] <peloverde> hyc, If you are seeking then that message makes perfect sense [01:22:54] <peloverde> In AAC basicaly there are two window types short and long. but you need a special transitional window to switch between them without artifacts [01:23:26] <hyc> peloverde: thanks [01:23:49] <peloverde> Any artifact should only last one frame (1024 samples) [01:24:08] <hyc> hm, ATRAC and MP3 have short and long frames too, but I don't recall them having such artifacts [01:25:44] <peloverde> MPEG does specify a normative way to switch without the transition (which I guess should help reduce artifacts) [01:26:04] <peloverde> That section of the code was written by one of the previous FFmpeg AAC authors [01:26:27] <peloverde> possibly superdump (Rob) [01:26:34] <hyc> also, the sole reason to switch to short frames was to catch transients, sharp attacks [01:27:09] <hyc> I'd guess most times you wouldn't know the difference between a glitch and the actual transient ;) [01:27:12] <peloverde> indeed but the encoder should look ahead and plan the transition one frame in advance [01:29:47] <peloverde> What is proper downmix behavior these days? I saw a bug quickly open then close [02:27:39] <bcoudurier> astrange, I only answered to you by mistake [02:27:50] <bcoudurier> I'm off bye guys [02:27:54] <astrange> oh, i didn't notice [02:27:58] <bcoudurier> I meant only to you, not the list [02:28:02] <astrange> btw mkv does have dts [02:28:10] <bcoudurier> huh ? [02:28:16] <astrange> import all pts for a block, sort in ascending order, there's dts [02:28:30] <bcoudurier> hum [02:28:36] <bcoudurier> like -2 ? [02:28:43] <bcoudurier> if pts is 0 and tb is 24 [02:28:58] <astrange> i'm not sure it always works but i think that's what you're supposed to do [02:29:04] <bcoudurier> you can't [02:29:06] <bcoudurier> you need delay [02:29:10] <bcoudurier> for mp4 at least [02:29:20] <bcoudurier> ctts is -2 for b pyramid [02:29:52] <bcoudurier> worst case is when it is activated [02:29:58] <bcoudurier> but the usage only appears in the middle of the file [02:29:58] <astrange> yuvi's demuxer in perian creates mov with dts from mkv and works in all practical situations [02:30:08] <astrange> i never compared it against a direct encode-to-mp4 though [02:30:49] <bcoudurier> well michael fixed it in most cases by honoring the value in sps [02:30:59] <bcoudurier> but if the value is missing [02:31:02] <bcoudurier> you have to compute it [02:31:34] <bcoudurier> I guess you don't have the problem with most mkv files since they are created with x264 ;) [02:31:46] <Dark_Shikari> most mkv files are created with mkvmerge [02:32:00] <bcoudurier> encoded with [02:32:03] <Dark_Shikari> oh [02:32:21] <bcoudurier> my files aren't created by x264 at all [02:32:35] <Dark_Shikari> what's the particular issue? [02:32:41] <bcoudurier> value in sps [02:32:47] <Dark_Shikari> sps_id? [02:32:49] <bcoudurier> dpb delay [02:32:51] <Dark_Shikari> ah [02:32:53] <Dark_Shikari> what is it set to? [02:32:56] <Dark_Shikari> or is it not set? [02:32:58] <bcoudurier> no value [02:33:04] <Dark_Shikari> Yes, this is a problem with the h264 spec [02:33:12] <Dark_Shikari> the only solution is to be willing to make the decoder wait a frame or two later [02:33:17] <Dark_Shikari> if you run over the guessed value [02:33:23] <bcoudurier> yes [02:33:48] <bcoudurier> or you use max delay, 16 [02:34:00] <bcoudurier> that's painful though [02:34:12] <bcoudurier> anyway I'm off [02:34:14] <bcoudurier> see you guys [02:44:41] <Kovensky> [flv @ 0xbe9d20]Estimating duration from bitrate, this may be inaccurate <-- what about the 'duration' metadata header? [02:52:00] <hyc> Kovensky: yeah, that always bothered me too [02:52:23] <hyc> but looking at the actual code, it doesn't seem to matter [02:57:11] <hyc> the cause is the av_has_duration() function [02:57:25] <hyc> it looks for a duration in each individual stream (audio or video) [02:57:50] <hyc> and it ignores whatever duration is recorded by the container (which is where the metadata duration got stored) [02:58:44] <hyc> the comment in av_has_duration is "Returns TRUE if the stream has accurate duration in any stream." [02:58:51] <hyc> what is "accurate"? how accurate? [03:16:24] <ramiro> how do I tar cfvj some/long/path, but when I extract the file it outputs to "path" instead of "some/long/path"? [03:25:44] <ramiro> got it: tar cfvj x.tar.bz2 -C some/long path [03:38:18] <BMintern> hi, i'm in the process of writing a fade filter for libavfilter. the problem is that i don't know a whole lot about working with yuv/rgb formats. i feel like if i was fading in the rgb space i would scale each color down to 0. working in the yuv space, however, all i've come up with is scaling y down to 0. obviously this is going to have 2 separate effects. which would be correct? [03:40:39] <Dark_Shikari> y to 0, u to 128, v to 128 [03:41:44] <BMintern> thank you [03:42:34] <relaxed> BMintern: did you ever get that overlay working? [03:42:59] <BMintern> yes, the "problem" was that i was using a 16-bit png instead of an 8-bit one [03:43:08] <BMintern> converting the png to 8-bit fixed the problem [03:43:16] <BMintern> probably a bug that ffmpeg can't handle 16-bit pngs? [03:53:51] <Dark_Shikari> more likely a missing feature [03:56:18] <Compn> Dark_Shikari : michael wants you to report bugs instead of just complaining about them :P [03:56:21] <Compn> ehe [03:56:36] <Compn> i reported a bunch of bugs about unsupported image formats and some poor soul implemented all of them [03:56:47] <Compn> poor kostya :D [04:01:42] <BMintern> thanks Dark_Shikari, that was perfect [04:02:05] <BMintern> i was stupid initially and didn't realize that the value was in the range [255, 0], but i figured it out [04:02:50] <BMintern> i'm happy to announce that i just finished a simple fade filter for libavfilter, i'll be sending a patch to ffmpeg-soc [04:08:42] <relaxed> BMintern: port yadif next :) [04:09:18] <BMintern> this will be my first ever code contribution to open source. i'm pretty satisfied with what i've done so far :) [04:10:02] <relaxed> yeah, that's great. [04:10:35] <hyc> he's on the road to a lifetime addiction :P [04:11:13] <Dark_Shikari> welcome to the club [04:12:04] <BMintern> well i have some (poorly-) paid work that i'm doing to process videos automatically, and i was like, "wtf, ffmpeg doesn't have fade?" [04:12:20] <BMintern> after i saw the "how to create your own filter" documentation, it looked like something i could do [05:13:57] <av500> the real dodo: http://www.bbc.co.uk/blogs/radiolabs/2009/10/realmedia_an_update.shtml [05:32:50] <astrange> should 'ffmpeg -i x -vpre veryslow -vcodec libx264' work? it doesn't [05:32:55] <astrange> vpre has to go after vcodec [05:34:56] <Dark_Shikari> astrange: is there an easy way to make it work? [05:36:24] <astrange> store the preset string and only read presets right before opening the encoder [05:36:44] <Dark_Shikari> would work [05:37:21] <astrange> hmm if you did -vpre x -vpre y and they didn't set all the same options behavior would change slightly [06:28:09] <wbs> hyc: had time to look at the patches I sent to the rtmpdump list? [06:28:26] <hyc> wbs: which ones? [06:28:53] <wbs> I sent 4 separate patchds on march 28 [06:29:08] <hyc> hmm. don't remember them, lemme check the archives [06:29:08] <wbs> three of them are quite trivial, the fourth perhaps needs discussion [06:31:35] <hyc> strange, I never got them. reading the archive now. [06:32:44] <wbs> weird, perhaps some spamfilter doesn't like me [06:33:10] <hyc> possible I guess [06:33:18] <hyc> ok, makefile patch, ok. [06:33:29] <hyc> you forgot DESTDIR on INCDIR but I'll fix that [06:34:09] <hyc> duh, destdir is already there, never mind [06:34:21] <KotH> salut [06:34:28] <kshishkov> shalom [06:34:34] <merbzt> priviet [06:34:41] <kshishkov> hej (: [06:34:44] <pJok> buenos noches [06:35:26] <hyc> hmm, you really think we need to check for the pkgconfig directory to exist? [06:35:31] <hyc> seems odd, but whatever... [06:35:32] <pJok> i hate this alternative route from kävlinge to malmö [06:35:45] <pJok> no cell signal [06:36:07] <wbs> hyc: yes, in my case, I choose to install to a completely nonexistant directory, e.g. /home/foobar/localstuff/rtmpdump [06:36:18] <hyc> right ok [06:37:52] <hyc> seektime/stoptime log - oops. left over from when they were doubles. [06:38:37] <wbs> yeah, one wouldn't expect a crash due to that one :-) [06:38:39] <kshishkov> pJok: here cell signal is not always present on major routes [06:40:38] <pJok> this is at least not a major route [06:41:08] <kshishkov> and "cell signal booster" is something not heard of completely [06:41:08] <pJok> its used by freight trains normally to go around lund [06:41:45] <hyc> wbs: hmm, I thought I just copied this command sequencing from the ffmpeg rtmpproto.c [06:41:56] <hyc> and I thought folks had already tested that against wowza [06:42:15] <wbs> the one i rtmpproto.c worked, yes, I haven't compared them [06:42:28] <hyc> frankly it made no sense to me. since this is at the initial connection, there should not be any streams existing yet [06:42:29] <av500> kshishkov: see, they even have freight trains with cell coverage :) [06:42:44] <wbs> but doing first createstream, then removestream, perhaps isn't sensible [06:42:46] <pJok> hehe [06:43:11] <pJok> av500, the new standard for rail signalling actually uses gsm-r ;) [06:43:13] <wbs> but the problem at least seems to be that we're waiting for a reply to the createstream, and if sending removestream, fcpublish, createstream all at once, we just ge a reply to the first one [06:43:51] <wbs> perhaps they should be chained so that only one is sent at a time, waiting for the reply to that and then proceeding with the next one [06:43:53] <hyc> wbs: I understand. but that's a server bug [06:44:12] <kshishkov> av500: I suspect that even their freight trains are more comfortable than ours [06:44:15] <hyc> normal flash clients and servers pipeline multiple messages at once. (Adobe) [06:44:54] <hyc> anyway, this makes no sense. ffmpeg rtmpproto.c also sends all 3 messages at once. [06:45:35] <hyc> oh, crap. in rtmpproto.c "hack for Wowza, it does not send result for release and publish calls" [06:46:05] <hyc> sounds to me like that comment is slightly incorrect then [06:46:14] <hyc> every invoke is tagged with a command counter [06:46:30] <kshishkov> and its maintainer was lazy and has not added keeping server version to allow better hacks [06:46:52] <hyc> and every result is tagged with the same number, so that results can be associated to their requests. [06:47:33] <hyc> so if in fact it is hanging waiting for a reply to CreateStream, which would be request #3 here, then that means woza sent a reply to #1 or #2 [06:49:33] <hyc> ah, except now I see that rtmpproto is sending them with hardcoded command numbers [06:49:44] <hyc> grumble... [06:52:13] <hyc> I guess I need to see a real Adobe client publishing to a real Adobe server [06:52:26] <hyc> this sequence of events looks all wrong [06:53:02] <hyc> (it works against rtmplite, but rtmplite only cares about the FCpublish and createstream [06:53:12] <hyc> it doesn't have a handler for releasestream) [06:53:45] <wbs> ok.. I don't have any such server to test with, unfortunately, but you should be able to use e.g. oflademo from red5 as client - that'd use adobe's routines for these things from within flash, right? [06:55:14] <hyc> dunno will look around [07:04:31] <kshishkov> I think you can always ask red5 devs for cooperation [07:08:14] <hyc> I guess. found this http://osflash.org/pipermail/red5commits_osflash.org/2007-March/001343.html they implemented these but they're no-ops [07:09:45] <wbs> hyc: sure that this is a wowza bug and not an intended protocol feature, btw? i.e., the server is allowed to only send a result to the last invoke, if it doesn't have anything else to say about the previous invokes [07:10:35] <kshishkov> could be gray area [07:12:43] <kshishkov> maybe transaction IDs are the same? [07:14:14] <hyc> no, I increment a counter on every invoke, they're all unique [07:14:19] <hyc> found this [07:14:30] <hyc> http://whispercast.org/trac/browser/trunk/whisperstreamlib/rtmp/rtmp_protoc… [07:14:42] <hyc> looks like FCPublish gets no reply on success [07:14:43] <kshishkov> official crap says each call should be responded [07:20:20] <wbs> hyc: what about this one, then? http://albin.abo.fi/~mstorsjo/check-txn.patch [07:23:41] <hyc> heh, no that won't do [07:24:02] <wbs> why not? [07:24:12] <hyc> AV_erase can be called for other reasons, so the list will not have a predictable number of entries [07:25:02] <hyc> are you assuming that getting one reply means all previous txns are resolved? [07:25:10] <hyc> I don't think that's valid [07:25:44] <wbs> ok, but the current code, doing methodInvoked = methodCalls[0] without checking which transaction actually was responded to, is that valid? [07:26:41] <wbs> shouldn't you then keep track of which transaction number each item in methodCalls had, and find the matching one? [07:26:47] <hyc> good question. this used to fail all the time in 1.x [07:29:22] <hyc> ah, some "results" come back with a txn of zero, regardless of the original request number [07:29:42] <hyc> that's why e.g. the __pnbwdone handler has to search for the request to erase [07:29:47] <hyc> __onbwdone [07:29:58] <kshishkov> __pwndone? [07:30:04] <hyc> typo [07:30:16] <hyc> this whole protocol sucks [07:30:25] <kshishkov> I know [07:30:38] <kshishkov> at least they made extra-sucky versions too [07:30:38] <hyc> took me days to figure out why onbwdone was corrupting the result queue... [07:31:58] <hyc> and look at play and publish - their "result" isn't a result message at all, it's an onStatus message [07:32:59] <wbs> hyc: that patch I showed above should at least handle that, if the transaction id is 0, we don't remove any method calls. the removing of skipped calls should perhaps be moved to within _result, though [07:34:12] <hyc> anyway, your patch won't fix the hang, since we're looking for an actual result that corresponds to the createStream request [07:34:22] <hyc> just erasing all the queued requests won't fix that [07:34:51] <wbs> no, that was just misunderstanding the code earlier [07:35:19] <wbs> I thought the server reply was for releasestream, but that was only the librtmp code _assuming_ the reply belonged to that invoke, through methodCalls[0] [07:35:46] <hyc> right [07:35:54] <wbs> the patch I showd does fix the hang, I actually do check my patches before I submit them [07:36:10] <wbs> I also valgrinded it to see that I didn't do anything else stupid [07:36:33] <hyc> but I don't want to poke and prod at the code until I know what is actually supposed to happen on the wire [07:36:52] <hyc> if releaseStream is normally a non-replied request, we can account for that without any other hacks [07:38:33] <wbs> yes, that seems to be the case, releaseStream and FCPublish aren't replied at all - if I comment out the SendCreateStream, I get no reply at all [07:39:14] <hyc> ok, then just change SendReleaseStream [07:39:22] <hyc> when it invokes RTMP_SendPacket [07:39:25] <hyc> change true to false [07:39:33] <hyc> and it won't go into the result queue [07:39:44] <hyc> do the same for SendFCPublish [07:39:47] <hyc> and it should all be fine [07:40:50] <wbs> ok, that's one solution, but the whole mess of just guessing which transaction was replied is giving me bad vibes - if the server CLEARLY says that "this is a reply to your transaction #4", then there should not need to be any guessing about which method the reply belongs to [07:41:08] <hyc> yes, true [07:41:17] * kshishkov thinks that his approach when client just cared for the first few invokes and mostly ignored results for the latter is not a very bad thing [07:41:36] <hyc> lol [07:42:16] <hyc> wbs: but you have to see some packet traces to realize [07:42:30] <hyc> more results come back with 0 / invalid txn ID than not [07:42:56] <wbs> yes, but if the txn ID is set, then I think that should be believed to be true at least? [07:43:21] <hyc> wbs: it doesn't gain anything [07:43:32] <hyc> if you get replies out of order, you're still hosed. [07:44:02] <wbs> yes, but it would gain you not needing to know whether releasestream and fcpublish are replied normally or not [07:44:17] <wbs> but anyway, I'll just fix it by assuming that they're not replied [07:44:36] <wbs> which is fine for me but perhaps breaks things for someone else [07:45:04] <hyc> which is why I'm googling to see what Adobe really expects here [07:46:00] <kshishkov> wireshark is your best friend then [07:48:28] <wbs> hyc: http://albin.abo.fi/~mstorsjo/no-reply-releasestream-fcpublish.patch works for me, too [07:49:29] <hyc> ok [07:49:39] <hyc> that's probably what I'll commit [07:49:45] <hyc> going to keep digging for a little while... [08:02:51] <hyc> I'm not convinced those requests are even necessary... [08:03:10] <hyc> most example source code I see only does createStream then publish [08:03:15] <hyc> no FCpublish [08:03:30] <hyc> no releaseStream [08:06:06] <wbs> hyc: that works for me, too [08:12:55] <hyc> http://www.rtmpd.com/browser/trunk/sources/thelib/src/protocols/rtmp/basert… [08:13:10] <hyc> FCPublish gets an onStatus response, not a _result [08:13:38] <hyc> releaseStream might get a result [08:13:41] <hyc> sigh [08:13:49] <wbs> with my version of wowza, it doesn't get on onStatus response either [08:15:55] <hyc> I'm going to drop the releaseStream request [08:16:07] <hyc> it appears to only be needed if there was already an active stream [08:24:57] <hyc> wireshark transcripts http://forum.telestream.net/forum/messageview.aspx?catid=45&threadid=4178&e… [08:25:03] <hyc> too bad they're only of wowza [08:44:44] <CIA-1> ffmpeg: astrange * r22740 /trunk/libavcodec/h264.c: [08:44:44] <CIA-1> ffmpeg: H264: Copy h264dsp when creating new slice threads [08:44:44] <CIA-1> ffmpeg: Fixes slice multithreading (broken in r22565) [08:44:44] <CIA-1> ffmpeg: Fixes issue1815 [08:47:44] <av500> peloverde: [aac @ 0x8b9a1b0]Transition from an ONLY_LONG or LONG_STOP to an EIGHT_SHORT sequence detected. If you heard an audible artifact, please submit the sample to the FFmpeg developers. [08:48:49] <astrange> did you seek? [08:48:53] <peloverde> That warning raises three default questions: [08:48:59] <peloverde> a) Did you seek? [08:49:17] <peloverde> b) was it on the first frame (that's a false positive that needs to be cleaned up) [08:49:27] <peloverde> and c) was there an audible artifact? [08:50:24] <av500> al03_48.mp4 [08:50:28] <av500> no seek [08:50:47] <av500> no on 1st frame, after 1s or so [08:50:56] <peloverde> Ahh al03_48.mp4 [08:50:59] <av500> :) [08:51:22] <peloverde> the al03* series was created to test this very condition [08:52:33] <peloverde> This transition is both illegal and has a normative behavior that isn't throwing up your hands and walking away (yes i know that sounds like an oxymoron) [08:53:04] <peloverde> So technically al03* isn't actually AAC because it contains forbidden syntax ;) [08:53:10] <av500> ok, I understand [08:53:20] <av500> I thought all these streams are supposed to decode ok [08:53:37] <peloverde> That stream is the exception [08:53:54] <av500> I picked it randomly :) [08:54:03] <peloverde> Also PNS streams have a special conformance tool and can't be compared by normal means [08:54:07] <hyc> damn, av500 is lucky [08:54:22] <KotH> av500: you should play lotto :) [08:54:22] <hyc> quick, pick 6 numbers between 1 and 57 for me [08:55:31] <av500> KotH: if I write al03_48.mp4 on the lotto thingy, u think I win? [08:56:00] <peloverde> I really should add a field to my fancy table <http://wiki.multimedia.cx/index.php?title=AAC_Conformance_Vectors> for that [08:56:01] <KotH> who knows... but it's worth a try [08:56:27] <peloverde> But I still think maybe it's time to just implement that windowing condition properly [08:56:37] <peloverde> I really don't think the overhead should be that significant [08:57:14] <hyc> and that "please submit a sample" message clearly needs to be extended: "unless you were seeking when this message occurred, or unless this was the very start of a stream, or unless you're playing a bogus stream, or your nick is av500" [08:57:41] <Dark_Shikari> lol [08:57:47] <peloverde> Also all the AAC streams from the MPEG4 file format conformance suite are basically broken too [08:58:38] <peloverde> They all signal AOT-1 rather than AOT [08:59:30] <peloverde> They also are inconsistent with the spec wrt header formats :/ [08:59:52] <Dark_Shikari> :/ [09:00:09] <Dark_Shikari> on an unrelated note, some good news. apparently google wants to pay to have the gpl h264 decoding asm relicensed [09:00:27] <KotH> of ffmpeg? [09:00:40] <KotH> interesting [09:00:41] <merbzt> Dark_Shikari: to lgpl ? [09:00:46] <av500> bsd? [09:01:03] <astrange> apparently? [09:01:11] <Dark_Shikari> yes [09:01:12] <Dark_Shikari> lgpl [09:01:12] <av500> or the GooglePublicLicence? [09:01:37] <Dark_Shikari> astrange: apparently as in "fbarchard emailed me about it, following up a previous discussion" [09:03:11] <peloverde> Dark_Shikari, They are looking for a scaler [09:03:27] <peloverde> be sure to let them know that libswscale is for sale [09:03:35] <Dark_Shikari> I thought vso already paid? [09:04:09] <merbzt> lets sell it twice [09:04:13] <Dark_Shikari> lol [09:04:28] <peloverde> I could have sworn that the x86 asm was still GPL [09:04:37] <merbzt> we can just change the license back to gpl [09:04:39] <Dark_Shikari> well, it's in the process of being fixed [09:04:42] <Dark_Shikari> due to the payment of $20k [09:04:58] <merbzt> peloverde: one file is still not lgpl [09:05:01] <av500> merbzt: cron job? [09:05:16] <thresh> :) [09:05:32] <av500> 4) profit! [09:05:33] <merbzt> av500: something like that yeah [09:06:35] <astrange> does swscale have enough documentation for people to get the details of yuv colorspaces right? [09:06:55] <av500> so patches get discussed, applied, paid and relicenced? [09:07:08] <peloverde> So who owns the last file? [09:07:25] <merbzt> peloverde: some asian semiconductor company [09:07:32] <peloverde> ahhh [09:07:36] <merbzt> dead end [09:07:47] <merbzt> so it's getting rewritten [09:08:44] <peloverde> ahh, who is working on that? [09:09:09] <merbzt> I think we had 3 possible candidates [09:20:48] <kshishkov> astrange: we have, I can write you a quick spec what to reimplement [09:21:58] <kshishkov> for example, I've tried to rewrite that x86 yuv2rgb but it's not that easy for me with GCC inline asm [09:23:29] <CIA-1> ffmpeg: cehoyos * r22741 /trunk/libavformat/asf.c: [09:23:29] <CIA-1> ffmpeg: Remove superfluous space from a conversion table. [09:23:29] <CIA-1> ffmpeg: Patch by Anton Khirnov, wyskas gmail [09:24:35] <astrange> i meant "does it tell you how to map AVColorSpace to an sws context setting" [09:25:07] <astrange> looks like no, none of the SWS_CS_* are used except SWS_CS_DEFAULT (601) [09:25:16] <kshishkov> peloverde: thanks for your state-of-ffaacenc mail, it's fun to read [09:25:32] <av500> peloverde: al_sbr_cm_48_[4|5].mp4, what is the expected channel ordering? [09:26:18] <peloverde> The channel ordering may be wrong, it fails my test harness due to an ordering mismatch [09:26:22] * bilboed-pi hugs people for updating APIchanges :) [09:26:34] <peloverde> superdump redid the channel ordering most recently [09:27:18] <av500> I have not tried yet, I was just wondering [09:27:45] <astrange> so it handles AVColorRange because that overlaps with pixel formats, but not really AVColorSpace and not really AVChromaLocation [09:27:54] <peloverde> The channel ordering issue is honestly something I haven't paid enough attention to [09:28:28] <merbzt> IIRC the channel order is correct now [09:28:36] <merbzt> or consistent [09:28:44] <peloverde> I figure that's an area where people seem to have strong enough opinions that they will fix it themselves [09:29:38] <av500> I see some 5.1 AAC streams return actx->channel_layout = 0x3F, but others return 0x00... [09:30:12] <av500> 0x3F and the WAVEFORMAT defines ordering makes sense to me [09:30:17] <av500> defined [09:30:26] <peloverde> PCE based vs non-PCE based? [09:30:56] <av500> probably, I looked into aac.c and found a place where it sets the layout to 0 [09:31:13] <av500> so, if it 0x00, the decoder cannot tell? [09:31:20] <peloverde> For PCE based configurations we get stuck with this weird annex in 13818-7 that seems difficult to map onto sane channel orderings/spatial configurations [09:32:16] <peloverde> The PCE is the 3rd biggest flaw of the AAC bitstream format IMHO [09:32:32] <Dark_Shikari> 3rd? [09:32:35] <Dark_Shikari> what are 1st and 2nd? [09:32:48] <peloverde> #1) Implicit PS [09:33:01] <peloverde> you can always find implicit SBR on the first frame [09:33:18] <peloverde> you can't find implicit PS until SBR processing actually gets turned on [09:33:37] <peloverde> So your channel count may spontaneously increase mid-decode [09:33:59] <Dark_Shikari> lol [09:34:14] <peloverde> #2) http://git.ffmpeg.org/?p=ffmpeg;a=commit;h=7c9d74801ae7281b2a880806d9e7a3bb… [09:34:53] <Dark_Shikari> lol [09:34:53] <kshishkov> maybe it would be better to hide 5.1 DTS inside stereo AAC instead [09:34:54] <peloverde> Zero sized codebook sections are both legal and create havoc [09:37:54] <peloverde> The PCE code should probably sniff if the arbitrary channel order matches something sane [09:38:57] <merbzt> peloverde: how depressed do you get when you work on aac ? [09:39:08] <av500> peloverde: ok, but e.g. al_sbr_cm_48_4.mp4, is it FL/FR and BL/BR? [09:39:26] <av500> or FL/FR and CTR and LFE? [09:40:24] <kshishkov> merbzt: try amr-nb spec, it's quite depressing as well [09:41:30] <peloverde> It's supposed to be deciphered according to this chart as far as I can tell: http://www.iec.ch/cgi-bin/getcorr.pl/yab/iso/isoiec13818-7-cor1%7Bed1.0%7De… [09:41:33] <peloverde> Annex G [09:43:00] <merbzt> atrac3 had a juvel in the bitstream syntax also [09:43:12] <peloverde> The actual PCE tells you: front, side, back or LFE [09:43:28] <peloverde> As far as I can tell no other information id provided [09:43:38] <merbzt> first we say how many subbands we have [09:44:02] <merbzt> then we can override that number later in the bitstream [09:44:35] <peloverde> (err Annex H, not G, the picture in the Cor) [09:45:02] <av500> I see the picture [09:45:04] <av500> :) [09:45:35] <av500> but that is an "example" for 22.2 channels, no? [09:46:33] * av500 larts MP4 for giving him a channel count of 0... [09:46:44] <peloverde> See the first paragraph on the first page [09:47:01] <peloverde> Also according to the PCE all those channels are front [09:47:28] <peloverde> Everything except the LFE is tagged front on that stream [09:49:46] <peloverde> al07* tags one channel pair back [09:50:11] <peloverde> Though I think al07* was finally removed from conformance [09:50:45] <peloverde> I'm sorry, I'm thinking of al15* [09:50:49] <peloverde> al07* is ok [09:51:17] <av500> peloverde: thx for the insights, but I doubt I will go at great length there. my users will prolly have stereo and 5.1 only :) [09:52:24] <peloverde> They might have some mono [09:52:42] <merbzt> av500: is channel_layout a nice field for you ? [09:54:12] <peloverde> I would say that PCEs don't see much use int he wild for channel configurations that can otherwise be specified but I was proven wrong on aac-main yesterday [09:54:19] <av500> peloverde: yes, but mono is most trivial to support :) [09:54:49] <av500> merbzt: it would be if the number of bits set inside it would match the channel count [09:55:06] <merbzt> it should [09:55:16] <merbzt> if not then the decoder is borked [09:55:26] <av500> as I said, for some aac, ch=6 and layout=0 :( [09:55:46] <av500> but I am OK if =0 means "i dont know" [09:56:11] <peloverde> It is a bit of a "I don't know" [09:56:25] <av500> like "I don't"? [09:56:35] * kshishkov remembers theoretical MoosePack parser which should do almost everything decoder does except actual synthesis [09:57:03] <peloverde> This "file doesn't know because the PCE is a piece of crap" [09:58:37] * av500 files that under "i dont know" [09:59:16] <peloverde> The PCE really seems to have opened a door to add certain reconfiguration features that they never added [10:03:49] <peloverde> How does your previous AAC decoder handle such files? [10:27:25] <av500> peloverde: no idea [10:28:50] <av500> peloverde: btw, the al_sbr_cm_48_[1|2|4|5] samples return a good channel layout, only 5.1 is 0 [10:32:36] <peloverde> av500, That makes sense, only the 5.1 file uses a PCE [10:32:42] <av500> ok [10:33:49] <peloverde> Also thanks for reminding me how much I hate the PCE :) [10:35:22] <superdump> av500 , peloverde : if there are channel ordering issues, it's probably because the spec's definitions of channel orders are confusing [10:35:29] <superdump> the maps can easily be changed [10:35:33] <superdump> i did the best i could :) [10:35:38] <peloverde> You did well with it [10:35:42] <peloverde> the PCE is a mess [10:35:44] <av500> superdump: no, actually it looks ok to me [10:35:58] <superdump> but one of you said that there was a conformance issue due to channel ordering [10:36:06] <superdump> is that with a layout = 0 case? [10:36:37] <peloverde> There are two issues, I never updated my conformance scripts for the channel order fixes [10:36:44] <superdump> oh [10:37:12] <peloverde> And PCE based configs spit out actx->channel_layout = 0x00 [10:37:16] <superdump> bilboed-pi: yeah, stefano is good with that :) [10:37:46] <superdump> well, maybe we could do some kind of layout matching thing for PCEs...? [10:37:53] <peloverde> I was thinking about that [10:37:55] <superdump> or maybe that would just add to the nightmare :) [10:38:12] <peloverde> Then i wondered how often the PCE is used for common layouts in the wild? [10:38:31] <peloverde> Most of the use case of the PCE is that the layout is strange and uncommon [10:38:40] <superdump> well, the ideal usecase [10:39:14] <superdump> but i would be interested to see if there are actually strange/uncommmon layouts for which the pce is used properly [10:39:29] <superdump> maybe a pce is used because people are confused by the specified channel layouts [10:39:41] <peloverde> All the 48 channel files use the PCE [10:39:47] <superdump> maybe it's used because it's there and so people think it should be used [10:39:52] <superdump> well, they have to don't they? [10:40:02] <peloverde> indeed [10:40:02] <av500> peloverde: 48 ch files in the wild? :) [10:40:07] <superdump> if they want any kind of specified layout [10:40:28] <superdump> i don't recall precisely, but only up to 8 channels have channel configs, right? [10:40:37] <superdump> the rest are not defined [10:40:41] <peloverde> indeed: 1,2,3,4,5,5.1, and 7.1 [10:40:46] <peloverde> IIRC nero, ct, and quicktime/itunes don't generate PCEs [10:40:52] <superdump> good [10:41:06] <av500> I bet they refuse to encode 48 channels as well [10:41:14] <peloverde> probably :) [10:41:29] <superdump> but that probably means that <weird encoder here> does <weird pce stuff> [10:41:35] <peloverde> At some point I need to do an encoder feature matrix [10:41:52] <superdump> i intend to read your ffaac summary now [10:41:54] <superdump> i'm intrigued [10:42:00] <av500> superdump: for me it is not an issue to treat layout=0 as "I dont know, assume something" [10:42:04] <superdump> it is something i would really like to improve so we can ditch faac [10:42:13] <superdump> but i have no time [10:42:17] <superdump> i'm knackered as it is [10:42:27] <superdump> av500: ok :) [10:42:51] <superdump> av500: then i guess it's as good as it can be right now if the ones with layouts are mapped correctly for you [10:43:06] <superdump> well, short of best matching for pce layouts [10:43:08] <peloverde> superdump, Also some of the 5.1 conformance files request 5 front channels [10:43:11] <peloverde> :) [10:43:16] <superdump> om... [10:43:21] <av500> peloverde: which ones? [10:43:22] * superdump head in hands [10:43:30] <av500> m) [10:43:56] <peloverde> al15* [10:44:12] <peloverde> al_sbr_cm_48_5.1 [10:45:20] <peloverde> al15* I believe is the stream that was removed from the conformance suite most recently (for a different reason) [10:45:40] <peloverde> I would try something on mp4-tech for al_sbr_cm_48_5.1 but no one seems to care anymore :( [10:45:58] <peloverde> maybe we need to get moving on the usac bandwagon asap? [10:46:07] <CIA-1> ffmpeg: cehoyos * r22742 /trunk/libavformat/utils.c: [10:46:07] <CIA-1> ffmpeg: Probe aac codecs for CODEC_ID_PROBE. [10:46:07] <CIA-1> ffmpeg: Patch by Joakim Plate, elupus ecce se [10:46:36] <superdump> ok, adding flexibility may be nice, but making things stupidly complicated for decoders to do correctly is not nice [10:47:01] <superdump> remind me, what is usac? [10:48:16] <superdump> "causing the FAAC method [10:48:18] <superdump> to shit the bed." [10:48:20] <superdump> rofl [10:48:22] <superdump> :) [10:48:40] <superdump> peloverde: i'd like to meet you and buy you a drink someday [10:48:58] <superdump> i have no idea when i'll swing by ohio though [10:49:14] <superdump> NY and CO, yes [10:49:24] <superdump> OH... not so much [10:50:19] <superdump> why is "it's what the reference encoder uses" a con? [10:50:23] <superdump> if it works well... [10:52:48] <superdump> peloverde: ideally i would say implement the ones that are useful for speed/quality tradeoff and make them selectable [10:53:11] <superdump> that is, if an algorithm is both slower and worse quality than something else, don't implement it [10:56:52] <superdump> it would be quite shiny to have a FOSS implementation of an AAC encoder beat the shit out of all other AAC encoders, as x264 does for h.264 [10:59:21] <pJok> wouldn't that require people actually start tackling ffaac rather than just talk about how bad it is? ;) [11:00:24] <superdump> yes [11:00:25] <siretart> superdump: FYI, related link: http://www.omgubuntu.co.uk/2010/03/aac-codec-to-be-removed-from-ubuntu.html [11:00:31] <superdump> it would [11:00:42] <superdump> it would need someone with the time and interest to work on it [11:00:43] <peloverde> USAC is Unified Speech and Audio Coding [11:01:08] <peloverde> It's basically CELP + AAC + Arithmetic coding pushed together into a nice little package [11:01:53] <peloverde> I've managed to distract myself from it with paid gigs on decoder parts [11:02:43] <peloverde> Dark_Shikari thinks he can ind a big pile of money but I question how far I can take it on my own [11:03:22] <superdump> is it used in the wild for anything? [11:03:39] <peloverde> It's still under development [11:03:43] <superdump> siretart: mmm, it'd be nice if canonical took an interest and funded its development [11:03:45] <peloverde> It should be very close to being done [11:03:51] <superdump> peloverde: then why is it interesting? [11:04:11] <superdump> munging CELP into AAC... urgh [11:04:14] <superdump> i know it's in the spec [11:04:15] <superdump> but urgh [11:04:41] <peloverde> superdump, It's interesting because the players are still engaged [11:04:53] <peloverde> So when I find these nasty inconsistencies they may still be fixable [11:04:59] <superdump> i see [11:05:12] <superdump> interesting from a spec reviewers perspective [11:05:43] <peloverde> It basically seems to be the Subpart 4 do over 10 years later [11:05:55] <peloverde> I have to head out, adios guys [11:12:41] <superdump> t'ra peloverde [11:21:41] <twnqx> wow, even strange codecs like vp6f work [11:21:46] <twnqx> <3 ffmpeg [11:44:41] <av500> lol http://marc.info/?l=openbsd-ports&m=126805847322995&w=2 [11:46:37] <nfl> hi how is an rtp depacketizer for a static payload format different from that of dynamic ones? [11:47:03] <merbzt> the former is more easy to implement [11:48:22] <CIA-1> ffmpeg: benoit * r22743 / (trunk trunk/tools): Add .version and graph2dot to ignore list. [11:48:30] <wbs> i guess the (de)packetization can be as easy/hard, but with dynamic payloads, there can be more configuration through sdp parameters [11:55:42] <twnqx> are there plans for a dts encoder? [11:56:51] <merbzt> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010#DTS_En… [11:56:57] <merbzt> we have code for it already [11:57:01] <merbzt> in the soc repo [11:57:58] <merbzt> twnqx: good enough answer ? [11:58:45] <twnqx> yes :] [11:58:56] <twnqx> thanks a lot, looking forward to it [12:04:32] <superdump> it might not be any good though if it doesn't get tuned [12:09:44] <merbzt> superdump the party pooper [12:09:52] <merbzt> it's gonna be awesome [12:11:02] <mru> http://news.ycombinator.com/item?id=1231454 [12:11:13] <mru> everybody upvote [12:11:16] <mru> autoconf bashing [12:11:51] * thresh thinks it's more of a *bsd people bashing [12:11:54] <pross-au> what about qmake bashing? [12:13:11] <mru> thresh: the enemy of my enemy is my friend [12:13:14] <mru> at least on facebook [12:15:00] <merbzt> on what ? [12:16:48] <pross-au> Seems to be more about the 'Linux versus Irrelevant Operating Systems' crusade, rather then autoconf specifically [12:18:17] <mru> he has a point [12:18:30] <mru> checking for versions when you should be checking a feature is wrong [12:21:26] <pross-au> we're talking GNU features though [12:22:04] <mru> not really [12:28:50] <nfl> i'm really sorry, the electricity went out [12:28:56] <nfl> wbs: you were sayin? [12:29:06] <mru> did you catch it? [12:29:17] <mru> runaway electricity can be dangerous [12:29:27] <nfl> under control now ;) [12:29:30] <wbs> nfl: didn't say anything else than what you probably saw, if you saw me say anything at all :-) [12:29:42] <nfl> ok [12:29:54] <pross-au> Hehe. No more free solaris [12:30:03] <wbs> that is, the only difference that I know about, is that static payloads have fixed payload id:s, while dynamic ones are taken from a pool >= 96 and configured through sdp lines [12:30:11] <pross-au> "I feel sorry for the person that this affects" ... :D [12:30:26] <wbs> and therefore, the dynamic ones probably can be configured much more flexibly [12:30:54] <CIA-1> ffmpeg: cehoyos * r22744 /trunk/ (52 files in 5 dirs): [12:30:54] <CIA-1> ffmpeg: Replace all occurences of PKT_FLAG_KEY with AV_PKT_FLAG_KEY. [12:30:54] <CIA-1> ffmpeg: Patch by Jean-Daniel Dupas, devlists shadowlab org [12:31:45] <merbzt> nfl: is this real ? http://www.bombay-connection.com/en_GB/site/page/1/releases [12:33:19] <nfl> merbzt: dunno sorry [12:34:05] <merbzt> nfl: where you even born then ? :) [12:37:11] <nfl> merbzt: no actually ;) [12:38:08] <nfl> dont chide me but am not much into music anyway :) [12:43:36] <mru> http://news.ycombinator.com/item?id=1230890 [12:43:50] * mru likes the first comment [12:44:58] <kshishkov> maybe some company will buffer for few more years before it notices one of the clients is gone [12:45:08] <nfl> lol [12:45:33] <av500> they have clients buffered [12:47:24] <nfl> i see that rtpdec_h263.c doesn't define parse_sdp_a_line. does this have anything to do with its payload type being static? [12:47:48] <wbs> nope, there are no fmtp parameters to parse out for h263 [12:48:07] <wbs> h263 nowadays do use a dynamic payload (where it has a different format than in the deprecated static payload format) [12:48:37] <nfl> hmm [12:56:10] <CIA-1> ffmpeg: michael * r22745 /trunk/libavformat/ (options.c utils.c avformat.h): Add AVFMT_FLAG_NOFILLIN and AVFMT_FLAG_NOPARSE. [13:25:59] <av500> is there any 7.1 sample in mplayer samples? [13:26:12] <mru> probably [13:29:05] <av500> dts has some [13:29:57] <twnqx> pcm might have some too :P [13:30:21] <twnqx> dunno if those .m2ts were ever added to the samples collection, though [13:30:29] <mru> http://rainwarrior.thenoos.net/music/moon8.html [13:30:52] <av500> is that in 7.1? :) [13:31:03] <mru> yeah, the 8-channel NES [13:31:16] <mru> one bit per channel... [13:34:18] <kshishkov> you've typed ~176 bits in this channel [13:34:26] <kshishkov> and that's just last line [13:35:08] <mru> http://www.youtube.com/watch?v=ZaR4fsUeTVY [13:36:16] <nfl> is a static payload depacketizer also supposed to define an RTPDynamicProtocolHandler? or is there some other method? [13:41:51] <nfl> anybody there? or is just that stupid questions dont get answered? ;) [13:42:07] <kshishkov> repeat again, BBB should know the answer [13:42:26] <BBB> huh? [13:42:31] <nfl> here goes: is a static payload depacketizer also supposed to define an RTPDynamicProtocolHandler? or is there some other method? [13:42:48] <BBB> uhm... [13:42:50] * BBB goes think [13:42:52] <BBB> I think so [13:43:09] <BBB> lu_zero and luca abeni (no IRC) would know [13:43:25] <nfl> ok [13:44:19] <BBB> the name of the "dynamic" handler should be the same one as in AVRtpPayloadTypes in rtp.c [13:44:47] <nfl> hmm [13:47:57] <jai> read the source [13:48:17] <av500> cool, bits_per_raw_sample is "set by libavcodec", except when it is not..... /sigh [13:53:54] <mru> btw, someone's giving indians a bad name on the gsoc-mentors list... [13:54:14] <KotH> how? [13:54:25] <kshishkov> maybe it's indians themselves and somebody just carries that along [13:57:40] <kshishkov> you're quite lucky that foreign language classes in ex-USSR taught mostly to hate English, otherwise you'll get another batch of people not comprehending what you say [14:01:24] <jai> :| [14:06:00] <KotH> kshishkov: they do that still? [14:07:16] <thresh> they did not at least 10 years ago [14:07:35] <thresh> though i attended nice schools [14:08:09] * KotH knows that there was a time, when you could end up in jail, if you studied english [14:10:17] <av500> of course, image somebody writes instruction on how to build *the bomb* in that language! [14:11:46] <peloverde> I wish that rule applied to my high school english teachers [14:11:47] <BBB> wbs: hah, you're just early, I wanted to ask you to co-mentor already ;) [14:12:35] <wbs> BBB: :-) blame merbzt ;-) [14:12:54] <BBB> do you want to do it? [14:12:54] <KotH> peloverde: lol [14:13:13] <BBB> it's fun stuff, and then I can focus on mms/speech codecs [14:13:18] <BBB> (amrwb, for example) [14:13:52] <merbzt> BBB: I'm ahead of you already [14:13:56] <merbzt> by 5 minutes [14:14:18] <wbs> BBB: given a good project and good student, sure. :-) [14:14:27] <BBB> one of those online forums I used to visit has a really suitable smiley that would fit here [14:14:40] <CIA-1> ffmpeg: cehoyos * r22746 /trunk/libavcodec/h264enc.c: Fix likely typo in r15937. [14:15:49] <CIA-1> ffmpeg: jai_menon * r22747 /trunk/doc/ffmpeg-doc.texi: Fix a few typos/grammar nits from r22739. [14:16:17] <BBB> http://gathering.tweakers.net/global/smileys/worshippy.gif [14:16:18] <BBB> that one [14:16:25] <BBB> or http://gathering.tweakers.net/global/smileys/pompom.gif [14:16:36] <jai> also [14:16:38] <jai> http://ffmpeg.pastebin.com/N9AByizu [14:17:00] <jai> ^ problem with the post commit hook [14:17:03] <wbs> oh boy do I love filling forms where I'm not allowed to type my name properly ;P [14:17:35] <mru> you should anglify your name [14:17:46] <merbzt> hahah, you got the same problem as andoma [14:17:58] <wbs> yep [14:18:06] <mru> I've learned to live with it [14:18:32] <wbs> i mostly try with the native form first, but i'm quite used to just doing ö->o [14:18:35] <mru> to the point that the 7-bit version _is_ my official name in some places [14:18:44] <wbs> oh, that's an accomplishment :-) [14:20:04] <merbzt> my work collegue was in the Philippines last year, his name ThunstrÃ¶m got translated to Thunderstorm [14:20:12] <mru> nice [14:20:27] <merbzt> yeah, awesome [14:20:52] <wbs> living with a swedish name in finland isn't all that awesome all the time either - the finns don't find it that easy to write just given the name verbally [14:29:27] <kshishkov> wbr: try writing or at least properly pronouncing my name - in Russian or Ukrainian edition [14:30:05] <av500> "kshishkov" :) [14:30:31] <kshishkov> no (and it would be Polish version :) [14:30:52] <kshishkov> ask mru if he can remember it [14:31:31] <merbzt> K. Sergeiovich S. [14:31:53] <kshishkov> ies, that too [14:32:07] <av500> Ð. ÐšÐžÑÐºÐŸÑ [14:32:36] <kshishkov> that's Bulgarian ;) [14:32:43] <av500> Ð. ÐšÐžÑÐºÐŸÑ [14:32:51] <kshishkov> mine ends with "Ð²" [14:33:10] <av500> it was supposed to be serbian, but my cyrillic is beyond rusty [14:33:24] <av500> but u are right, sorry: [14:33:30] <av500> Ð. ÐšÐžÑÐºÐŸÐ² [14:35:34] <kshishkov> and guess why I'm mostly known as Kostya instead of correct "Konstantin" [14:35:51] <av500> â. â¹âââ±âŠâ [14:36:13] <kshishkov> first symbol seems correct [14:36:50] <av500> so google translator did well :) [14:38:45] <thresh> yeah, everyone fails to spell my name too [14:39:35] <kshishkov> there are still Chinese and Indians [14:39:49] <Compn> kshishkov : probably 'kostya' from ffmpeg commit nick ? :) [14:40:33] <kshishkov> Compn: good guess, now figure how I got that one in first place [14:41:02] <kshishkov> also meaning of Indian name "Kumar" in slang Russian usually corresponds to its bearer [14:49:12] <merbzt> jai: have you gotten your social-security number yet ? [14:49:38] <merbzt> the news has hit swedish press now [14:49:49] <jai> merbzt: the one about studera? [14:50:05] <mru> what news? [14:50:09] * mru missed something [14:50:17] <kshishkov> merbzt: for the record I got mine even before going to university. Not that it gives any security (especially social) [14:50:46] <merbzt> no, there is a 10 year old Indian project of giving each citizen over 15 years of age a "social security" number [14:51:21] <jai> merbzt: oh, everyone assumed that was vaporware :) [14:51:38] <merbzt> it's not [14:51:52] <merbzt> it has hit swedish press [14:51:54] <kshishkov> I'd rather call it KLZ anyway [14:51:55] <merbzt> must be true then [14:52:26] <nfl> i've posted the depacketizer to the soc-ml. please take a look [14:52:42] <jai> merbzt: the project is being handled by one of the local sweatshops here [14:54:43] <merbzt> in sweden we get ours by birth [14:55:21] <merbzt> jai: hows the application process going ? [14:55:25] <kshishkov> we get ours sometime after internal passports. In tax offices as you do [14:55:27] <jai> merbzt: oh, its over :) [14:55:45] <merbzt> jai: yeah but did you get accepted ? [14:56:05] <jai> merbzt: yeah, i'll be working with the comparch group at uwisc [14:56:44] <jai> btw, http://www.uidaicards.com/, for the coding scheme [14:57:16] <merbzt> the UK ?? I thought you where going to join the ranks of proud ffmpeg-swe devs [14:57:34] <jai> merbzt: they haven't processed my application yet :( [14:57:38] <jai> merbzt: chalmers that is [14:57:51] <jai> merbzt: and s/UK/US :) [14:58:07] <merbzt> omg [14:58:18] <kshishkov> merbzt: for the record, UK is subsidiary of Sweden. At least in FFmpeg development sense [14:58:25] <merbzt> but think about the timezones [14:58:35] <merbzt> kshishkov: true true [14:58:40] <jai> merbzt: i know, sucks bigtime :( [14:58:42] <av500> he can talk to peloverde and Dark_Shikari all day long [14:58:53] <merbzt> but think about the children [14:59:06] <merbzt> the children [14:59:09] <av500> merbzt: that is what prevents me going there! [14:59:16] <merbzt> :) [14:59:18] <kshishkov> merbzt: also I've heard thatt Johan III was king of Scotland as well [14:59:22] <jai> i'd much rather prefer chalmers, but apparently they get spammed by asian applicants each year, which kinda works against us :/ [14:59:53] <merbzt> jai: coz we don't charge for education ... [15:00:01] <kshishkov> jai: local universities are spammed by both asian and african applicants [15:00:47] <jai> merbzt: also, the place is awesome :) [15:01:03] <merbzt> indeed [15:01:54] <merbzt> everyday I go to work and I have to jump of the buss 2 stops before my regular stop because of the traffic I think of the awesomeness [15:02:39] <kshishkov> at least it goes [15:02:53] <av500> ok, understood, actx->bits_per_raw_sample is useless, it is av_get_bits_per_sample_format(actx->sample_fmt) that counts... [15:04:14] <jai> merbzt: i thought swedes prefer cycling :) [15:04:24] <merbzt> my bike got stolen [15:04:28] <kshishkov> jai: not if you compare them to Danes [15:04:34] <merbzt> and there still is icey outside [15:04:47] <merbzt> need to buy a new one [15:05:14] <kshishkov> and don't forget that Christopher Polhem invented a thing for you [15:05:27] <av500> merbzt: http://www.wendmag.com/blog/wp-content/uploads/ice-bike.jpg [15:05:28] <jai> av500: not really useless, if the container stores such information we could always remux it back [15:05:44] <av500> jai: right [15:05:59] <merbzt> nice helmet [15:07:28] <thresh> it is a moto helmet [15:07:55] <av500> then u need this I guess: http://www.iceroadracing.net/galleryfrench2/images/athiebault1.jpg [15:10:36] <kshishkov> merbzt: it should be better in three years for you - http://sl.se/templates/Page.aspx?id=8795 [15:11:00] <mru> kshishkov: never trust SL [15:11:10] <merbzt> kshishkov: thank you for the comforting words :) [15:11:46] <kshishkov> mru: why? [15:12:10] <mru> they lie to you [15:12:48] <kshishkov> do they close lines forever without any forewarning? [15:13:21] <av500> with ppl still inside? [15:14:21] <kshishkov> av500: if you think that somebody _cares_ about people here you need you optimism deflated [15:14:37] <jai> lolwut [15:15:20] <kshishkov> mru: while I was enjoying SL transport in April they managed to close one of the most important tram lines here [15:15:37] <mru> to understand SL you must understand how the money flows [15:15:53] <kshishkov> and it took only a few months to prepare a replacement bus for a wee part of the removed route [15:16:06] <mru> the county council takes tax money and pays private companies to run the trains and buses [15:16:14] <av500> 4) profit [15:16:32] <mru> the lowest bidder gets the contract [15:17:05] <kshishkov> yes, that's why you got MTR instead of Veolia for Tunnelbanan [15:17:05] <mru> the contractors only care about following the letter of the contract to ensure they get paid [15:17:29] <mru> around here veolia transports rubbish [15:17:42] <av500> here they transport people :) [15:17:43] <merbzt> no more veolia [15:17:50] <kshishkov> around here it's all rubbish [15:17:54] <mru> av500: is there a difference where you live? [15:18:11] * av500 is offended [15:18:20] <mru> I didn't mean it like that [15:18:29] * mru rephrases [15:18:30] * kshishkov used a Veolia bus from Helsingfors Central to Vanda Airport [15:18:41] <mru> av500: are you lucky enough to live in a place where there's a difference? [15:18:58] * av500 thinks so [15:19:20] <kshishkov> mru: ask merbzt about "marshrutka" [15:19:32] <mru> anyway, one of the SL rules states no more than 5% (iirc) of trains may be delayed, or the contractor has to pay fines [15:19:47] <mru> another rule states that any delay less than 5 minutes is considered on time [15:19:57] <mru> guess how much delay all trains have [15:20:09] <kshishkov> 5 mins [15:20:13] <mru> correct [15:20:31] <mru> a certain number of cancelled trains are also allowed [15:20:39] <mru> guess how many they cancel every day [15:20:44] <av500> as much as allowed [15:20:47] <mru> exactly [15:20:51] <kshishkov> here trains have delays from5 to 70 mins [15:21:31] <mru> when a train is delayed by more than 5 minutes, they'll cancel it, delay it for another 10 minutes and pretend it's the next one [15:21:39] <mru> if they have cancel slots remaining [15:21:43] <av500> lol [15:21:45] <jai> lulz [15:22:09] <mru> I'm not making this up [15:22:24] <kshishkov> and how it's in comparison to British transport? [15:22:39] <mru> probably not much difference [15:22:45] <mru> I rarely use public transport [15:22:59] <mru> there's one good thing about southampton: taxis are practically free [15:23:05] <kshishkov> you should come here to understand you live in wonderful world [15:23:15] <mru> you can go anywhere in the city for Â£5 or so [15:23:27] <mru> split between 3 or 4 people that's less than a bus fare [15:23:39] <mru> assuming there is a bus in the first place [15:23:42] <jai> 3-4 people fit in a single taxi? [15:24:06] <benoit-> jai: why wouldn't they ? [15:24:06] <kshishkov> yes, it has 4 seats IIRC [15:24:10] <mru> a normal taxi can take 4 passengers [15:24:40] <mru> if at least 3 of them are reasonably slim at least [15:24:48] <jai> ah, i guess taxis here are a bit smaller then... [15:24:59] <mru> probably cheaper too [15:25:04] <jai> of course [15:25:09] <jai> welcome to the third world :) [15:25:16] <mru> depends on your income though [15:25:33] <mru> I gather the income gap in india is huge [15:25:35] <kshishkov> jai: I'm already there [15:25:44] <jai> kshishkov: so i've heard ;) [15:25:57] <jai> mru: yeah [15:31:15] <kshishkov> Compn: considering you mail to mplayer-dev-eng. The best approach is to replace them all with lavc native decoders [15:35:25] <kshishkov> I suspect we need FFmpeg Enterprise^W Developers Edition specially for testing new features and loading binary codecs [16:17:49] <mru> now daring fireball found my ogg article [16:18:03] <mru> only took him a month... [16:18:04] <kshishkov> better late than never [16:19:29] <av500> he could not see through the flames I guess [16:31:48] <pJok> mru, but ogg is the best container in the universe!!!111[/trollmode] [16:32:06] <av500> not our universe [16:32:17] <av500> but there are others [16:32:24] <kshishkov> then you don't live in xiphverse [16:32:46] <pJok> who cares about xiph anyways? [16:34:09] <kshishkov> RMS, I think [16:34:22] <pJok> but who cares about RMS? [16:34:39] <kierank> fsf [16:34:56] <pJok> this is ffmpeg... who cares about RMS? ;) [16:35:09] <av500> kshishkov: no way, he uses an all free laptop and the only audio/video he can decode on it is txt and libaa [16:35:29] <jai> yep, gNuisance [16:35:39] <pJok> hmm [16:35:47] <pJok> shouldn't ffmpeg have libcaca support? ;) [16:35:59] <kshishkov> av500: free laptop as "RMS free" or as "free beer" [16:36:17] <kshishkov> pJok: I think we'll get it soon [16:36:18] <jai> pJok: hook up ffplay to libvo :) [16:37:09] <av500> kshishkov: RMS free [16:37:21] <av500> bios in source code [16:37:50] <kshishkov> based on Sparc as the only CPU with open VHDL too? [16:38:01] * elenril thinks opensource bios is a great idea [16:38:06] * elenril kicks his broken bios [16:38:17] <kshishkov> we have some of those [16:38:30] * kshishkov prefers firmware to bios though [16:38:36] <kshishkov> or at least a monitor [16:38:40] <elenril> coreboot doesn't work on laptops [16:38:45] <av500> kshishkov: it is actually something you might know: Loongson 2F CPU, 797-900MGHz [16:38:46] <pJok> kshishkov, but you need propriotary software to make the logic mesh in the fpga [16:38:56] <av500> Lemote YeeLoong 8101B 10" [16:39:09] <mru> eeew [16:39:11] <av500> maybe it does decode theora though [16:39:15] <mru> elenril: have you tried seabios? [16:39:25] <kshishkov> av500: I have Gdium, almost the same stuff [16:39:26] <av500> mru: no, (fr)eeeew [16:39:40] <av500> kshishkov: hence my remark :) [16:40:26] <mru> I heard the lemote machines not only used a weird cpu, they also used a crappy northbridge/pci-controller not quite compatible with the cpu [16:40:51] <av500> mru: no read: "The unique programmable Northbridge provides space for customization; the operation and application of free operating system could adopt a free open-source software (FOSS), which is a powerful software package management mechanism that provides the most convenient methods for users' customization and development demands to exempt from getting into the trouble of software copyright." [16:40:53] <av500> :) [16:41:29] <av500> who care if it does not match the CPU when you can have this [16:41:43] <elenril> mru: no [16:42:07] <elenril> when i last asked in #coreboot, they told me it won't work on most laptops [16:42:17] <elenril> and recovery would be very hard [16:42:36] <mru> the bios is something that runs for a few seconds a few times a year [16:42:41] <mru> I don't really care much about it [16:42:45] <kshishkov> mru: Gdium crap (SiS 501) is no better [16:42:57] <mru> kshishkov: that's the remarkable thing [16:43:00] <mru> it _is_ better [16:43:06] <kshishkov> yuck! [16:43:28] <elenril> well my bios practically can't boot from an usb disk [16:43:38] <mru> that sucks if you need it [16:43:41] <kshishkov> also don't say such things about bios in presence of DOS programmers [16:43:56] <mru> they have only themselves to blame [16:44:07] <pJok> the only advantage of dos is the boottime [16:44:38] <mru> linux boots pretty damn fast with init=/bin/sh [16:44:51] <mru> and that's already much more than dos ever provides [16:44:58] <av500> why boot? [16:45:21] <kshishkov> mru, you can replace bios with linux kernel too [16:45:39] <mru> not quite [16:45:44] <mru> you still need something to configure ram etc [16:45:56] <av500> kshishkov: sound better than DOS approach to replace kernel with BIOS :) [16:46:45] <kshishkov> s/replace kernel/make OS around BIOS with somecrap.sys/ [16:47:10] <mru> the idea of the bios wasn't entirely without merit at the time [16:47:18] <mru> unfortunately they botched the implementation [16:48:52] <kshishkov> well, making PC out of 8088 with cheesy CP/M clone was a botched idea [16:50:34] <kshishkov> why couldn't they do something like Acorn machine? [16:52:13] <jai> ^ freenode failure [16:52:51] <kshishkov> nah, quite good for blackmailing [17:04:04] <BBB> kshishkov: wanna help with a math problem? [17:05:05] <BBB> kshishkov: http://ffmpeg.pastebin.com/QVzT46cn there's two pieces of code, I'd expect them to do the same but they don't - why not? [17:08:50] * BBB is confused [17:12:46] * kshishkov looks for function sources [17:15:35] <kshishkov> BBB: looks like celp_filterf sets first value before actual filtering and tilt does that after filtering [17:16:03] <BBB> should be done before [17:16:12] * BBB sent his interpretation of the postfilter to the list [17:18:08] <kshishkov> oh, the order! [17:18:32] <kshishkov> celp_filterf is ascending [17:18:37] <kshishkov> and tilt is descending [17:18:58] <kshishkov> so in tilting it uses _untouched_ samples during compensation [17:19:34] <kshishkov> and in celp_filterf it updates in[n-1] = out[n-1] before calculating out[n] from it [17:23:53] <BBB> I see [17:24:17] * BBB guesses that's a bug in the code then [17:24:22] <kshishkov> I really suggest you take VoxWare MetaS... [17:24:28] <BBB> ? [17:24:31] <BBB> the dll? [17:24:37] <BBB> I'm lazy, I'd like to do video [17:24:40] <kshishkov> the codec [17:24:52] <BBB> I'll do it some other time :) [17:24:54] <kshishkov> ok, WVP2 will wait for you too [17:25:12] <BBB> I doubt it, you guys are on it fast [17:25:28] <kshishkov> "you guys"? [17:25:34] <BBB> you, that soc student :) [17:26:36] <kshishkov> I remember only three successful REs for GSoC - WMAPro, MLP and RV4 [17:26:57] <kshishkov> so you have better chances it's audio codec that will be REd, not video ;) [17:28:13] <BMintern> has anyone here worked on libavfilter? i already got a fade filter working, but now i'm having trouble getting a concatenate filter to register [17:28:19] <BMintern> http://ffmpeg.pastebin.com/iCub2y4Z [17:29:10] <BMintern> if i copied those 2 files along with vf_concatenate.c to ffmpeg/libavfilter/ and then did "make ffmpeg_g", it should work, right? [17:29:53] <kshishkov> have you run configure after you added that filter? [17:30:38] <BMintern> yes [17:31:00] <BMintern> it seems really strange to me [17:31:47] <kshishkov> just check for CONFIG_CONCATENATE_FILTER in config.mak and HAVE_CONCATENATE_FILTER or similar in config.h [17:33:05] <BMintern> CONFIG_CONCATENATE_FILTER=yes [17:33:05] <BMintern> and [17:33:05] <BMintern> #define CONFIG_CONCATENATE_FILTER 1 [17:33:05] <BMintern> respectively [17:33:19] <kshishkov> make clean && make [17:33:48] <kshishkov> it should help [17:34:19] <kshishkov> if not then ask DonDiego, he has magic crystal ball [17:35:17] <BMintern> thanks, doing it now. i was just kind of lost because i thought i followed the same process as i did when i did it before [17:41:26] <BMintern> so weird, it's still not showing [17:42:01] <kshishkov> look into vf_concatenate.c for filter name then [17:42:26] <BMintern> ha! wow i'm dumb [17:43:35] <BMintern> obv working now [18:45:49] <CIA-1> libswscale: reimar * r30978 /trunk/libswscale/rgb2rgb_template.c: [18:45:49] <CIA-1> libswscale: Replace some "m" constraints by MANGLE to avoid issues with some compilers not [18:45:49] <CIA-1> libswscale: being able to compile it and deduplicate the code at the same time. [18:51:52] <bcoudurier> hi guys [18:51:57] <Dark_Shikari> hi bcoudurier's onjoin script [18:55:59] <jai> someone should make fftrollbot respond next time :) [18:56:41] <kshishkov> just fill default onbcoudurierjoin script, that's all [19:03:52] <CIA-1> ffmpeg: stefano * r22748 /trunk/libavformat/avformat.h: [19:03:52] <CIA-1> ffmpeg: Make av_match_ext() declaration public (move its declaration out of [19:03:52] <CIA-1> ffmpeg: the #ifdef HAVE_AV_CONFIG_H block in avformat.h). [19:05:19] <bcoudurier> fucking mkv [19:05:36] <bcoudurier> requiring a parser for every codec is fucking useless [19:06:12] <bcoudurier> I really don't get how people can prefer mkv to mp4 [19:06:41] <elenril> because it supports more codecs? [19:06:52] <CIA-1> ffmpeg: stefano * r22749 /trunk/doc/APIchanges: Add entry for the addition of av_match_ext() to the public API. [19:07:45] <Dark_Shikari> bcoudurier: for the user, it's better [19:07:50] <Dark_Shikari> better tools, better support [19:08:03] <bcoudurier> what usage ? [19:08:11] <Dark_Shikari> It's much like the ogg argument, where the xiph devs excuse shitty design by saying that it doesn't matter for users. [19:08:11] <bcoudurier> elenril, isom is a _generic_ container [19:08:11] <jai> anime ;) [19:08:15] <Dark_Shikari> And they're often right [19:08:25] <bcoudurier> ie it provides mechanism to encapsulate _any_ codec [19:08:37] <Dark_Shikari> Find me a player that supports vorbis in mp4. [19:08:42] <Dark_Shikari> Or ASS subtitles. [19:08:46] <bcoudurier> just pick one fourcc [19:08:49] <bcoudurier> gpac does [19:08:54] <Dark_Shikari> gpac isn't a media player [19:08:58] <Dark_Shikari> I'm talking from the _user_ perspective [19:08:59] <bcoudurier> they have one [19:08:59] <Dark_Shikari> this is the problem [19:09:04] <Dark_Shikari> yes but nobody uses it [19:09:07] <bcoudurier> ffplay supports it [19:09:14] <bcoudurier> you can put vorbis in mov [19:09:17] <Dark_Shikari> nobody uses ffplay, and it doesn't do subtitles [19:09:17] <bcoudurier> ffplay will play it [19:09:22] <ramiro> Dark_Shikari: I do [19:09:27] <ramiro> (use ffplay) [19:09:29] <bcoudurier> so what ? do you want me to patch VLC for you ? [19:09:32] <bcoudurier> I can do that [19:09:35] <Dark_Shikari> my point is that, right now [19:09:38] <bcoudurier> your reasoning is dumb [19:09:39] <Dark_Shikari> mkv supports a ton of things that mp4 doesn't [19:09:44] <bcoudurier> no [19:09:45] <Dark_Shikari> in _practice_ [19:09:46] <Dark_Shikari> people use it because of that [19:09:49] <Dark_Shikari> I'm not talking about developers [19:09:54] <Dark_Shikari> I'm not talking about capabilities [19:09:59] <Dark_Shikari> I'm talking about what players _actually support_. [19:10:10] <bcoudurier> and extending broken basement is not really clever IMHO [19:10:10] <Dark_Shikari> if you want to change things, make players support those things for mp4 too. [19:10:15] <bcoudurier> players means VLC [19:10:22] <bcoudurier> if VLC supports it [19:10:24] <Dark_Shikari> players means MPC-HC [19:10:25] <bcoudurier> that's enough [19:10:26] <Dark_Shikari> and VLC [19:10:27] <Dark_Shikari> and mplayer [19:10:42] <bcoudurier> I don't care about MPC-HC [19:10:46] <Dark_Shikari> But users do [19:10:50] <Dark_Shikari> they don't care what you care about [19:10:53] <Dark_Shikari> they care about what they use [19:11:06] <Dark_Shikari> and considering everyone distributing MKV files almost universally says "don't use VLC"... [19:11:15] <Dark_Shikari> what are the odds they will switch to a format that only VLC supports? [19:11:26] <bcoudurier> that's just false [19:11:34] <bcoudurier> tell me why users are always remuxing to mp4 ? [19:11:42] <bcoudurier> we get a _ton_ of remuxing errors [19:11:43] <Dark_Shikari> I've never seen a user remuxing to mp4 [19:11:44] <kierank> they are? [19:11:48] <bcoudurier> because mkv is _not_ suitable [19:11:49] <Dark_Shikari> I've seen a user _re-encoding_ to mp4 [19:11:50] <elenril> for ipods? [19:11:52] <Dark_Shikari> for ipods [19:11:56] <Dark_Shikari> but high profile mp4 won't play on an ipod either [19:11:57] <bcoudurier> ipods, ps3 [19:12:06] <bcoudurier> everything that's just not piracy [19:12:09] <Dark_Shikari> you cannot remux a typical mkv to play on an ipod [19:12:21] <Dark_Shikari> and the peoplewho distribute ipod-compatible h264 files do so as mp4 anyways [19:12:35] <bcoudurier> mkv was good for one thing [19:12:39] <bcoudurier> subs [19:12:48] <bcoudurier> it provided a solution before everybody else [19:12:53] <Dark_Shikari> you are ignoring reality. people wonder why anyone at all uses ogg: it's because of support and tools. if you want to beat a shitty format, make your better one have better tools, and better support. [19:13:04] <kierank> at the time of decision there was no ac-3 in mp4 too [19:13:10] <bcoudurier> well [19:13:23] <bcoudurier> my tree has covert art support for mp4 [19:13:40] <Dark_Shikari> now make everything support it. that's what matters to users [19:13:47] <Dark_Shikari> Once everything supports it, you can convince the pirates to use it [19:13:50] <Dark_Shikari> once the pirates use it, everyone will [19:14:00] <bcoudurier> it's funny because the _technical_ arguments against ogg matters [19:14:02] <bcoudurier> but not against mkv [19:14:08] <Dark_Shikari> huh? [19:14:11] <bcoudurier> you need to get some logic here [19:14:21] <Dark_Shikari> I have no idea what you're saying [19:14:26] <Dark_Shikari> I'm saying the situation with ogg and mkv is the same [19:14:34] <Dark_Shikari> both are technically worse formats than isom, though ogg is much worse [19:14:41] <Dark_Shikari> But you can't "beat them" by just whining about how much they suck [19:14:46] <bcoudurier> yes [19:14:46] <Dark_Shikari> you beat them by making better tools and better support [19:15:30] <bcoudurier> nero put ac-3 in mp4 since a long time [19:15:42] <bcoudurier> same for vobsub [19:18:41] <bcoudurier> <Dark_Shikari> I've never seen a user remuxing to mp4 [19:18:54] <bcoudurier> how can you say that, when you told so many users to use gpac [19:19:01] <bcoudurier> because of the monotone timestamps error [19:19:02] <Dark_Shikari> gpac can't remux to mp4 either [19:19:04] <Dark_Shikari> it doesn't take mkv input [19:19:22] <bcoudurier> extract essences..... [19:19:28] <Dark_Shikari> ok, better said, I've never seen a user remuxing to mp4 for ipod [19:19:40] <Dark_Shikari> I have seen users remuxing to mp4 for ps3 or whatever, but most of the time what they're doing _won't work_ [19:19:49] <bcoudurier> I bet a lot more people will do now for ipad [19:19:52] <Dark_Shikari> for example, ASS subtitles won't work on PS3 [19:19:59] <Dark_Shikari> and users will find later, after remuxing, that their subs are gone [19:20:11] <Dark_Shikari> bcoudurier: apple still isn't officially supporting high profile on ipad yet :/ [19:20:16] <bcoudurier> I know [19:20:20] <Dark_Shikari> I wonder how long until they finally get around to that [19:20:30] <bcoudurier> I know [19:20:37] <kierank> same day all the quicktime bugs are fixed [19:20:52] <Dark_Shikari> lol [19:21:22] <bcoudurier> fixing quicktime doesn't mean fixing anything else unfortunately, apple uses different implementations/base [19:21:39] <bcoudurier> in FCP, iphone [19:21:57] <kierank> speaking of which does iphone support weightp [19:21:58] <Dark_Shikari> same with apple tv [19:22:00] <Dark_Shikari> fork of quicktime :/ [19:22:07] <Dark_Shikari> kierank: yes. it doesn't use the quicktime decoder either [19:22:09] <Dark_Shikari> it uses the OMAP thingy [19:38:31] <BBB> bcoudurier: so what's the status of officer-vote? [20:05:39] <BMintern> would anyone care to look over a filter for me and try to help me figure out what i'm doing wrong? [20:06:17] <Dark_Shikari> don't ask to ask, just ask [20:06:36] <BMintern> ok, it's http://bmintern.homeunix.com/vf_concatenate.c [20:06:46] <Dark_Shikari> 404 [20:06:52] <BMintern> yeah sorry, one sec [20:07:49] <BMintern> http://bmintern.homeunix.com/~brandon/vf_concatenate.c [20:08:07] <Dark_Shikari> don't we already have a concat filter? [20:08:10] <BMintern> the point is to take two clips and just combine them into one [20:08:12] <BMintern> do we? [20:08:29] <drv> there is a concat protocol, not a filter afaik [20:08:42] <Dark_Shikari> oh. I guess you're right [20:09:28] <BMintern> is my approach completely wrong? [20:10:37] <BMintern> right now it just outputs the first input and seems to ignore the other one [20:11:59] <BMintern> there's also http://bmintern.homeunix.com/~brandon/vf_concatenate.patch if you're interested in compiling [20:17:10] <BMintern> Vitor1001- i'm working on concatenate and i'm not sure what i've done wrong. it's only outputting the first video and seems to ignore the 2nd [20:17:25] <BMintern> http://bmintern.homeunix.com/~brandon/vf_concatenate.c or http://bmintern.homeunix.com/~brandon/vf_concatenate.patch [20:17:32] <Vitor1001> BMintern: sorry, can't talk right now :( [20:17:36] <BMintern> ok, np [20:41:41] <CIA-1> ffmpeg: rbultje * r22750 /trunk/libavcodec/ (avcodec.h options.c): Add avcodec_copy_context(). [20:56:48] <BBB> wbs: can you change the rtsp muxer code to use avcodec_copy_context() in that one location that we talked about? ;) [20:58:56] <bcoudurier> Dark_Shikari, I completely agree that the better tools and better support is the key [21:03:36] <CIA-1> ffmpeg: rbultje * r22751 /trunk/ (ffserver.c ffmpeg.c): (log message trimmed) [21:03:36] <CIA-1> ffmpeg: Fix FFM-based streaming from ffmpeg to ffserver. The basic problem is that [21:03:36] <CIA-1> ffmpeg: we'd memset() the codec context to zero, thereby setting audio input to U8 [21:03:36] <CIA-1> ffmpeg: and video to YUV420P. For most video encoders, that actually works, but for [21:03:36] <CIA-1> ffmpeg: most audio codecs, it doesn't. This patch changes defaults to those set by [21:03:36] <CIA-1> ffmpeg: avcodec_context_get_defaults() and have ffmpeg figure out the optimal encoding [21:03:37] <CIA-1> ffmpeg: format itself if not set explicitely (as it does for the non-ffserver-cases [21:11:42] <CIA-1> ffmpeg: rbultje * r22752 /trunk/ (libavcodec/avcodec.h doc/APIchanges): Document API addition of avcodec_copy_context(). [21:33:00] <BBB> latest x264 in mac/darwinports is 20090810-2245 :( [21:33:02] <BBB> that's old... [21:33:51] <astrange> fink is... far worse [21:34:11] <astrange> i haven't taken over ffmpeg and related packages there as there's a lot of them, and i have no idea what some (libquicktime) even are [21:35:26] <BBB> do you remember cinderella? [21:35:41] <BBB> it's this video editor made by this biologist (I always think it's funny, because that sounds like me) [21:35:48] <BBB> it had native quicktime support [21:36:01] <BBB> that code was forked so others could use it too, and they called it libquicktime [21:36:07] <astrange> is it the same as cinelerra? [21:36:16] <BBB> yeah, the name changed a couple of times [21:36:59] <BBB> mjpegtools (my first step into free software coding) actually used libquicktime at some point [21:37:01] <BBB> maybe it still does [21:39:59] <janneg> iirc mjpegtools on gentoo has still a quicktime use flag [21:40:32] <pasteeater> looks like libquicktime is still being developed [21:40:37] <pasteeater> 23. Feb 2010 libquicktime-1.1.5 released: This release brings encoding of AC3 and H.264 in AVI [21:40:43] <pasteeater> ooh...H.264 in AVI [21:43:04] <BBB> libquicktime does avi now? [21:43:09] <BBB> something sounds weird [21:43:39] <troy_s> On that subject, is there any work at getting >8bpc bit depth into ffmpeg? [21:43:49] <BBB> I thought we had that already [21:44:27] <Dark_Shikari> not in most encoders/decoders whose formats support it [21:47:00] <troy_s> Dark_Shikari: So is the groundwork in place then? [21:47:24] <troy_s> Dark_Shikari: Because I have asked a pretty astute fellow (working on RED code implementation) and he suggested that there wasn't infrastructure in ffmpeg for it. [21:47:30] <troy_s> Dark_Shikari: Granted, that may have changed. [21:49:26] <Dark_Shikari> there is, afaik [21:49:30] <Dark_Shikari> we have pixfmts and swscale functions [21:49:51] <saste> BMintern: post the concatenate patch to the soc ML [21:50:22] <saste> BMintern: I have some fix for you... [21:50:44] <troy_s> Dark_Shikari: Thanks for that. Is the patch to non-scale 16-235 results on HD x264 material in place in upstream yet? As in can I output a non squished 16-235 PNG from an x264 source? [21:51:28] <BBB> troy_s: your fellow is right that in the past, the ifnrastructure wasn't there, but afaik it is there now [21:51:50] <troy_s> BBB: Well that is most excellent news. Any chance we will see ICC / LUT support? [21:52:05] <Dark_Shikari> troy_s: x264 has a --fullrange flag [21:52:15] <BBB> I'm not the person working on that ;) [21:52:21] <troy_s> Dark_Shikari: ffmpeg or x264 itself? [21:52:25] <Dark_Shikari> I'm talking about x264 [21:52:41] <Dark_Shikari> if you're talking about ffmpeg (don't say x264), swscale has some... weirdness [21:52:45] <Dark_Shikari> afaik, it still assumes EVERYTHING is BT.601 [21:52:49] <troy_s> Dark_Shikari: Yes. That's exactly what I am talking about. [21:53:07] <troy_s> Dark_Shikari: (And I believe the clamp (SMPTE?) could happen in 709 as well? [21:53:16] <troy_s> Dark_Shikari: But I kindly got a patch from David here. [21:53:20] <Dark_Shikari> fix it then [21:53:23] <Dark_Shikari> get it committed =p [21:53:33] <troy_s> Dark_Shikari: I was hoping that it would land in upstream. [21:53:37] <Dark_Shikari> pcrange vs tvrange is rarely called "clamping" [21:54:28] <BMintern> saste: i will, thank you [21:55:29] <troy_s> Dark_Shikari: Thanks for your time. [21:56:06] <Dark_Shikari> you also don't have to ping me with every single message [22:48:58] <dchana> hi there [22:49:12] <dchana> I have a question about the j2k project [22:49:19] <dchana> anyone here is a mentor for that project? [23:01:56] <BBB> dchana: better to email ffmpeg-soc/ffmpeg-devel about that [23:03:37] <Compn> kostya worked on j2k a bit i think [23:03:55] <Compn> but i guess hes not here atm [23:04:29] <dchana> thanks [23:04:38] <BBB> jai did it as soc project last year [23:04:41] <BBB> you could also ask him [23:05:02] <dchana> Jai is not here [23:05:14] <dchana> I'm looking for the mentor [23:05:20] <DonDiego> dchana: mail ffmpeg-soc please [23:05:36] <DonDiego> let's try to reduce the traffic on -devel where reasonably possible

1 0