Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

July 2010

1 participants
22 discussions

IRC log for 2010-07-15
by irc＠mansr.com 16 Jul '10

16 Jul '10

[00:01:00] <Dark_Shikari> oh cool, if I "unrolled" the branches like crazy, I get a pretty good speed boost. [01:03:35] <kierank> did something change in the fft recently? [01:04:29] <drv> avfft.c has a few recent changes, don't see anything else at a glance [01:17:07] <kierank> hmmm i could swear my output matched octave before i rebased [01:29:16] <peloverde> nothing except trivial API fixes has changed since march [01:33:15] <kierank> octave's ifft of the identity vector outputs an array with each element equal to: 1/size but mine for some reason just outputs 1 for each value [01:33:57] <peloverde> IIRC that is the way our ifft has always behaved [01:34:16] <kierank> i see [02:17:08] <Dark_Shikari> x264 now supports NV12 input. Do we care enough to add it to ffmpeg? [02:17:14] <Dark_Shikari> Is there any decoder that outputs NV12? [02:18:10] <drv> i think there's at least nv12 support in swscale [02:19:44] <Dark_Shikari> technically there is, but it takes the slow path [02:19:52] <Dark_Shikari> e.g. the only converter does a slow C YV12 -> NV12 [02:19:57] <Dark_Shikari> so you have to do two steps, and it's not optimized [02:20:04] <Dark_Shikari> so the only worthwhile case would be if the video was _already_ nv12 [02:20:07] <Dark_Shikari> and we wanted to avoid a conversion. [02:26:10] <pengvado> nothing in libavcodec touches nv12 [02:27:10] <Dark_Shikari> not even the gpu decode stuff? [02:29:33] <drv> there's an entry for it in raw.c, but that's it [02:30:48] <Dark_Shikari> heh. [02:50:17] <siretart> [02:50:32] <Dark_Shikari> [06:23:42] <av500> peloverde: what do I need to do to be webm supporter? [06:24:52] <peloverde> I don't know, two people have asked on webm-discuss [06:25:21] <peloverde> In one case jk forwarded it to the webmaster, in the other there was no response [06:26:10] <saintdev> lol @ MN [06:39:32] <kshishkov> av500: loosing your mind should be the first step [06:40:45] <av500> I'm still undecidecd whether being listed on that page is free advertisement or invitation to be sued... [06:43:34] <av500> (not speaking for ffmpeg, ffmpeg should be added there imho) [06:45:40] <mru> I doubt we'd become any bigger a target by being on that list [06:46:01] <CIA-99> ffmpeg: mru * r24243 /trunk/libavcodec/arm/h264dsp_neon.S: ARM: remove two insns from NEON chroma loop filter [06:46:11] <av500> mru: not speaking about ffmpeg [06:46:25] <mru> yes, you said that [06:46:25] <av500> I meant for a commercial company [06:46:39] <av500> I have no fear at all for ffmpeg... [06:46:45] <av500> you cannot sue SW [06:46:49] <mru> quite [06:47:10] <mru> and as far as we know, nobody has ever been sued for using ffmpeg [06:47:33] <av500> you dont sue ppl for using ffmpeg, you sue them for not paying patent royalties [06:48:57] <mru> some people are afraid of the RE'd stuff [06:49:41] <av500> yeah, being sued by a 10y old defunct game publisher... :) [06:49:52] <av500> or by Lego... but that is almost cool [06:50:10] <av500> and, you can always limit the range of codecs and containers [06:50:18] <mru> for using pcm, hmm [06:50:22] <av500> we don't ship a full build of course [06:50:35] <mru> you have no reason [06:59:17] <astrange> not until someone patents av_malloc [07:07:28] <mru> or wrappers in general [07:25:46] <jai> is the dv maintainer around nowadays? [07:25:58] <kshishkov> generally not [07:26:05] <kshishkov> and hardly on IRC [07:26:18] <kshishkov> I'm not sure if I've ever seen him here [07:26:34] <jai> ah [07:26:59] <mru> he was at linuxtag 2006 [07:27:32] <av500> vortex manipulator anybody? [07:27:44] <jai> ffdv doesnt respond very well to fuzzed file [07:27:48] <jai> *files [07:27:54] <av500> ffuzzed? [07:28:04] <jai> zzufd :) [07:28:06] <mru> the dv code is very fragile [07:28:07] <kshishkov> fix it [07:28:16] <mru> it's always the first to fail on obscure systems [07:28:22] <mru> along with dnxhd [07:28:54] <kshishkov> rv40? [07:29:13] <thresh> kshishkov: want to rofl? http://www.securitylab.ru/news/395807.php [07:29:28] <jai> yeah, once i get some time hopefully, i'll try and fix some [07:29:38] <jai> found some memleaks as well [07:29:45] <thresh> ROC is so funny. [07:29:55] <av500> thresh: conservative politicians do the same here all the time.... [07:30:11] <kshishkov> thresh: грешно смеяться над убогими [07:30:32] <av500> they dont sport that mighty beards though... [07:32:29] <thresh> loving that: Прилетит, например, неожиданно какая-нибудь комета и своим мышиным космическим хвостиком сбросит со стола цивилизации золотое яичко Интернета. [07:32:57] <av500> comets? [07:33:21] <av500> civilization [07:33:27] <kshishkov> thresh: я, между прочим, учился в той же школе, что и Леонид Черновецкий - фиг меня таким удивишь [07:34:03] <thresh> av500: yes [07:34:47] <av500> gahm russian is too unserbian for me in the end... [07:34:50] <kshishkov> av500: and allusion to Russian folk tale about golden egg with GUI security [07:34:53] <av500> m->, [07:35:41] <av500> Leonid who? [07:36:24] <thresh> Kiev mayor, insane guy [07:36:45] <kshishkov> http://en.wikipedia.org/wiki/Leonid_Chernovetskyi [08:21:51] <CIA-99> ffmpeg: mstorsjo * r24244 /trunk/MAINTAINERS: Update maintainers list according to renames made in rev 21284 and 22109 [08:57:09] <CIA-99> ffmpeg: vitor * r24245 /trunk/configure: [08:57:10] <CIA-99> ffmpeg: Fix obviously missing dependency of float DCT. [08:57:10] <CIA-99> ffmpeg: Fixes issue 2095. [11:43:58] <CIA-99> ffmpeg: pross * r24246 /trunk/libavformat/iff.c: remove redundant text and whitespaces from iff demuxer av_log() statements [11:54:27] <CIA-99> ffmpeg: jai_menon * r24247 /trunk/ffmpeg.c: [11:54:27] <CIA-99> ffmpeg: FFmpeg : Close input file and free any related memory if [11:54:27] <CIA-99> ffmpeg: av_find_stream_info fails. [12:06:44] <CIA-99> ffmpeg: cehoyos * r24248 /trunk/tools/patcheck: [12:06:44] <CIA-99> ffmpeg: grep Changelog entry from unified diffs [12:06:44] <CIA-99> ffmpeg: Patch by Rafa?l Carr?, rafael d carre a gmail [12:13:34] <pross-au> mru/anyone: does av_realloc() ensure 16-byte alignment? [12:13:39] <mru> yes [12:13:43] <mru> no [12:13:45] <mru> av_malloc does [12:13:47] <mru> not realloc [12:14:02] <mru> there is easy way to do it with realloc [12:14:04] <mru> *is no [12:14:09] <pross-au> Right [12:14:27] <pross-au> Then our #ifdef MEMALIGN hack for av_malloc is kinda pointless?! [12:14:48] <mru> no [12:15:06] <av500> what start alinged stays aligned, no? [12:15:09] <av500> starts [12:15:12] <mru> av_malloc guarantees alignment [12:15:47] <pross-au> okay [12:16:08] <mru> memalign isn't particularly standard though [12:16:11] <mru> so we have to check for it [12:16:33] <pross-au> for the AVFrame get_audio_buffer() stuff i really need av_realloc [12:16:41] <pross-au> Or some additional creativity... [12:16:53] <mru> why do you think you need realloc? [12:18:09] <pross-au> allocing and freeing memory for each frame seems pointless [12:18:37] <pross-au> that said, we don't need to retain the data, just 'grow' or 'shrink' the buffer [12:18:47] <pross-au> contents can be trashed [12:19:19] <av500> is there a point to shrink it? [12:19:35] <mru> probably not [12:19:35] <pross-au> av500: flac? [12:19:47] <pross-au> "please allocate me a 5MiB frame" [12:19:55] <mru> yes, so? [12:20:07] <mru> either you have it or you don't [12:20:14] <pross-au> if all the remaining frames are less then that, it' wasted [12:20:18] <av500> and if contents are to be trashed: if size > alloc_size ) alloc_size *= 2; free(); malloc( alloc_size ) .... [12:20:34] <mru> grep for fast_realloc [12:20:41] <pross-au> ok [12:21:35] <pross-au> guessing that fast_realloc is always 16-bit aligned either [12:50:31] <DonDiego> calling out to all you gitards: [12:50:51] <DonDiego> why can't the be all and end all of vcs systems handle empty directories? [12:51:03] <Dark_Shikari> it can't? [12:51:16] * DonDiego waits for the zealots to explain i do not really need that feature.. [12:51:25] <DonDiego> apparently not.. [12:51:40] <DonDiego> neither can mercurial IIRC [12:51:47] <Dark_Shikari> http://stackoverflow.com/questions/115983/how-do-i-add-an-empty-directory-t… [12:51:59] <Dark_Shikari> it's a design flaw that could be remedied not-too-difficultly [12:52:01] <DonDiego> but subversion and bazaar have no trouble [12:52:03] <Dark_Shikari> But nobody actually cares enough to do it [12:52:17] <Dark_Shikari> meaning that probably it's not used enough for it to be a huge issue. [12:52:21] <mru> I find that far less annoying than that svn can't replace a directory with a file in one commit [12:52:52] <mru> I don't think I've ever deliberatly created an empty directory in any vcs [12:53:08] <DonDiego> see? see? i just *knew* the trolls would come out of the woodworks in no time.. [12:53:10] <av500> Dark_Shikari: why not add .gitignore [12:53:19] <av500> oops, DonDiego ^^^^^^ [12:53:26] <lu_zero> iirc tar still have the same issue [12:53:28] <mru> in fact, I don't think I've ever created a directory without immediatly putting something in it [12:53:56] <Dark_Shikari> DonDiego: it's not really trolling. it's more of a matter of "this is a very very minimally useful feature, and while it'd be nice to have, it's not really something huge to bitch about" [12:54:12] <lu_zero> Dark_Shikari: I'm somehow afraid it isn't considered a flaw [12:54:21] <av500> mru: I created "~/my_swiss_bank_accounts/" very early, but never anything to put in there.. [12:54:23] <mru> DonDiego: seriously though, why do you need empty dirs? [12:54:35] <DonDiego> lu_zero: tar handles empty dirs flawlessly of course [12:54:41] <Dark_Shikari> lu_zero: I suspect a patch would be welcome, it's just nobody cares to do it. [12:54:58] <kshishkov> why not rewrite git in C++ while you're on it [12:55:19] <DonDiego> mru: the build system of a lib here at work puts binaries in a subdir and it's easier to add it to svn than to create it in the makefile [12:55:19] <av500> DonDiego: wrt trolls, is that the reason not to switch to git? [12:55:40] <mru> DonDiego: just create it in the makefile [12:55:40] <av500> ? [12:55:43] <av500> +1 [12:56:01] <av500> assuming you have the source code of the makefile.... [12:56:09] <DonDiego> or i can do it in svn instead of working in git-svn.. [12:56:13] <mru> av500: makefile.am? [12:56:28] <av500> mru: dunno, there are wierd commercial things... :) [12:56:53] <kshishkov> av500: and git can't synchronize with kitchen sink and coffee machine. Let's not switch to it. [12:57:02] <av500> kshishkov: stop trolling [12:57:06] <av500> :) [12:57:12] <mru> putting an empty dir in vcs for that reason is just as stupid as checking in compiled object files [12:57:37] * av500 checks in compiled object files from 3rd party :) [12:58:10] <av500> the (3rd) party is always right! [12:58:46] <kshishkov> av500: there's only one party and it's always the first! [12:59:02] <mru> birthday party? [12:59:20] <pJok> will there be cake? [12:59:29] <av500> pJok: check in the cake [12:59:36] <mru> the cake is a lie [12:59:45] <mru> just like the empty dir [13:00:14] <av500> trope! [13:00:18] <pJok> mru, i see that you got into the party submission position ;) [13:02:36] <av500> wrt git, should be easy to assign a special SHA e.g. 0000... to empty file and add that to every tree... [13:07:55] <jai> ^ defeats the purpose of the cloak doesnt it? [13:08:07] <elenril> kshishkov: your kitchen sink doesn't run ssh? [13:09:40] <av500> lol: http://www.seamonkey-project.org/releases/seamonkey2.0.5/changes#spc_os AIX and OS/2 are not retarded, they are "special" [13:09:59] <elenril> lol [13:13:19] <thresh> new zealand wins [13:13:56] <BBB> peloverde: are you working on the webm support thing? [13:14:54] <lu_zero> BBB: ? [13:15:02] <funman> hello [13:15:47] <kshishkov> hi [13:16:37] <Dark_Shikari> BBB: asm done yet? =p [13:17:05] <BBB> fell asleep last night ;) so no [13:17:09] <BBB> but it'll be done today [13:17:16] <mru> code while you sleep! [13:17:33] <kshishkov> get Windows ME in result! [13:26:31] <kshishkov> warning! may cause brain freeze - http://pastie.org/1045593 [13:27:22] <av500> I reported abuse! [13:28:08] * kshishkov has more stuff in store to abuse av500 [13:28:27] <av500> lets fight to death using 3rd party uglycode :) [13:28:34] <funman> kshishkov: that'd be useful to spot radiation-induced memory errors [13:28:37] <av500> or is that in-house? [13:28:47] <mru> that's dtshd ref code [13:28:57] <av500> mru: rapidshare? [13:29:17] <mru> don't know where kshishkov got it [13:29:20] <av500> mru: and I was spot on with "3rd party uglycode" [13:30:27] * av500 throws some "i4_idx" loop variables at kshishkov [13:30:42] <Dark_Shikari> i4_idx isn't too bad, that makes sense. [13:30:44] <av500> and of course its WORD32 i4_idx; [13:30:45] <Dark_Shikari> assuming h264 [13:31:07] <av500> for(i4_idx = 0; i4_idx < n; i4_idx++) [13:31:22] <Dark_Shikari> where n is 16 obviously =p [13:31:22] <av500> the int i is all decorated, the "n" is just n ... :) [13:31:57] <av500> ah, that also exists: WORD32 i4_i; [13:32:01] <av500> i4i [13:32:12] <Dark_Shikari> BBB: quick optimization for you to try in vp8 [13:32:17] <av500> and only 4 after lauching both sidewinders... [13:32:18] <kshishkov> av500: in documentation variable names are like nNumSamplSub-subFr = 8; [13:32:23] <Dark_Shikari> calculate filter_level immediately after decoding each mb [13:32:24] <Dark_Shikari> store it [13:32:30] <Dark_Shikari> and reload it for the per-row deblocking [13:32:36] <Dark_Shikari> reason: mb structs are still in cache. [13:32:41] <Dark_Shikari> x264 does this, it helps. [13:32:55] <Dark_Shikari> Also, this will make it easier to convert the MB structures into a ring buffer. [13:33:00] <Dark_Shikari> which reduces cache misses. [13:35:20] <BBB> ok I will try that [13:35:30] <BBB> (have a lab meet now, so can't work on it right away) [13:35:37] <Dark_Shikari> k [13:39:39] <DonDiego> how does vp8 speed compare to libvpx nowadays? [13:40:11] <Dark_Shikari> on profile==1, we're tied [13:40:14] <Dark_Shikari> in the last test I did [13:40:23] <Dark_Shikari> on the regular profile we're still way slower as BBB isn't done with the loopfilter asm yet [13:42:09] <Honoome> I assume this is x86? [13:42:39] <Dark_Shikari> yes [15:42:05] <kierank> roozhou: we found out what that problem with scenarist was if you didn't already see on doom9 [15:42:09] <kierank> it was the users fault [15:54:46] <peloverde> BBB: not directly [16:13:02] <roozhou> kierank: that's ok [17:02:52] <funman> mru: do you often disassemble arm code? [17:09:33] <mru> funman: define often [17:09:48] <mru> I don't do it every day [17:10:13] <funman> once in a while [17:10:24] <funman> do you use anything beyond IDA and objdump? [17:10:50] <mru> sometimes gdb [17:10:59] <mru> and oprofile can do asm listings [17:11:06] <mru> depends on what I'm doing [17:11:18] <funman> ok [17:11:38] <funman> you know EDA ? [17:12:04] <mru> no [17:12:55] <funman> an emulator / disassembler which renders graphs in javascript, started by geohot but never finished [17:20:59] <peloverde> When people say EDA I usually think of Verilog [17:21:49] <mru> it was rather obvious from the context he referred to something else [17:21:56] <mru> and I don't know that EDA either [17:45:42] <kshishkov> peloverde: and in Russian "eda" means "food". Guess what I think of when I hear that word? [17:45:59] <peloverde> vhdl? [17:46:06] <_av500_> food? [17:46:16] <kshishkov> points go to _av500_ [17:46:18] <_av500_> black forest bacon! [17:46:19] * elenril wants some chocolate [17:46:25] <kshishkov> food still tries to evade him [17:46:46] <_av500_> elenril: a chocotrope? [17:47:00] <kshishkov> _av500_: how it's called in German? [17:47:18] <_av500_> Schwarzwälder Schinken [17:47:51] <kshishkov> _av500_: does not look like bacon to me. I can look into my fridge again but it's not bacon to me [17:48:27] <_av500_> ham then [17:48:45] <mru> ham is too broad a term [17:48:58] <elenril> _av500_: http://tvtropes.org/pmwiki/pmwiki.php/Main/EverythingsBetterWithChocolate [17:49:07] <_av500_> u discuss it, i need to go wreck my carport... [17:49:22] <kshishkov> mru: more meat than fat [17:49:37] <mru> _av500_: try driving the car at high speed into the supports [17:49:40] <mru> that should do it [17:49:52] <mru> or better, use somebody else's car [17:50:05] <kshishkov> and somebody else to drive too [17:54:26] <BBB> kshishkov: http://www.listware.net/201007/mplayer-libav-user/51495-libav-user-rtsp-err… [17:54:29] <BBB> kshishkov: can you answer that? [17:56:37] <kshishkov> no, it just some error [17:56:52] <kshishkov> probably stream is damaged [17:57:19] <kshishkov> and "MB skip/VOP DQuant" are just old debug messages, ignore them [17:57:47] <BBB> the bottom part is damage, the rest is debug? [17:58:05] <kshishkov> exactly [18:14:21] <jai> lol @ michael [18:19:33] <Dark_Shikari> lol michael [18:20:33] <kshishkov> add Peter's name to MARRIAGES file then [19:13:26] <_av500_> done, very limited partial wrecking [19:14:42] <mru> find any trolls underneath? [19:16:00] <_av500_> no, only regenwurms [19:16:24] <mru> earthworms [19:21:57] <mru> peloverde: ping [19:27:02] <lu_zero> yawn [19:28:07] * lu_zero is sleepy [19:42:17] <peloverde> pong [19:43:40] <mru> peloverde: I'd appreciate if you didn't give baptiste ammunition against me [19:43:43] <mru> he's bad enough as is [19:44:18] <mru> the comma-separated lists are an ugly hack [19:44:26] <peloverde> While he might be wrong about the ideal API he seems correct that this change does not break current ABI/API [19:44:40] <mru> fine, I'll concede that [19:44:47] <mru> since we already have one such list [19:44:53] <mru> but that's one too many imo [19:45:09] <mru> we could add an alias list right now without breaking anything [19:46:23] <peloverde> Apps using the alias list would require a higher minimum version? Not ideal but I suppose it is acceptable [19:48:09] <mru> apps wouldn't be required to use it [19:48:16] <mru> now they are required to split the name [19:48:23] <mru> or it won't work with av_find_input_format() [19:48:49] <peloverde> apparently the whole list with all the commas works in av_find_input_format() [19:49:37] <mru> hmm, apparently [19:49:47] <mru> but it's still fucking ugly [19:59:48] <elenril> w00t, new fflames [20:00:05] <lu_zero> elenril: ames? [20:00:11] <lu_zero> lames? [20:00:14] <lu_zero> llamas! [20:00:17] <Dark_Shikari> mru: you'll enjoy this one [20:00:18] <Dark_Shikari> 03:54 < derf> Okay, gcc, I don't understand [20:00:18] <Dark_Shikari> 03:54 < derf> str r0, [sp, #4] [20:00:19] <Dark_Shikari> 03:54 < derf> ldr r4, [sp, #4] [20:00:24] <Dark_Shikari> a register to register move, by way of the stack. [20:00:29] <Dark_Shikari> On a 3-operand architecture, obviously. [20:00:38] <lu_zero> why? [20:00:41] <Dark_Shikari> Because it's gcc. [20:00:45] <lu_zero> no [20:00:52] <lu_zero> how's the code around? [20:01:01] <Dark_Shikari> dunno, but nothing can possibly justify that. [20:01:25] <Dark_Shikari> unless it's volatile or something obviously. [20:01:25] <lu_zero> if you tell gcc that all the regs are busy maybe [20:01:34] <mru> it's possible it needed to store the value to stack for some other reason [20:01:47] <mru> still shouldn't have done the load [20:02:08] <_av500_> maybe the part on the stack is declared volatile? [20:02:26] <mru> it's problem with how gcc works internally [20:02:43] <mru> it decided that it had to go onto the stack, perhaps even validly [20:02:49] <mru> now the value lives on the stack [20:03:24] <mru> the next rtl expression needs the value, and because it lives on the stack, it goes and loads it [20:03:47] <mru> when it was stored to stack, the old register got marked unused [20:04:08] <mru> for the load, the register allocator chose another register (randomly) [20:04:25] <mru> had it chosen the same one, some peephole optimisation might have eliminated the load [20:04:37] <mru> this is very annoying in gcc [20:05:30] <lu_zero> they are working on the third iteration of that part of code in few years... [20:05:31] <neerfri> Hi All, sorry to interupt, small question, in ffmpeg.c, AVInputStream->pts is saved as time in AV_TIME_BASE right ? [20:05:31] <mru> it can be interesting to dump the rtl between each optimisation pass and watch it morph [20:05:42] <Dark_Shikari> mru: wow, this is even better [20:05:43] <Dark_Shikari> 04:05 < derf> What's fun is it then proceeds to use the copy in _both_ r0 and r4. [20:05:45] <lu_zero> neerfri: should be documented that way [20:05:59] <mru> hmm, so the register wasn't dead after all [20:06:08] <elenril> peloverde: does aacdec do downmixing? [20:06:22] <_av500_> no [20:06:25] <peloverde> elenril: no that would be retarded [20:06:33] <neerfri> lu_zero: yup, right now it only says: /* current pts */ [20:06:34] <_av500_> special! [20:06:42] <peloverde> There is noting format specific about downmixing in an aac encoder [20:06:46] <mru> Dark_Shikari: the rtl for that could be interesting [20:06:47] <peloverde> *nothing [20:06:56] <elenril> i thought it was supposed to be done by decoders [20:06:58] <elenril> nvm then [20:07:01] <mru> peloverde: he said dec [20:07:08] <peloverde> oh sorry [20:07:11] <peloverde> I'm dumb [20:07:12] <mru> ac3 and dts can downmix before transform [20:07:21] * _av500_ loves that [20:07:35] <peloverde> In hte general case AAC can't [20:07:39] <mru> if aac doesn't allow that, there's no point in doing any mixing in decoder [20:07:49] <mru> _av500_: would you like to do it faster? [20:08:07] <_av500_> which one? [20:08:21] <mru> let's say dts [20:08:23] <_av500_> i thought i had all your DTS love? [20:08:39] <mru> the downmixing can be made faster [20:08:42] <peloverde> HE-AAC can downmix during SBR synthesis in theory [20:09:08] <mru> _av500_: you have the bulk of what's possible [20:09:18] <_av500_> thx :) [20:09:18] <mru> the qmf filter was by far the most time consuming [20:09:51] <peloverde> Would people be interested in SBR domain downmixing? [20:10:17] <Dark_Shikari> mru: do modern ARM chips have store/load forwarding? [20:10:31] <mru> yes [20:10:32] <Dark_Shikari> how does it compare to the absurd level that x86 has? [20:12:53] <peloverde> Have people heard of tooboos? They seem a little shady [20:12:59] <Dark_Shikari> tooboos? [20:13:02] <mru> peloverde: he came to you now? [20:13:27] <peloverde> so I should avoid him? [20:13:43] <mru> I don't know anything about them [20:14:17] <mru> I don't have time anyway [20:14:31] <lu_zero> peloverde: they contacted me as well [20:14:47] <peloverde> I'm always a little skeptical about russian and chineese companies [20:16:04] <lu_zero> peloverde: they asked you about some quick reformat from spark? [20:16:13] <peloverde> yeah [20:16:23] <lu_zero> (that isn't _that_ quick from what I read) [20:17:05] <_av500_> mru: they are looking for a flash developer :) [20:17:34] <_av500_> anda java dev [20:25:44] <Compn> so is there some recipe for a bikeshed or do the blueprints for such threads get made on the fly ? [20:25:58] <Compn> short demuxer names been around for a while, good time to shed it up! [20:26:25] <mru> peloverde: go ahead with the patch if you think it's good [20:27:49] <BBB> Dark_Shikari: can you re-say all problems with my patch? [20:27:53] <BBB> Dark_Shikari: my chatlog disappeared [20:28:33] <BBB> or maybe it didn't [20:28:35] <BBB> hold on [20:28:54] <Dark_Shikari> go read the official log then [20:28:55] <Dark_Shikari> I don't keep logs [20:30:12] <Dark_Shikari> mru: more fun [20:30:12] <Dark_Shikari> 04:29 < derf> mov r1, r7, asl #1 [20:30:13] <Dark_Shikari> 04:29 < derf> ldrsh r5, [fp, r1] [20:30:13] <Dark_Shikari> 04:30 < derf> (r1 is then subsequently clobbered before being used again) [20:30:37] <mru> shift could be done in the ldr [20:30:43] <mru> gcc doesn't seem to like doing that [20:30:49] <mru> not the first time I've seen this [20:30:49] <Dark_Shikari> yeah. it really doesn't. [20:31:07] <Dark_Shikari> GCC doesn't seem to ever use the free shift unless the shift ends up next to the op in the RTL [20:31:17] <Dark_Shikari> e.g. it'll optimize x >> 2; x += 5; [20:31:27] <Dark_Shikari> but it won't optimize x>>=2; y>>=2; x+=5; y+=5; [20:31:43] <mru> that really sucks [20:31:54] <Yuvi> 4.4 should be a lot better with using free shifts [20:32:04] <Dark_Shikari> 04:31 < derf> gcc (Gentoo 4.5.0 p1.1) 4.5.0 [20:32:04] <mru> 4.4 generates 25% slower code [20:32:11] <mru> 4.5 is back at 4.3 speed [20:32:19] <Dark_Shikari> mru: odd/even rule [20:32:26] <Dark_Shikari> the opposite of Star Trek [20:32:46] <mru> 3.4 was alright [20:32:53] <Dark_Shikari> well yeah [20:32:55] <Dark_Shikari> it only applies to 4. [20:32:56] <mru> so it's odd parity [20:33:07] <Dark_Shikari> Ah, true [20:33:10] <Dark_Shikari> so it's the parity of the whole expression. [20:33:19] <Dark_Shikari> that's why 2.9 was good [20:33:23] <_av500_> 2.9.5 is even [20:33:30] <mru> it's 2.95 [20:33:31] <Dark_Shikari> we ignore micro numbers for this purpose. [20:33:33] <mru> so still odd [20:33:41] <mru> the micro numbers generally improve things [20:33:44] <Dark_Shikari> Yeah [20:33:47] <Dark_Shikari> They're bugfixes mostly [20:33:50] <mru> .0 is full of bugs [20:33:56] <mru> .1 compiles most things [20:34:00] <mru> .2 is almost usable [20:34:10] <_av500_> lol: #define VIDDEC_ZERO 0 [20:34:16] <mru> .3 is stable enough to use [20:34:19] <_av500_> #define VIDDEC_ONE 1 [20:34:25] <_av500_> #define VIDDEC_MINUS -1 [20:34:26] <mru> lol [20:34:27] <Dark_Shikari> _av500_: corporate policies of no numeric constants [20:34:39] <mru> Dark_Shikari: love those policies [20:34:42] <_av500_> bangalore style [20:34:52] <mru> but they forgot to write (0) [20:35:08] <mru> because someone told them to always put parens around macros [20:35:43] <_av500_> better put ((0)), you never know what the pesky preproc will do [20:36:51] <_av500_> ha: OMX_U16 arr[100]; [20:36:59] <_av500_> pirate day? [20:38:08] <Dark_Shikari> wait [20:38:10] <Dark_Shikari> from the same code? [20:38:14] <_av500_> yes [20:38:16] <Dark_Shikari> the same code where they used defines to avoid cnostants? [20:38:22] <_av500_> yes [20:39:21] <_av500_> it gets better, they have #define FOO_BAR_MALLOC(..) macros which assume you have an EXIT: label in your code.... [20:39:22] <BBB> if I use m8 on x86-64, should I use cglobal name, args, regs, 9 or cglobal name, args, regs, 1? [20:39:42] <Dark_Shikari> 9 [20:39:52] <Dark_Shikari> however, it should only use 9 if you're on x86_64. [20:40:02] <Dark_Shikari> We should really modify x86inc.asm to clip the value to 8 on x86_32. [20:40:07] <Dark_Shikari> I wonder if it already does. [20:40:12] <Yuvi> does it do anything with it on 32-bit? [20:40:17] <Yuvi> I thought it only mattered for win64 [20:40:59] <Dark_Shikari> Oh [20:41:00] <Dark_Shikari> You're right [20:41:02] <Dark_Shikari> nevermind, so yeah [20:45:08] <BBB> so I can just always set it to 9? [20:45:10] <BBB> that's great :) [20:48:21] <BBB> Dark_Shikari: the pshufb sse3 version, can I do that in a separate commit? [20:48:26] <Dark_Shikari> Sure. [20:48:28] <BBB> it'll need a sse3 version of the simple loopfilter also [20:48:32] <BBB> and that is all unrelated [20:48:36] <BBB> hence separate is better maybe [20:48:39] <Dark_Shikari> That's fine./ [20:48:46] <BBB> ok, so pb_80 is in m8 now on x86-64 [20:48:48] <BBB> (untested) [20:48:58] <Dark_Shikari> btw, eventually we should do some basic atom optimizations, i.e. not doing pshufb on atom [20:49:08] <Dark_Shikari> pshufb takes 6 cycles, unpipelined, on atom. [20:50:17] <BBB> I wonder what the advantage is of using m9-15 instead of stack if I only use it once, sicne (at least on win64), I need to push to the stack anyway (+pop) to use m9-15 [20:50:44] <BBB> I guess "it's only better on linux/mac"? [20:51:18] <Yuvi> don't you use it at least 6 times? [20:51:33] <BBB> pb_80, yes [20:51:35] <BBB> the others, no [20:51:41] <BBB> I already changed pb_80 [20:51:48] <BBB> I wonder if I should change the others [20:51:56] <Dark_Shikari> the others, you shouldn't do it [20:52:00] <Dark_Shikari> only for things you use more than once [20:52:14] <BBB> I mean "stuff I save to the stack", btw [20:52:27] <Dark_Shikari> Yes, you should. [20:52:48] <BBB> ok, let me rewrite some of that stuff then [20:53:12] <BBB> %ifdef m8 is fine to abuse as a "if sse2 && x86-64"? [20:54:31] <Dark_Shikari> Yes [20:54:52] <Dark_Shikari> It's not really abuse, it's more correct [20:54:56] <Dark_Shikari> because you want to use m8 "if it's available" [20:55:01] <Dark_Shikari> not "if it's x86_64 and sse2" [20:55:07] <Dark_Shikari> it just happens that the latter are cases where "it is available" [20:55:25] <BBB> probably, yeah [20:56:10] <Yuvi> h264 does edge extension from fpel positions, right? [20:56:19] <Dark_Shikari> huh? [20:56:39] <Dark_Shikari> it says "any pixel beyond the edge is defined as equal to the closest valid pixel" [21:08:57] <Yuvi> but only for actual pixels, and then all subpel is done from that? [21:12:24] <Dark_Shikari> yes [21:17:52] <pengvado> peloverde: why can't aac downmix? [21:18:26] <_av500_> no patch sent? [21:26:50] <BBB> Dark_Shikari: can you test this for me? [21:26:53] <BBB> I have no idea if it works [21:27:08] <BBB> I can put the patch on pastebin or so if you want to test or review or neither [21:27:40] <BBB> or I can commit and check fate and cry foul if it breaks [21:27:43] <BBB> and say it's your fault [21:27:44] <BBB> or so [21:34:44] <Dark_Shikari> test what [21:36:09] <BBB> my x86-64 part of the inner loopfilter [21:36:18] <BBB> it's a little different so it probably needs testing [21:36:38] * BBB wonders if a coreduo is 64bit [21:36:41] <BBB> probably not right? [21:36:59] <Dark_Shikari> no [21:37:03] <Dark_Shikari> and again [21:37:04] <Dark_Shikari> test what [21:37:06] <Dark_Shikari> I don't see a link [21:37:54] <BBB> http://ffmpeg.pastebin.com/KEn3hn7K [21:38:27] <pJok> BBB, coreduo lacks 64bit [21:38:58] <Dark_Shikari> oh, I can't test it. I don't have enough ram to open my ubuntu vm. [21:39:06] <Dark_Shikari> someone else here will have to. [21:39:08] <Dark_Shikari> Or just commit. [21:39:21] * BBB looks for random x86-64 victim [21:39:24] <BBB> mru!~ [21:39:40] <lu_zero> BBB: what do you need? [21:39:55] * lu_zero is still fetching the test traces from cairo... [21:40:07] <BBB> lu_zero: test the above patch (versus current SVN) to make sure output against the vp8 test suite is identical [21:40:24] <lu_zero> tell me how step by step [21:40:30] <lu_zero> I'm sleeping more or less [21:40:46] <BBB> Run this: [21:40:46] <BBB> http://ffmpeg.pastebin.com/ZsYJH4xq [21:41:06] <BBB> samples are vp8-test-vectors-r1 google first result [21:41:27] <BBB> so download samples somewhere, tell script where the samples are, run ./test.sh [21:41:32] <BBB> copy test.md5s to ref.md5s [21:41:34] <BBB> apply my patch [21:41:37] <BBB> and re-run the script [21:41:49] <BBB> test.md5s and ref.md5s should be identical on x86-64 [21:43:26] <lu_zero> test.sh ? [21:44:09] <lu_zero> or run_test.sh? [21:46:52] <BBB> anything you like [21:46:58] <BBB> you can call it lu_zero.sh [21:47:30] <lu_zero> BBB: which script... [21:47:38] <BBB> http://ffmpeg.pastebin.com/ZsYJH4xq [21:48:07] <lu_zero> ahhh [21:48:08] <lu_zero> =_= [21:48:35] <Dark_Shikari> BBB: suggestion re lines 439-453 [21:48:47] <Dark_Shikari> is there any way to delay the calculation of m1 more [21:48:51] <Dark_Shikari> to get m7 finished earlier? [21:48:54] <Dark_Shikari> to limit the dependency chain? [21:49:14] <Dark_Shikari> Or, equally, to make m7 calculation start earlier [21:49:51] <BBB> I'm very short of registers there [21:50:06] <Dark_Shikari> k [21:50:39] <Dark_Shikari> 385-389 ... might this not be simpler if we just didn't have an mmx version on x86_64? [21:50:45] <Dark_Shikari> there's no x86_64 cpu that could possibly need it [21:50:48] <Dark_Shikari> we could dump mmxext there too [21:51:01] <lu_zero> Results identical [21:51:06] <lu_zero> apparently [21:51:11] <Dark_Shikari> \o/ [21:51:12] <BBB> lu_zero: x86-64, 64-bit binary? [21:51:13] <BBB> thanks :) [21:51:17] <lu_zero> yup [21:51:39] <BBB> Dark_Shikari: I'll have to write a few ifdefs in various places to dump the mmx/mmxext versions on x86-64, also in vp8dsp-init.c [21:52:01] <Dark_Shikari> I guess. ok [21:52:02] <BBB> I don't think 385-389 will get easier [21:52:09] <BBB> because it needs that mova on mmx/x86-32, still [21:52:22] <BBB> did I mention SWAP is amazing? [21:52:37] <BBB> whoever invented SWAP should get a nobel prize [21:52:40] <Dark_Shikari> lol [21:52:43] <Dark_Shikari> that would be pengvado :) [21:53:18] <Dark_Shikari> It's even more helpful in DCTs. [21:53:45] <Dark_Shikari> lines 237-240 ... I'm confused here. don't we want 3 pixels on each side, not 2? [21:53:55] <Dark_Shikari> "-2" [21:54:13] <BBB> 4 left, 3 right [21:54:17] <BBB> so it's actually -4 [21:54:25] <Dark_Shikari> why is it -2 then [21:54:34] <BBB> check line 165 [21:54:41] <Dark_Shikari> Why not lea -4 ? [21:54:45] <Dark_Shikari> instead of -2 [21:54:55] <BBB> that way the movd in the end needs no const offset [21:55:00] <BBB> to write four pixels per row [21:55:02] <Dark_Shikari> Just add an extra add [21:55:13] <Dark_Shikari> every single constant offset wastes one byte of code size [21:55:37] <Dark_Shikari> i.e. do -4 at the start in the lea [21:55:41] <Dark_Shikari> and do an "add blah, 2" later [21:55:48] <Dark_Shikari> Unless that would involve multiple adds due to the multiple pointers [21:56:05] <BBB> for mmx, I do two loops, 8 rows per loop [21:56:15] <BBB> so I'd need an add 2, and then a sub 2 later [21:56:15] <Dark_Shikari> and? [21:56:18] <BBB> is taht ok? [21:56:36] <BBB> actually maybe I don't... let me check, I can probably fix that [21:56:42] <BBB> you're probably right [21:58:17] <Dark_Shikari> 444-445: maybe swaps? [21:58:21] <Dark_Shikari> I mean after. [21:59:57] <Dark_Shikari> 509-512: interleave [22:00:42] <CIA-99> ffmpeg: mru * r24249 /trunk/libavcodec/arm/h264dsp_neon.S: ARM: NEON H264 chroma loop filter 3 cycles faster [22:04:09] <Dark_Shikari> BBB: 182-188 should be movu [22:04:18] <Dark_Shikari> Doesn't change the output, it's just more correct. [22:06:07] <Dark_Shikari> 281-303: can any of this be more interleaved? [22:08:47] <BBB> ok, I fixed the -2 thing [22:08:52] <BBB> it's all without const now [22:09:00] <BBB> I had to change one add to a lea and add two adds [22:09:02] <BBB> is that ok? [22:09:48] <BBB> 444-445 need to stay that way, I need to keep a backup of these, I use them far below [22:09:52] <BBB> they are q1/p1 [22:10:02] <BBB> which I backup so I can add the filter result to it in the end [22:12:05] <BBB> movu, you mean movq? [22:12:13] <BBB> (509-512 interleave done) [22:13:47] <BBB> 281-303 is again register-sparse, if you have ideas on how to interleave I'd love to hear it... maybe my approach is crazy :) [22:15:59] <pengvado> I don't think "sparse" is the word you're looking for [22:17:17] <BBB> I have no registers left [22:20:24] <BBB> what is movu? [22:20:30] <Dark_Shikari> move unaligned [22:20:50] <Dark_Shikari> 444-445: I mean using a swap so that you don't use the output of the mova immediately after [22:22:21] <Dark_Shikari> like everywhere else. [22:22:24] <Dark_Shikari> if only for consistency. [22:22:56] <Dark_Shikari> re aligning the stack -- that doesn't need to be done on 64-bit [22:23:47] <Dark_Shikari> pengvado: does WIN64 have the red zone? [22:24:04] <Dark_Shikari> BBB: the "red zone" is 128 bytes below rsp which are valid and can be used. [22:24:10] <Dark_Shikari> thus you don't have to sub rsp if you're using fewer than 128 byets on x8_64. [22:24:13] <Dark_Shikari> *x86_64 [22:25:50] <Dark_Shikari> ok, win64 doesn't have the red zone, *nix64 does [22:25:57] <Dark_Shikari> so you can avoid the sub on *nix64. [22:29:07] <Dark_Shikari> BBB: flim_E and flim_I are only used once. you don't need to put them on the stack; just calculate them on the fly when they're needed. [22:30:10] <Dark_Shikari> oh, you can't do that because you overwrite the gprs [22:37:58] <BBB> Dark_Shikari: 444-445 aaa I see, is that necessary even though there's another mova in between? [22:38:05] <BBB> I thought that would negate any potential effect [22:38:55] <Dark_Shikari> I guess it doesn't matter. [22:38:58] <BBB> Dark_Shikari: and E/I aren't used once in the mmx/mmxext case [22:39:00] <BBB> they're used twice [22:39:14] <Dark_Shikari> and it doesn't matter per what I said [22:39:15] <Dark_Shikari> re registers [22:39:22] <Dark_Shikari> now what you should fix is the redzone [22:39:43] <BBB> first movu [22:40:05] <BBB> so I should use movu if I read unaligned from memory? [22:40:26] <BBB> is movu 8-byte, a-size or something else? [22:40:27] <Dark_Shikari> yes.... [22:40:50] <Dark_Shikari> it's a-size [22:41:05] <BBB> ok, so these reads are 8-bytes in the mmsize=16 case [22:41:08] <BBB> what do I use then? [22:41:35] <Dark_Shikari> movh [22:42:06] <BBB> ok, got it [22:42:54] <BBB> I can assume the reads in 174-179 are aligned, right? [22:42:59] <BBB> (I think so at least) [22:43:14] <Dark_Shikari> Yes. [22:43:19] <Dark_Shikari> Otherwise it would crash. [22:43:23] <BBB> ok, fixed that [22:43:46] <BBB> now redzone [22:44:02] <BBB> the stack isn't aligned on 64bit btw [22:44:06] <BBB> I don't use the stack on 64bit [22:44:15] <Dark_Shikari> ah ok [22:44:25] <BBB> that whole block is %ifndef m8 [22:44:30] <Dark_Shikari> also, whenever I think of the red zone, I can't avoid hearing http://www.youtube.com/watch?v=zliubqahaZM [22:44:42] <Dark_Shikari> BBB: ok, great. [22:44:48] <Dark_Shikari> I think that covers everything. [22:44:52] <Dark_Shikari> er.... [22:45:07] <Dark_Shikari> oh nvermind [22:45:10] <Dark_Shikari> thought I saw something else [22:45:39] <BBB> time to commit then? [22:45:45] <BBB> then I can move on to finishing mbedge [22:45:54] <Dark_Shikari> Looks good. This is the most important asm function in vp8 imo [22:46:01] <BBB> this, and mbedge [22:46:14] <BBB> together they are 60% of my callgraph [22:46:20] <Dark_Shikari> oh, one thing [22:46:25] <Dark_Shikari> 412-413 [22:46:30] <Dark_Shikari> shouldn't you only have to make one copy there, not two? [22:46:37] <Dark_Shikari> e.g. [22:46:39] <Dark_Shikari> tmp = q0 [22:46:44] <Dark_Shikari> q0 -= p0 [22:46:47] <Dark_Shikari> p0 -= tmp [22:47:48] <BBB> then I lose p0 [22:47:55] <Dark_Shikari> Unless you need p0/q0 around for later. [22:47:56] <BBB> I need p0 to add the filter result to later on [22:47:56] <Dark_Shikari> Oh [22:47:57] <Dark_Shikari> Ah [22:47:58] <Dark_Shikari> ok [22:48:07] <BBB> m2-m5 are the holy grail in the function [22:48:11] <BBB> "they shall not be touched" [22:48:17] <BBB> or so [22:48:29] <Dark_Shikari> you shall not touch [22:48:32] <Dark_Shikari> </gandalf> [22:48:40] <BBB> that was pass, not touch :) [22:49:03] <Dark_Shikari> it could probably use a comment about that [22:49:05] <Dark_Shikari> I know [22:49:18] <BBB> I'll add a comment [22:49:55] <BBB> done [22:50:09] <BBB> anything else? [22:50:41] <Dark_Shikari> Looks good to me. [22:50:42] <BBB> <itchy fngers> [22:50:47] <BBB> let's commit \o/ [22:51:09] <Dark_Shikari> do a new profile after :) [22:51:15] <Dark_Shikari> Oh yeah, we need to do chroma [22:51:17] <Dark_Shikari> mbedge first, or chroma first? [22:51:22] <Dark_Shikari> I think chroma first, it's less work than a whole new filter [22:53:15] <neerfri> Dark_Shikari: Hi ! posted a question in #ffmpeg, your asnwer on this can probably save me a few days of work, if you can please have a look [22:56:16] <BBB> Dark_Shikari: I wanted to do mbedge first because it's more complex ;) [22:56:23] <bcoudurier> humm [22:56:30] <Dark_Shikari> lol [22:56:33] <Dark_Shikari> do the easier ones first [22:56:37] <bcoudurier> does anybody follow the thesis vs wordpress issue ? [22:57:26] <Dark_Shikari> BBB: the priority of any asm function is (speed benefit) / (time to write it) [22:57:38] <BBB> uh... ok [22:57:48] <BBB> chroma then [22:58:03] <Dark_Shikari> It makes sense, right? [22:58:04] <BBB> you wanted me to make it call U/V in a single go with two pointer arguments right? [22:58:07] <Dark_Shikari> Yes. [22:58:12] <Dark_Shikari> So all that changes is the transpose. [22:58:19] <Dark_Shikari> well, basically the Stuff On The Top [22:58:21] <Dark_Shikari> and Stuff On The Bottom [22:58:24] <BBB> right [22:58:27] <Dark_Shikari> the mmx one just loops over the two. [22:58:31] <Dark_Shikari> the sse one merges them, then unmerges. [22:58:42] <BBB> got it [23:03:27] <CIA-99> ffmpeg: rbultje * r24250 /trunk/libavcodec/x86/ (vp8dsp.asm dsputil_mmx.c vp8dsp-init.c dsputil_mmx.h): VP8 H/V inner loopfilter MMX/MMXEXT/SSE2 optimizations. [23:03:33] <Dark_Shikari> \o/ \o/ \o/ [23:04:16] <BBB> \o/ indeed [23:04:18] <BBB> on to chroma [23:04:23] <BBB> or, actually, on to home [23:04:26] <BBB> wife is waiting [23:16:00] <peloverde> janneg: LATM ping? [23:17:52] <iive> so vp8 now have complete set of asm routines? [23:17:56] <Dark_Shikari> No. [23:18:01] <Dark_Shikari> mbedge and chroma and chroma mbedge still need to be done. [23:18:03] <Dark_Shikari> 3 more. [23:18:07] <Dark_Shikari> well, 6 counting both directions. [23:18:30] <iive> oh... [23:19:32] * iive puts back the champagne. [23:19:58] <iive> have fun [23:50:51] <Dark_Shikari> Yuvi: Wait, why can't deblocking be done until after two rows are done? [23:51:00] <Dark_Shikari> that can't be right. [23:51:35] <Yuvi> Dark_Shikari: intra pred, I started with the border saving but didn't get it bitexact [23:51:45] <Dark_Shikari> Oh. Intra pred. [23:52:17] <Yuvi> http://pastie.org/1046472 <- current patch [23:52:28] <Dark_Shikari> I was doing the filter strength hack. [23:54:05] <Dark_Shikari> shouldn't you kill lines 141-143? [23:55:28] <Yuvi> yeah [23:55:48] <Dark_Shikari> what's with the if(tr)? I thought tr was a separate argument? [23:56:59] <Yuvi> whether the mb is on the right edge -> should exchange tr too [23:57:04] <Dark_Shikari> no, I mean in intra pred [23:57:10] <Dark_Shikari> topright is a separate argument to the itnra pred functions [23:57:26] <Yuvi> yeah [23:58:06] <Dark_Shikari> also, are you handling the right-side case correctly? [23:58:12] <Dark_Shikari> you still have to have something there for that case [23:58:38] <Yuvi> it's always the same for all 4 blocks on the right, edge extended from the row to the top [23:58:40] <Yuvi> maybe not

1 0

IRC log for 2010-07-14
by irc＠mansr.com 15 Jul '10

15 Jul '10

[00:03:00] <lu_zero> doing [00:05:24] <lu_zero> http://ffmpeg.pastebin.ca/1900165 [00:05:33] <lu_zero> hi mchinen_ [00:05:47] <mchinen_> hey [00:06:34] <mchinen_> what's jason ruggle's handle? [00:07:16] <kierank> jbr or jbruggles [00:09:12] <mchinen> there was a flac parser patch from him posted to the ml in march 2009 that never got committed, anyone hear more about this? [00:10:06] <lu_zero> uhm interesting vlc wiki disappeared [00:10:14] <hyc> what kind of overflow is this talking about? [msmpeg4 @ 0x30f6770] ignoring overflow at 17 8 [00:10:38] <hyc> and since it was logged in red, should I also ignore it or not? [00:12:30] <lu_zero> Honoome: managed to reproduce it? [00:12:47] <Honoome> lu_zero: give me a sec I'm sending out a bunch of bug reports [00:13:53] <lu_zero> ok [00:21:38] <saintdev> peloverde: can you have a long_stop followed by a long_start? [00:21:55] <peloverde> yes [00:22:28] <saintdev> ok, so you don't have to have a short between the two (i realize i have them reversed :P) [00:22:50] <peloverde> START STOP is also legal but probably stupid [00:26:17] <saintdev> yeah, that's what i meant [00:33:54] <j0sh> is it just me, or is wireshark like, really, REALLY bad at tracing rtmp packets? [00:36:21] <Honoome> j0sh: define that? [00:50:18] <j0sh> Honoome: half the time it doesn't decode packets properly [00:50:33] <Honoome> maybe the dissector is incomplete [00:50:47] <j0sh> gets messed up in the middle of strings (double-S'es), which throws off everything [00:51:31] <j0sh> and it doesn't properly mark all rtmp packets as such, which took me a looooong time to realize when i was filtering [00:52:12] <hyc> yeah, wireshark's rtmp decoder sucks [00:53:04] <j0sh> hyc: how feasible do youthink it would be to use librtmp in an evented server [00:55:03] <j0sh> i'm using it right now and it's blocking on reads, but i don't know if it's just because my server implementation is incomplete [01:01:26] <Honoome> j0sh: can I make use of your better knowledge of rtsp in ffmpeg? :) [01:02:07] <j0sh> Honoome: yeah i really shoould get back on that. havent done any gsoc work in like, a week [01:02:39] <Honoome> don't worry, it shouldn't be much about that ;) [01:03:05] <Honoome> Luca found that the start time for rtsp stream get set negative [01:03:48] <j0sh> ah [01:03:57] <j0sh> hope it wasn't something i broke, heh [01:03:59] <Honoome> he tracked it down to av_update_streams_timing, I tracked it down to update_initial_timestamps further [01:13:18] <bgentry> hi everyone... I understand there is work underway for ffmpeg to handle generic downmixing, i.e. allowing AAC 6ch => AAC 2ch using the built-in ffaac decoder ? [01:15:32] <Honoome> j0sh: where is the packet_buffer set? rtsp? [01:18:48] <peloverde> bgentry: yes, but that will occur outside of the AAC decoder but still inside FFmpeg [01:19:25] <bgentry> peloverde: yes, that's what I was wondering.. as of right now, I can accomplish that downmix using libfaad in an old ffmpeg build but not with the newest trunk builds [01:20:08] <peloverde> There is a generic remixing/resampling interface being discussed [01:20:10] <j0sh> Honoome: packet buffer? [01:20:31] <bgentry> peloverde: still pretty far off though? [01:21:01] <peloverde> yes it's still kind of far off [01:21:17] <Honoome> j0sh: okay tracked it down a bit further: finalize_packet into rtpdec.c, sets the pts to -115 and -119 [01:21:30] <peloverde> in the interim you can pipe ffmpeg output to sox to remix and then back to ffmpeg to encode (ugly, i know) [01:21:43] <kierank> mplayer has a downmixer iirc [01:22:09] <Honoome> delta_timestamp is negative [01:22:47] <j0sh> under what conditions? [01:23:22] <Honoome> seems like always at the start of the run [01:23:37] <Honoome> http://ffmpeg.pastebin.ca/1900165 and see query [01:23:55] <j0sh> for all codecs? [01:24:08] <Honoome> that's a good question [01:24:38] <j0sh> Honoome: brb, gotta go eat [01:25:32] <bgentry> peloverde: any reason i shouldn't use libfaad for that purpose? [01:27:41] <peloverde> Libfaad is slow, you are required to figure out the actual channel count on your own since it upmixes mono to stereo by default, libfaad is less conformant, libfaad does not support some complicated multichannel scenarios at all (not just remixing wise) [01:28:44] <bgentry> those are good reasons =) [01:28:59] <bgentry> not familiar with sox but i will try and figure that out [01:29:09] <Honoome> okay it seems like we've got a problem either sending rtcp or decoding rtcp [01:45:24] <peloverde> I really wish 26.403 had a theory section [01:46:21] <Honoome> I really wish that they didn't call it Normal Play Time since the NPT vs NTP mistakes are present even in the RFC2326 itself [02:46:47] <peloverde> I think I found a bug, and it is more rewarding than /. [02:47:42] <saintd3v> peloverde: is tns part of lc, or just main? [02:47:47] <peloverde> LC [02:48:11] <peloverde> Why all the interest in AAC all of the sudden? [02:48:21] <saintd3v> why not? :P [03:02:05] <peloverde> Does anyone who knows psy know why end up averaging adjacent barks? [03:03:10] <Dark_Shikari> "why end up averaging" [03:03:13] <Dark_Shikari> what I can't parse that sentence [03:03:30] <peloverde> why we [03:03:39] <peloverde> Does anyone who knows psy know why we end up averaging adjacent barks? [03:04:13] <Dark_Shikari> averaging what in the adjacent barks? [03:05:47] <peloverde> Averaging like a smoothing filter [03:06:12] <peloverde> We calculate barks with "13.3f * atanf(0.00076f * f) + 3.5f * atanf((f / 7500.0f) * (f / 7500.0f))" which I understand [03:06:53] <Dark_Shikari> averaging WHAT [03:06:56] <Dark_Shikari> averaging... weights? [03:06:58] <Dark_Shikari> averaging... energies? [03:07:07] <Dark_Shikari> averaging... numbers of G20 protestors? [03:07:19] <peloverde> jesus give me a second, I'm trying to think this through [03:07:57] <peloverde> coeffs->barks[g] = (barks[i - 1] + prev) / 2.0 [03:08:05] <peloverde> prev = barks[i - 1] [03:08:17] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/aacpsy.c;h=466b0e9a1a73… [03:09:10] <Dark_Shikari> a lowpass filter over the barks I guess? [03:09:18] <peloverde> yes, why? [03:10:08] <peloverde> And why do we use the same scale for short and long windows such that the top long sfb is in bark 25 and the top short sfb is only in bark 14 [03:10:26] <Dark_Shikari> ask the person who wrote it [04:09:28] * peloverde glares angrily at git-svn [04:11:08] <peloverde> It worked! [04:11:22] <CIA-99> ffmpeg: alexc * r24230 /trunk/libavcodec/aacpsy.c: aacenc: psy_3gpp_init(): Calculate barks on demand. [04:11:23] <CIA-99> ffmpeg: alexc * r24231 /trunk/libavcodec/aacpsy.c: [04:11:23] <CIA-99> ffmpeg: aacenc: psy_3gpp_init(): Fix ath for the first line in each sfb. [04:11:23] <CIA-99> ffmpeg: Fix the MDCT line to frequency calculation for the first line in each sfb. [04:11:23] <CIA-99> ffmpeg: Use this value to calculate ATH. [04:11:24] <CIA-99> ffmpeg: alexc * r24232 /trunk/libavcodec/aacpsy.c: aacenc: aac_psy_init(): Factorize line_to_frequency. [04:11:25] <CIA-99> ffmpeg: alexc * r24233 /trunk/libavcodec/aacpsy.c: aacenc: psy_3gpp_init(): Fix line_to_frequency for short windows. [04:20:45] <peloverde> And my reward is that I get to move on to this wonderful artifact: http://i.imgur.com/jlLF4.png [04:21:16] <saintdev> oh wow, lol [07:09:04] <peloverde> wow, that bug might actually be in the TLS [07:09:26] <kshishkov> TLS as in secure sockets? [07:09:36] <peloverde> TLS as in two loop search [07:09:41] <peloverde> search_for_quantizers_twoloop() [07:09:59] <kshishkov> ah, MPEG-2 NBC model [07:10:30] <peloverde> which means in this case psy is behaving [07:11:30] <kshishkov> behaving how? [07:11:41] * kshishkov fears to hear "behaving properly" [07:12:08] <peloverde> Like not using long window line to bark conversions for short windows? [07:44:03] <av500> peloverde: "Firefogg is build using ffmpeg2theora and FFmpeg" [07:44:12] <av500> not "built"? [07:44:42] <peloverde> close enough [07:46:24] * Honoome hates on the rtp/rtsp specs! [07:47:01] <kshishkov> Honoome: please give some hate to RTMP specs as well [07:47:18] <Honoome> kshishkov: do they juggle between NTP and NPT as name for timestamps as well? [07:48:02] <kshishkov> Honoome: no, but good luck figuring out timestamps there at all [07:48:12] <mru> why stop there? you could have PNT, PTN, TNP, TPN, ... [07:48:20] <Honoome> rfc2326 sometimes mistypes NPT in NTP [07:48:28] <mru> send them some TNT [07:48:30] <av500> NPN, PNP [07:48:42] <mru> NMOS [07:48:53] <av500> ECL? [07:48:55] <peloverde> JFET [07:49:02] <av500> tubes [07:49:04] <mru> IGBT [07:49:14] <kshishkov> CRT [07:49:19] <mru> LGBT? [07:49:30] <av500> YGBKM [07:49:30] <kshishkov> sounds like PRNG [07:50:33] <saintdev> AES [07:50:44] <av500> triple rot13 [07:51:12] <mru> but make sure to do the second rot13 _anticlockwise_ [07:51:16] <mru> otherwise it doesn't work [07:51:31] <av500> of course, and we run it twice for extra security [07:52:01] <cartman> LGTM [07:52:01] <kshishkov> New Optimized Permutation [07:52:32] <mru> LMGTFY [07:52:39] <av500> HDMITX_CALLBACK_INT_EDID_BLK_READ [07:52:54] * kshishkov once was responsible to know all abbreviations [07:53:25] <kshishkov> still better than remember all function graphics [07:53:54] <saintdev> av500: ECB 3-ROT13? [07:54:09] <av500> psst... [07:54:49] <saintdev> CBC then? [07:55:06] <mru> CDC [07:55:19] <kshishkov> DEC FTW [07:55:26] <av500> the computer or the diseace control? [07:55:34] <av500> c->s [07:56:24] * kshishkov looks at channel name - #medicine-sanitary [07:56:32] <kshishkov> yep, disease control [07:56:47] <twice11> how do you do CBC on ROT13? add letter numbers? [07:57:02] <mru> PDP [07:57:13] <kshishkov> VAX [07:57:14] <mru> or number the letters [07:58:55] <kshishkov> romans managed that without numbers [07:59:05] <kshishkov> heck, they even wrote numbers with letters [07:59:22] <kshishkov> (as many other ancient civilisations) [07:59:47] <av500> kshishkov: they used tricks: http://www.phy6.org/outreach/edu/roman.htm [08:00:02] <jai> hmm, so animated gifs no longer work [08:00:03] <lu_zero> wbs: I cannot find your patch about rtp-info [08:00:21] <mru> http://img.thedailywtf.com/images/mark/errord/062510/china.png [08:00:46] <mru> jai: animated gifs never worked, they always made you look like an idiot [08:01:15] <kshishkov> mru: but they ate trafic well on dialup, don't forget that [08:01:39] <jai> mru: well, atleast with olf ff* [08:01:45] <jai> seems like a regression [08:01:48] <jai> :) [08:02:41] <wbs> lu_zero: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-April/086465.html [08:03:24] <mru> http://www.textfiles.com/underconstruction/ [08:04:40] <av500> down for me [08:05:01] <mru> yeah, but you know what's there [08:05:20] <av500> http://webcache.googleusercontent.com/search?q=cache:2CaH_Hho520J:www.textf… [08:05:47] <av500> all urls broken too [08:07:03] <lu_zero> wbs: they might be _quite_ useful now =) [08:07:23] <av500> ahh, it loads! \\\ooo/// [08:07:37] <wbs> lu_zero: oh, good. :-) [08:11:00] <Honoome> wbs: read that as luca wanted me to debug an issue last night that was caused by lacking those :P [08:11:11] <wbs> Honoome: hah :-) [08:11:50] <av500> lol: "How come you know so much about Assembly? have you been coding Amiga demos or games?" [08:11:59] <av500> Dark_Shikari: admit it! [08:14:02] <Dark_Shikari> av500: lol [08:14:11] <lu_zero> wbs: ok the last two patches fixed a problem [08:14:47] <lu_zero> after fixing skip_spaces they could go in [08:14:47] <wbs> oh, nice [08:15:27] <wbs> iirc they were a bit ugly in some sense (storing a huge amount of parsing buffers in the rtsp context or something), but if you and BBB are ok with it [08:15:47] <wbs> I think I'd want to reread the patches yet before applying them, it's a while since I wrote them :-) [08:16:00] * lu_zero now should try to understand yet another strange issue [08:26:55] * j0sh waves at wbs and lu_zero [08:27:25] <wbs> j0sh: where's the updated qdm2 patch? :-) [08:27:38] <j0sh> aye, i know :( [08:28:02] <j0sh> ah, most of the changes you asked for were minor, let me do it right now [08:28:17] <wbs> shouldn't be much left on that, I'll apply the patches I sent at latest when the rest is cleared up [08:28:19] <wbs> yeah [08:28:29] <lu_zero> =) [08:28:31] <lu_zero> brb [08:29:33] <wbs> j0sh: and as next task, the qt depacketizer could be quite interesting, but probably also a bit messy. doing one or a few packetizers instead, so you get to write new code instead of just polishing up old things, is totally ok with me, too [08:30:16] <wbs> j0sh: but packetizers usually need to be ok'd by luca abeni, too, but I can review them to work out the initial details at least [08:30:34] <j0sh> wbs: ok, sounds good [08:30:53] <j0sh> would be nice to write some new code, so i'll do a packetizer [08:31:18] <wbs> as long as we get the qt depacketizer within the soc schedule, it's ok with me :-) [08:31:35] <j0sh> heh, alright [08:31:43] <j0sh> what exactly is preventing it from being committed in its current form? [08:31:56] <wbs> no idea, I've never read it through [08:32:17] <j0sh> alright [09:42:09] <Dark_Shikari> LOL @ michael's newest email [09:42:23] <ohsix> url [09:43:12] <Dark_Shikari> Re: [FFmpeg-devel] [FFmpeg-devel-irc] IRC log for 2010-07-09 [09:43:16] <Dark_Shikari> > [02:21:11] <saintdev> i vote pi = 2*C/D [09:43:17] <Dark_Shikari> C=acos(0) [09:43:17] <Dark_Shikari> D=1 [09:43:32] <ohsix> nice [09:44:23] <av500> #define C (acos(0)), no? [09:49:37] <kshishkov> C=atan(1) and D=0.5 will also work fine [09:50:50] <av500> now find all possible solutions [09:51:07] <av500> I just found them, but place to write it down.... [09:52:04] <twice11> ...the margin here is too small? [09:52:09] <av500> yeah [09:52:12] <kshishkov> there are infinite number of them [09:52:32] <av500> see :) [09:53:20] * kshishkov likes Euler's formula [09:53:45] <thresh> sounds like facebook to me! [09:54:02] <kshishkov> OK, back to trolling [10:15:11] <Honoome> hm faad is gone, right? [10:15:33] <Honoome> so we no longer upmix mono <22khz? [10:15:45] <mru> gone, removed, exiled, banished... [10:16:42] <Honoome> patch coming [10:28:13] <j0sh> wbs: qdm2 patch sent, i was scratching my head over that NOTS thing for a while [10:29:01] * janneg fährt meist nur 230km/h mit ICE, die Klimaanlage im verspätete n ICE samstagmittag war auch am rande ihrer kapazität [10:29:12] <janneg> upps [10:29:16] <j0sh> its 3:30am here, so my logic is probably strained [10:30:27] <av500> janneg: you goot cooked too? [10:31:13] <Honoome> j0sh: don't worry about the thing last night (when it was _my_ 3.30 :P), it was lu_zero who forgot some patches [10:31:57] <kshishkov> av500: next time you travel by train, take some dill with you - should give you better look [10:32:27] <av500> kshishkov: I only travel by train in extremely mild weather [10:32:28] <janneg> not really, it was ok in the cabin, but not enough to cool the parts between the coaches and at the doors [10:34:27] <janneg> the train had almost an hour delay because the original driver had a "hitzschlag" [10:34:33] <av500> lol [10:34:37] <kshishkov> better than Ukrainian "express" - you are not allowed to open windows and no noticeable ventilation in carriages [10:35:36] <av500> janneg: i guess they need to stock fresh drivers at all stations, like the pony express [10:35:38] <pross-au> Anyone watch the trans-siberian train video on google.ru ? [10:35:52] <av500> still watching it [10:36:14] <pross-au> Cool [10:36:44] <kshishkov> IIRC it takes a week to go from Moscow to Valdivostok by train [10:36:54] <kshishkov> and it was usually late by several days [10:37:12] <kshishkov> beat that, Deutsche Bahn! [10:37:13] <av500> make it late 7 days and its back on time [10:37:26] <janneg> av500: I think it was a fresh driver and he didn't made it to the train [10:38:07] <av500> "..Dear passengers, we have removed the dead driver, train starting any minute..." [10:39:47] <thresh> kshishkov: you cant buy a ticket from Moscow to Vladivostok [10:40:07] <thresh> well turns out I'm wrong [10:40:28] <av500> in soviet russia, ticket buys you.... [10:41:07] <j0sh> Honoome: no worries, i noticed your patch on -devel, glad u were able to track it down [10:41:09] <thresh> a couple of years ago, you couldnt buy a direct ticket, you would have a couple of transfers here and there [10:41:39] <thresh> but who in his sane mind would want to travel that far by train anyway [10:41:41] <Honoome> j0sh: that wasn't much of the issue, missing rtp-info was the problem :P wbs already sent a patch [10:41:50] <av500> thresh: ash cloud! [10:42:43] <pross-au> thresh: train lovers [10:43:18] <mru> the ash cloud is a conspiracy by the train lovers [10:43:27] <thresh> pross-au: seems like you never tried to travel in russian trains ;-) [10:43:46] <mru> the love in strong in some people... [10:43:49] <thresh> most of those do not have air conditioning, not telling about bio toilets [10:43:52] <thresh> talking [10:43:56] <kshishkov> thresh: ukrainian ones are reported to be in slightly worse conditions anyway [10:44:02] <pross-au> we're got our own public transport mess here [10:44:29] <thresh> my friends are now in a 24h long trip on a train and it's +35 outside [10:44:42] <thresh> i wonder how dead are they now [10:44:42] <kshishkov> thresh: dumping all shit ontol rail tracks is not considered "bio" anymore? [10:45:47] <mru> death is boolean [10:45:48] <kshishkov> thresh: форточки! [10:46:03] <kshishkov> mru: not for Norwegian Blue parrots [10:46:03] <mru> hmm, that has a nice ring to it [10:46:12] <mru> yeah, for them it's tristate [10:47:23] <Honoome> guh? [10:47:36] <kshishkov> dead/not dead/just resting [10:47:56] <Honoome> HE? o_O [10:48:13] <pross-au> 35degC sounds nice [10:48:23] <Honoome> pross-au: if you're a salamader [10:48:26] <mru> pross-au: only compared to 45 [10:48:53] <pross-au> Compared to 12 [10:49:01] <Honoome> compared to 12 I still prefer 12 [10:49:12] <mru> is 25 not an option? [10:49:14] <pross-au> Eek, that's the middle of winter [10:49:28] <Honoome> you can cover youself up from cold, it's difficult to strip further after being naked [10:49:28] <mru> pross-au: where you are it _is_ middle of winter [10:49:34] <pross-au> Nods [10:50:07] <mru> Honoome: heat has some nice side-effects [10:50:12] <Honoome> such as? [10:50:13] <kshishkov> Honoome: but like with debts you can shift heat somewhere else with some manipulations [10:50:14] <mru> like bringing out some skin in the girls [10:50:26] <Honoome> mru: that only works if you have girls around [10:52:33] <mru> Honoome: there are always some girls around [10:52:41] <mru> well, not in the office... [10:53:01] <kshishkov> expand your range for "around", there's main street not so far away [10:53:25] * Honoome lives lost in the middle of fields [10:53:39] <av500> nature girls... [10:54:17] <mru> kshishkov: so where are the x-ray goggles? [10:55:38] <kshishkov> mru: with my sight it makes no difference [10:56:36] <pross-au> You have built in x-ray vision kshishkov? Whoa. [10:57:17] <kshishkov> pross-au: nope [10:57:22] <wbs> j0sh: yes, go get some sleep already. ;P this needs yet another round, but there shouldn't be much left [11:14:03] <KotH> av500: ping [11:27:00] <av500> plong [11:28:04] <av500> KotH: ^^^ [11:41:08] <lu_zero> plang? [11:41:49] <mru> clang? [11:41:51] <Honoome> lu_zero: check my patch on -devel :P [11:41:56] <Honoome> mru: sunstudio [11:43:31] <lu_zero> Honoome: sure [11:44:00] * lu_zero it is a the top-ix looking at a strange kernel fault (.32) [11:48:33] <lu_zero> bbl [12:27:10] <CIA-99> ffmpeg: mstorsjo * r24234 /trunk/libavformat/ (rtpdec.h rtpdec.c): rtpdec: Allow depacketizers to specify that pkt->pts should be left as AV_NOPTS_VALUE [12:28:23] <CIA-99> ffmpeg: mstorsjo * r24235 /trunk/libavformat/rtpdec_svq3.c: [12:28:23] <CIA-99> ffmpeg: rtpdec_svq3: Return the timestamp in *timestamp instead of pkt->pts [12:28:23] <CIA-99> ffmpeg: The timestamp of the first RTP packet forming the output AVPacket is [12:28:23] <CIA-99> ffmpeg: written back in *timestamp, which is used in later calculations in generic [12:28:23] <CIA-99> ffmpeg: rtpdec code (together with RTCP sync timestamps) to form the final pkt->pts [12:28:23] <CIA-99> ffmpeg: value. [12:32:50] <CIA-99> ffmpeg: mstorsjo * r24236 /trunk/ (5 files in 2 dirs): [12:32:50] <CIA-99> ffmpeg: Add a depacketizer for QDM2 [12:32:50] <CIA-99> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail, original code [12:32:50] <CIA-99> ffmpeg: by Ronald S Bultje. [12:37:24] <tborg> Thanks, Dark_Shikari, I found the conversion! [12:39:22] <tborg> oh wrong chat... [13:13:17] <CIA-99> ffmpeg: diego * r24237 /trunk/libavcodec/ (escape124.c fraps.c rl2.c): [13:13:17] <CIA-99> ffmpeg: Remove incomplete Doxygen for static decode_frame functions. [13:13:17] <CIA-99> ffmpeg: These functions are not documented for other decoders and [13:13:17] <CIA-99> ffmpeg: should be obvious enough even without Doxygen. [13:13:17] <CIA-99> ffmpeg: patch by Thilo Borgmann, thilo.borgmann googlemail com [14:17:29] <zap0> hello, i was wondering why codec r210 (Uncompressed RGB 10 bit) had a decoder, but no encoder? [14:18:14] <av500> nobody wrote one? [14:18:26] <zap0> i know its simple, but im having trouble understanding the pixel packing from the decoder source, can someone look at it, and perhaps explain it. [14:18:43] <zap0> its in f210dec.c [14:19:13] <zap0> oops.. r210dec.c [14:19:37] <elenril> http://archives.free.net.ph/message/20091216.211852.836d2ff2.fi.html [14:20:43] * elenril wonders if google is down today =p [14:24:22] <zap0> elenril, the source code i downloaded is more recent, and is different. [14:25:31] * zap0 wonders if elenril is stuck in some 6month old time warp :p [14:30:42] * elenril sighs [14:30:55] <elenril> note the link to http://samples.mplayerhq.hu/V-codecs/R210/ [14:30:59] <elenril> which contains some docs [14:35:24] <av500> ...Three 10-bit unsigned components are packed into one 32-bit big-endian word... [14:35:55] <av500> sounds hellishly complicated [14:37:07] <kierank> av500: needs a massive bikeshed thread to decide what to do [14:37:25] <kierank> and an r210 task force [14:37:36] <jai> and a task force co-ordinator [14:37:52] <kshishkov> yep, form a comittee [14:38:06] <jai> ohloh says ffmpeg has a manager, thats convenient [14:38:32] <mru> loloh [14:41:28] <kshishkov> told you, in Russian "oh loh" means "aww, (what the) sucker" [14:43:04] * kshishkov asks if the position of FFmpeg VP on fringe codecs is still open [14:43:39] <lu_zero> kshishkov: =) [14:46:43] <zap0> elenril, thanks. [16:20:57] <funman> hi [16:21:07] <mru> lo [16:21:18] <jai> sup funman [16:22:17] <funman> having a pastis, hacking a demuxer [16:22:30] <mru> fixed-point demuxer? [16:22:52] * funman feels confused [16:23:11] <mru> aren't you the fixed-point guy? [16:23:13] <funman> there a floating-point ones? [16:23:15] <funman> no [16:23:47] <mru> irc says you are: funman [~fun@rockbox/developer/funman] [16:24:19] <funman> i do mostly reverse engineering in rockbox, nothing with codecs/formats [16:25:05] <elenril> how big is a performance hit with hw-accelerated virtualization? [16:25:12] <funman> our codecs guys include saratoga, mt, buschel, stripwax .. [16:25:39] * elenril wonders if he should virtualize a proper os here instead of dealing with windoze [16:25:53] <av500> what performance is there to lose then? [16:28:08] <funman> i wanted to give a try to a demuxer for a (very) simple format : the lego mindstorm RSO, which is raw PCM after a fixed header [16:28:32] <funman> and i wonder if libavformat/raw.c is the right place for this [16:28:51] <jai> funman: yeah, should be fine i think [16:28:53] <mru> copy .wav or .au demuxer and modify [16:29:13] <mru> .au is probably the simplest [16:29:24] <funman> all the formats i see are raw variants of some codec, and all the PCM ones have no headers so i would think a new file is needed [16:29:41] <funman> but the file says "/* simple formats */" so i'm also tempted to add it there [16:29:53] <mru> where is the .au demuxer? [16:30:06] <funman> au.c [16:30:28] <mru> it probably uses read/write/seek functions from raw.c though [16:31:53] <funman> seek but not read (not sure why) [16:48:01] <Tjoppen> funman: generalize some of the code in the .wav demuxer so they both can share code? [16:50:12] <funman> Tjoppen: raw.c alreayd has generic code [16:55:04] <elenril> if i'm running 32bit windoze on a 64bit cpu, can virtualized oses be 64bit? [16:55:41] <mru> probably not with vmware workstation/server or virtualbox [16:55:54] <elenril> :( [16:55:56] <mru> with xen or vmware esx server it's of course possible [16:56:03] * elenril is using virtualbox [16:56:05] <mru> since those sit outside the os [16:56:15] <elenril> but those are a PITA to setup, no? [16:56:20] <mru> probably [16:56:24] <mru> never tried [16:56:31] <mru> didn't get past the first page of the manual [16:56:41] <mru> so yes, actually [16:58:52] <elenril> VMM: fixed host crash when running 64-bit guests on 32-bit hosts << from virtualbox changelog [16:59:01] <elenril> i guess it works then :) [16:59:12] <mru> wow [16:59:16] <funman> if it crashes, it works! [16:59:20] <mru> I didn't expect that [17:07:11] <funman> would you recognize which adpcm is used by looking at the pascal source code for the encoder? [17:07:28] <mru> compare to ours [17:07:38] <mru> or feed the encoded file to all of ours and see which sounds right [17:08:39] <funman> i have no encoded file [17:08:48] <funman> the thing builds in borland delphi iiuc [17:21:48] <bcoudurier> pastis ? [17:21:52] <bcoudurier> are you french ? [17:22:25] <funman> yes [17:22:53] <av500> not pernod? [17:22:55] <kshishkov> funman: yes, we will. Even i know Pascal [17:24:36] <kshishkov> and ADPCM encoder contains decoder anyway [17:25:50] <funman> kshishkov: http://pastie.org/1044327 [17:25:57] <funman> av500: you mean ricard? [17:26:19] <jai> hmm, i have only seen a bottle of pastis once [17:26:26] <jai> pretty rare to come across one here [17:26:35] <funman> where are you? [17:26:41] <kshishkov> funman; from the first quick glance - IMA ADPCM [17:26:48] <jai> funman: je suis indien [17:26:56] <funman> kshishkov: well the function name told me that already ;) [17:27:18] <jai> heh [17:28:04] <funman> listening test is quite hard: encoded data is limited to 16kB [17:28:14] <kshishkov> funman: looks like plain IMA ADPCM without any deviations from the standard [17:28:44] <funman> err, 64kB (1<<16) [17:29:34] <CIA-99> ffmpeg: reimar * r24238 /trunk/ (libavcodec/dvbsubdec.c libavformat/mpegts.c): [17:29:35] <CIA-99> ffmpeg: Pass the composition and ancillary ID for DVB subtitles via extradata instead [17:29:35] <CIA-99> ffmpeg: of sub_id, this allows detecting when that information is not available and [17:29:35] <CIA-99> ffmpeg: just decode everything. [17:29:35] <CIA-99> ffmpeg: In addition extradata is required for many codecs and thus in contrast to [17:29:35] <CIA-99> ffmpeg: sub_id generally already passed on by any programs using libav*. [17:29:36] <CIA-99> ffmpeg: Also ask for a sample if we encounter a stream with multiple/changing IDs. [17:30:51] <funman> kshishkov: that'd be CODEC_ID_ADPCM_IMA_WAV? this one doesn't like the bitstream [17:31:38] <kshishkov> yes, it looks so - but this codec also should store initial step and predictor [17:32:08] <funman> ah so it needs them from demuxer? [17:32:09] <kshishkov> in that detail it may differ - and your snippet gives no details on that [17:32:21] <kshishkov> actually its written in bitstream in some way [17:33:03] <funman> reload the paste, i pasted the full file [17:33:43] <funman> hm i see a .wav id for IMA_ADPCM in this file [17:34:36] <funman> that's CODEC_ID_ADPCM_IMA_WAV ($0011) [17:36:50] <kshishkov> hmm, here it step=predictor=0 and raw ADPCM data [17:37:19] <kshishkov> ADPCM_IMA_WAV expects predictor and step coded at the beginning IIRC, hence the difference [17:47:29] <funman> predictor = step_index = 0 gives me silent output [17:48:12] <funman> do you want a sample? [17:49:01] <kshishkov> yes [17:49:27] <kshishkov> I'll deal with this in 10 mins or so [17:52:54] <kshishkov> and remember - step = step table index, so actual step >= 1 [17:54:35] <funman> kshishkov: http://pastie.org/1044366 (WAV) http://pastie.org/1044367 (RAW ADPCM). base64 encoded, 8kHz 1 channel [17:56:23] <funman> mru: here comes a fixed-point guy :) [18:31:23] <kshishkov> looks more like raw indeed [19:00:39] <Compn> oh, encoding question [19:01:30] <Compn> say i'm capping at 720:480 and cropping to 716:486 or so, would it be worth it to rescale to 720:480 to get the 16x16 ? or would rescaling introduce more problems than non-16 res ? [19:01:44] <Compn> er cropping to 476 [19:37:04] <CIA-99> ffmpeg: aurel * r24239 /trunk/libavformat/matroskaenc.c: [19:37:04] <CIA-99> ffmpeg: matroskaenc: write DisplayUnit element to better match the spec [19:37:04] <CIA-99> ffmpeg: This makes it clear that we are specifying the aspect ratio, and not [19:37:04] <CIA-99> ffmpeg: the intended display size in pixels. [19:50:59] <CIA-99> ffmpeg: rbultje * r24240 /trunk/MAINTAINERS: Add myself as mmst maintainer. [19:57:56] <lu_zero> hi [19:58:53] <spaam> hi [20:14:30] <Dark_Shikari> >lego mindstorms demuxer [20:14:32] <Dark_Shikari> oh wow. [20:17:35] * _av500_ waits for a demuxer for those cards that played "happy birthday" in the 80's [20:18:46] <funman> Dark_Shikari: serious business [20:22:21] <BBB> jai: does vlc have an online viewgit webpage somewhere? [20:23:15] <mru> it should [20:26:17] <BBB> nm found it [20:26:22] <BBB> well hidden [20:26:34] <funman> 'git.videolan.org' , can't make it more obvious [20:27:36] <jai> BBB: ^ [20:27:49] <BBB> how do I know they use git :-p [20:28:24] <Honoome> funman: he's used to the cvs/svn viewvc stuff that needs to be something like videolan.org/cgi-bin/onemoredirforthesakeofit/viewvc.git/repository/trunk/v… :P [20:28:54] <mru> :-) [20:28:58] <funman> shortest strings is a built in function of git (like 96067e4922878b125f86509a83c3495670bcb450 for example) [20:29:58] * Honoome actually dislikes gitweb, but he had no time to keep on working on gitarella [20:30:13] <mru> gitweb is better than any of the svn ones at least [20:30:26] <Honoome> used to be much slower [20:30:46] <spaam> cgit is nice :) [20:31:15] <spaam> http://cgit.lighttpd.net/ in action ;D [20:33:54] <kierank> spaam: looks basically the same [20:38:07] <Honoome> mostly faster [20:38:16] <Honoome> 'cause it's in C with caching rather than in perl without [20:39:35] <mru> doesn't gitweb mostly invoke the normal git tools to do the work? [20:39:45] <mru> caching would still help of course [20:41:12] <Honoome> mru: it always invoked the normal git tools afaik [20:41:41] <mru> it obviously does the html formatting in perl [20:41:47] <mru> but that shouldn't take long [20:42:12] <Honoome> mru: cgit does not call into git [20:42:20] <Honoome> it uses the internal library to access the data [20:42:58] <mru> I would've thought the whole thing was io-bound anyway [20:43:00] <Honoome> lu_zero: can we close michael and ciaranm in a room together for a couple of months? [20:45:19] <Honoome> they both expect the whole OS to turn around their personal needs, they both love condorcet voting, but they disagree on the language (C vs C++)... would be a nice match [20:46:13] <mru> do you think they'd vote on it? [20:46:38] <Honoome> or they'd end up in trollock [20:46:45] <Honoome> [which is a deadlock of trolling] [20:48:01] <funman> expecting the other to troll, or expecting the other to stop trolling? [20:48:42] <Honoome> I'd expect we could have a troll-powered free energy generator [20:50:10] <peloverde> Does roundup seem unusually slow (over the past few days) to anyone else? [20:50:56] <mru> roundup is _always_ unusually slow [20:52:09] <peloverde> No it's always *usually* slow [20:52:17] <peloverde> These days it seems bugzilla slow [21:03:43] * BBB probably fixed all mmst.c bugs he cound find today [21:04:38] <BBB> back to simd then [21:05:44] <mru> let's finally beat libvpx [21:05:59] <Dark_Shikari> \o/ [21:06:05] <Dark_Shikari> did you commit the normal filter yet? [21:06:07] <Dark_Shikari> or still more to do [21:07:34] <BBB> I didn't address your issues raised yesterdya yet [21:07:37] <BBB> will work on that late today [21:07:50] <BBB> I promised my soc student to help him beat the crapshit out of mmst.c first, to make sure it always works [21:08:05] <BBB> I sent him all stuff that was wrong, he'll fix it & commit, I'll go back to simd meanwhile :) [21:10:55] <_av500_> ot: http://cache.gawkerassets.com/assets/images/39/2010/07/periodic_table_cursi… [21:16:31] <funman> _av500_: it lacks duke nukem quotes, i suppose those are the heaviest elements [21:18:34] <_av500_> the duke was not a brit, was he? [21:21:03] <funman> don't think so [21:21:27] <funman> is that a brit insults table? (i see the crown) [21:22:57] <CIA-99> ffmpeg: diego * r24241 /trunk/libavcodec/ (aacadtsdec.h lsp.h ac3_parser.h): Restore mistakenly removed [in]/[out] Doxygen parameter attributes. [21:36:28] <BBB> wma audio still crashes on my computer :( [21:36:34] <BBB> anybody else have a problem with that? [21:37:24] <mru> no, I don't have a problem with wma crashing your computer [21:37:27] <funman> yeah i've a problem with people using wma [21:40:52] <BBB> hum... [21:43:59] <funman> BBB: just tried one file and it sounded ok [21:44:43] <_av500_> BBB: crash how? [21:44:53] <BBB> ff_imdct_half_sse [21:59:14] <BBB> does wmadec.c never call ff_imdct_init()? [22:00:42] <mru> wma regression tests pass on fate, so clearly it's not totally broken [22:03:54] <BBB> true [22:04:02] <BBB> it doesn't check return value of ff_mdct_init() [22:04:15] <mru> and it's failing? [22:06:10] <BBB> no, but the values are unallocated nevertheless [22:06:13] <BBB> I'm trying to figure out why [22:13:27] <BBB> damn it I need valgrind for mac [22:13:45] <mru> no, you need a valgrind-capable computer [22:15:19] <BBB> blegh [22:21:42] <BBB> does anyone want to do some valgrind runs for me with custom ffmpeg patches? [22:29:54] * BBB goes search bugzilla for g-mac-10.6 patches [22:33:48] <bcoudurier> the 10.6 branch works [22:33:58] <bcoudurier> somewhat [22:34:04] <BBB> I'm testing it as we speak [22:34:11] <BBB> should work for ffmpeg, given that that's still 32-bit [22:34:31] <bcoudurier> huh ? [22:34:34] <bcoudurier> you can use 64bits [22:34:42] <bcoudurier> ./configure --enable-64bit-only worked [22:42:09] <BBB> bcoudurier: I know it works [22:42:15] <BBB> bcoudurier: but I don't want to mess with it yet ;) [22:42:23] <BBB> maybe later [22:44:52] <BBB> let's see if I should not have done this [22:58:42] <BBB> I'm starting to think I need a make clean or so... [22:59:21] <BBB> I suppose valgrind is quite wonderous [23:00:05] <Dark_Shikari> itis [23:00:24] <BBB> thank god I have a working valgrind again [23:00:32] <BBB> one of those few tools nobody can live without [23:22:13] <CIA-99> ffmpeg: bcoudurier * r24242 /trunk/libavformat/oggenc.c: [23:22:13] <CIA-99> ffmpeg: In ogg muxer, use dyn buffer to compute crc of the page, fix muxing with pipe [23:22:13] <CIA-99> ffmpeg: when page buffer is bigger than default buffer size. Max page is 65k. [23:24:03] <Vitor1001> BBB: Did you try to reproduce your bug using -acodec copy? [23:31:20] <Dark_Shikari> optimization puzzle [23:31:25] <Dark_Shikari> x = {-2,32} inclusive [23:31:29] <Dark_Shikari> y = {-2,32} inclusive [23:31:48] <Dark_Shikari> in the fewest ops, calculate (x == 2 && y == 2) [23:32:12] <Dark_Shikari> (x+1)&(y+1)==-1 works, but I think it might be worse than the naive way [23:35:02] <Dark_Shikari> hmm. newer gcc compiles if(x==2 && y==2) as [23:35:08] <Dark_Shikari> cmp, je, cmp, je [23:35:13] <Dark_Shikari> 3.4 compiles it branchlessly [23:35:20] <Dark_Shikari> e.g. cmp, sete, cmp, sete, test, je [23:35:32] <Dark_Shikari> Probably can't beat the branchy version in this case. [23:35:55] <Dark_Shikari> Oh. I can do if( i_refa + i_refb == -4 ) [23:36:02] <Dark_Shikari> er, x + y == -4 [23:37:08] <roxfan> did you mean (x == -2 && y == -2) then? [23:37:25] <Dark_Shikari> er, yeah. [23:37:29] <Dark_Shikari> stupid typo of mine. [23:40:21] <kierank> gcc will presumably turn that into x + y + 4 then just use je? [23:41:58] <Dark_Shikari> no [23:42:01] <roxfan> comparing with -4 is the same as adding 4, so probably not [23:42:10] <Dark_Shikari> it does [23:42:15] <Dark_Shikari> 2f6: 8d 04 2e lea eax,[esi+ebp*1] [23:42:16] <Dark_Shikari> 2f9: 83 f8 fc cmp eax,0xfffffffc [23:42:48] <Dark_Shikari> because lea doesn't set flags [23:42:58] <Dark_Shikari> Now what bugs me about this is [23:43:02] <Dark_Shikari> esi and ebp are never used again in the function [23:43:17] <Dark_Shikari> so it doesn't have to maintain them [23:43:57] <Dark_Shikari> I'm trying to simplify if( b == -2 && c == -2 && d != -2 ) [23:44:14] <Dark_Shikari> damn, gcc loves inserting nops everywhere. [23:44:33] <roxfan> why -2? [23:44:39] <Dark_Shikari> -2 ---> ref isn't available [23:44:46] <Dark_Shikari> -1 ---> ref is invalid (intra) [23:44:50] <roxfan> hmm [23:44:52] <Dark_Shikari> 0-32 ---> valid ref values [23:45:14] <Dark_Shikari> i.e. "if both top mvs aren't available, predict based on left mv" [23:45:32] <kierank> maybe you could do c xor d and then jne [23:45:41] <kierank> for the second part [23:45:46] <Dark_Shikari> how would xor help? [23:45:51] <Dark_Shikari> I don't see how that would be fewer ops [23:47:18] <Dark_Shikari> guess it isn't very important. [23:50:50] <Dark_Shikari> the other one I wish I could get faster is [23:50:51] <Dark_Shikari> int i_count = (i_refa == i_ref) + (i_refb == i_ref) + (i_refc == i_ref); [23:50:55] <Dark_Shikari> more specifically [23:50:58] <Dark_Shikari> if( i_count > 1 ) [23:51:02] <Dark_Shikari> but I can't find any magic for doing that. [23:51:37] <Dark_Shikari> i.e. if i_ref matches more than one of i_refa, i_refb, and i_refc.

1 0

IRC log for 2010-07-13
by irc＠mansr.com 14 Jul '10

14 Jul '10

[00:12:24] <bcoudurier> hehe [00:13:55] <Compn> huh [00:13:57] <peloverde> If you think his assessment is inaccurate and/or biased then simply give an official answer [00:14:02] <Compn> _skal_ : so got any answers? :P [00:14:07] <Compn> unrelated to Dark_Shikari [00:14:10] <Compn> ignore him [00:14:19] <Dark_Shikari> peloverde: google is allergic to certainty [00:29:36] <Kovensky> <+hyc> C >> C++ <-- what would happen here? would the C first get shifted to the right by C bits and then incremented? [00:30:07] <Kovensky> actually, that would always result in 1 wouldn't it [00:49:03] <pengvado> undefined behaviour [00:50:19] <CIA-99> ffmpeg: alexc * r24227 /trunk/libavcodec/aacsbr.c: aacsbr: Eliminate double precision arithmetic. [00:51:03] <_skal_> surprisingly [00:51:39] <_skal_> considering that log2(C) <= C [00:52:11] <_skal_> compiler should hardcode 0 for this one [00:56:35] <peloverde> ^ yay FFMIN() </sarcasm> [01:01:56] <Compn> so skals not going to answer any of my dumb questions ? :( [01:02:23] * Compn wants tons of samples [01:21:45] <kierank> bcoudurier: how much do you know about smpte timecode? [01:23:28] <bcoudurier> a bit [01:24:00] <bcoudurier> I probably can answer your questions [01:26:57] <kierank> do you know if there are any variations to the way it's encoded? [01:27:07] <bcoudurier> a ton [01:27:31] <kierank> there a lot of bits between the timecodes that I have no idea what they do: http://gitorious.org/ffmpeg-e-distribution-audio/ffmpeg-e-distribution-audi… [01:27:38] <kierank> line 303 onwards [01:28:08] <bcoudurier> lol at the name [01:28:24] <bcoudurier> yup standard in dv [01:30:00] <bcoudurier> oh you mean these 9 bits ? [01:30:11] <kierank> yes all these bits in between [01:30:35] <kierank> afaik the metadata has a "full" timecode whatever that means [01:30:41] <kierank> so there must be more stuff there [01:32:51] <bcoudurier> crc ? [01:33:04] <bcoudurier> vitc comes with crc usually [01:33:07] <bcoudurier> these 8 bits [01:33:12] <bcoudurier> at the end [01:34:25] <kierank> hmm maybe [01:34:32] <bcoudurier> yeah it's binary group [01:34:36] <bcoudurier> these 9 bits [01:34:40] <bcoudurier> see SMPTE 2019 DNxHD [01:35:44] <bcoudurier> or better SMPTE 12M [01:37:45] <kierank> ok, thanks [01:38:41] <bcoudurier> woah do you need to clip the values ? :> [01:39:42] <kierank> dunno, it was more of a sanity thing [01:40:59] <bcoudurier> 8 bytes total ? [01:41:41] <kierank> iirc yes [01:41:51] <kierank> anyway sleep time [01:41:52] <kierank> night [01:41:56] <bcoudurier> looks like DNxHD one [01:42:07] <bcoudurier> good night [01:43:49] <bcoudurier> maybe they shuffled things around [03:39:41] <peloverde> siretart: Parts of README.Debian seem out of date [06:18:14] <saintdev> is there an existing FIR filter? [06:20:44] <kshishkov> yep, take any DSP book [06:21:08] <saintdev> in lav* :P [06:21:44] <kshishkov> resamplers [06:22:04] <kshishkov> and MC interpolation code [06:22:11] <kshishkov> no generic code though [06:22:39] <kshishkov> may I offer you IIR filter since we have one? [06:24:03] <saintdev> kshishkov: yeah i know about the iir [06:27:36] * Sho_ imagines the Monty Python cheese shop sketch with filters [06:28:05] <Sho_> s/sketch/skit/ [06:30:03] <twice11> The MP3 and DTS/DCA band mixers are also some sort of FIR filter. [06:30:04] <kshishkov> Sho_: yes, we're fresh out of Wiener filters as well [06:30:15] <kshishkov> indeed they are [06:47:44] * benoit- is scratching his head on 24219 [06:49:43] <mru> benoit-: and scratch you may [06:50:07] <benoit-> mru: why did you add that? [06:50:13] <mru> I don't know [06:50:17] <mru> it doesn't make sense [06:50:30] <benoit-> agreed [06:53:19] <mru> there must be something in the german water... [06:54:14] <av500> mru: btw: http://ahoipolloi.blogger.de/stories/1663338/ [06:55:05] <mru> :-) [06:55:22] <CIA-99> ffmpeg: mru * r24228 /trunk/libavcodec/avfft.c: 100l: really fix fft external API init functions [06:56:16] <mru> lovely comments too [06:56:28] <mru> lu_zero: "Ein Bisschen Hitze und die Deutsche Züge werden Italienisch." [06:57:46] <benoit-> :) [07:06:22] <av500> lol "modify the code" [07:07:07] <mru> my favourite commit message is "fox typos" [07:07:30] <av500> well, this is telling at least [07:08:05] <kshishkov> mru: "fix something" [07:08:25] <mru> that's one of mine [07:08:36] <mru> actually it was "musb: fix something" iirc [07:08:46] <kshishkov> indeed, I remember [07:08:50] <av500> but I cant understand how they could add new functionality without renaming all the variables before, what's up with china these days [07:09:15] * kshishkov wonders what's the deal about xavs - we have native en and decoder anyway [07:09:35] <av500> NIIC syndrome [07:10:12] <mru> we don't have an avs encoder [07:11:16] <kshishkov> I thought we got one - or at least almost got it [07:13:26] <av500> 1st rule of a succesful fork, make the code undiffable to the parent: http://xavs.svn.sourceforge.net/viewvc/xavs/trunk/matroska.c?r1=9&r2=27 [07:14:24] <kshishkov> 0th rule - relicense it a dozen times, preferably to nonexistent licenses [07:14:39] <mru> lol @ the checkin comment [07:14:42] <KotH> moin [07:14:48] <kshishkov> shalom [07:14:56] <benoit-> KotH: morgen [07:15:31] <kshishkov> "modify the bugs" ? [07:17:04] <av500> "first commit with no asm support" [07:17:16] <saintdev> av500: first commit, aka fun with sed [07:27:50] <cartman> av500: there should be a global coding style ;) [07:28:02] <av500> of course, mine! [07:34:29] <cartman> I would care much, if only there was something global [07:35:44] * mru declares the global style to be the one without bugs [07:36:04] * kshishkov always suspected it's nonexistent anyway [07:44:08] <Sho_> cartman: hey [07:44:32] <cartman> lo Sho_ :) [07:44:44] <Sho_> cartman: so you do still know how to start an IRC client! :) [07:44:55] <cartman> Sho_: seems so! :) [07:45:03] <Sho_> nice :) [07:45:19] <cartman> yeah nice to see friends around =) [07:45:47] <Sho_> cartman: have to run off right now actually :-( but nice to see you around again! [07:45:58] <cartman> Sho_: see ya! [07:46:04] <Sho_> ditto :) [07:50:29] <lu_zero> mru: ? [07:50:34] <mru> lu_zero: ! [07:50:59] <ohsix> no better use for the interrobang [07:51:15] <lu_zero> mru: . [07:51:46] <kshishkov> what's stock price for other punctuation signs? [07:51:55] <lu_zero> the lastlog gave me [07:51:58] <lu_zero> 08:54 <@mru> lu_zero: "Ein Bisschen Hitze und die Deutsche Züge werden Italienisch." [07:52:16] <mru> "a little heat and the german trains become italian" [07:52:53] <mru> referring to the meltdown the german trains suffered this weekend [07:53:25] <lu_zero> I was missing the news [07:53:45] <lu_zero> sounds fair [07:57:25] <lu_zero> mru: could you point me to a good arm/neon reference? [07:57:36] <lu_zero> all I have is overly verbose [07:58:25] <av500> arm website [07:58:53] <lu_zero> av500: that is overly verbose AND chaotic =P [07:59:30] <av500> prob mru to write one [07:59:33] <av500> prod [08:00:27] <lu_zero> av500: so the best docs so far are those =| [08:01:13] <av500> I know no better ones [08:01:29] <mru> the ARM ARM is the best I know of [08:01:42] <mru> it's the only accurate and complete one I know of too [08:02:55] <cartman> mru: what is there any "C/ASM for dummies" [08:03:02] <cartman> s/what// [08:03:20] <cartman> arm arm is pretty techical stuff [08:03:31] <mru> asm coding _is_ technical [08:05:06] <benoit-> cartman: what would you need apart from the instruction description to know what an instruction does? [08:05:30] <cartman> benoit-: an introduction to asm :) [08:06:03] <av500> its a series of instructions... [08:06:41] <cartman> never mind :) [08:06:43] <Dark_Shikari> you could read one of the 5 chatlogs from every time that I've done my "asm tutoring" =p [08:06:50] <cartman> I forgot your mocking potential :P [08:06:54] <Dark_Shikari> where I've given about half a dozen separate people 2-hour tutorials on asm [08:06:58] <Dark_Shikari> (all of whom went on to write great asm) [08:07:17] <cartman> one question I would ask is [08:07:32] <cartman> Should you be writing good C before good ASM? [08:07:33] <mru> Dark_Shikari: that was sse, not arm [08:07:58] <mru> cartman: not required [08:08:08] <benoit-> cartman: I'd say no [08:08:10] <mru> there were good asm coders before C was invented [08:08:10] <cartman> mru: interesting [08:08:43] <benoit-> I know people unable to write proper C code who are really good assembly-wise [08:09:10] <mru> there is a connection between asm and C [08:09:22] <mru> you must understand the machine to write well in either of them [08:09:27] <Dark_Shikari> mru: I know [08:09:30] <mru> but C is also more than that [08:09:44] <Dark_Shikari> but if you want to "learn asm" IMO it doesn't matter what you start with -- the core concept is identical [08:09:48] <Dark_Shikari> once you understand the core concept [08:09:50] <Dark_Shikari> you can go learn any instruction set [08:09:54] <Dark_Shikari> of course, every instruction set has its quirks [08:10:04] <Dark_Shikari> and on some you have to care about different things than others [08:10:09] <mru> true [08:10:10] <Dark_Shikari> e.g. in neon scheduling matters, x86 not so much [08:10:25] <mru> but x86 asm distracts from the core concept by being so full of quirks [08:10:50] <Dark_Shikari> It's hard to say it's quirky when there's only about 3 other simd languages that matter to compare to [08:11:00] <Dark_Shikari> neon, altivec, sse.... what others? [08:11:05] <lu_zero> Dark_Shikari: spu [08:11:13] <Dark_Shikari> isn't spu just an altivec derivative? or is it a bit fancier? [08:11:26] <mru> neon needs much fewer mind-bending hacks to be efficient [08:11:46] <Dark_Shikari> I'd say it needs more [08:11:49] <Dark_Shikari> scheduling is hard [08:11:53] <mru> not really [08:11:54] <Dark_Shikari> especially on an arch with a very high ratio of latency to throughput [08:12:00] <Dark_Shikari> on x86 you can bullshit it all and it still works [08:12:07] <lu_zero> Dark_Shikari: it has some more instructions and you get some new concepts about memory management [08:12:09] <mru> loop unrolling is all you need [08:12:13] <Dark_Shikari> lu_zero: oh true, there's the DMA [08:12:35] <Dark_Shikari> though that isn't really asm per se, that's more of an architecture thing [08:12:39] <lu_zero> so in itself is a bit interesting [08:12:46] <Dark_Shikari> i.e. it affects how you build your application [08:12:48] <Dark_Shikari> and less the asm [08:13:04] <lu_zero> (more stuff exposed) [08:13:12] <mru> it does affect the code in some ways [08:13:33] <lu_zero> more or less like the ppc atomic primitives vs x86 ones [08:13:34] <mru> you really must process data a block at a time [08:13:38] <mru> you can't go jumping about [08:14:08] <lu_zero> and you know in a quite rought way if your code is overly bloated ^^; [08:17:18] <cartman> how do you learn the "main concept" ? [08:17:47] <mru> by years of hard work [08:17:57] <lu_zero> the main concepts.... [08:17:59] <cartman> hard work needs to start with something :) [08:18:17] <lu_zero> well you have to know how the cpu usually work [08:18:20] <kshishkov> main concept, ele card, div x, whatever [08:18:22] <mru> or flip through the manual and apply common sense [08:18:45] <cartman> lu_zero: thats a good start :) [08:18:56] <cartman> a computer architechture book [08:19:05] <lu_zero> mru: before maybe knowing a bit about pipelining, cicles per instruction and such help [08:19:07] <mru> for ARM, I recommend the ARM ARM [08:20:10] <lu_zero> after that all you need is an indexed/searchable doc [08:20:27] <lu_zero> with instruction name - what it does - latency/quirks [08:21:05] <KotH> oi cartman [08:21:10] <cartman> lo KotH [08:21:23] <cartman> whats the name for the arm arm book btw? [08:21:25] <cartman> Google is confused [08:21:37] <KotH> arm architecture reference manual [08:21:51] <cartman> ah thanks KotH , always a useful guy! [08:22:02] <mru> cartman: http://infocenter.arm.com/help/topic/com.arm.doc.ddi0406b/index.html [08:22:15] <KotH> and if you want an intro into asm, go to a used book store, and grab yourself an copy of an old x86 asm book [08:22:29] <cartman> KotH: I am working on ARM tablets these days [08:22:34] <cartman> would be interesting to learn arm asm [08:22:35] <mru> KotH: that sounds like bad advice [08:23:03] <mru> x86 asm has very little in common with arm [08:23:13] <cartman> mru: got the pdf version? :) [08:23:20] <mru> just download it [08:23:26] <mru> you probably have to register [08:23:26] <cartman> need registration [08:23:30] <mru> but it's harmless [08:23:32] <cartman> oh k [08:23:33] <mru> they won't spam you [08:23:35] <lu_zero> cartman: it's free [08:25:06] * lu_zero obviously forgot which email he registered with... [08:25:57] <cartman> I was already registered, it seems [08:25:57] <cartman> :) [08:27:29] <Dark_Shikari> mru: x86 asm has the same things in common with arm that it has in common with all asm [08:27:37] <Dark_Shikari> it's really all the same shit. [08:27:38] <mru> which isn't a lot [08:27:45] <Dark_Shikari> at most, it might be [08:27:51] <Dark_Shikari> "oh cool, I can do this with arm that I couldn't do with x86" [08:27:55] <Dark_Shikari> or "crap, can't do this on arm" [08:28:01] <Dark_Shikari> but really, it's all the same shit. [08:28:14] <mru> in the sense of "instructions do stuff with registers" yes [08:28:29] <Dark_Shikari> the hardest concepts to grasp are the basic ones. [08:28:40] <mru> but arm is a strict load/store architecture [08:28:40] <Dark_Shikari> once you have those, everything else is easy. [08:28:42] <lu_zero> x86 hides a _lot_ from you [08:29:26] <mru> x86 has only a few registers and relies on memory operands [08:29:37] <mru> a naive translation to arm will stink badly [08:29:49] <Dark_Shikari> But why would you ever translate? [08:30:10] <mru> if you learned x86 asm you might still be thinking in those terms [08:30:25] <Dark_Shikari> I don't see the relevance [08:30:27] <Dark_Shikari> asm is just a set of tools [08:30:33] <Dark_Shikari> different arches have different tools [08:30:44] <Dark_Shikari> if you went up to a carpenter and said "build this desk without a screwdriver" [08:30:48] <Dark_Shikari> he could do it [08:30:53] <Dark_Shikari> just like going to an x86 asm programmer and saying [08:30:54] <av500> of course [08:30:54] <mru> yes, and you can't do fine woodwork with a jackhammer [08:30:56] <Dark_Shikari> "don't use memory operands" [08:31:08] <Dark_Shikari> or saying "hey, you now have 16 registers." [08:31:10] <av500> who needs a screwdriver for a desk anyway... [08:31:16] <Dark_Shikari> av500: IKEA! [08:31:26] <mru> comes with a little allen key [08:31:40] <Dark_Shikari> the gods of particleboard [08:31:43] <kshishkov> mine still required screwdriver to assemble [08:32:12] <av500> you just need glue! :) [08:32:26] <av500> and a biscuit router [08:32:38] <lu_zero> what's bisquit router? [08:32:40] <lu_zero> a [08:33:02] <kshishkov> I can route busquits to myself without any tools [08:33:02] <Dark_Shikari> one that goes well with butter [08:33:06] <ohsix> it plunge cuts slots to put little wedges of wood that absorb glue in [08:33:21] <av500> lu_zero: http://images.meredith.com/wood/images/p_biscuit.jpg [08:33:24] <av500> yummy [08:34:51] <lu_zero> ^^; [08:35:18] * kshishkov wants to hint that modern furniture may include metal and glass [08:35:53] <av500> meh [08:38:28] * kshishkov pries av500's book "Stumps - the only way to build furniture" from his hands [08:39:31] <av500> kshishkov: no stumps involved: http://www.flickr.com/photos/av500/3694812587/ [08:39:57] <benoit-> wow! what an award: http://www.downloadroute.com/images/av-awards/FFmpeg-FFmpeg.png [08:40:06] <av500> and ok, you need a screwdriver for the hinges [08:40:07] <benoit-> I hope you guys are proud of that [08:40:18] <benoit-> such an achievement [08:40:31] <av500> well, good time to add ffads... [08:40:40] <benoit-> we've been waiting for that all our lives; and there it is, at least! [08:41:05] <Dark_Shikari> the reason sites "award" those is to try to get you to put the award on your page [08:41:08] <Dark_Shikari> and link back to them [08:41:14] * kshishkov waited for something completely different [08:41:56] <av500> Hmm, i can photoshop such an award in 5 minutes [08:42:28] <kshishkov> av500: please do - The Official FFmpeg Seal of Approving FFmpeg [08:48:06] <av500> http://imagebin.ca/view/SN_zA5v.html [09:03:52] <Dark_Shikari> so should I crosspost http://mailman.videolan.org/pipermail/x264-devel/2010-July/007508.html [09:03:55] <Dark_Shikari> to ffmpeg-devel? [09:03:57] <Dark_Shikari> or ffmpeg-users? [09:05:19] <kshishkov> wasn't Google using inhouse H264 encoder? [09:05:35] <Dark_Shikari> no, they use x264 now for youtube [09:07:10] * kshishkov wants FFmpeg Enterprise Edition bundled with it [09:07:27] <Dark_Shikari> What special features are in Enterprise Edition? [09:07:31] <Dark_Shikari> besides the gold-plated manual [09:07:43] <kshishkov> it's harder to use [09:08:00] <Dark_Shikari> impossible. [09:08:28] <kshishkov> do you usually use ed for editing? [09:08:51] <Dark_Shikari> lol [09:08:51] <peloverde> Dark_Shikari: Reddit hates you today :) [09:08:59] <mru> link? [09:09:02] <Dark_Shikari> only today? [09:09:06] * mru wants to gloat :-) [09:09:09] <peloverde> especially today? [09:09:09] <peloverde> http://www.reddit.com/r/programming/comments/cougf/x264devel_announcing_com… [09:10:23] <kshishkov> Dark_Shikari: also why your x264 page spells FFmpeg name without capital F's? [09:10:53] <Dark_Shikari> fuck that. [09:10:57] <Dark_Shikari> lol [09:11:00] <Dark_Shikari> it's a unix tool [09:11:03] <Dark_Shikari> therefore, it is all lower case [09:13:13] <av500> Dark_Shikari: clever plot, 1st diss VP8, then sell X264 :) [09:13:41] <Dark_Shikari> yes, I'm horribly evil [09:13:57] <Dark_Shikari> except for the part where x264 isn't competing with vp8. [09:14:28] <peloverde> I never noticed that gregory maxwell wrote a rebuttle http://lists.wikimedia.org/pipermail/wikitech-l/2010-May/047795.html [10:08:55] * mru has enough of ubuntu and installs portage on top of it [10:09:24] <Dark_Shikari> lol [10:14:38] <lu_zero> gentoo-prefix or just taking over? [10:14:55] <Dark_Shikari> http://x264dev.multimedia.cx/?p=486 [10:15:12] <mru> lu_zero: hostile takeover [10:15:16] <lu_zero> ^^; [10:15:26] <lu_zero> rsync is wonderful for that [10:15:51] <mru> I'm just emerging things I as need them [10:16:01] <lu_zero> ^^; [10:16:01] <av500> Dark_Shikari: now imagine google opening up to bistream changes in order to add "interlaced" :) [10:16:28] <av500> "due to popular demand"! [10:16:41] <elenril> Dark_Shikari: inb4 mpeg-la paid you [10:16:42] <lu_zero> argh [10:38:30] <KotH> mru: but at least it teaches you the basics of asm [10:38:42] <KotH> mru: unlike all of these reference books, which teach you only the details [10:39:07] <mru> KotH: what "it"? [10:39:36] <kshishkov> mru: "x86 asm for complete dummies" [10:39:39] <twice11> "it" seems to be the x86 asm introduction book mentioned some hours ago. [10:54:41] <Dark_Shikari> http://graphjam.files.wordpress.com/2010/07/funny-graphs-good-team-playing-… [10:55:29] <thresh> parodox, orly [10:55:52] <av500> Dark_Shikari: nice [10:55:59] <mru> where's north korea in that graph? [10:56:10] <mru> them being there at all was the biggest paradox [10:56:21] <av500> them returning home is a paradox [10:56:39] <mru> are they still alive? [10:57:15] <av500> go to north korea and check [11:03:49] <av500> hmm, http://graphjam.files.wordpress.com/2010/06/funny-graphs-where-trolls-reall… [11:13:47] <cartman> av500: lol [11:15:14] <Dark_Shikari> http://graphjam.files.wordpress.com/2010/06/funny-graphs-talents-of-the-ita… [11:38:18] <lu_zero> Dark_Shikari: I'm wondering [11:38:22] <spaam> av500: so mru live with his mother.... [11:38:42] <lu_zero> how hard would be add vp8 to x264? [11:38:53] <Dark_Shikari> I've answered this before; not too difficult [11:39:06] <Dark_Shikari> just a quick scan of the files that would need or not need changing [11:39:29] <Dark_Shikari> analyse.c: not many changes, mostly just removing stuff [11:39:33] <Dark_Shikari> cabac.c: rewrite [11:39:36] <Dark_Shikari> cavlc.c: remove [11:39:36] <mru> spaam: no, I live under a bridge [11:39:39] <thresh> so you'll rename to xp8? [11:39:46] <Dark_Shikari> encoder.c: partial rewrite, mostly header stuff and reference handling [11:39:49] <Dark_Shikari> lookahead.c: unchanged [11:39:51] <Dark_Shikari> macroblock.c: rewrite [11:39:55] <Dark_Shikari> me.c: mostly unchanged [11:40:01] <Dark_Shikari> ratecontrol.c: tiny minor changes [11:40:10] <Dark_Shikari> rdo.c: rewrite the trellis (or remove), everything else the same [11:40:14] <Dark_Shikari> set.c: rewrite, that's header stuff [11:40:22] <Dark_Shikari> slicetype.c: keep the same, just turn off b-frames [11:42:45] <kshishkov> what about AVS :{ [11:44:37] <wbs> Dark_Shikari: how hard would that be to integrate in x264 itself, to keep both h264 and vp8 encoding in the same codebase? [11:44:52] <Dark_Shikari> not unreasonable. [11:45:01] <Dark_Shikari> especially if you don't implement all of vp8. [11:46:16] <kshishkov> well, I think you've still not implemented all of H.264 [11:46:55] <Dark_Shikari> of course, but vp8 is quite a bit smaller. [11:47:04] <kshishkov> good for them [11:47:05] <Dark_Shikari> for example, not implementing alt refs would make things simpler. [11:47:25] <kshishkov> B-frame reordering :) [11:47:26] <Compn> x264vp8 could corner both encoding markets [11:47:27] <Compn> lulz [11:48:20] <lu_zero> and would be another implementation [11:48:26] <Compn> bwahaha [11:48:34] <lu_zero> making the whole vp8 stuff more interesting [11:48:35] <Compn> well, better than on2 encoder [11:49:16] <lu_zero> since you might then have a better leverage about adding stuff on vpnext [11:49:39] <Dark_Shikari> I would commit a patch to add vp8 support. [11:49:58] <thresh> oh come on, x264 getting more and more bloated [11:50:10] <lu_zero> thresh: shut up =P [11:50:25] <kshishkov> thresh: what do you expect, it's going corporate [11:50:33] <thresh> :) [11:50:53] <Dark_Shikari> yeah, damn those "useful features" like audio support [11:51:06] <thresh> yeah, heard of unix way of doing stuff? :) [11:51:29] <Dark_Shikari> yes, that's called gstreamer [11:51:34] <Dark_Shikari> piping between modules... [11:51:36] <Dark_Shikari> oh wait, we hate that =p [11:51:42] <kshishkov> thresh: they had it that way, then somebody decided to listen to users [11:51:45] <thresh> that's not nix way I knew about it [11:51:55] <Dark_Shikari> well, ffmpeg is definitely not the nix way [11:52:04] <thresh> i wasnt claiming that ;P [11:52:04] <Dark_Shikari> everything stuffed together into a bunch of interdependent, inseparable libs [11:53:20] <kshishkov> oh, and they all depend on libc/libm [11:54:21] * Compn tries to imagine installing 100 different projects just to get same functions as ffmpeg [11:54:43] <Compn> no, dont think so [11:54:57] <Dark_Shikari> nobody said the unix way was inherently right. [11:55:15] <thresh> sure it is, ask stallman! [11:55:28] <Dark_Shikari> no no no [11:55:30] <Dark_Shikari> he's not about unix [11:55:33] <Dark_Shikari> he's about GNU/LINUX. [11:55:34] <kshishkov> thresh: luckily, it has nothing to do with him [11:55:41] <kshishkov> GNU/Hurd [11:55:52] <kshishkov> or GNU/EMACS [11:55:59] <DonDiego> stallman is a lisp hacker from a community that predates unix [11:56:10] <Dark_Shikari> I'd just like to interject for a moment. What you're referring to as Linux, is in fact, GNU/Linux, or as I've recently taken to calling it, GNU plus Linux. Linux is not an operating system unto itself, but rather another free component of a fully functioning GNU system made useful by the GNU corelibs, shell utilities and vital system components comprising a full OS as defined by POSIX. [11:56:16] <kshishkov> IIRC it was McIlroy who invented pipes and helped defining Unix way [11:56:18] <DonDiego> please revisit your history lessons before trolling [11:56:27] <thresh> ;-) [11:56:32] <Dark_Shikari> DonDiego: >predates unix [11:56:38] <Dark_Shikari> I'm pretty sure unix was around before he was born. [11:56:47] <thresh> my brain melts here, cant use it... [11:56:48] <DonDiego> he? [11:56:56] <DonDiego> he == stallman? [11:56:59] <Dark_Shikari> Unix was 1969. [11:57:04] <Dark_Shikari> oh, wow, you're right [11:57:06] <Dark_Shikari> he's really fucking old [11:57:08] <Dark_Shikari> 1953 [11:57:19] <DonDiego> remember what i told you about the history lesson? [11:57:20] <thresh> you thought he's in this 30s? [11:57:27] <Dark_Shikari> no, 40s [11:57:35] <Dark_Shikari> DonDiego: he was hacking on lisp when he was 16? [11:57:36] <kshishkov> thresh: Russians are not supposed to think with _brain_ anywau [11:57:38] <kshishkov> *anyway [11:57:41] <Dark_Shikari> I doubt that. [11:57:51] <DonDiego> around that age [11:57:58] <DonDiego> but unix was not used everywhere then [11:58:08] <Dark_Shikari> well of course. [11:58:11] <thresh> kshishkov: yes, everything is decided by party and pm [11:58:26] <pross-au> What's the relevance of lisp again? [11:58:28] <Dark_Shikari> even today unix isn't "used everywhere". [11:58:30] <DonDiego> he was a lisp hacker before he got exposure to unix even iirc [11:58:34] <Dark_Shikari> pross-au: HAVE YOU READ YOUR SICP TODAY? [11:59:07] <Dark_Shikari> My other car is a cdr. [11:59:18] <kshishkov> thresh: not only that, you should know traditional Russian way of doing things and proverb "русский человек _задним_ умом крепок" [11:59:53] <thresh> kshishkov: nice troll. ;-) [11:59:59] <KotH> Dark_Shikari: sounds like you've read the whole of it :) [12:00:03] <siretart> peloverde: what do you mean specifically? [12:00:04] <kshishkov> pross-au: it serves the role of Visual Basic for not so dummy people - learning language, internal script language, etc [12:00:46] * kshishkov wonders where's the browser with LispScript support though [12:01:01] <KotH> kshishkov: it's called emacs [12:01:07] <mru> browsers are written by dummies [12:01:19] <mru> and yes, emacs has a browser [12:01:29] <mru> worst browser ever btw [12:01:32] <Dark_Shikari> it needs a text editor though [12:01:37] <Dark_Shikari> imho [12:01:42] <kshishkov> mru: worse than text editor? [12:01:57] <mru> Dark_Shikari: I'm writing code, what would I do with a text editor? [12:01:58] <pross-au> Do should it be called GNU/FFmpeg? [12:02:04] <mru> FFgnu [12:02:04] <av500> at least it has a good mailer... [12:02:13] <av500> FFmpegnu [12:02:18] <mru> av500: it really does [12:02:37] <pross-au> I mean, the first versions only worked on gcc [12:02:49] <pross-au> Just like Linux [12:03:00] <spaam> mru: do you watch movies in emacs? :) [12:03:00] <kshishkov> Emacs also demonstrates huge deviation from Unix way BTW [12:04:46] <av500> spaam: he watches movies in md5sum.... [12:05:14] <kshishkov> av500: indeed, I saw him doing so [12:06:11] <thresh> stallman uses vlc [12:07:32] <pross-au> thresh: which codecs? [12:07:39] <lu_zero> thresh: how so? [12:07:47] <thresh> I only know about V4L [12:08:16] <thresh> http://mailman.videolan.org/pipermail/vlc-devel/2007-October/035357.html [12:08:20] <thresh> see attachment in the end [12:08:31] <kshishkov> thresh: good point against VLC, I'll remember that [12:08:44] <thresh> ;-) [12:24:37] <foehn> does someone know of a fixed-point port of wmaenc ? [12:30:34] <kshishkov> foehn: rockbox devs do [12:34:29] <av500> encoder? [12:37:04] <foehn> only saw a decoder in their sources [12:38:46] <kshishkov> ah, fixed-point encoders are not that popular [12:40:27] <av500> encoding in WMA is not popular anyway [12:41:15] <foehn> how about fixed-point mp3 ? [12:45:08] <kshishkov> unlikely [12:45:26] <kshishkov> of course you can do that but why? [12:48:05] <foehn> I need either a wma or mp3 encoder for an arm9 cpu [12:50:39] <kshishkov> well, Google in help [12:53:39] <foehn> didn't find anything... [12:54:06] <av500> commercial solutions exist for sure [12:56:07] <foehn> that's true, but I'm looking for open-source [12:56:26] <foehn> would even offer a bounty for implementing it in ffmpeg [12:56:30] <kshishkov> just make one then [12:58:04] <av500> there is this "shine" thing [13:03:35] <foehn> yep, I was thinking of trying to integrate it into ffmpeg [13:03:50] <foehn> but it's rather slow, needs 130Mhz+ on an ARM9E [13:05:11] <av500> patches welcome I guess... [15:14:50] * KotH could need a search function over the samples collection [15:16:06] <mru> search for what? [15:16:49] <KotH> i need a 640x480 sized sample of at least 1min size, mpeg4 asp, audio doesnt matter [15:17:05] <mru> make one [15:18:41] <av500> ffmpeg -i .... [15:19:30] <thresh> or ffprobe, indexed [15:29:54] <Jianwen> hi [15:31:38] <KotH> could someone with a state of the art PC (aka i7 class) do me a favor and run time for i in `seq -w 1 1000`; do convert -size 640x480 xc: +noise Random blah${i}.png;done and tell me the numbers? thanks [15:51:12] <KotH> .o0(looks like all those with fast machines run away) [15:54:06] <lu_zero> I have a lousy quad core would be ok? [15:54:59] <KotH> what cpu? [15:55:04] <lu_zero> phenom [15:55:25] <KotH> i'd say that sounds ok [15:56:04] <lu_zero> let me unbreak imagemagick on that box [15:56:43] <KotH> unbreak? [15:57:33] <mru> real 2m9.076s [15:57:33] <mru> user 2m18.284s [15:57:33] <mru> sys 0m5.126s [15:57:49] <KotH> mru: cpu? [15:57:54] <mru> i7 940 [15:58:02] <KotH> GHz? [15:58:06] <mru> 2.93 [15:58:11] <KotH> thanks a lot! [15:58:23] <mru> in tmpfs btw [15:58:32] <KotH> that's ok [15:58:54] <KotH> i need a guestimate for how much faster an up to date machine is, compared to what i have here ^^' [15:59:02] <pengvado> did you intend to bench both the noise generator and the png encoder? [15:59:10] <KotH> yes [16:15:24] <spaam> KotH: what do you get? :) [16:16:57] <iive> mru: i thought your computer had ecc ram. [16:18:04] <KotH> spaam: real 13m35.476s [16:18:24] <spaam> what kind of cpu is that? :O [16:18:34] <KotH> p4 1.6ghz [16:18:51] <KotH> i wouldnt ask for a fast machine if i'd have one at hand ;) [16:22:32] <microchip_> KotH: Willamette? [16:24:02] <KotH> microchip_: gesundheit! [16:24:10] <microchip_> ? [16:24:29] <microchip_> i was asking if the p4 was a Willamette (which is the worst p4 core arch) [16:25:30] <microchip_> ya know, under the p4 you have Willamette's, Northwoods, Prescotts, etc [16:27:17] <KotH> i have no fucking clue [16:27:34] <twice11> 1.6GHz sounds like the first core arch. [16:27:46] <microchip_> it must be a Willamette, no Northwood or Prescott has such low frequency [16:28:36] <microchip_> iirc, Nrothwoods start at 1.8 GHz [16:28:44] <microchip_> or was it 2? [16:36:42] <twice11> Wikipedia says northwood starts at 1.6GHz. [16:37:15] <twice11> Easiest disctinction: Willamette has 256KB L2, Norhtwood 512 [16:37:39] <mru> CELERON!!! [16:38:05] <twice11> Dual Celeron 300A @ 450 (cheapest SMP ever)? [16:59:14] <KotH> mru: selerie is something to eat, not something to run computers with ;) [17:04:22] <Kovensky> <KotH> spaam: real 13m35.476s <-- o_o' [17:04:27] <Kovensky> real 6m18.229s [17:04:27] <Kovensky> user 4m53.368s [17:04:27] <Kovensky> sys 0m23.692s [17:04:31] <Kovensky> (Sempron 2800+ @ 1.7GHz) [17:05:10] <twnqx> O_O [17:05:31] <KotH> Kovensky: it's a p4 :) [17:05:43] <Kovensky> I could test on a T2370 but it'd be on a cygwin+win7 so you'd get hours of sys [17:05:51] <KotH> lol [17:07:24] <Kovensky> either that or it'd overheat and suffer an emergency shutdown [17:07:33] <Kovensky> shit idles at 70C at best ._. [17:07:41] <KotH> o_0 [17:07:54] * Kovensky is forcibly throttling it to 80% speed to avoid reaching 100C [17:11:58] <twnqx> i once throttled a cpu clockspeedwise to avoid blowing the fuse in a plane >_> [17:54:08] <alien_> im looking for the bes video converter but im a newbie so i need a screen that shows me what im doing,,not terminal [17:54:16] <alien_> can someone help [17:54:47] <peloverde> "Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg." [17:55:54] <alien_> so even if u know u wont tell me necause im not in that channel [17:56:29] <twnqx> ffmpeg doesn't show [17:56:39] <twnqx> actually, none of the good tools do :P [17:56:52] <alien_> not good [17:56:55] <twnqx> also, an encoder just encodes. nothing to see here. [17:56:58] <alien_> hard to work for newbies [17:57:43] <alien_> see somebody that wants to work with linux need a degree on computers [18:01:00] <Compn> twnqx : recommend 'super' next time :P [18:02:40] <CIA-99> ffmpeg: mru * r24229 /trunk/libavcodec/avfft.c: avfft: remove useless parens [18:12:23] <peloverde> "This seems like a real mess. How come that Opera managed to release a (supposedly) compatible WebM decoder? [18:12:23] <peloverde> " WTF are people really that retarded [18:12:42] <BBB> opera uses libvpx, no? [18:13:02] <BBB> I emailed their CTO once, he doesn't like ffmpeg - at all [18:13:04] <peloverde> opera uses libvpx wrapped via gstreamer [18:13:09] <BBB> he calls "the whole thing" a mess [18:13:30] <elenril> ffmpeg is clearly evil [18:13:56] <elenril> decodes other formats than theora etc [18:14:51] <BBB> "ffmpeg makes vp8 violate h264 patents" [18:14:56] <kierank> lol [18:14:59] <mru> by sharing code between h264 and vp8 [18:15:09] <kierank> flawless logic right there [18:15:12] <BBB> absolutely [18:15:22] <mru> I wouldn't be surprised if someone said that and meant it [18:15:40] <mru> like mozilla believe using ffmpeg to decode theora is illegal [18:15:42] <BBB> it's sad how that kind of mindset is supported by supposedly "pro-free-software" tards [18:16:04] <BBB> mozilla knows better, at least their board... just some people around it are insanely stupid, like chris blizzard [18:16:06] <mru> the "tard" part says it all [18:16:27] <BBB> after all, mozilla funded that website to convert any video to theora^d^dwebm [18:16:32] <BBB> what's its name again? [18:16:39] <BBB> miro? [18:16:39] <kierank> wehavetoomuchgooglemoney.com [18:16:47] <mru> youtube? [18:17:02] <BBB> mirovideoconverter.com [18:17:04] <BBB> funded by mozilla [18:17:07] <BBB> uses ffmpeg internally [18:17:19] <elenril> >convert any video [18:17:25] <elenril> so yeah, what else could they use [18:17:50] <BBB> gstreamer? [18:17:53] <BBB> oh wait [18:17:54] <kierank> so you use supposedly evil patented software so you can avoid using evil patented software [18:18:00] <kierank> more flawless logic [18:19:10] <elenril> BBB: actually tons of user have no idea they're using ffmpeg [18:19:39] <elenril> it needs more publicity [18:20:52] <peloverde> elenril: I agree [18:21:46] <BBB> I've said that once [18:21:50] <kierank> turn ffmpeg into some sort of emotional argument and you'll get all the publicity you like [18:21:53] <kierank> that's what xiph do [18:22:09] <BBB> but all projects that use ffmpeg to supposedly free you from the patented evil outside world, they all refuse [18:22:34] <BBB> I don't think they even know that ultimately, we're all on the same side [18:22:35] <BBB> but ohwell [18:22:36] <kierank> also you need to make vlc change their name to ffmpeg/vlc [18:22:48] <jai> lol [18:23:08] <kierank> and if anyone just says plain "VLC" inflict a verbal tirade on them [18:23:13] <elenril> lawl [18:23:39] <mru> ff/vlc [18:24:01] <BBB> just ffvlc [18:24:08] <BBB> fstreamer [18:24:14] <BBB> fnome [18:24:37] <BBB> we should rewrite glib and base it on libavutil and call it lavulib [18:24:53] <peloverde> What about firefogg [18:25:09] <jai> lavc/lavf bindings for python/ruby might get some publicity [18:25:14] <jai> well atleast on reddit [18:25:21] <kierank> or haskell [18:25:27] <peloverde> That's another thing people say they use to avoid ffmpeg, but it really wrapps FFmpeg [18:25:41] <jai> kierank: dons will do that :) [18:25:42] <peloverde> Can we ask free software projects taht ship ffmpeg binaries to credit FFmpeg? [18:25:49] <BBB> peloverde: yes [18:26:01] <BBB> but the definition of "credit" in legal terms is rather unspecific [18:26:06] <mru> someone should create a libavcompat of lavc wrappers api-comptible with everything we replace [18:26:07] <jai> peloverde: of course [18:26:14] <BBB> source code attribution might be enough already [18:26:19] <jai> one would assume they do that already, but you never no... [18:26:22] <BBB> so gpl-compliant projects that ship source would never have problems [18:26:27] <mru> and then insist that anything using libpng or is derived from ffmpeg and thus patented [18:26:33] <jai> *know [18:26:36] <mru> s/or// [18:26:44] <peloverde> BBB, jai: I don't really care about full source offfer yada yada, but credit and a link is more than reasonable [18:26:58] <BBB> peloverde: I fully agree [18:27:01] <jai> indeed [18:27:09] <BBB> peloverde: I think most projects do that, we should ask the ones that don't to still do it [18:27:16] <mru> the full source code thing is a nice stick to beat them with [18:27:29] <BBB> http://gstreamer.freedesktop.org/modules/gst-ffmpeg.html - no ffmpeg link [18:27:41] <jai> BBB: yell at them ;) [18:27:44] <BBB> who was the gst kid in here again? [18:27:54] <mru> bilboed [18:27:55] <jai> bilboed isnt around [18:27:56] <peloverde> superdump ;) [18:28:01] <mru> BBB [18:28:20] * elenril sees no mention of ffmpeg at http://www.mplayerhq.hu/design7/info.html [18:28:25] <peloverde> http://firefogg.org/ has no mention [18:28:29] * kshishkov suspects it's everybody except him [18:28:41] * elenril blames KotH [18:29:38] <elenril> youtube doesn't give credit! [18:29:59] <BBB> youtube doesn't distribute [18:30:00] <jai> _skal_: ^ [18:30:06] <jai> but credit would be nice :) [18:30:10] <BBB> agreed [18:30:18] <BBB> bbc doesn't credit [18:30:24] <BBB> although they openly admit on our mailinglist [18:30:31] <KotH> i'd rather take their money than their credit ;) [18:49:11] <peloverde> http://bugs.launchpad.net/firefogg/+bug/605132 [18:50:18] <jai> peloverde: thx for doing that [18:52:05] <jai> also, now that ffprobe is in trunk, maybe we can remove it from projects.html? [19:01:21] <peloverde> Is it better to just add these free software projects to the projects using FFmpeg page or wait until they reach some level of "compliance"? [19:03:48] <peloverde> Also the tcvp link is dead [19:16:26] <_av500_> tcvp ftw! [19:23:06] <mru> heh [19:23:41] <mru> it's probably the most over-engineered thing I've ever made [19:24:24] <mru> but that's what you get when you take two crazy EE students and give them too much time [19:25:09] <mru> it actually started out as an assignment at uni [19:25:39] <mru> it went out of control somewhere along the way [19:27:33] <peloverde> Does anyone remember the name of the thread where the audio overhaul is being discussed? [19:27:44] <mru> which one of them? [19:28:07] <mru> I guess pross-au's thread is more focused [19:28:47] <astrange> [FFmpeg-devel] [PATCH+RFC] AVFrame for audio [19:30:14] <mru> hmm, look what I found http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/10208 [19:31:20] <peloverde> You mean we discuss something for a while, fail to reach consensus, and shelve it? Unthinkable [19:31:35] <mru> this is extra good [19:31:47] <mru> it has felker _and_ kabi [19:32:02] <mru> and alex as bonus troll [19:45:54] <peloverde> "This isn't a case of the pot calling the kettle black, it's a case of the pot calling the kettle a chicken eating n***r and joining the KKK" a +14 comment on reddit about DS http://www.reddit.com/r/programming/comments/cp216/vp8_a_retrospective/c0u5… [19:47:06] <mru> where is this mythical hardware that only supports baseline? [19:47:46] <elenril> >implying D_S wrote the h.264 standard [19:47:46] <Honoome> peloverde: well, didn't you know that reddit is the place where "rebels" who only rant about the status quo find peace? [19:49:49] <Honoome> okay now can somebody tell me how is it possible that people feel like ccache helps them with building stuff that uses C++ like kdelibs when a) the object files are HUGE so the hashing/copying is a huge hit b) the longest step ever is the linking ? [19:50:28] <mru> when did linking get so expensive? [19:50:47] <peloverde> when people started using c++? [19:50:56] <mru> 10 years ago, I always knew the wait was almost over when I saw the link command [19:51:20] <mru> a 1-hour build would link in less than a minute [19:51:25] <mru> and even that would be extreme [19:51:33] <elenril> my laptop spends ages in iowait when trying to get enough free ram for linking [19:51:39] <mru> elenril: get more ram [19:51:43] <elenril> inb4 get more ram [19:51:46] <elenril> lol [19:51:55] <peloverde> When I only had 2GB ram I couldn't link chrome [19:52:02] <Yuvi> now we have LTO so you can get C++ link times even with C [19:52:19] <mru> does lto give you _anything_ else? [19:52:30] <mru> apart from a few bonus bugs [19:53:35] <Honoome> Yuvi: and what happens with C++ link time? [19:53:37] <twice11> LTO should give you the performance advantage of inline functions without having to expose source code in header files. [19:53:52] <Yuvi> not really for C unless you wrote it without caring about performance [19:54:30] <Honoome> LTO basically is just a way to fix the conudrum of "extern inline functions" as far as I can tell [19:54:33] <jai> i dunno about gcc's lto but firefox seemed to benefit a bit with ltcg turned on in VS [19:55:07] <peloverde> Firefox is C++ [19:55:25] <jai> yeah [19:55:41] <mru> Honoome: what conundrum? [19:55:46] <Yuvi> Honoome: well, c++ has a number of other problems with inlining class functions and templating that LTO fixes, still makes link times astronomical [19:55:58] <mru> it's a valid optimisation of course, but "extern inline" has no such meaning according to spec [19:56:32] <Honoome> mru: in C++ it should have iirc [19:56:54] <mru> how did the optimising linkers in all the old unixes manage btw? [20:01:04] <hyc> there weren't a lot. aix is the only one I recall. maybe mips. [20:01:38] <mru> I never looked into the details but many linkers have -O flags [20:01:52] <Honoome> gnu ld has it as well [20:01:55] <mru> I'm pretty sure I've seen it on sun [20:01:55] <Honoome> but it does not perform LTO [20:02:01] <mru> Honoome: only for compatibility with sun [20:02:08] <Honoome> nope it does a couple of things [20:02:23] <mru> the gnu linker accepts tons of sun flags and then ignores them [20:02:40] <mru> almost everything gnu is closely modeled on sun [20:03:03] <mru> not that there's anything bad about that [20:03:24] <Honoome> too bad they stopped taking hints from Sun ELF extensions a bit of time ago [20:03:43] <mru> NIH got the better of them [20:03:44] <Honoome> I wouldn't have minded if GNU ld produced the padded .dynamic section that allows to _add_ RPATH [20:04:04] <mru> without rewriting the entire file [20:04:09] <Honoome> obviously [20:04:18] <Honoome> anyway ld -O1 does changes a bit of the [20:04:24] <Honoome> shared object generation [20:05:56] <hyc> The MIPS linker actually made code changes, replacing larger offsets with smaller ones where possible, and relocating to compensate [20:06:40] <mru> and the aix linker does some bizarre things [20:06:52] <mru> because they designed such a twisted abi [20:13:28] <peloverde> I need to get filtered Internet or something, I read reddit and get angry and lose motivation to actually work on FFmpeg [20:13:51] <mru> how about simply not reading it? [20:14:28] <Honoome> peloverde: not reading reddit is a perfectly valid solution [20:16:30] <peloverde> easier said than done [20:16:51] <Honoome> peloverde: it's like reading comments on bugs for me... I ask for broken documentation to be killed, I get the door slammed in my face (bug closed right away), I call the doc bullshit and I'm called the relations police at me, I reopen to public the bug and I'm the rude one [20:25:37] * pJok turns off any http access for peloverde [20:27:39] <kierank> pJok: you are the master of the internets? [20:27:53] <mru> isn't that al gore? [20:29:41] <Honoome> kierank: he only has to be the sysadmin at peloverde's isp [20:31:52] <BBB> peloverde: are you one of those who spends half day reading slashdot etc.? :-p [20:32:21] <peloverde> somedays I do :( [20:33:04] <BBB> seriously, you should stop doing it [20:33:18] <mru> it rots your brain [20:33:30] <BBB> after a year or so, so when you're beyond your initial "ohmygod I'm depressed because I cannot read slashdot-tards", you'll suddenly feel so much better [20:33:48] <BBB> slashdot is like crack [20:33:52] <BBB> you think you like it [20:34:23] <mru> 10 years ago it was actually interesting at least some of the time [20:34:45] <spaam> mru: so http://www.theregister.co.uk/ is bette? :P [20:34:47] <spaam> better [20:35:11] <peloverde> I don't even particularly like it but it's easy... far easier than chasing bugs through ffaacenc [20:35:17] <mru> spaam: hardly comparable [20:35:34] <mru> peloverde: bug debugging is more satisfying when you succeed [20:35:46] <mru> there's no such thing as succeeding on /. or reddit [20:35:53] <peloverde> So I go to gawk and at some point I feel involved [20:35:54] <mru> unless you are a pure troll [20:36:58] <elenril> mru: http://encyclopediadramatica.com/List_of_ways_to_win_at_the_internet [20:37:05] <peloverde> What happened to required "-strict experimental" for aac, "./ffmpeg -i ../../exp/cdn.wav out.m4a" seems to work and it isn't generating ALAC [20:37:46] <BBB> peloverde: faac? [20:37:52] <kierank> mru: this guy won reddit http://www.reddit.com/r/entertainment/comments/cp190/the_old_spice_man_resp… [20:39:03] <saintdev> oh wow he posted on reddit also [20:39:24] <pJok> mru, Obama is the master of the internet... he has the killswitch [20:39:37] <peloverde> kierank: Do you see what you are doing to me?! ;) [20:40:08] <peloverde> BBB, nope, I don't "--enable-nonfree" [20:44:43] <Honoome> peloverde: I thought faac was only considered gpl, not nonfree? [20:44:55] <peloverde> Honoome: You are thinking of faad [20:45:09] <peloverde> faac cribs a bunch of ISO reference code [20:45:19] <mru> considered gpl... [20:45:34] <Honoome> which version? I know there was a faad version with an advertising clause that is gpl-incompatible [20:45:40] <Honoome> but I don't remember specific trouble with faac beside patents [20:45:44] <bcoudurier> peloverde, it doesn't work by codec_id [20:46:04] <Honoome> mind you, before rms and the freetards made a fuss about gentoo we were pretty liberal for what concerns licenses [20:46:32] <peloverde> Honoome: Its exactly the same as the old lame issue back in the day [20:46:51] <mru> gentoo is still pretty liberal [20:47:05] <Honoome> mru: less so than we used to be [20:47:13] <Honoome> we're still "hiding" with the fact that we don't provide binaries ;) [20:47:14] <bcoudurier> mru [20:47:20] <mru> it lets me link whatever the hell I want against curl, even if curl is linked against openssl, for instance [20:47:24] <bcoudurier> I found a patch somewhere that use attribute hidden [20:47:30] <bcoudurier> for some symbols like ff_pb* [20:47:51] <bcoudurier> that makes compilation work with PIC when compiling statically in a shared library [20:47:58] <bcoudurier> what's wrong with this approach ? [20:48:31] <mru> I see no relation between symbol hiding and pic [20:48:49] <peloverde> If i use out.webm it tries to use ffvorbis [20:48:59] <bcoudurier> linker says it cannot relocate ff_pb* [20:49:15] <mru> yes, that won't go away by hiding it [20:49:18] <bcoudurier> it does [20:49:22] <mru> weird [20:49:28] <mru> are you using -Bsymbolic as you should? [20:49:31] <bcoudurier> I use __attribute__(hidden) [20:49:39] <bcoudurier> default configure flags [20:49:43] <bcoudurier> just --enable-pic [20:49:46] <bcoudurier> for x86_64 [20:49:52] <mru> well, does it use -Bsymbolic? [20:50:04] <bcoudurier> yes [20:50:08] <Honoome> mru: -Bsymbolic still allows the symbol to be exported [20:50:18] <Honoome> hidden visibility avoids exporting it [20:50:24] <mru> yes, but internal references are bound directly to the local one [20:50:32] <mru> tey can't be interposed [20:50:42] <Honoome> true but I guess here the linker is dying because of the exported copy not the local one [20:50:55] <mru> that's weird [20:51:01] <Honoome> seen weirder [20:51:06] <mru> exporting a symbol doesn't create relocations [20:51:32] <bcoudurier> it's when creating a shared library from libavcodec.a [20:51:40] <bcoudurier> more specifically a python c binding [20:51:51] <bcoudurier> on x86_64 [20:51:55] <mru> does --enable-shared work? [20:51:57] <Honoome> bcoudurier: are you using -Bsymbolic when linking the binding? [20:52:12] <bcoudurier> ah not when linking the binding, no [20:52:13] <mru> -Bsymbolic has no effect on the .a [20:52:23] * Honoome hands mru the harisen [20:52:31] * Vitor1001 is in a soc-student answering frenzy ;) [20:52:57] <bcoudurier> if we require so, maybe we should put that in the FAQ [20:53:10] <bcoudurier> I just added hidden to the ff_pb* [20:53:27] <Honoome> to be honest I wouldn't mind if we started hiding symbols :P [20:53:33] <mru> I had no idea we required anything like that [20:53:41] <mru> and we do hide loads of symbols [20:54:00] <Honoome> yeah? [20:54:07] <mru> the version scripts do that [20:54:16] <mru> building a shared lib from a .a isn't really supported [20:54:19] <mru> by us [20:54:26] <mru> too many caveats [20:54:27] <Honoome> mru: that only hides them at .so time :P [20:54:34] <bcoudurier> that very useful though [20:54:39] <mru> Honoome: of course [20:54:41] <bcoudurier> at least for bindings [20:54:44] <mru> you can't hide them in the .o files [20:54:47] <mru> nothing would work then [20:55:02] <Honoome> mru: you can mark them hidden in the .o files [20:55:16] <mru> yeah, I suppose [20:55:20] <Honoome> that way when producing another .so from them (without the version script) they won't be exported [20:55:29] <mru> but every patch anyone posted to do that was full of hack [20:55:31] <Honoome> and bcoudurier's use case would work out of the box [20:55:33] <Honoome> yes I know [20:55:35] * Honoome posted one [20:55:46] <mru> I know you did [20:55:52] <mru> and it wasn't pretty [20:56:20] <Honoome> bcoudurier: I'm not sure how useful it is for bindings tbh... distros would probably dislilke that :P [20:56:40] <bcoudurier> well I'm talking about distros [20:56:45] <bcoudurier> I'm talking about tools I deploy [20:56:58] <mru> linking the the .so makes more sense to me [20:57:04] <mru> *linking to [20:57:10] <bcoudurier> and usually when it's static I have way less problems [20:57:34] <bcoudurier> I'm not _talking_ about distros, sorry [20:57:38] <mru> rpath tricks not good enough? [20:58:40] <bcoudurier> dunno, I've never used that [20:59:26] <bcoudurier> also compiling static permits to not upgrade existing tools [20:59:44] <bcoudurier> meaning no weird problems because of upgrade [21:00:02] <bcoudurier> but that would also be fixed by rpath I guess [21:13:19] <peloverde> What are people's thoughts on mono bitrates? [21:14:19] <mru> never really thought about them [21:15:14] <peloverde> maybe someday I'll understand this obsession with stereo [21:15:17] <peloverde> :) [21:35:32] <Kovensky> I remember when I was trying to stuff 1h of music in under 25mb with lame [21:36:00] <Kovensky> downmixing to mono was the single largest quality drop, even if I kept the same bitrate as the stereo encode [21:36:51] <mru> sounds odd [21:36:57] <Kovensky> I prefered to lower the bitrate and raise the lowpass a little bit (thus getting more artifacts, but somewhat more surviving detail) [21:37:07] <mru> stereo to mono downmix shouldn't lose _that_ much quality [21:37:38] <Kovensky> http://money.cnn.com/2010/07/13/technology/windows_xp/index.htm?source=cnn_… [21:37:44] <Kovensky> link not related, but lol [21:38:11] <Kovensky> mru: probably the downmixing algo sucked, lame just does averaging [21:38:23] <mru> is there another way? [21:38:46] <Kovensky> I may just be making up stuff (I suck at math), but maybe biasing towards the extremes would help [21:38:59] <mru> what does that mean? [21:39:21] <Kovensky> averaging is very noticeable when there are stereo effects like guitar switching from left to right or vice-versa, or when there's enough stereo separation in the original [21:39:37] <mru> you lose the separation of course [21:39:42] <mru> but that's expected [21:39:44] <Kovensky> the "further" the sound is from the average, the more it dies down [21:41:02] <mru> how else would you do it [21:41:14] <mru> imagine placing your two speakers side by side [21:41:32] <mru> so they effectively become a single source as far as your perception is concerned [21:42:14] <mru> either one at max amplitude will obviously be only half as strong as both at max at the same time [21:42:29] <Kovensky> I just wonder if adding a bias towards "extremes" would help [21:42:39] <Kovensky> I never actually looked into psychoacoustics (but I'd like to) [21:42:42] <mru> I'd be more worried about the sided cancelling out [21:43:01] <mru> if you have the same frequency with opposite phase on either channel [21:43:22] <mru> in a stereo setup you'd still hear something [21:43:33] <mru> depending on your listening position [21:44:29] <Kovensky> yeah [21:45:18] <mru> maybe some kind of frequency-domain averaging would work better [21:45:48] * Kovensky should study DSP [21:46:06] <Kovensky> I find it a really interesting subject but I never find time / good sources =p [22:09:43] <peloverde> I love one I see a bug and it turns out to be at least to or three actual bugs [22:23:11] <Compn> i think its more fun when you find a bug and do a quick one-line hack but then its rejected because you have to refactor a ton of code to make ti all right :P [22:25:40] <mru> even better is when you have a small, clean patch fixing the problem, but fails to fix an unrelated problem someone remembers when seeing the context of the diff [22:26:34] <Compn> oh those are fun [22:26:51] <Compn> what about 'oh i've had that in my tree for a year, i should have committed it...' replies? [22:27:06] <peloverde> http://firefogg.org/ Fixed [22:31:26] <mru> Compn: at least those get it fixed [22:35:03] <peloverde> What do people think about a "powered by FFmpeg" logo? would that be too 1990s? [22:37:45] <mru> I have a better idea [22:38:01] <mru> sell licences to display the ffmpeg logo [22:38:13] <mru> like dolby etc [22:38:38] <peloverde> Who would we sell them too? The FFmpeg hosting people> [22:38:54] <mru> anyone who'll buy [22:38:56] <kierank> why would anyone buy one? [22:39:06] <saintdev> google [22:39:10] <mru> if we sue them if they display it without paying... [22:39:19] <saintdev> oh wait they "don't use ffmpeg" ;) [22:39:28] <hyc> how much do the logos have to sell for to cover the cost of a laywer? [22:39:38] <Dark_Shikari> hyc: lol [22:39:52] <peloverde> I would rather not get into Mozilla style trademark trolling [22:39:58] <Dark_Shikari> +1 [22:40:28] <mru> my favourite is the debian logo [22:40:29] <hyc> and registering a trademark costs money and lawyer time already [22:40:46] <mru> some troll used a standard brush applied to a default spiral in adobe illustrator or similar [22:41:02] <mru> and now they throw a hissy fit whenever someone else uses the same default settings [22:41:54] <saintdev> don't steal their magic smoke [22:42:02] <hyc> if they actually paid to register a mark then they're obligated to object whenever anything similar comes along. otherwise the registration is invalidated [22:43:44] <peloverde> You can still have a broadly license a trademark and protect it against specific abuses [22:45:07] <peloverde> Intent is a big part of the law even though programmers are uncomfortable with it [22:45:10] <hyc> either way, you have to demonstrate that you were proactive in all cases. You have to show that you negotiated a license, or that you pursued an infringer. [22:45:28] <hyc> if you can be shown to be negligent, your mark can be ruled to be abandoned. [22:45:49] <peloverde> no you don't, you can lay out guidelines for use and only go after people that break those guidelines [22:46:04] <peloverde> you don't need to negotiate individual licenses with each user [22:47:15] <hyc> hmmm. I suppose. But in general, licenses require mutual agreement to be enforceable. [22:48:09] <michaedw1> the best part of the debian smoke is that it's an "homage" to Buzz Lightyear's chin spiral [22:48:31] <mru> hyc: yes, but trademarks are protected without a contract [22:48:34] <mru> just like copyright [22:48:52] <Dark_Shikari> michaedw1: lol [22:49:04] <saintdev> michaedw1: lol [22:49:14] <michaedw1> just like copyright, a trademark is a legislatively created basis for a tort claim [22:49:44] <mru> most trademarks are only granted in a narrow field though [22:49:55] <hyc> yes [22:49:59] <mru> so that linux washing powder doesn't infringe [22:50:20] <hyc> but registration means you're getting exclusive use. in order to allow anyone else to use it, you have to explicitly licens to them. [22:50:46] <mru> if they fall within the same field [22:50:47] <michaedw1> not exactly. depends on what sort of "use" they're making of it. [22:51:20] <hyc> And then there's perfectly non-infringing stuff, which you can still make a fuss over. Like DEC over "Nothing sucks like a Vax." [22:51:25] <mru> if your trademark registration only covers computer programs, I can sell furniture under the same name without bother [22:51:36] <michaedw1> they can use it in "better than Brand X" comparisons too [22:52:00] <michaedw1> they just can't apply it to their own products [22:52:37] <mru> yes, using a trademark to refer to the thing it was registered for is ok [22:52:52] <michaedw1> or imply that they are affiliated with it, or otherwise try to make use of the goodwill associated with it [22:53:07] <michaedw1> including with their own "confusingly similar" mark [22:54:45] <michaedw1> the trademark registration procedure, like the patent application procedure, exists largely to establish a standardized set of factoids that will be useful in the event of litigation [22:55:38] <michaedw1> you don't really find out how broad the scope of your trademark is until you try to sue someone for misappropriating it [23:14:10] <kierank> i love it when there's a massive chunk of code that doesn't seem to be ever used and i don't have to reverse engineer it [23:18:03] <Honoome> kierank: only if you were to reverse it you'd find it's actually the answer to life, the universe and everything [23:19:03] <Honoome> (nop isn't 0x42 in x86, is it?) [23:19:14] <Honoome> 0x90 maybe? [23:22:07] <Dark_Shikari> 0x90 yes [23:23:09] <lu_zero> yawn [23:23:35] <Honoome> lu_zero: since for one rare occasion we _are_ debugging ffmpeg :P [23:23:43] <lu_zero> eh.. [23:23:52] <Honoome> well, you are, I'm playing MI2 :P [23:24:05] <lu_zero> mi2? [23:24:21] <Honoome> monkey island 2 [23:24:38] <lu_zero> Honoome: tell me how to make gdb watch a field a struct across different function calls [23:24:51] <Honoome> trying to get the "less than three hours completion" trophy [23:25:10] <Honoome> lu_zero: I could suggest you voodoo programming to stay on topic :P [23:25:55] <Honoome> although I guess 3dfx failing cut that option out [23:26:41] <Honoome> lu_zero: watchpoints should refer to memory areas iirc [23:27:22] <Honoome> maybe mru has a better idea [23:27:33] <mru> use printf [23:28:03] <hyc> just print &struct->field and then watch the address [23:28:24] <mru> watchpoints rarely work the way you hope [23:28:42] <hyc> heh. use them enough times and you get used to how they actually work. [23:29:06] <mru> I know how they work [23:29:13] <mru> it's just rarely useful [23:29:35] <mru> maybe if your code is sloppy they can be useful [23:29:47] <mru> if you really have no clue what is writing where [23:30:30] <hyc> or if you're chasing an overrun caused by some library that you didn't write... [23:30:38] <mru> valgrind [23:31:08] <peloverde> valgrind is king [23:31:46] <hyc> valgrind is nice, but it still requires you to know something about your code. [23:31:52] <lu_zero> I'm pretty much puzzled [23:32:02] <bcoudurier> valgrind ownz [23:32:17] <mru> if you don't know anything about your code, you're doing something very wrong [23:32:20] <Honoome> lu_zero: no I am [23:32:20] <lu_zero> since I don't know where and when the avcontext->start_time gets garbled [23:32:44] <hyc> and valgrind won't help you find overruns that don't cause immediate SEGVs [23:32:58] <bcoudurier> it does here ? [23:33:02] <Honoome> hyc: uh yes it would [23:33:07] <Honoome> it lists all invalid memory accesses [23:33:08] <hyc> a watchpoint is still better for that [23:33:21] <hyc> Honoome: nobody said the access had to be invalid. [23:33:54] <hyc> overrunning a couple of packed fields in a struct [23:34:04] <hyc> or a large array offset that lands in another valid memory region [23:34:07] <peloverde> valgrind will find illegal and uninitialized reads before the SEGV [23:34:32] <mru> valgrind pads allocations enough that most overruns are caught [23:35:01] <mru> if something writes to a totally random address that happens to be in a valid block, it won't notice of course [23:35:03] <lu_zero> so [23:35:03] <Honoome> hyc: if it's a large offset it'll be caught, the structure I'm not sure [23:35:07] <lu_zero> it starts 0 [23:35:35] <lu_zero> av_open_input_stream sets it to AV_NOPTS_VALUE [23:35:52] <mru> printf the value in a bunch of places where you think you know what it should be [23:35:59] <mru> or at least can tell if it's bad [23:36:02] <lu_zero> sdp_parse sets it back to 0 [23:36:06] <bcoudurier> demuxer or in av_find_stream_info [23:36:15] <mru> then binary search [23:36:24] <lu_zero> av_update_stream_timings botches it [23:37:09] <mru> looks like you already know the answer then [23:37:20] <lu_zero> now the question is _why_ it does that? [23:37:31] <mru> I'm afraid no debugger can tell you that [23:37:39] <mru> you'll have to read the code and understand it [23:37:46] <mru> scary, I know [23:38:43] <lu_zero> mru: what's scary is that I'm afraid to know [23:38:55] <lu_zero> since makes _no_ sense [23:39:08] <Honoome> you wrote the code by chance? [23:39:19] <lu_zero> you cannot set to negative a stream that starts at 0 [23:39:26] <lu_zero> and you know that [23:39:44] * Honoome knows eah [23:39:50] <bcoudurier> what's the status of faad btw ? [23:39:52] <lu_zero> Honoome: if the rtsp.c code is at fault maybe [23:40:01] <bcoudurier> removed, right ? [23:40:05] <mru> yes [23:40:13] <bcoudurier> thanks [23:40:37] <Honoome> lu_zero: not from feng side though, right? [23:42:47] <Honoome> if I do finish mi2 in less than half an hour I'll take a look if you can cut down the area [23:44:03] <lu_zero> the strange assumption is in ffmpeg apparently [23:47:39] <Honoome> which function? [23:47:51] * Honoome just finished mi2 [23:49:15] <lu_zero> av_update_stream_timings [23:50:42] <Honoome> lu_zero: quick way for me to reproduce? [23:51:34] <lu_zero> open demuxer_avf.c in feng [23:51:51] <lu_zero> feed av_open_input_file with an rtsp url [23:52:16] <lu_zero> e.g. rtsp://media.lscube.org/tests/tc.mov?tcp [23:52:42] <Honoome> you mean you don't know why it appears to be -1 when you try to seek to -1? [23:53:12] <lu_zero> no [23:53:35] <lu_zero> s->start_time gets overwrote [23:53:39] <lu_zero> hi j0sh [23:53:44] <lu_zero> so from a proper 0 [23:53:54] <lu_zero> as parsed by sdp_parse [23:53:57] <lu_zero> you get garbage [23:54:16] <Honoome> may I ask you for a favour then? :P [23:54:18] <lu_zero> and I'm wondering what ffmpeg/ffplay does to prevent that [23:54:40] <Honoome> testcase it down to simple calls... [23:55:16] <lu_zero> Honoome: quite feasible [23:56:57] <lu_zero> avformat_alloc_context + av_open_input_file + av_find_stream_info [23:57:00] <lu_zero> that's all [23:57:34] <Honoome> write a .c file, will ya?

1 0

IRC log for 2010-07-12
by irc＠mansr.com 13 Jul '10

13 Jul '10

[00:12:37] <saintd3v> peloverde: so do both long and short windows belong to a window group? [00:13:24] <peloverde> saintdev: Each frame is either one long window or eight short windows, the eight short windows are divided into groups [00:14:49] <saintd3v> ok, that's what i guessed. what do the groups signify? is each group one temporal block? [00:16:53] <peloverde> each window is a complete MDCT window [00:17:13] <peloverde> Windows in the same group have identical scalefactors [00:17:54] <peloverde> (as well as identical stereocoding status) [00:22:45] * Honoome wonders what in the mind of humans make them think that theycan make a difference all at once, after five years of nobody caring enough to force a _small_ change? =_= [00:54:32] <hemanthm> NAMES ffmpeg-devel [03:05:40] <saintdev> peloverde: would you be ok with http://pastebin.org/389742 [03:07:45] <peloverde> In principle I have no problem with it but it seems unnecessary until there is a second psymodel available [03:08:28] <saintdev> true [07:17:49] <av500> so, now I have all 5 utube 4k samples downloaded [07:20:06] <kshishkov> can your player handle them in native resolution? [07:21:23] <av500> not yet [07:21:34] <av500> I might have to hook a few players together [07:22:24] <kshishkov> archos videowall? [07:22:32] <mru> mornings [07:22:38] <av500> greets [07:22:49] <Yuvi> why does this guy on the ML keep insisting that a C99 compiler can't use posix functions... [07:23:14] <av500> because he can? [07:24:24] <av500> nice, ffplay segfaults on these 4k clips [07:25:09] <av500> in libavfilter [07:25:31] <kshishkov> goda morgnar, mru [07:25:47] <kshishkov> av500: probably swscaler issue [07:25:48] <mru> kshishkov: in the office already? [07:25:56] <kshishkov> mru: of course, unlike you [07:26:07] <av500> mru: a, the german fif [07:26:09] <av500> gig [07:26:20] <thresh> moroning [07:26:22] * av500 must wake up [07:26:30] <av500> mru: ah, the german gig [07:26:44] <av500> kshishkov: I hope your offices are airconned [07:26:50] <kshishkov> av500: I'd say it was just for my entertainment but who cares about me? [07:26:51] * mru blames the french woman who was supposed to fetch him... [07:27:05] <kshishkov> mru: I can tell her [07:27:15] <thresh> don't tell me about air conditioning :( [07:27:24] <av500> 29.7 here... [07:27:29] * mru hopes there is air conditioning [07:27:36] <mru> oh yeah... [07:27:38] <kshishkov> thresh: you don't like fairy tales? [07:27:43] <mru> av500: wtf did you do to the trains last night? [07:27:43] <av500> mru: the air is in a condition! [07:27:44] <kshishkov> mru: there is [07:27:56] <av500> mru: some ppl got grilled at 50°.... [07:27:57] <thresh> kshishkov: i'd enjoy airy ones now [07:28:19] <mru> all trains from FRA were at least 1h delayed [07:28:42] <av500> heat [07:28:43] <thresh> maybe they started to melt. [07:28:53] <mru> I managed to get a on a crowded ICE to mannheim [07:29:02] <av500> german trains run well in extreme balmy wheather only... [07:29:08] <mru> caught a delayed connection from there [07:29:31] <mru> they apologised for the delay, caused by an interruption of service [07:30:31] <mru> seriously, that's what they said [07:30:54] <superdump> there has been a delay [07:31:02] <superdump> it was caused by something that caused a delay [07:31:12] <kshishkov> by definition [07:31:15] <superdump> have a nice delay [07:31:39] <mru> or does "betriebsabbruch" (iirc) mean something else? [07:32:54] <superdump> google translate says "demolition company" [07:33:08] <mru> that sounds wrong to me [07:33:12] <mru> but I'm not german... [07:33:13] <superdump> probably [07:33:23] <av500> interruption of service [07:33:29] <av500> or something like that [07:33:34] <mru> like I said [07:34:01] <twice11> interruption od service would be "Betriebsunterbrechung". [07:34:22] <twice11> "Betriebsabbruch" would be more like "termination of service". [07:34:37] <mru> but then there should've been no train at all [07:35:07] <twice11> Maybe it was too hot for the guys to use the right word. [07:35:20] <mru> the train was nice and cool [07:35:26] <mru> the second one [07:35:30] <av500> you lucky bastard :) [07:35:31] <mru> the first one was too crowded [07:35:49] <mru> not melting, but not nice either [07:36:02] <mru> melting ice... [07:36:05] <mru> hmm [07:37:41] * av500 ponders grabbing the new laptop and going to the cellar [07:37:59] <mru> your dungeon has wifi? [07:38:14] <av500> I can run a cable there as well [07:38:21] <av500> it has cat6 [07:38:27] <kshishkov> mru: the most crowded train I've seen here is Strasbourg-Offenburg regional train [07:53:36] * mru facepalms at the c99 "discussion" [08:13:09] <av500> meh, utube 4k samples are blocky [08:13:22] <kierank> it's a total waste of time [08:13:30] <kierank> someone should upload crowdrun [08:13:54] <av500> they might look good when downscaled to 1080 [08:38:36] * av500 likes the almost poetic: "[PATCH] flvdec.c consider nondecreasing dts order" [09:01:07] <CIA-99> ffmpeg: benoit * r24209 /trunk/libavcodec/dca.c: [09:01:07] <CIA-99> ffmpeg: Move XCH parameters into context structure. [09:01:07] <CIA-99> ffmpeg: Patch by Nick Brereton $name AT n$surname DOT net [09:07:26] * mru sorts frames in condescending order [09:07:50] * kshishkov sees that IRL [09:10:01] * twice11 prefers noncendensing order :) [09:10:12] * twice11 prefers noncondensing order, sorry, typo. [09:11:46] <CIA-99> ffmpeg: benoit * r24210 /trunk/libavcodec/dca.c: [09:11:46] <CIA-99> ffmpeg: Fix side channels when XCh extension is present. [09:11:46] <CIA-99> ffmpeg: Patch by Nick Brereton $name AT n$surname DOT net [09:33:44] <markuman> what did you know about the [h264 @ 0xa00dbc0]missing picture in access unit... messages? is the h264 decoder still looking for a pair of frames? [09:52:40] <CIA-99> ffmpeg: diego * r24211 /trunk: Ignore directory with generated Doxygen documentation. [10:18:11] <CIA-99> ffmpeg: lu_zero * r24212 /trunk/libavformat/rtsp.c: [10:18:12] <CIA-99> ffmpeg: Report when a method gets an error status code [10:18:12] <CIA-99> ffmpeg: That makes easier understand what went wrong. [10:18:12] <CIA-99> ffmpeg: In debug mode the whole reply gets printed. [10:43:26] <lu_zero> hi [10:44:38] <mru> lo [10:44:43] * kshishkov thinks it's really good idea to make useful commit before "hi" [10:50:03] <lu_zero> kshishkov: how are you? =) [10:59:44] <lu_zero> interesting, there is something wrong in h264_parser.c [11:00:41] <lu_zero> the h264 elementary stream doesn't seem seekable anymore [11:00:42] <twnqx> Stream #0.2: Subtitle: [0][0][0][0] / 0x0000 Unsupported codec (id=94212) for input stream 2 <-- hm. what kind of subs could that be? [11:01:18] <twnqx> (in mkv) [11:01:46] <av500> hmm [11:01:50] <lu_zero> twnqx: the 0x0000 is telling that it didn't pick anything [11:01:58] <Compn> twnqx : use mplayer [11:02:10] * Compn dislikes ffmpeg error messages [11:02:31] <Compn> mplayer -demuxer mkv that is [11:02:51] <twnqx> Compn: rebuilding mplayer. my installed binary was linked against an obsolete x264... [11:03:03] <twnqx> geh, and it doesn't compile [11:03:46] <twnqx> hm. mkvinfo says S_TEXT/ASS [11:03:49] <Compn> build static, keep old binaries :P [11:03:56] <Compn> ass parser isnt in yet [11:04:18] <twnqx> huh. i'm pretty sure ffprobe identified it earlier [11:12:59] <lu_zero> twnqx: if it did then we have a problem [12:09:25] <lu_zero> cartman: what's up? [12:09:45] <cartman> lu_zero: sky is up [12:09:47] <cartman> and hello! :) [12:11:05] <lu_zero> =) [12:30:10] <av500> DonDiego: no more typos in commit messages, just use: http://whatthecommit.com/ [12:33:14] <CIA-99> ffmpeg: benoit * r24213 /trunk/libavcodec/dca.c: [12:33:14] <CIA-99> ffmpeg: Use math constant instead of hardcoded rounded value for sqrt(0.5). [12:33:14] <CIA-99> ffmpeg: Patch by Christophe.Gisquet (gmail) [12:34:23] <ohsix> ispell hook! or an $EDITOR/VISUAL that does it for you [12:41:40] <DonDiego> stop bullshitting me with typos already, that's not what i was talking about [12:41:49] <av500> iKnow [12:42:11] <ohsix> pancreas [12:44:04] <DonDiego> ohsix: wtf? [12:46:53] <benoit-> mru: any way to have make fate verbose, instead of tiny ? [12:47:10] <benoit-> (already tried V=... of course) [12:47:59] <mru> I'll fix that [12:48:26] <benoit-> thanks [12:48:38] <mru> tonight hopefully [12:48:50] * mru has a dayjob of sorts for a while [12:49:29] <benoit-> mru: no problem, I'm in no hurry [12:51:02] <DonDiego> mru: what are you doing? [12:51:48] <benoit-> DonDiego: sorting :) [12:51:53] <kshishkov> DonDiego: sitting and typing [12:51:55] <mru> DonDiego: writing code [12:52:02] <mru> well, no actual coding done yet [12:52:03] <av500> DonDiego: ashishting [12:52:49] <mru> so how do I get ubuntu to not shove a huge window in my face every time I plug in a usb flash stick? [12:53:01] <av500> close eyes quickly [12:53:19] <av500> mru: they make you uses ubuntu? I hope they pay well [12:53:37] <mru> it was the most sane CD they had on hand [12:53:47] <kshishkov> sane? [12:53:55] <mru> if it gets too annoying I'll replace it with something else [12:56:08] <DonDiego> i use ubuntu at work [12:56:15] <DonDiego> replace gnome with something else [12:56:20] <DonDiego> awesome comes to mind [12:56:37] <mru> not to my mind [12:56:55] <mru> software rarely is the adjectives in its name [12:57:10] <janneg> killall -15 hald-addon-storage maybe [12:57:25] <mru> I found a setting to not open the window at least [12:57:29] <mru> now it only auto-mounts it [12:57:33] <ohsix> mru: in that huge window it pops up, go to Edit -> Preferences, Media tab [12:57:44] <mru> ohsix: yeah, I found that [12:57:48] <ohsix> yar there; and hal is dead [12:57:55] <mru> what if I want to enable it again then? [12:58:02] <mru> when the window is no longer popping up? [12:58:10] <av500> why would you? [12:58:22] <ohsix> thats the file browser; you can just open one of them again from Places [12:58:22] <kshishkov> any folder window may be good for that [12:58:44] <ohsix> i only mentioned it in the manner i did cuz you did already :P (and calling it nautilus is probably useless) [13:07:47] <jai> awesome is pretty good [13:08:09] <mru> isn't one of those silly tiling window managers? [13:08:41] <mru> ohsix: is it still nautilus?? UGH!!! [13:09:03] <ohsix> heh, its not as its been in the past; they've thrown most of it out [13:09:21] <ohsix> press f3 and its like xtree gold! [13:10:05] <ohsix> and it has tabs and a crumb bar [13:10:19] <mru> my file manager is called coreutils [13:10:25] <av500> mc ftw [13:10:27] * thresh uses zsh [13:10:39] <thresh> so i can interactively manage my files [13:10:41] <mru> mc was only good because the dos shell is so shitty [13:10:47] <av500> thresh: not zsh uses you? [13:11:05] <mru> thresh: zsh still needs coreutils or equivalent [13:11:09] <ohsix> it doesn't select the extension when you rename stuff either \m/ [13:11:28] <jai> mru: yeah [13:11:44] <mru> well, I _want_ overlapping windows at times [13:11:57] <mru> it's rare for all of a window to contain useful information [13:12:31] <av500> e.g. MS window [13:12:54] <ohsix> if its not a terminal window you could probably say its mostly wasted space and useless information :P [13:13:50] <jai> mru: you can float windows with awesome [13:14:05] <jai> stuff like gimp would be a pain otherwise [13:14:41] <mru> is it as customisable as emacs? [13:14:48] <mru> if not, I'll not consider it [13:14:54] <jai> mru: of course [13:15:05] <jai> the config is written in lua [13:15:13] <mru> blegh [13:15:18] <jai> quite readable imho [13:15:32] <mru> it's bloody object oriented [13:16:00] <jai> http://git.naquadah.org/?p=awesome.git;a=blob;f=awesomerc.lua.in [13:16:06] <jai> ^ thats what it looks like [13:16:12] <mru> I know what lua looks like [13:16:19] <mru> it looks like any other OO lang [13:16:39] <jai> i meant the overall configuration :) [13:17:06] <jai> again, i dont know much about why lua sucks, but it seems to fit in quite well [13:17:37] <jai> you could even write widgets in < 10loc [13:18:26] * kshishkov thinks the only good object-oriented language for window managers was Smalltalk [13:19:02] * mru likes his lisp-based wm [13:19:12] <mru> it makes sense with a functional language [13:19:16] <mru> events trigger functions [13:19:46] <jai> mru: which one? sawfish? stumpwm? [13:19:57] <mru> sawfish [13:20:02] <jai> k [13:20:16] <mru> been using it for a decade or so [13:20:19] <mru> got used to it [13:20:35] <mru> and I have a minimally intrusive configuration [13:21:08] <ohsix> sawfish ftw [13:21:47] <av500> mru: so why dont you use it then? [13:25:15] <mru> av500: I do on my computers [13:25:40] <mru> I just got dumped in front of a pc with nothing sane on it [13:27:02] <av500> apt get install sawfish? [13:27:04] <kshishkov> yes, IT guy said he can't install Gentoo there [13:27:09] <av500> lol [13:27:16] <av500> mru: quit! [13:27:18] <mru> nobody said such thing [13:27:36] <av500> so, install gentoo... [13:27:46] <av500> and take the rest of the week off while it compiles... [13:27:46] <mru> but ubuntu is half-sane compared to the rpm distros and quick to install compared to gentoo [13:28:10] <kshishkov> mru: I just said you may like it more when that PC was assembled for you [13:28:17] * av500 uses an insane rpm distro [13:28:31] <kshishkov> av500: caldera openlinux? [13:28:45] <mru> kshishkov: yes [13:28:46] * lu_zero should come up with better install media for gentoo [13:29:00] <mru> lu_zero: I'm quite happy with it as is when I have the time [13:29:27] <lu_zero> av500: updating a single fresh install of ubuntu made me reconsider how gentoo is slow to install ^^ [13:29:35] <lu_zero> still we can do way better =P [13:30:03] <mru> untarring a stage3 is fast [13:30:07] <mru> but it's rather minimal [13:30:16] <av500> lu_zero: I have no idea how slow gentoo is too install, all the docs made my tl;dr... [13:30:18] <av500> me [13:30:44] <jai> you cant use your laptop? [13:30:57] <mru> I don't think they'd like that [13:31:09] <jai> ah, enterprise security [13:31:17] <av500> jai: laptop does not run visual source safe [13:31:28] <jai> av500: lolwat [13:31:40] <av500> like the deadly joke, they let him work only on one line at a time [13:32:03] <lu_zero> mru: where did you ended up now? [13:32:19] <kshishkov> lu_zero: closer to Italy, rejoice [13:32:43] <lu_zero> how closer? [13:32:57] <mru> a few metres from kshishkov [13:33:03] <lu_zero> ah [13:33:53] <lu_zero> mru: stage4 are the way =P [13:34:32] <mru> normally stage3 is about what I want [13:34:44] <lu_zero> =) [13:34:48] <mru> since I'd be tweaking the flags and recompiling almost everything anyway [13:35:00] <mru> but get a pc up and running quickly, something more complete would be nice [13:35:19] <kshishkov> live CD [13:46:40] <pross-au> utt [13:47:53] * kshishkov tries to guess what mailer pross-au uses [13:48:49] <pross-au> yes, um, showing my noobness here. all the cool people seem to use gmail [13:49:34] <elenril> nah, gmail fails at threading [13:50:44] <kierank> this thread gets better: http://forum.doom9.org/showthread.php?p=1416686 [13:50:54] <kierank> introducing an audiophile [13:51:55] <ohsix> almost all the junk he mentions have nothing to do with extra dynamic range olol [13:55:38] <mru> I bet all that audio he's processing came off 16-bit CDs in the first place [13:56:36] <pJok> mru, remember that the loudspeaker cords have to be polarized and you have to use the speaker cables for a while before they sound their best... [13:57:33] <KotH> pross-au: the cool people have their own mailserver [13:58:01] * KotH wouldnt trust any us company with any private data [13:59:43] <av500> KotH: you trusted DHL with your home address :) [14:02:58] <pross-au> KotH: another reason why i wont outsource my brain [14:35:51] <KotH> av500: not only my home adress, but also my phone number is publicly available online [14:37:42] <mru> as is mine [14:37:45] <mru> just ask whois [14:39:12] <benoit-> I guess we're quite a lot in this case [14:41:46] <KotH> mru: interestingly, hardly anyone knows about whois...even sysadmins [14:41:53] <KotH> mru: seems to be a dark art or something [14:42:09] <mru> my mother knows about it [14:42:13] <mru> and I didn't tell her [14:43:32] <benoit-> KotH: snail mail spammers do know about it though... [14:43:45] <KotH> huh? [14:43:53] <KotH> never got snail spam that way [14:44:20] <benoit-> I already received two letters to renew my domain name that way [14:44:38] <benoit-> KotH: with really high pricing BTW [14:44:39] <KotH> thought dead family members (who've not even had a mail adress) get a wining notification every three months by snail mail [14:44:48] <KotH> lol [14:45:00] <kierank> the domain letters make it look like it's from the official NIC [14:45:02] <KotH> do you have .com domain or somethign? [14:45:38] <benoit-> KotH: .org [14:45:40] <KotH> kierank: just because it's something official looking it does not mean it is official [14:46:00] <mru> I get the domain scams about once a year [14:46:10] <KotH> kierank: unless of course it's an official looking death sentence signed by me personally... then i'd run and hide ;) [14:46:16] <benoit-> kierank: just as official as winning notification by email, huh? :) [14:46:36] <benoit-> mru: same here [15:05:11] <twnqx> ok, i'm worried now... trying to compile the latest mkvtoolnix, i get [15:05:14] <twnqx> In file included from src/common/common.h:14: [15:05:14] <twnqx> cc1plus: internal compiler error: Segmentation fault [15:05:19] <twnqx> :( [15:05:21] <lu_zero> cc1plus [15:07:39] <lu_zero> which version of gcc? [15:08:57] <twnqx> 4.3.4 [15:10:47] <lu_zero> uh [15:10:53] <lu_zero> the memory is fine? [15:14:15] <Honoome> twnqx: I think I know that one [15:14:52] <Honoome> twnqx: http://bugs.gentoo.org/show_bug.cgi?id=311595 maybe [15:15:58] <twnqx> lu_zero: ECC memory with no NMIs, no MCE, and nothing else [15:16:39] <twnqx> Honoome: yes, excactly that one. [15:17:09] <twnqx> well, upgrading to 4.4.3 and checking again. [15:17:28] <Honoome> twnqx: 4.4.3 has the same trouble [15:21:22] <twnqx> :\ [15:21:43] <spaam> :| [15:21:47] <microchip_> :\ [16:30:58] <lu_zero> g++ ... soon with even more C++ magic dust [17:05:26] <BBB> Dark_Shikari: how do I do an or in a yasm macro? like ifidn %1, mmx || idn %1, 3dnow [17:10:35] <Yuvi> BBB: don't think you can do that, would this be for 64-bit vs. 128 bit registers? [17:22:47] <BBB> Yuvi: no, for reusing some code for 3dnow and mmx [17:22:51] <BBB> but not mmxext [17:23:13] <Yuvi> what's different with mmx2? [17:23:23] <BBB> pmaxusb is available [17:24:07] <BBB> btw my guess is that the filter_mbedge calculation of w1/2/3 can only be done in word, not byte, am I right? [17:24:35] <Yuvi> yes, the *27 etc needs word expansion [17:25:44] <Yuvi> what do you do without pmaxusb? [17:25:44] <Yuvi> could you make it a macro and %define PMAXUSB to the mmx/3dnow emulation, or is the mmx version much different? [17:31:19] <BBB> the mmx version is quite different [17:31:35] <BBB> (pipelining) [17:31:50] <BBB> I guess I could do without that... [17:32:10] <Yuvi> well, do you care about the pII? [17:32:16] <Yuvi> (much) [17:32:21] <Yuvi> apparently some opera users do [17:32:53] <kshishkov> give them IE3 [17:33:22] <Honoome> pll? [17:33:24] <CIA-99> libswscale: benoit * r31722 /trunk/libswscale/yuv2rgb.c: [17:33:24] <CIA-99> libswscale: Change the type of Y table to pointer to void in fill_table(). [17:33:24] <CIA-99> libswscale: This fixes warnings about wrong type being used, e.g.: [17:33:24] <CIA-99> libswscale: libswscale/yuv2rgb.c: In function ?ff_yuv2rgb_c_init_tables?: [17:33:24] <CIA-99> libswscale: libswscale/yuv2rgb.c:778: warning: passing argument 4 of ?fill_table? from incompatible pointer type [17:33:24] <CIA-99> libswscale: libswscale/yuv2rgb.c:598: note: expected ?uint8_t *? but argument is of type ?uint16_t *? [17:33:41] <BBB> libvpx has some bug reports about pre-SSE MMX users [17:33:43] <BBB> so they do exist [17:33:57] <Honoome> ah p2 /me was at a los [17:34:14] <BBB> and if we're gonna claim that we're faster than libvpx, we'd better be faster across a wide range of cpus [17:34:42] <DonDiego> focus on the relevant cpus first [17:34:43] <Honoome> I thought some embedded via cpus are non-sse mmx-capable? [17:34:48] <kshishkov> like Z80 [17:34:52] <DonDiego> and those that will be relevant in the future [17:35:01] <kshishkov> Honoome: wrong - ARM! [17:35:03] * DonDiego writes that on a non-relevant cpu [17:35:05] <BBB> DonDiego: working on it [17:35:08] <DonDiego> :) [17:35:14] <BBB> inner loopfilter is done [17:35:14] <BBB> w [17:35:17] <BBB> orking on mbedge now [17:35:26] <BBB> than after that do the chroma loopfilter [17:35:33] <BBB> which is pretty much a copy of the above 2 [17:35:35] <BBB> then we're done [17:35:37] <BBB> so almost there... [18:07:43] <Yuvi> _av500_: do you know about any problems with android's toolchain and movw/movt relocations from .rodata? [18:08:58] <av500> Yuvi: err [18:09:12] <av500> not that I know of [18:10:15] <Yuvi> hm, a user is having problems with it in x264 and claims it only goes away if he moves the data to .text, even with static libs... [18:11:02] <av500> sorry, no idea [18:11:37] <Dark_Shikari> BBB: ? [18:11:53] <BBB> hi [18:12:24] <BBB> Dark_Shikari: ifidn %1, mmx || idn %1, 3dnow [18:12:28] <BBB> can I do something like that? [18:12:32] <Dark_Shikari> why not just do [18:12:34] <Dark_Shikari> %if 3 ? [18:12:40] <Dark_Shikari> er, %if %d [18:12:42] <Dark_Shikari> %3 [18:12:45] <Dark_Shikari> and make it a function argument [18:12:47] <Dark_Shikari> er, macro argument [18:12:59] <BBB> ah, i.e. make arg 3 optional? [18:13:03] <Dark_Shikari> no, just make it 1 or 0 [18:13:05] <BBB> ah [18:13:06] <BBB> ok [18:13:19] <BBB> but so in short, yasm does not have an or directive for macros? [18:13:59] <Dark_Shikari> I don't know, I don't think so [18:14:19] <BBB> did you check the assembly itself? did it look ok? :-p [18:14:20] <Dark_Shikari> or, it kinda does, but it can't or between %ifidns [18:14:24] <Dark_Shikari> no [18:14:32] <Dark_Shikari> lemme do that. [18:14:34] <Yuvi> it has the standard || but only for numbers [18:16:11] <Dark_Shikari> BBB: nice transpose [18:16:14] <Dark_Shikari> for sse2 [18:16:57] <Dark_Shikari> suggestion: [18:17:02] <Dark_Shikari> %ifdef ARCH_X86_64 [18:17:06] <Dark_Shikari> mova m8, [pb_80] [18:17:14] <Dark_Shikari> %define myvar m8 [18:17:16] <Dark_Shikari> %else [18:17:19] <Dark_Shikari> %define myvar [pb_80] [18:17:20] <Dark_Shikari> %endif [18:17:24] <BBB> good point [18:17:31] <Dark_Shikari> Actually, that should be %ifdef m8 [18:17:35] <Dark_Shikari> since it shouldn't apply for mmx. [18:17:50] <Dark_Shikari> pb_80 chosen because it's used more than once. [18:18:34] <Dark_Shikari> SPLATB_REG -- make an ssse3 version of the function [18:18:40] <Dark_Shikari> where SPLATB does pshufb reg, ZERO [18:18:47] <Dark_Shikari> And no other change. [18:18:56] <Dark_Shikari> i.e. everything else is still sse2. [18:19:04] <BBB> hm... ok [18:19:38] <Dark_Shikari> where is WRITE_4x2D defined? [18:19:40] <Dark_Shikari> it isn't in your patch. [18:19:52] <BBB> it's already there, up just before the simple loopfilter [18:20:28] <Dark_Shikari> btw, feel free to optimize my WHT code since as Yuvi said, it'd be better to avoid pextrw on old cpus. [18:20:30] <BBB> it does movd [..], reg; punpckhdq reg, reg; movd[..], reg [18:20:50] <BBB> ok, I'll look at that (after loopfilter) [18:20:51] <Dark_Shikari> Where is your simple loopfilter? [18:20:53] <Dark_Shikari> it isn't in vp8dsp. [18:21:03] <BBB> should be [18:21:13] <Dark_Shikari> I just did an svn up [18:21:16] <BBB> %macro SIMPLE_LOOPFILTER 3 [18:21:21] <BBB> there [18:21:50] <Dark_Shikari> No it isn't there [18:21:54] <Dark_Shikari> I'm at r24213. [18:22:13] <Dark_Shikari> oh ignore me. fuck my two local versions. [18:22:24] <Dark_Shikari> ok, found. [18:22:55] <Dark_Shikari> would it be feasible to make macros for the load-transpose and such in this loopfilter, too? [18:23:14] <DonDiego> BBB: libavcodec/wmavoice.c:1906: warning: format ‘%lu’ expects type ‘long unsigned int’, but argument 5 has type ‘unsigned int’ [18:23:21] <DonDiego> BBB: x86_32 only? [18:23:25] <BBB> maybe... I think they are reused for mbedge, so I probably should [18:24:12] <BBB> DonDiego: my stupid compiler makes sizeof() long [18:24:24] <BBB> DonDiego: maybe %z? [18:24:59] <Dark_Shikari> BBB: two things to note: [18:25:12] <BBB> DonDiego: try making it %zu [18:25:16] <CIA-99> ffmpeg: alexc * r24214 /trunk/libavcodec/aacdec.c: [18:25:16] <CIA-99> ffmpeg: aacdec: Remove the warning about non-meaningful window transitions. [18:25:17] <CIA-99> ffmpeg: It created false positives on seeks and where the first frame is STOP or SHORT. [18:25:17] <CIA-99> ffmpeg: It failed to warn in illegal SHORT->LONG transitions. In general it created [18:25:17] <CIA-99> ffmpeg: much confusion and many junk bug reports from the users. [18:25:21] <Dark_Shikari> 1) as a general note, mmx functions will often never be used on x86_64 because sse2 is faster on all cpus, and all x86_64 cpus have sse2. [18:25:34] <Dark_Shikari> as you'll note, in x264, some mmx functions are just ifdeffed away on x86_64. [18:25:44] <Dark_Shikari> now, second fact which may be useful [18:26:01] <Dark_Shikari> 2) on x86_64, don't use the stack, just use more mm registers [18:26:02] <DonDiego> BBB: better ask one of the c wizards [18:26:04] <Dark_Shikari> for sse2 [18:26:08] <Dark_Shikari> (for backing stuff up) [18:26:13] * DonDiego looks sideways at mru [18:26:19] <Dark_Shikari> so %define the locations in the stack or whatever [18:26:32] <BBB> ah, and on arch_64, use the reg instead of the stack [18:26:41] <BBB> that's a good idea [18:26:58] <Dark_Shikari> note a) this only works for sse2 [18:27:07] <Dark_Shikari> b) if you wanted you could just not compile the mmx code on x86_64 [18:27:11] <Dark_Shikari> if that made things any easier. [18:27:18] * Dark_Shikari reads the actual code [18:27:21] <BBB> ok, I'll look at that [18:27:27] <Dark_Shikari> "flim"... is this a word? [18:27:29] <Dark_Shikari> or a byte? [18:27:36] <Dark_Shikari> oh, I was looking at the simple one [18:27:51] <Dark_Shikari> can you use SPLATB on lines 1215-1226 in the simple one? [18:27:54] <Dark_Shikari> "splat register with flim" [18:28:03] <Dark_Shikari> oh, you already did. [18:28:28] <BBB> I'd probably apply that separately, but yes [18:31:15] <Dark_Shikari> besides that, can't see anything else. your patch is officially cool. [18:32:00] <BBB> \o/ [18:32:07] <Dark_Shikari> hah, found a suboptimality [18:32:10] <Dark_Shikari> + mova m7, [rsp+mmsize*3] [18:32:11] <Dark_Shikari> + pandn m7, m6 [18:32:15] <Dark_Shikari> m6 is then never used again. [18:32:27] <Dark_Shikari> why not swap the two and do pandn m6, [rsp+mmsize*3] ? [18:32:37] <BBB> that's not the same [18:32:40] <BBB> it's not pand, it's pandn [18:32:54] <Dark_Shikari> pandn does.... pand with not SOMETHING? [18:33:06] <BBB> pandn x, y does ~x & y [18:33:16] <_skal_> so tricky [18:33:17] <Dark_Shikari> ok [18:33:33] <BBB> ~x & y != x & ~y [18:33:46] <Dark_Shikari> lines 380-382 of your patch have a lot of linear dependency. is there no way to avoid that¿ [18:33:58] <Dark_Shikari> how about this, would this be the same? [18:34:01] <Dark_Shikari> paddsb m7, m1 [18:34:04] <Dark_Shikari> paddsb m1, m1 [18:34:09] <Dark_Shikari> paddsb m7, m1 [18:34:25] <_skal_> nope [18:34:31] <Dark_Shikari> why not? [18:34:35] <_skal_> saturation isn't the same [18:34:37] <Dark_Shikari> why not? [18:34:43] <Dark_Shikari> I chose the order specifically so that it was [18:34:51] <Dark_Shikari> if m1 saturates, m7 will saturate [18:35:18] <Dark_Shikari> I think. [18:35:22] <BBB> if m7 is -128, adding 127 [18:35:29] <BBB> add 127 -> -1, add 127 -> 126 [18:35:31] <_skal_> think m7=-1, m1 = 64 [18:35:34] <BBB> adding 3x 127 -> 127 [18:35:50] <CIA-99> ffmpeg: diego * r24215 /trunk/Doxyfile: Turn off the useless default chatter that doxygen prints to the console. [18:35:56] <Dark_Shikari> how about abusing the fact that is4tap is only 0 and 1 then? [18:36:01] <Dark_Shikari> oh [18:36:01] <Dark_Shikari> I see [18:36:07] <Dark_Shikari> is4tap is p1-q1 [18:36:42] <Dark_Shikari> I fail to see how the current one even saturates correctly. [18:36:51] <Dark_Shikari> suppose p1-q1 is B and q0 - p0 is A [18:36:54] <Dark_Shikari> i.e. 3*A + B [18:37:05] <Dark_Shikari> we are doing [18:37:07] <Dark_Shikari> B += A [18:37:09] <Dark_Shikari> B += A [18:37:11] <Dark_Shikari> B += A [18:37:12] <CIA-99> ffmpeg: diego * r24216 /trunk/Doxyfile: [18:37:12] <CIA-99> ffmpeg: Do not generate LaTeX Doxygen documentation by default. [18:37:12] <CIA-99> ffmpeg: Our general use case just requires HTML documentation, so skip the extra step. [18:37:41] <Dark_Shikari> hmm. maybe it works. [18:37:46] <BBB> B is saturated by itself in the spec also [18:37:54] <BBB> so it's clip(3*a+clip(b)) [18:38:07] <Dark_Shikari> that's silly. [18:38:27] <BBB> yeah, but convenient [18:38:40] <BBB> you can see how the spec was built around simd, rather than the other way around ;) [18:38:46] <Dark_Shikari> not convenient [18:38:53] <BBB> the mbedge is worse [18:38:53] <Dark_Shikari> convenient would be if the saturation was in the middle. [18:39:09] <Dark_Shikari> thus not requiring a 5-cycle-long dependency chain [18:39:28] <Dark_Shikari> make that 8 cycles [18:39:59] <BBB> true [18:40:52] <_skal_> you could intersperse the mova m5, [pb_f8] in middle i guess [18:41:09] <Dark_Shikari> not really useful [18:41:12] <Dark_Shikari> the cpu already does speculative loads [18:41:58] <Dark_Shikari> _skal_: oh yeah, one thing I was going to bug you about since you're the youtube google guy [18:42:02] <Dark_Shikari> http://www.youtube.com/watch?v=4vlVudQSj90 [18:42:08] <Dark_Shikari> a guy uploaded a 1080p screen capture and youtube somehow totally broke the scaling [18:42:18] <Dark_Shikari> it seems a bit odd, so I figured I might as well poke you about it. [18:42:54] <Dark_Shikari> BBB: why psrlq for lines 408-409? [18:42:59] <Dark_Shikari> for sse, shouldn't it be psrldq? [18:43:00] <Dark_Shikari> or what [18:43:49] <_skal_> "This video has been removed by the user. " [18:43:54] <_skal_> damned, *so* bad? :) [18:44:01] <Dark_Shikari> _skal_: blegh, he removed it? [18:44:04] <Dark_Shikari> does youtube keep backups? =p [18:44:21] <Yuvi> google delete data? [18:44:23] <Dark_Shikari> the scaling looked like someone had done a point resize down to ~720p [18:44:23] <Yuvi> never! [18:44:26] <Dark_Shikari> and then point resized back up [18:44:30] <Dark_Shikari> But the source video was fine [18:46:03] <Dark_Shikari> BBB: fyi, psrldq is slower than psrlq on some chips, so don't use it if you can avoid it, I'd just like to know why you can use psrlq [18:48:47] <_skal_> btw i played with the idea of keeping pb_80 as sole constant, in a reg this week-end [18:48:55] <_skal_> http://pastebin.com/MZ4NAcBn [18:49:00] <_skal_> not sure how it helps, but hey [18:49:10] <_skal_> in case. [18:50:55] <Dark_Shikari> 32-bit isn't that important [18:52:57] <CIA-99> ffmpeg: alexc * r24217 /trunk/ (9 files in 3 dirs): [18:52:57] <CIA-99> ffmpeg: Split the ADTS header decoder off of the ADTS parser. [18:52:57] <CIA-99> ffmpeg: The AAC decoder and ADTS-to-ASC BSF both require the header decoder [18:52:57] <CIA-99> ffmpeg: but not full parsing capabilities. [18:54:09] <Dark_Shikari> btw, BBB, I guess it's obvious, but just to put it on the table, the mmx chroma one shouldn't do anything special (since, well, duh) [18:55:06] <Dark_Shikari> should just loop over the channels [18:55:23] <mru> DonDiego: you looked my way... [18:57:23] * kshishkov would like glance detector working over hundreds of kilometers too [19:05:55] <BBB> Dark_Shikari: I can use either [19:06:17] <BBB> Dark_Shikari: I cleared the least-significant bit, so psrlw x, 1, psrld, psrlq, psrldq all do the same thing [19:06:24] <Dark_Shikari> ok [19:06:30] <BBB> psrlq is just random [19:06:34] <BBB> I could've chosen psrlw also [19:06:42] <BBB> not sure why I chose psrlq [19:08:03] <BBB> and for the chroma one, I'll use the same code, but I need to change the C prototype first [19:14:53] <DonDiego> mru: i thought you might be able to suggest the right printf length specifier for a 'sizeof(float)' operation [19:15:31] <DonDiego> r [19:16:59] <mru> z of course [19:17:12] <mru> it is specifically for size_t arguments [19:17:22] <Vitor1001> DonDiego: cast it to an int, it will fit ;) [19:17:27] <mru> and type type of a sizeof expression is size_t [19:18:42] <BBB> DonDiego: change to %zu is fine with me, feel free to apply [19:37:27] <CIA-99> ffmpeg: diego * r24218 /trunk/libavcodec/wmavoice.c: [19:37:27] <CIA-99> ffmpeg: Use correct length modifier for size comparison in printf expression, fixes: [19:37:27] <CIA-99> ffmpeg: libavcodec/wmavoice.c:1906: warning: format `%lu' expects type `long unsigned int', but argument 5 has type `unsigned int' [19:37:27] <CIA-99> ffmpeg: approved by Ronald and Mans on IRC [19:46:23] <Honoome> mru: won't that depend on whether you enable -std=mingwbrokenstd? :P [19:46:57] <mru> :-) [19:47:28] <mru> the z modifier is c99 though [19:48:06] <Honoome> I _really_ wonder how that guy wrote the autotools book o_O [19:48:22] <mru> explains a thing or two about autotools [19:48:31] <mru> or about the guy [19:48:33] <mru> not sure which [19:50:35] * Honoome sighs, as he's not a native speaker [19:55:08] <CIA-99> ffmpeg: mru * r24219 /trunk/libavcodec/avfft.c: avfft: make init functions return NULL on failure as intended [20:17:56] <kierank> is there any way to get gdb to break when a register equals a certain value [20:18:10] <mru> not efficiently [20:18:20] <mru> since the cpu doesn't have a trap for that [20:18:38] <kierank> what's the inefficient way? [20:18:46] <mru> single-step and test [20:18:54] <mru> which can be automated [20:19:01] <mru> but is a few million times slower [20:25:12] <CIA-99> ffmpeg: mru * r24220 /trunk/tests/ (4 files in 2 dirs): [20:25:13] <CIA-99> ffmpeg: fate: add vp8 bilinear tests [20:25:13] <CIA-99> ffmpeg: Mike added these some time ago, and I forgot to update here. [20:27:53] <hyc> the gdb watch command will do it for you. and yes, millions of times slower. [20:30:09] <jb_vacation> Compn: I am away these days, sorry... [20:30:46] <Honoome> jb_vacation: not in venice again, I suppose? [20:36:24] <jb_vacation> Honoome: south of France [20:36:31] <Honoome> kk :) [20:37:02] <mru> africa? [20:37:06] <jb_vacation> I wouldn't do the same mistake twice ;) [20:37:19] <mru> africa is south of france [20:38:59] <Honoome> :P [21:03:43] <CIA-99> ffmpeg: vitor * r24221 /trunk/tests/fate2.mak: Add TrueSpeech regtest [21:18:00] <CIA-99> ffmpeg: mru * r24222 /trunk/configure: [21:18:00] <CIA-99> ffmpeg: configure: match regtest ref files more strictly [21:18:00] <CIA-99> ffmpeg: Only names consisting of letters, numbers, hyphens, and underscores [21:18:00] <CIA-99> ffmpeg: are allowed. [21:23:57] <CIA-99> ffmpeg: cehoyos * r24223 /trunk/libavcodec/ (libvpxenc.c options.c): [21:23:57] <CIA-99> ffmpeg: Do not map video quantizer scale (from 1-51 to 0-63) for libvpx anymore. [21:23:57] <CIA-99> ffmpeg: Patch by James Zern, jzern google [21:36:37] <CIA-99> ffmpeg: alexc * r24224 /trunk/libavcodec/aacdec.c: aacdec: Use a LUT to generate CCE scale. [21:36:38] <CIA-99> ffmpeg: alexc * r24225 /trunk/libavcodec/aacdec.c: aacdec: Eliminate the use of doubles in decode_cce(). [21:37:12] <CIA-99> ffmpeg: alexc * r24226 /trunk/libavcodec/aacdec.c: aacdec: Eliminate the use of doubles in the MAIN predictor. [22:07:18] <kierank> will audio decoders start using avframe eventually? [22:21:05] <BBB> yes [22:32:44] <bcoudurier> hi g uys [22:39:43] <Honoome> what if there were kde devs in here? [22:40:10] <kierank> mru would banish them because they'd talk about c++ a lot [22:40:11] <_skal_> 'lut Baptiste [22:40:16] <Honoome> kierank: rotfl [22:40:30] <kierank> the one i met a few years ago did [22:41:08] <Honoome> kierank: but me and mru always talk about C++... laughing at its users [22:41:14] <hyc> C >> C++ [22:42:43] <kierank> hehe for some random reason I always thought librtmp was c++ [22:48:41] <bcoudurier> hey _skal_ [22:48:52] <bcoudurier> content de te voir ici :) [22:55:40] <BBB> oh boy, they talk french [22:55:48] <BBB> mais non! [22:58:18] <astrange> where's the master logo image? [23:15:22] <peloverde> astrange: svn://svn.ffmpeg.org/ffmpeg.org trunk/src/ffmpeg-logo.svg [23:29:16] <Compn> _skal_ : btw did google/youtube ever give up their non-working-in-ffmpeg samples ? [23:29:50] <Compn> _skal_ : i've mailed one google guy but he cant get thru to youtube or something [23:30:14] <Compn> _skal_ : if you know any contacts or are still working there could you get official response ? :) [23:31:34] <kierank> they probably have hundreds of thousands of non-working samples [23:33:08] <Compn> goody [23:33:22] <Dark_Shikari> which they have repeatedly refused to give out [23:33:30] <Dark_Shikari> because it would require them to publicly admit they use ffmpeg. [23:33:58] <Compn> _skal_ : also unnofficially, get one of them ffmpeg devs to submit a bunch of patches anonymously [23:34:01] <Compn> :) [23:34:04] <Compn> just to piss Dark_Shikari off [23:34:09] <Compn> i'm sure they got x264 patches too [23:34:49] <kierank> iirc their x264 has a poc which increments in a weird way [23:35:22] <kierank> can't remember what it does though [23:36:29] <Compn> Dark_Shikari : so mr knows everything bout youtube/google, hows the webm patent pool going so far ? [23:37:19] <Dark_Shikari> they won't tell anyone [23:37:27] <Dark_Shikari> ask google [23:37:29] <Dark_Shikari> maybe they'll tell you [23:37:31] <bcoudurier> lol [23:37:38] <kierank> ask mpeg-la [23:37:48] <Compn> yeah i meant 3rd party seeking money like mpeg-la [23:39:10] * Compn thinks up other things to troll Dark_Shikari with [23:54:00] <_skal_> That's a lot of questions, and it's not like Dark needs answers to quote Google in his announcements [23:54:05] <_skal_> so.

1 0

IRC log for 2010-07-11
by irc＠mansr.com 12 Jul '10

12 Jul '10

[00:01:55] <Kovensky> hm [00:02:00] <Kovensky> seems that I missed when the header actually got fixed [00:02:16] <mru> there could have been a temporary glitch [00:02:17] <Kovensky> libavutil/pixdesc.h had a few inline functions that used intreadwrite stuff [00:02:45] <mru> I remember pixdesc.h using endian definitions from config.h [00:02:49] <mru> we fixed that [00:03:02] <Kovensky> (the deprecated func is avcodec_get_pix_fmt, the new one was av_get_pix_fmt but when I tried fixing the warning it would fail) [00:05:45] <saintd3v> peloverde: what are scalefactor bands vs. scalefactor window bands? [00:08:21] <CIA-99> ffmpeg: vitor * r24181 /trunk/tests/ (ref/fate/yop fate2.mak): Psygnosis YOP demuxer and decoder test [02:54:01] <mru> lol @ michael's response to german comments in patch [02:57:23] <Dark_Shikari> which thread? [04:11:18] <_av500_> A64 encoder [04:12:31] <Dark_Shikari> lol [07:55:03] <_av500_> woot: avcodec_decode_audio4 [07:55:45] <_av500_> i wonder if it is going to overtake 0.x releases [08:00:25] <kshishkov> FFmpeg 1.0 will use avcodec_{de,en}code_{audio,video}42 [08:01:15] <_av500_> that will output samples in XML? [08:02:01] <kshishkov> of course - libavcodec replaced with libavxslt [08:04:12] <_av500_> kshishkov: its sunday, go to the park, ride a steam train! [08:04:18] <pross-au> 42 lol [08:04:40] <pross-au> kshishkov: we are gonna need an xml parser sooon [08:04:48] <_av500_> pross-au: you could have smuggled 42 in as a typo [08:05:06] <kshishkov> _av500_: I'm not from sunny Serbia, it's too hot for me to go outside [08:05:21] <_av500_> pross-au: why not use any of the 375 existing xml parser libs :) [08:05:45] <kshishkov> idiotic question - we don't like using external libs [08:06:13] <pross-au> because ours will be better [08:06:53] <_av500_> kshishkov: iKnow. btw, at some time I found out that our own SW here used 3 different xml parser libs... [08:07:12] <pross-au> same problem here _av500_ [08:07:17] <Yuvi> at the same time? [08:07:32] <_av500_> Yuvi: for different sub modules [08:07:49] <_av500_> each guy that needed xml brought in another lib it seems [08:07:52] <xxthink> http://pastebin.org/389226 [08:07:58] <xxthink> this is the transcoding log [08:08:02] <pross-au> its a common design pattern _av500_ [08:08:05] <xxthink> I transcodea ts to mp4 [08:08:21] <xxthink> But the video and audio can't be synchronized correctly [08:08:22] <pross-au> "i prefer lib foo so im gonna use it" [08:08:43] <_av500_> pross-au: its more like "I will not read any of the existing sourse code" [08:09:06] <pross-au> actually thats my biggest complain about software engineers. [08:09:27] <xxthink> The problem is I can't make sure the audio and video start time because there aren't PTS infor in the first packet of audio and video [08:09:28] * _av500_ thinks about patching his libc to output NO_PTS instead of -9223372036854775808 [08:10:38] <xxthink> _av500_: yes. But if there isn't PTS info in the first packet [08:10:51] <xxthink> How to decide its PTS ? [08:11:04] <_av500_> xxthink: no idea, I would consider such a file broken [08:11:47] * _av500_ would drop all stuff until PTS && key_frame [08:11:51] <xxthink> _av500_: But now ffmpeg considers its PTS is 0 [08:12:06] <xxthink> I also think these packets should be dropped [08:12:13] <_av500_> xxthink: well, that is about the best guess it can make, no? [08:12:39] <xxthink> _av500_: but it can't make sure this method is correct [08:12:52] <xxthink> sometimes it will cause problems [08:13:04] <_av500_> i dont doubt that [08:13:11] <xxthink> why? [08:13:28] <xxthink> you agree with the current method? [08:13:49] <_av500_> i have not looked much into current method [08:13:59] <xxthink> ok [08:14:17] <_av500_> xxthink: where is this file from? [08:14:35] <xxthink> I have a TS file, [08:14:41] <xxthink> But the audio is in Chinese [08:14:51] <xxthink> So I can find it is not correct [08:15:23] <xxthink> this TS file is record from the Cable TV [08:16:23] <xxthink> But this TS file can be displayed correctly by mplayer [08:16:46] <xxthink> so I don't know how mplayer treat this packets? [08:17:49] <_av500_> xxthink: playing is much easier than transcoding [08:18:03] <_av500_> you can send no pts frame to the decoder, but not to the muxer [08:18:35] <xxthink> but the player should decide its PTS correctly [08:18:47] <_av500_> its only a few frames [08:18:49] <_av500_> i guess [08:19:03] <_av500_> so the player can just output them without timing [08:19:03] <_av500_> thats what i do [08:19:21] <xxthink> i c [08:20:27] <jai> ffmpeg needs an xml parser? [08:20:36] <xxthink> so one method for transcoding is discard all these frames [08:20:43] <_av500_> jai: for enterprise customers [08:20:50] <jai> xspf? some tracker format? [08:20:57] <jai> _av500_: of course :) [08:24:50] * kshishkov waits for superdump to create profiles for FFmpeg in XML [09:21:38] <mru> mornings [09:21:52] * elenril has only one morning here [09:22:02] * mru gives elenril some of his spares [09:22:20] <elenril> w00t, thanks [09:22:40] <mru> when you work from home, you easily accumulate lots of unused mornings [09:27:05] <kshishkov> goda morgnar [09:27:21] <kshishkov> you'll need them soon [09:27:58] <mru> nah, german clocks show an hour more, so it's not as early there [09:47:52] <kshishkov> actually it's Russian clocks that show an hour more than it's really is [09:48:25] <mru> no, they're even more ahead [09:49:00] <mru> everybody knows the best time is in greenwich [09:49:49] <kshishkov> yep, but compared to neighbouring countries they have skewed clocks [09:49:51] <Honoome> species at this time of the year [10:15:26] <CIA-99> ffmpeg: pross * r24182 /trunk/libavcodec/avcodec.h: Fix trivial punctuation error [10:15:26] <CIA-99> ffmpeg: skal * r24183 /trunk/libavcodec/libvorbis.c: use avccontext->frame_size where appropriate [10:15:39] <CIA-99> ffmpeg: skal * r24184 /trunk/libavcodec/libvorbis.c: add some buffer checks [10:15:39] <CIA-99> ffmpeg: reimar * r24185 /trunk/ (4 files in 3 dirs): Add avsubtitle_free function. [10:15:39] <CIA-99> ffmpeg: reimar * r24186 /trunk/libavcodec/dvbsubdec.c: Remove useless casts and memset. [10:15:40] <CIA-99> ffmpeg: reimar * r24187 /trunk/libavcodec/pgssubdec.c: Set pix_fmt to the correct value for the format the PGS decoder actually uses. [10:15:50] <CIA-99> ffmpeg: reimar * r24188 /trunk/libavcodec/utils.c: 100l, change avsubtitle_free to the actually tested and working version. [11:29:37] <CIA-99> ffmpeg: mstorsjo * r24189 /trunk/libavformat/ (Makefile mp3.c): [11:29:37] <CIA-99> ffmpeg: Fix ID3v1 tags in mp3 files [11:29:37] <CIA-99> ffmpeg: Patch by James Darnley, james dot darnley at gmail [11:50:36] <CIA-99> ffmpeg: stefano * r24190 /trunk/ (libavutil/avutil.h doc/APIchanges): [11:50:36] <CIA-99> ffmpeg: Update lavu minor and add APIchanges entry after r24174 (add bswap.h [11:50:36] <CIA-99> ffmpeg: and intreadwrite.h API public interface). [11:55:37] <CIA-99> ffmpeg: lu_zero * r24191 /trunk/libavformat/rtpdec_h264.c: [11:55:37] <CIA-99> ffmpeg: Handle av_base64_decode return value [11:55:37] <CIA-99> ffmpeg: garbled sdp would cause crash otherwise. [11:57:47] <CIA-99> ffmpeg: stefano * r24192 /trunk/doc/ffmpeg-doc.texi: [11:57:47] <CIA-99> ffmpeg: Fix crop filter syntax shown for the -crop* options in the ffmpeg man [11:57:47] <CIA-99> ffmpeg: page. [11:57:47] <CIA-99> ffmpeg: Patch by Stefan de Konink /$name/@/konink/de. [12:03:55] <lu_zero> mru: poing [12:04:03] <mru> pong [12:04:20] <lu_zero> vp8 is broken on big-endian or just ppc? [12:04:32] <mru> only ppc with gcc 4.0.4 [12:04:39] <lu_zero> -_- [12:04:42] <lu_zero> it's ancient [12:04:46] <mru> yeah [12:04:57] <mru> shall we officially not support it? [12:05:26] <kshishkov> depends on the reason [12:05:35] <mru> it miscompiles stuff [12:05:43] <kshishkov> so does every compiler [12:05:54] <lu_zero> I'd ask for a 4.1 [12:05:59] <mru> it miscompiles ffmpeg where most other versions work [12:06:11] <kshishkov> and it's 4.0 ... ok then [12:13:51] <lu_zero> fun [12:14:16] <lu_zero> asking for an h264 elementary stream using -vcodec copy generates garbage... [12:14:27] <mru> from mp4? [12:14:35] <lu_zero> do we have already a topic about it? [12:14:46] <mru> you need -vbsf h264_mp4toannexb [12:14:46] <lu_zero> mru: yup [12:15:35] <lu_zero> I wonder if it's feasible adding a warning [12:18:09] <_av500_> "here be dragons" [12:25:58] <lu_zero> hic sunt leones you meant [12:45:22] <CIA-99> ffmpeg: vitor * r24193 /trunk/tests/ (ref/fate/pictor fate2.mak): Add Pictor/PC Paint PIC regtest [12:48:15] <peloverde> saintdev: scalefactor window bands = scalefactor bands within a window, scalefactor band [12:48:15] <peloverde> = scalefactor band within a window group [12:48:26] <peloverde> For long windows the two are identical [12:48:49] <peloverde> num_swb is the top band, max_sfb is the top transmitted band (the rest are implicitly zero) [13:18:47] * mru @ airport [13:19:52] <mru> android wifi AP working fine :-) [13:21:15] <wbs> ah, the new stuff in 2.2? [13:21:29] <mru> yeah [13:22:04] <wbs> good thing that that is available now. had to set up the inofficial tethering using openvpn and whatnot once, when the only connection I had was on the phone [13:22:41] <wbs> so browsing and downloading and RTFMing on the phone, moving binaries to the computer and trying to set it up there [13:23:36] <mru> heh [14:06:27] <CIA-99> ffmpeg: vitor * r24194 /trunk/tests/fate2.mak: DTS Coherent Acoustics regtest [14:14:13] <CIA-99> ffmpeg: vitor * r24195 /trunk/tests/fate2.mak: NellyMoser regtest [14:28:56] * mru out [14:30:25] <kshishkov> sounds like asm [14:44:03] <zorgy7> hi guys, does anyone know what the values: ff_mjpeg_bits_dc_luminance, ff_mjpeg_bits_dc_chrominance and ffm_mjpeg_val_dc are? [14:44:22] <zorgy7> they are located in mjpeg.c [14:45:33] <CIA-99> ffmpeg: victor * r24196 /trunk/libavfilter/ (avfilter.c vf_scale.c defaults.c): Use avfilter_copy_picref_props() along lavfi. [14:47:53] <kshishkov> zorgy7: should be obvious if you know at least a little bit about JPEG coding [14:48:28] <zorgy7> kshishkov: yea :( i have no idea of JPEG coding [14:49:20] <zorgy7> so i can find out more if i look into the encoding/decoding algorithm for jpeg? [14:50:41] <kshishkov> of course [14:51:07] <CIA-99> ffmpeg: kostya * r24197 /trunk/libavcodec/truespeech.c: [14:51:07] <CIA-99> ffmpeg: Do not try to decode less than one frame of data in TrueSpeech decoder. [14:51:08] <CIA-99> ffmpeg: This should solve issue 2085. [14:51:20] <zorgy7> okay [14:57:22] <CIA-99> ffmpeg: victor * r24198 /trunk/libavformat/avformat.h: Clarify the avoidance of usage of these AVStream fields. [15:20:01] <Compn> doh where is j-b ? [15:30:33] <kshishkov> in France, obviously [15:31:24] <janneg> Compn: on vacation [15:31:33] <Compn> ah [15:31:47] <Compn> was going to ask him if vlc's ftp had any dvb/mpegts subtitle samples [15:32:38] <janneg> Compn: are you looking for something special [15:33:41] * janneg is pretty sure that samples has some. if not I can upload some [15:34:32] <Compn> reimar wanted more dvb subs and some special dvb vbi teletext too, and any other mpeg subtitles that werent working 100% in mplayer ... [15:35:11] <Compn> see thread 'mpeg-ts (pgs) subtitle support' on dev-eng [15:35:16] <janneg> dvb vbi teletext is on my todo list [15:35:54] <Compn> well tell reimar that so you guys dont duplicate work :) [15:37:17] <Compn> janneg : btw do you have an account at videolans' trac ? the sample url is 404 here and itd be nice if uploader fixed it >> http://trac.videolan.org/vlc/ticket/3461 [15:39:17] <janneg> Compn: just looking through my samples for dvb vbi teletext [15:40:19] <janneg> and I have no account for videolan's trac, asking in #vlc would probably help [15:40:42] <Compn> so it goes :) [15:43:20] <BBB> Dark_Shikari: ping [16:39:26] <lu_zero> the gsoc webapp is still broken? [16:57:12] <CIA-99> ffmpeg: jbr * r24199 /trunk/ (8 files in 2 dirs): [16:57:12] <CIA-99> ffmpeg: Add AVCodecContext.lpc_type and Add AVCodecContext.lpc_passes fields. [16:57:12] <CIA-99> ffmpeg: Add AVLPCType enum. [16:57:12] <CIA-99> ffmpeg: Deprecate AVCodecContext.use_lpc. [16:58:12] <CIA-99> ffmpeg: jbr * r24200 /trunk/doc/APIchanges: Fill-in revision number for addition of lpc_type and lpc_passes. [17:14:25] <nfl> how do I force more data to be passed to decode_frame() as compared to that being passed currently for a particular frame? [17:14:50] <nfl> I need 24B, but get only 16B and it isn't EOF yet [17:22:05] <kshishkov> something is wrong with your approach then [17:22:08] <kshishkov> what codec? [17:22:18] <nfl> g723.1 [17:22:38] <kshishkov> why do you need more data? [17:23:04] <nfl> for the particular frame type, I need 24 bytes [17:23:36] <kshishkov> sounds like your parser should handle that [17:24:02] <kshishkov> I'm pretty sure there's no way to make decode_frame() ask for more bytes [17:24:12] <nfl> I was asked to set CODEC_CAP_SUBFRAMES instead of using a parser :) [17:25:09] <kshishkov> still, if some frames are of bigger size, request it - you can signal that you have not consumed all data [17:25:23] <nfl> that is what I do currently [17:25:40] <nfl> return the no. of bytes consumed for the current frame [17:26:06] <nfl> so what exactly does CODEC_CAP_SUBFRAMES indicate? [17:27:19] <kshishkov> that your actual frame data contains several frames [17:27:37] <kshishkov> and codec may use it partially to output several buffers of data [17:28:25] <nfl> so I take it that a parser is the only way out? [17:28:56] <kshishkov> nope [17:29:23] <nfl> what else can I do then? [17:30:35] <kshishkov> ask on ML with all statements clear - why you need more data sometimes and why you can't get it with current approach [17:32:00] <nfl> ok [17:32:11] <kshishkov> that should be better than asking here [17:43:20] <wbs> the decoder can simply output nothing (without returning an error) and buffer the data internally, too [17:43:36] <wbs> the mpeg audio decoder used to do that up until a few years ago [17:44:25] <wbs> the api-example.c in lavc relied upon that, see the changes in the log of that file when I fixed it for the new behaviour of the decoder a while back [17:46:45] <nfl> ok [17:47:35] <CIA-99> ffmpeg: cehoyos * r24201 /trunk/libavcodec/libvpxenc.c: [17:47:35] <CIA-99> ffmpeg: Set libvpx encoding profile to libavcodec's profile. [17:47:35] <CIA-99> ffmpeg: Patch by James Zern, jzern google [17:52:37] <wbs> nfl: where are you receiving the data from? usually, you wouldn't feed incomplete frames to a decoder (but you could want to feed more than one frame) [17:53:04] <nfl> wbs: from a file [17:53:18] <kshishkov> wbs: that's why I'd like to see it in a mail - easier to understand [17:58:11] <nfl> wbs: so this is what I will do: store the 16B in a buffer, return 16, in the next call, append 8B to the buffer and return 8. sounds ok? [17:58:41] <nfl> *sound [17:59:03] <CIA-99> ffmpeg: jbr * r24202 /trunk/doc/APIchanges: APIchanges: fix a grammar mistake [18:03:20] <lu_zero> uhm? [18:03:49] * lu_zero reads the email [18:04:50] <lu_zero> wbs: I'm planting more verbose error reporting in ffrtsp and ffrtp, once I'm done I'll need your help picking up what's missing [18:05:21] * lu_zero is actively feeding broken streams while messing with feng [18:25:08] <kierank> what's the easiest way of getting samples which are doubles into something i can listen to? [18:25:25] <kierank> to verify that the decoding works [18:26:56] <wbs> lu_zero: oh, nice :-) [18:31:31] <wbs> nfl: yes. that's one way of solving it. do you blindly read chunks of data from the file that you pass to the decoder? [18:32:15] <nfl> blindly? [18:32:57] <wbs> as in, you don't know how large the frames are at that point, so you may cut the frames and feed incomplete frames to the decoder? [18:33:31] <nfl> yes [18:33:32] <wbs> normally, the demuxer would read from the file using at least some kind of framing, returning data in packets containing one or more full frames [18:34:12] <wbs> if you don't have such a demuxer, you can either use a parser, make the decoder handle the case as we discussed earlier, or [18:34:45] <wbs> refill the buffer when the number of bytes left is getting small, as we do in api-example.c right now [18:35:04] <wbs> the last case doesn't fit into ffmpeg.c though [18:35:04] <nfl> I use raw.c to read in the file contents [18:36:12] <wbs> kshishkov: sorry for taking the discussion here instead of on the ML, i'm in a sotuation where irc is easier than mail atm [18:36:31] <wbs> but I guess I can recap the situation in a ML reply in a moment [18:53:24] <wbs> kshishkov, nfl: summarized as a reply on -soc [18:59:28] <nfl> wbs: thanks [19:13:19] <lu_zero> uhmmm [19:13:28] <lu_zero> sdp_parse looks overoptimistic... [22:18:10] <CIA-99> ffmpeg: ramiro * r24203 /trunk/configure: [22:18:11] <CIA-99> ffmpeg: mingw32: properly check if vfw capture is supported by the system headers [22:18:11] <CIA-99> ffmpeg: Remove check for an specific w32api version, checking instead if vfw.h [22:18:11] <CIA-99> ffmpeg: supports vfw capture. The defines in w32api 3.12 were wrong, so this must be [22:18:11] <CIA-99> ffmpeg: accounted for in the check. [22:32:34] <CIA-99> ffmpeg: ramiro * r24204 /trunk/configure: mingw32: merge checks for mingw-w64 and mingw32-runtime >= 3.15 into one [22:53:39] <CIA-99> ffmpeg: conrad * r24205 /trunk/libavcodec/vc1dec.c: vc1: ff_draw_horiz_band needs a one row delay when the loop filter is active [22:53:41] <CIA-99> ffmpeg: conrad * r24206 /trunk/libavcodec/vc1dec.c: [22:53:41] <CIA-99> ffmpeg: vc1: Fix ordering of loop filter for I/B frames [22:53:41] <CIA-99> ffmpeg: All horizontal edges must be filtered before all vertical edges [22:53:41] <CIA-99> ffmpeg: conrad * r24207 /trunk/libavcodec/x86/ (4 files): Make ff_pw_4 128 bits [22:53:41] <CIA-99> ffmpeg: conrad * r24208 /trunk/libavcodec/x86/ (Makefile vc1dsp_mmx.c x86util.asm vc1dsp_yasm.asm): MMX/SSE VC1 loop filter

1 0

IRC log for 2010-07-10
by irc＠mansr.com 11 Jul '10

11 Jul '10

[00:04:58] <peloverde> hmm... I wonder if I'm screwing up the conversion from 24-bit pcm [00:05:27] <mru> are you using the iso ref files? [00:05:43] <peloverde> yes [00:05:52] <mru> I couldn't make sense of them either [00:06:26] <mru> it looks like ffaac outputs a swath of near-zero samples at the start that's not in the ref files [00:07:03] <Dark_Shikari> windowing issue? [00:07:11] <Dark_Shikari> mdct priming? [00:07:20] <peloverde> The reference decoder seems to delay the files 2048 samples more than the reference rendering [00:07:48] <peloverde> The SBR conformance tool requires those samples [00:08:31] <Dark_Shikari> is that the mdct size or something? [00:09:03] <peloverde> It's twice the mdct size [00:11:48] <peloverde> I wonder what rounding policy sox uses when I convert them [00:41:45] <CIA-99> ffmpeg: mru * r24153 /trunk/libavutil/pixdesc.c: pixdesc: add missing includes [00:41:46] <CIA-99> ffmpeg: mru * r24154 /trunk/libavutil/lfg.c: lfg: add missing includes [00:41:46] <CIA-99> ffmpeg: mru * r24155 /trunk/libavutil/intreadwrite.h: intreadwrite: common.h is not needed, attributes.h is sufficient [00:46:59] <peloverde> On one of these files the information at the begining is on-zero, wonder-fucking-ful [00:47:18] <peloverde> Why do the reference renderings not match the reference decoder delay wise? [01:05:27] <Compn> wow [01:05:34] * Compn likes turbo option [01:05:47] <Compn> 3fps > 24fps for first pass [01:06:04] <Dark_Shikari> "turbo option"? [01:06:15] <Compn> mencoder -lavcopts turbo [01:06:20] * Compn forgets what it does [01:06:34] <Dark_Shikari> for xvid or something? [01:06:41] <Compn> for ... lavc [01:06:51] <Dark_Shikari> lavc what [01:06:58] <Compn> lavc encoding [01:07:04] <Dark_Shikari> lavc is a library [01:07:05] <Dark_Shikari> it has many encoder [01:07:08] <Dark_Shikari> *many encoders [01:07:10] <Compn> ooh sorry [01:07:12] <Compn> mpeg4 asp [01:07:32] <Compn> but i fink it works on other codecs [01:07:38] <Compn> it maybe motion est etc [01:07:41] * Compn looks up [01:08:18] <Compn> To shave off some encoding time, you can specify the turbo option on the first pass; this reduces subq and frameref to 1. [01:08:44] <Dark_Shikari> Those are x264 options. [01:09:12] <Compn> well, i pasted that from the x264 part yes [01:09:18] <Compn> but turbo is listed under libavcodec section too [01:09:26] <Compn> btw i still havent fixed the b-pyramid stuff in the mencoder docs ;\ [01:10:30] <Compn> turbo (two pass only) [01:10:30] <Compn> Dramatically speeds up pass one using faster algorithms and disabling CPU-intensive options. This will probably reduce global PSNR a little bit (around 0.01dB) and change individual frame type and PSNR a little bit more (up to 0.03dB). [01:10:49] <Compn> from man, under lavcopts [01:11:10] <Compn> so i guess whatever 'cpu-intensive options' exactly means is still a mystery [01:11:25] * Compn capturing vhs [01:11:32] <Compn> any point in using x264 for vhs captures? :P [01:11:58] <peloverde> I sent an e-mail to mp4-tech, if no one responds, I'll escalate to mpam next week [01:12:27] <Dark_Shikari> Compn: of course, x264 already does its own turbo automatically [01:12:30] <Dark_Shikari> mencoder is just old and doesn't use it [01:12:57] <Compn> mencoder isnt old, it died and became a zombie. it just wont stop! [01:13:05] <Compn> isnt just old* [01:13:23] <Compn> but ok, thats a good idea Dark_Shikari :) [01:13:31] <Dark_Shikari> you should write a patch [01:13:33] <Dark_Shikari> it takes 5 minutes [01:13:42] <Compn> Dark_Shikari : also, i wonder... is it worth it to use grayscale decoding for 1st pass ? [01:13:50] <Compn> i heard somewhere gray decode was faster... [01:13:54] <Dark_Shikari> extremely marginally [01:13:55] <Dark_Shikari> not worth it [01:13:59] <Dark_Shikari> and it'll be less accurate [01:14:13] <Compn> ah [01:14:32] <Compn> well if i can dig up a commit that added some other x264 option to mencoder, i guess i can copy pasta [01:14:58] <Compn> but i'm in that non-programmer boat that diego is stuck in [01:16:34] <ohsix> Dark_Shikari: what parameters would you use for the best quality regardless of cpu time spent [01:16:44] <Dark_Shikari> --qp 0 [01:16:45] <Dark_Shikari> done ;) [01:16:52] <ohsix> for something that would end up, say, 700mb [01:17:01] <Dark_Shikari> ok, in that case --preset placebo. [01:17:24] <ohsix> i got to mess with some 264 stuff in handbrake the other day and there was some obvious stuff [01:17:42] <ohsix> is qp 0 lossless or something? [01:17:44] <Dark_Shikari> yes [01:17:52] <Dark_Shikari> you asked best quality [01:17:55] <Dark_Shikari> so I answered lossless [01:17:55] <Dark_Shikari> =p [01:17:58] <ohsix> right :P [01:18:02] <ohsix> at least you winked [01:18:21] <Compn> hmm [01:18:22] <ohsix> will fancy motion search and stuff get you much if you're crunching 80 minutes into 700mb? [01:18:33] <Compn> ohsix : always. [01:18:59] <Compn> Dark_Shikari : did you guys all take a break from porting x264 optimizations > ffwebm ? [01:19:40] <Compn> ohsix : in fact... the more cpu intensive options you use, the better bang (quality) for your buck (bitrate) [01:20:06] <ohsix> so just turn them all on? [01:20:14] <ohsix> or where i can pick an integer pick the largest [01:20:21] <Compn> if <any encoder> knows there are 100 frames without motion, it can save bits from there to use in other high motion frames ;p [01:20:46] <Compn> read ahead motion estimation [01:20:56] <Compn> or something [01:20:59] <ohsix> hm, how can i measure the difference between the source and what i encode; that might be a more useful question [01:21:07] <Dark_Shikari> ohsix: --preset placebo [01:21:10] <Dark_Shikari> =p [01:21:15] <Compn> psnr or ssrn or whatever its called [01:21:18] <ohsix> is that ironically named? [01:21:19] <Dark_Shikari> Compn: we're waiting on bbb to stop being lazy [01:21:20] <Compn> best to measure using eyes tho [01:21:30] <Dark_Shikari> ohsix: It's named for the people who would pick ANY OPTION that made things slower [01:21:36] <ohsix> can only trust eyes when it gets _really_ bad [01:21:37] <Dark_Shikari> And you know those people =p [01:21:45] <ohsix> ah, cool [01:21:49] <Dark_Shikari> placebo is the slowest option [01:21:53] <Compn> its ironic and unironic at the same time [01:21:58] <Dark_Shikari> it's very very marginally better than the next-slowest ("veryslow") [01:22:01] <ohsix> theres no junk in there that really doesn't need to be slow? [01:22:01] <Dark_Shikari> and a lot slower. [01:22:16] <Dark_Shikari> everything that's on in placebo does actually help, it just helps so little it's a waste of time [01:22:25] <ohsix> k cool [01:22:28] <Dark_Shikari> <ChronoCross> I feel as though ----------------------tesa should be an option. it should be compareable to lossless with the side effect of it taking an eternity to encode. [01:22:29] <Compn> sounds like Dark_Shikari needs to write a faq on x264 options [01:22:32] <Dark_Shikari> <ChronoCross> I guarantee 90% of the people in this channel and doom9 would use it. [01:22:32] <ohsix> waste of time is what i'm looking for \m/ [01:22:35] <Dark_Shikari> <pengvado> no, it has to be blatantly obvious. [01:22:37] <Dark_Shikari> <pengvado> --placebo [01:22:40] <Dark_Shikari> <pengvado> which makes your encode 10x slower and donates the difference to folding@home [01:22:43] <Dark_Shikari> Compn: --help [01:22:44] <Dark_Shikari> --fullhelp [01:22:46] <Dark_Shikari> --longhelp [01:22:52] <Dark_Shikari> --wtfgigantichelp http://mewiki.project357.com/wiki/X264_Settings [01:22:56] <Compn> well ohsix , read some manuals or join #x264 [01:23:06] <Compn> and stop user questions in devel chans [01:23:10] <ohsix> not that interested yet; when i'm comparing snr i might [01:23:17] <Dark_Shikari> psnr is horrible to compare [01:23:22] <ohsix> it is OT, but i was asking Dark_Shikari, i'll stfu now [01:23:24] <Dark_Shikari> particularly among encoders not optimized for it [01:23:30] <Dark_Shikari> It's not OT, there's nothing else going on. [01:25:02] <ohsix> if you're doing Eyes, is there something to do a rough scan and tell you possible trouble scenes so you don't have to watch a large portion of the video to look [01:25:20] <Dark_Shikari> I'm not sure what you're trying to do [01:25:22] <Compn> custom matrices? no clue [01:25:30] <Dark_Shikari> using different options usually will not change the bit distribution [01:25:32] <Compn> Dark_Shikari : he only wants to scan 50x60 box for motion [01:25:37] <Dark_Shikari> so it won't change what scenes are "trouble" and what aren't [01:25:56] <ohsix> oic [02:07:52] <Dark_Shikari> mru: [02:07:55] <Dark_Shikari> you should have said who it was [02:07:59] <Dark_Shikari> fuck no do not recommend me to that guy [02:08:15] <Dark_Shikari> Please fucking no [02:09:32] <ohsix> who [02:10:10] <saintdev> peloverde: ping [02:10:15] <peloverde> pong [02:13:10] <saintdev> peloverde: actually let me think out this question, not exactly sure how to word what i want to ask :P [04:08:54] <CIA-99> ffmpeg: ramiro * r24156 /trunk/configure: [04:08:55] <CIA-99> ffmpeg: configure: properly check for mingw-w64 through installed headers. [04:08:55] <CIA-99> ffmpeg: mingw-w64 can also target 32-bit code. [05:26:18] <peloverde> The more I read about phonon the more I can't decide if I should laugh or headdesk [05:28:09] <ohsix> laugh, and read the impetus behind it and laugh more [05:32:46] <elenril> how is it worse than other layers of wrappers? [05:36:31] <peloverde> Mostly that they wrap other wrappers, and that they don't want a phonon FFmpeg because it doesn't uses libmad and libfaad and all those other libraries we've obsoleted [05:37:55] <ohsix> and people writing wrappers usually know the software they're wrapping, and have a reason to wrap it; not knowing the subject matter makes for some amazing bodges once some tard loaded up on c++ has stubbed out a wonderful pile of classes [05:40:24] <ohsix> though i suspect its more someone wanting to do something before they know they need to do it [05:42:40] <elenril> isn't ffmp3 faster than libmad? [05:43:27] <peloverde> even if not, the difference is negligible [05:44:00] <peloverde> But people have a cargoculted affinity for these libs [05:44:00] <elenril> http://forum.doom9.org/showthread.php?t=155516 [05:47:16] <peloverde> yes I saw that [05:58:39] <peloverde> Wow, even our lawyer doesn't think FFmpeg is free software "Watched my first YouTube video using all free software and codecs. I feel so... clean. #WebM" [06:00:07] <ohsix> huhuhuhuhuhuuh [06:00:21] <Dark_Shikari> gg sflc [06:02:10] <pross-au> mru: u about? [06:11:38] <elenril> anyways, i thought phonon wrapped gstreamer/dshow/xine/etc [06:11:54] <elenril> and didn't use the libs that actually DoStuff directly [06:13:34] <peloverde> It does [06:13:37] <elenril> peloverde: tell him that by that logic linux isn't free software as it violates tons of patents [06:14:33] <peloverde> elenril: It's funny that all the asshats who have made ffmpeg the new patent posterchild never seem to bitch about patents in the kernel and especially in drivers [06:15:14] <ohsix> is there an mpeg-la for os patents; one that is constantly bloviating [06:15:23] <pross-au> its called selective love peloverde [06:15:43] <ohsix> the companies already making a business out of lunix have defensive portfolios if the need ever arise [06:15:58] <peloverde> ohsix: See the FAT driver debacle [06:16:21] <peloverde> MS suing TomTom (which was in retaliation for othershit but still) [06:17:14] <peloverde> MPEG-LA selectively enforces on free software too, so I don't see much of a difference [06:17:35] <ohsix> is there an ibm for ffmpeg yet [06:18:03] <pross-au> I prefer the sweep it under the rug approach [06:18:18] <peloverde> What does that have to do with anything, IBM didn't come to TomTom's defense [06:18:31] <ohsix> when you're talking fud you just really need to know where it comes from, that theres a lot of fud is neither here nor there [06:19:05] <ohsix> the penultimate attack on linux was the sco thing [06:19:59] <Dark_Shikari> that was less of an attack and more of a comedy sketch [06:20:00] <peloverde> ohsix: you are continuing to ignore my factual argument [06:20:09] <ohsix> nein [06:20:23] <ohsix> they aren't comparable, i'm saying linux is entirely different [06:20:36] <peloverde> ohsix: What are your thoughts on MS's successful use of the FAT patent(s) against TomTom's use of Linux kernel [06:20:49] <ohsix> moreover the scope is larger and any patent can likely be worked around, to decode a given file format you might be dead [06:21:11] <ohsix> i think its just fat and they didn't have to air much dirty laundry to do it [06:21:24] <peloverde> The FAT patent is essential [06:21:38] <peloverde> In this case decoders are analogous to drivers [06:21:52] <ohsix> if you don't create short names then you don't run afoul of the patent [06:22:22] <ohsix> and thats how it was worked around afterwards [06:24:11] <peloverde> And that's the equivalent of say dropping B-Frame support from the MPEG-4 encoder [06:24:34] <ohsix> and nobody was fudding fat even though they new there were patents involved before tomtom [06:24:52] <Dark_Shikari> peloverde: you mean mpeg-4 decoder [06:24:55] <ohsix> nah; you can read it, and distros can even build kernels that still create short names [06:25:21] <peloverde> Dark_Shikari: in this case I actually mean encoder because the patent was on generating long and short names at the same time [06:25:38] <Dark_Shikari> .... that's a pretty retarded patent [06:25:40] <ohsix> well it doesn't happen at the same time, but its good enough [06:25:45] <peloverde> Dark_Shikari: I know [06:25:54] <ohsix> Dark_Shikari: and how they bodged long file names in is retarded too :D [06:26:16] <ohsix> dumb things are unique enough for a patent too, though [06:26:55] <ohsix> and it was a defensive move to other DOS implementations right around when they started messing with stuff, and making software randomly fail "requiring" dos [06:28:17] <ohsix> practical implication for other DOS vendors is they couldn't generate long names [06:31:25] <peloverde> See also http://en.swpat.org/wiki/Duds_and_non-solutions [06:35:50] <CIA-99> ffmpeg: darkshikari * r24157 /trunk/libavcodec/options.c: [06:35:51] <CIA-99> ffmpeg: Change qmax/qmin limits to 63 instead of 51. [06:35:51] <CIA-99> ffmpeg: VP8 supports quantizers up to 63. [06:36:57] <ohsix> fud may as well be real; because you'll be paying someone for an opinion or a proactive defense/research [06:37:55] <ohsix> works best where you cant be certain, and apply liberally [07:15:45] <peloverde> Is there a way to adjust the delay for CMP = oneoff? [07:49:48] <peloverde> Interesting main profile doesn't seem to have the delay issue [07:55:55] <CIA-99> ffmpeg: reimar * r24158 /trunk/ (6 files in 3 dirs): Add native GSM 06.10 audio decoder. [07:58:45] <elenril> \o/ yet another lib goes away [08:27:17] <peloverde> mru: I have a set of AAC scattershot tests from the conformance suite [08:31:39] <peloverde> I've kind of stuck to things that are essential or that I'm curious as to how they play on all the targets we support [08:32:11] <peloverde> notable holes include the rigorous tests on the SBR tools, Independent coupling, downsampled SBR, IPD/OPD, PS mixing mode B [08:32:23] <peloverde> also the uncompressed PCM references seem large [08:32:35] <peloverde> do you think we should flac or gz them? [08:37:39] <peloverde> I suppose I should copypasta that into an e-mail [08:37:49] <peloverde> also why I am I still awake [08:38:24] <peloverde> Oh also it doesn't cover any of the broken files we hack around [08:38:50] <peloverde> ...some vague comments about cyborgs... [08:43:26] <mru> morning [08:43:51] <mru> Dark_Shikari: sorry, never heard of that guy before, didn't know he's a total troll (as you imply) [08:44:59] <peloverde> mru: Do you have any thoughts on above before I send my [RFC/PATCH]? [08:46:10] <Dark_Shikari> mru: more like one of those stupid managers who doesn't understand shit [08:46:37] <mru> Dark_Shikari: ok, noted [08:46:53] <mru> I'll file anything from him to /dev/null henceforth [08:49:29] <mru> peloverde: you asked for a delay parameter... [08:50:09] <peloverde> never mind that, I've hacked on the first few samples of my local reference rendering [08:50:38] <peloverde> I'm hope the AHG on ASM will issue new vectors [08:50:50] <mru> what's the problem? [08:51:07] <peloverde> in regard to delay or otherwise? [08:51:11] <mru> delay [08:51:22] <mru> and otherwise [08:51:43] <peloverde> Delay is more-or-less fixed [08:52:36] <peloverde> Should I go ahead with my subset? should I try to get better coverage? Is 31 MB of vectors ok? [08:53:04] <mru> go ahead and post the patch [08:53:37] <mru> I don't think we can avoid the size [08:54:20] <peloverde> Well we could flac or gz the pcm files [08:55:03] <peloverde> 6 of the 7 signaling tests have identical payloads, the last makes me want to punch someone at CT in the face [08:55:09] <mru> flac would require flac or ffmpeg installed on the test machine [08:55:24] <peloverde> don't we already require ffmpeg on the test machine? [08:55:29] <mru> no [08:55:53] <peloverde> can't we just unflac it with the ffmpeg under test? [08:56:35] <mru> I'd rather not [08:56:51] <mru> it gets complicated for the embedded stuff [08:57:24] <peloverde> ok [08:58:05] <mru> it would also make all those test fail if the flac decoder breaks [08:58:36] <peloverde> true but you could make the same argument about the mp4 demuxer [08:59:04] <mru> aac decoder isn't very useful w/o mp4 demuxer anyway [08:59:35] <peloverde> aac-in-adts? [08:59:54] <mru> sure, that exists too [08:59:59] <peloverde> It was probably the prevalent form of AAC pre iTunes [09:00:14] <mru> possibly [09:00:18] <mru> but not anymore [09:01:24] <peloverde> AAC pre iPod probably had around the same marketshare as TwinVQ [09:01:44] <peloverde> and we support .vqf [09:02:09] <mru> so? [09:02:20] <mru> aac in mp4 is very, very common _now_ [09:02:37] <mru> for a long time ffaac didn't even work with adts at all [09:02:51] <mru> because the authors at the time didn't think it important [09:03:31] <peloverde> for a long time FFmpeg didn't support twinvq [09:03:53] <mru> look, forget history [09:04:01] <mru> aac in mp4 is everywhere [09:04:24] <mru> relying on the mp4 demuxer to test aac is reasonable [09:04:34] <mru> relying on a totally unrelated decoder is not [09:05:09] <mru> the first rule of testing is not to entangle your tests [09:05:44] <peloverde> If I wasn't entangling tests my 13 MB archive would be 1.3 GB [09:06:10] <mru> then don't entangle more than necessary [09:06:21] <peloverde> using flac or gz gives me room to test more AAC features [09:06:47] <mru> how well do the files compress with gzip or lzma? [09:08:05] <peloverde> xz saves 25% [09:08:17] <mru> and flac? [09:11:56] <peloverde> flac saves 60% [09:12:32] <mru> are people tight on diskspace? [09:12:46] <Dark_Shikari> bandwidth? [09:12:49] <peloverde> I'm tight on bandwidth [09:15:09] <CIA-99> ffmpeg: mstorsjo * r24159 /trunk/libavcodec/psymodel.c: Fix a leak in the AAC encoder [09:19:15] <mru> bandwidth doesn't matter [09:19:22] <mru> you only download the samples once [09:21:16] <peloverde> people are also constantly bitching about space on samples.mplayerhq.hu [09:22:41] <mru> 30MB is nothing [09:23:22] <Dark_Shikari> might as well compress when you can [09:23:32] <mru> we can do it later just as well [09:25:42] <peloverde> ok [10:09:58] <jai> what is a "channel conversion"? [10:10:27] <jai> and why do we care what liba52 does [10:11:12] <markuman> i've got a question to the "missing picture in access unit" message. does parse_nal_units search for a pair of frame? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073538.html [10:50:20] <mru> jai: I don't think we do care [10:50:25] <mru> we certainly shouldn't care [10:53:03] <jai> mru: well, the thread is "Audio conversion and floating-point codecs" [10:53:35] <jai> some part sounded weird [10:53:37] <jai> *parts [10:54:05] <jai> err, libavfilter audio - af_resample [10:54:11] <jai> ^ that thread [10:54:57] <jai> too much focus on sdl and ffplay doesnt help either [10:57:53] <Dark_Shikari> multimedia.cx is down [10:58:03] <mru> jai: OH FUCK [10:58:11] <mru> I thought I'd have more time with this [10:58:23] <mru> he's fucking up the audio conversion all over again [10:58:31] <jai> mru: yep :| [10:58:37] <mru> Dark_Shikari: works for me [10:58:42] <jai> mru: maybe you can "mentor" him or something [10:58:46] <Dark_Shikari> 404 here [10:58:47] <mru> I don't have time [10:58:49] <Dark_Shikari> times out nicely [10:58:52] <kshishkov> mru: not for me [10:59:13] <Dark_Shikari> http://downforeveryoneorjustme.com/http://www.multimedia.cx/ [10:59:18] <Dark_Shikari> It's not just you! http://www.multimedia.cx looks down from here. [10:59:51] <Dark_Shikari> back up now, it seems. [10:59:58] <mru> hmm, it was slow there for a bit [11:00:28] <jai> ah, k [11:00:28] <kshishkov> mru: you're not using certain Norwegian browser, are you? [11:00:34] <mru> oh no [11:08:38] <Transport> and down here in the uk, and ping www.multimedia.cx fails too ATM [11:09:09] <mru> works here in southampton [11:09:21] <Transport> virgin cable here [11:09:27] <kshishkov> mru, try wiki [11:09:51] <mru> loads but a bit slow [11:11:21] <mru> dns for that domain seems down [11:11:24] <Transport> i get the dns lookup ip number 207.45.186.114 but request time out odd [11:11:35] <bilboed> works from spain [11:12:06] <Compn> mru : ask some other maintainer to look at it if you dont have time [11:12:07] <Compn> :) [11:12:15] <Compn> -maintainer / mentor [11:12:40] <mru> all my time is taken up fending off stupid ideas [11:13:40] <kshishkov> hmm, wget works, browser does not [11:14:08] <Compn> lol [11:15:10] <Compn> multimedia.cx seems slower than www.multimedia.cx , maybe its just me :P [11:15:17] <Compn> but all three (wiki) come up fine [11:15:35] <mru> they're all on the same IP address [11:16:04] <Transport> its pinging fine now..... [11:16:19] <jai> Compn: maybe it wont be required at all since peter is looking into it as well ? [11:16:25] <Transport> and http://downforeveryoneorjustme.com/http://www.multimedia.cx/ works to [11:16:43] <mru> jai: I want a proper replacement for audioconvert.c, not a silly filter [11:16:51] <jai> mru: of course, i agree [11:16:59] <mru> please say so in the thread [11:17:01] <Compn> mru : btw , your mail i think lacks some details as what you want the guy to do [11:17:02] <mru> if you didn't already [11:17:19] <jai> mru: well, i could go +1 since you phrased it better than i could :) [11:17:24] <mru> Compn: I probably want him to crawl under some rock where he'll do no damage [11:17:32] <Compn> which is a general problem i've seen in ffmpeg mails. e.g. lots of 'dont do this' and not so much 'do this and that' [11:17:33] <Compn> lol [11:18:06] <mru> I thought I was pretty clear about first making planar audio work [11:18:15] <mru> or at least put the data structures in place [11:18:25] <Compn> well i havent read the whole thread sooo i'm just going on that one mail [11:18:28] <mru> who is this guy anyway? [11:18:56] <jai> Compn: well, in this specific case, i'd say a much better discussion is happening [11:19:14] <Compn> jai : ok i'll butt out :) [11:19:28] <jai> Compn: wait what :) thats not that i meant [12:23:48] <mru> DonDiego: is there a way to make doxygen use a different name for a function than what is in the code? [12:24:16] <mru> it's currenly spitting out docs for av_clip_*_c() [12:24:28] <mru> the correct name people should use is av_clip_*() [12:28:56] <siretart> mru: perhaps \fn could work here: http://www.stack.nl/~dimitri/doxygen/commands.html#cmdfn [12:30:02] <mru> yeah, possibly [12:30:18] <mru> would be nice if it allowed to just override the name though [12:35:24] <_av500_> http://mobile.osnews.com/story.php/23525/Deep_Analysis_of_the_VP8_Codec_by_… [12:35:42] <mru> lol [12:35:55] <mru> that's the msu comparison [12:36:04] <mru> they don't even document what settings they used [12:36:11] <mru> and the graphs look dubious to say the least [12:36:43] <kshishkov> BBB may be proud to be called x264 dev [12:37:14] * mru should probably take his name off the x264 web page [12:37:55] <mru> there's not much left of what I once did there [12:38:01] <mru> maybe some vui code [12:38:09] <mru> and they lifted some asm from ffmpeg [12:38:22] <kshishkov> mru: that page still features some weird email for you [12:38:32] <mru> it still works [12:38:53] <mru> every email address I've used in the last 10 years still works [12:39:02] <mru> and some that I haven't used [12:39:51] <kshishkov> good thing then [14:04:05] <Vitor10011> mru: Nice changes to fate-run.sh, but one problem remains [14:04:16] <mru> go [14:04:41] <Vitor10011> mru: the decoder can have decode_frame() return an error, and for error concealing, ffmpeg.c will keep decoding the file [14:04:57] <mru> yes... [14:04:59] <Vitor10011> if it happens with every frame, ffmpeg will return success and an empty file [14:05:03] <mru> ah [14:05:08] <Vitor10011> with MAXDIFF = 0... [14:05:12] <mru> let me fix that then [14:05:18] <Vitor10011> great, thanks [14:06:23] <Vitor10011> mru: Just please check the size, to be sure it still fail if it decode correctly just half of the file [14:27:24] <CIA-99> ffmpeg: aurel * r24160 /trunk/libavcodec/arm/Makefile: fix VP5/6 neon dependencies [14:37:43] <CIA-99> ffmpeg: kostya * r24161 /trunk/libavcodec/ (vc1dec.c vc1.c): [14:37:43] <CIA-99> ffmpeg: Make WMV3 decoder print more errors when decoding beta WMV9 files. [14:37:43] <CIA-99> ffmpeg: As a side effect it will also decode a lot of P-frames from those. [15:26:32] <CIA-99> ffmpeg: ramiro * r24162 /trunk/doc/faq.texi: [15:26:33] <CIA-99> ffmpeg: faq: remove note that says avisynth "has just been added". it has been there [15:26:33] <CIA-99> ffmpeg: for almost 4 years. [15:28:35] <kierank> lol [15:29:44] <kshishkov> we have a lot of still experimental things though [15:42:16] <DonDiego> why is libxvidff.o and libxvid_rc.o compiled conditional to CONFIG_LIBXVID and not CONFIG_LIBXVID_ENCODER? [15:42:43] <DonDiego> this is causing a compilation failure in mplayer [15:42:55] <kshishkov> fix mplayer [15:43:15] <DonDiego> mplayer is not in need of fixing [15:44:20] * kshishkov files that into the fourth category of lies [15:46:31] <DonDiego> wtf? [15:48:25] <kshishkov> BTW, aren't those configs always in the same state? [15:50:27] <mru> DonDiego: that is to _fix_ a damn build failure [15:50:33] <mru> read the commit message [15:50:45] <mru> --enable-libxvid --disable-encoder=libxvid fails otherwise [15:51:15] * pJok is aparantly not the only person with bad taste in this city [15:51:38] <pJok> what are the odds that two yellow mondeo station wagons are parked right next to each other? [15:51:44] <kshishkov> pJok: city? [15:52:05] <kshishkov> also I find Ford cars to be of bad taste indeed [15:52:08] <pJok> kshishkov, Landskrona [15:52:14] <mru> an ex-workmate's wife drives a yellow pt cruiser... [15:52:14] <pJok> kshishkov, http://sphotos.ak.fbcdn.net/hphotos-ak-ash2/hs080.ash2/37363_413924883630_6… [15:52:24] <kshishkov> pJok: I thought it was rather a town [15:52:25] <pJok> mru, thats not bad taste... thats just horrible taste [15:52:38] <pJok> kshishkov, 28k inhabitants... its a city ;) [15:52:54] <mru> and that's after she sold the yellow porsche boxter [15:54:05] <pJok> a yellow boxter is ok... [15:54:13] <pJok> but a pt cruiser isn't... no matter what color [15:54:13] <mru> of course [15:54:22] <kshishkov> pJok: I lived in a city with population of Stockholm, so everything significantly smaller is a town to me [15:54:32] <mru> I'm just putting it in the proper perspective [15:54:52] <pJok> kshishkov, you live in germany now... it doesn't count ;) [15:55:58] <kshishkov> pJok: ok, in Sweden everything with population >10k was a city it seems. So you're right [15:56:36] <kshishkov> pJok: and my current "city" still has > 290k people [15:56:57] <mru> kshishkov: I'd say it has the necessary elements for a city [15:58:08] <jai> hey there pJok [15:58:14] <pJok> hey jai :) [15:58:49] <pJok> mru, i have a 24hr/day gas station, a mcdonalds and 3 major supermarket chains (4th one coming soon) [15:58:55] <kshishkov> mru: by your definition Ukraine has no cities [15:58:56] <pJok> that pretty much qualifies for a city [15:59:20] <mru> how many cinemas? [15:59:28] <mru> casino? [15:59:33] <mru> university? [16:00:40] <pJok> 1 [16:00:45] <pJok> i dont think there's a casino [16:00:55] <pJok> but the closest to a casino is in helsingborg at the station [16:01:05] <pJok> they have roulette and blackjack [16:01:25] <pJok> and university is in lund [16:01:35] <pJok> the cinema, only one very small one [16:01:43] <mru> then it's no city [16:01:53] <mru> what about pubs and nightclubs? [16:01:57] <kshishkov> Storkyrkan? [16:02:00] <mru> sports stadium? [16:03:05] <pJok> there are a few pubs and nightclubs [16:03:14] <pJok> one stadium [16:51:55] <CIA-99> ffmpeg: alexc * r24163 /trunk/tests/fate2.mak: AAC fate2 tests. [16:58:56] <CIA-99> ffmpeg: mru * r24164 /trunk/tests/fate-run.sh: fate: ensure file sizes match in oneoff tests [16:59:05] <mru> Vitor10011: that better? [17:02:05] <Vitor10011> mru: Great, thanks! [17:12:18] <CIA-99> ffmpeg: ramiro * r24165 /trunk/configure: mingw32: avisynth does not need w32api >= 3.13 [17:42:11] <mru> peloverde: ping [17:48:06] <peloverde> pong [17:48:42] <mru> some of the aac tests fails with maxdiff=2 on arm [17:48:47] <mru> ok to increase fuzz? [17:49:03] <peloverde> How much? [17:49:06] <mru> 2 [17:50:24] <peloverde> Are you talking about al04_44 or the others? [17:50:36] <peloverde> I'm ok with bumping any/all of them to FUZZ=2 [17:50:37] <mru> all but al04_44 [17:51:01] <peloverde> You can bump any of those that you need to to FUZZ=2 [17:51:08] <peloverde> Anything above that I'd like to manually verify first [17:54:56] <mru> ok [18:02:06] <CIA-99> ffmpeg: mru * r24166 /trunk/tests/fate2.mak: fate: some AAC tests need FUZZ=2 on ARM [18:43:50] <CIA-99> ffmpeg: vitor * r24167 /trunk/tests/fate2.mak: Add fate2 test for RA288 [18:47:00] <CIA-99> ffmpeg: vitor * r24168 /trunk/tests/fate2.mak: Add RealAudio COOK fate2 test [20:44:09] <mru> \o/ michael in email mode [20:46:06] <kierank> i'm not getting any emails from ffmpeg-devel [20:46:12] <kierank> i haven't got the last 15 or so [20:46:14] <mru> are you subscribed? [20:46:15] <kierank> yes [20:46:18] <mru> :-) [20:47:08] <mru> firstname@lastname? [20:47:14] <kierank> yes [20:47:26] <kierank> hmm one just appeared but there's a big gap still [20:48:42] <mru> status=deferred (host mx5.biz.mail.yahoo.com[74.6.140.31] refused to talk to me: 421 4.7.0 [TS01] Messages from 213.144.138.186 temporarily deferred - 4.16.55.1; see http://postmaster.yahoo.com/errors/421-ts01.html) [20:48:56] <mru> summary: yahoo mail admins are idiots [20:49:38] <mru> and I get connection refused trying to open that url [20:49:43] <kierank> so do I... [20:49:47] <mru> so their webmaster is also an idiot [20:50:01] * mru recommends staying off yahoo [22:09:55] <CIA-99> ffmpeg: mru * r24169 /trunk/ (27 files in 3 dirs): [22:09:55] <CIA-99> ffmpeg: bswap: change ME to NE in macro names [22:09:55] <CIA-99> ffmpeg: Other parts of FFmpeg use NE (native endian) rather than ME (machine). [22:09:55] <CIA-99> ffmpeg: This makes it consistent. [22:13:23] <CIA-99> ffmpeg: mru * r24170 /trunk/ (51 files in 8 dirs): Add av_ prefix to bswap macros [22:22:44] <CIA-99> ffmpeg: mru * r24171 /trunk/libavutil/bswap.h: Make bswap.h safe to install as public API [22:22:44] <CIA-99> ffmpeg: mru * r24172 /trunk/configure: Set fast_unaligned in avconfig.h [22:22:45] <CIA-99> ffmpeg: mru * r24173 /trunk/libavutil/intreadwrite.h: Make intreadwrite.h installation-safe [22:22:46] <CIA-99> ffmpeg: mru * r24174 /trunk/libavutil/Makefile: Install bswap.h and intreadwrite.h [22:25:19] <CIA-99> libswscale: mru * r31679 /trunk/libswscale/ (rgb2rgb.c yuv2rgb.c swscale.c): Add av_ prefix to bswap macros [22:58:08] <CIA-99> ffmpeg: vitor * r24175 /trunk/tests/ (fate2.mak ref/fate/mpeg2-field-enc): Add MPEG2 field encoding fate2 regtest [23:16:39] <CIA-99> ffmpeg: vitor * r24176 /trunk/tests/fate2.mak: Add QCELP regtest [23:20:58] * Kovensky prefers to think of "NE" as "neither endian" [23:21:46] <pJok> or No Endian [23:22:59] <Kovensky> < CIA-99> ffmpeg: mru * r24173 /trunk/libavutil/intreadwrite.h: Make intreadwrite.h installation-safe <-- finally [23:23:18] <Kovensky> there was some function that was deprecated months ago; its replacement was on a public header that depended on intreadwrite [23:23:46] <Kovensky> forgot which, but it's sth that ffms2 used ._. [23:36:05] <CIA-99> ffmpeg: reimar * r24177 /trunk/libavcodec/avcodec.h: Document that and why subtitle decoders do not support direct-rendering. [23:42:15] <CIA-99> ffmpeg: vitor * r24178 /trunk/tests/fate2.mak: Add QDM2 test [23:43:08] <CIA-99> ffmpeg: reimar * r24179 /trunk/libavformat/gxf.c: Check url_fseek results in gxf demuxer. [23:51:06] <CIA-99> ffmpeg: vitor * r24180 /trunk/tests/fate2.mak: Add Intel Music Coder regtest [23:57:25] <mru> Kovensky: I find that hard to believe [23:57:55] <mru> at least I don't see any currently installed headers depending on it [23:58:16] <mru> therefor, no public functions can depend on it being available to the user

1 0

IRC log for 2010-07-09
by irc＠mansr.com 10 Jul '10

10 Jul '10

[00:00:45] <Vitor1001> But I still insist in the fate2 target. I'd hate to wait "not-too-long" to test more codecs... [00:00:52] <mru> ok, ok [00:02:00] <mru> reload git [00:05:54] <mru> right the, lets make some tests [00:05:55] <Vitor1001> mru: Perfect for me. [00:06:03] <mru> +n [00:07:21] <Vitor1001> mru: Well, now I'm going to sleep. But tomorrow I'll have a look at it. [00:07:22] <Vitor1001> Thanks! [00:07:44] <mru> I've been wanting to get this done forever [00:07:49] <mru> thanks for the kick in the rear [00:08:59] <Vitor1001> ;) [00:09:04] <Vitor1001> Good night! [00:09:25] <mru> it's troll driven development :-) [00:41:38] <CIA-99> ffmpeg: mru * r24132 /trunk/tests/ (91 files in 4 dirs): [00:41:39] <CIA-99> ffmpeg: tiny_psnr: print max absolute difference between files [00:41:39] <CIA-99> ffmpeg: Regression test reference updates are due to the extra output [00:41:39] <CIA-99> ffmpeg: from tiny_psnr. [00:41:39] <CIA-99> ffmpeg: Patch by Vitor Sessak [00:41:39] <CIA-99> ffmpeg: mru * r24133 /trunk/ (Makefile tests/fate-run.sh): [00:41:40] <CIA-99> ffmpeg: fate: pass additional variables to test script [00:41:40] <CIA-99> ffmpeg: This passes the following additional variables to the test script: [00:41:41] <CIA-99> ffmpeg: - CMP method to use comparing output with reference, default 'diff' [00:41:41] <CIA-99> ffmpeg: - REF reference file, default 'tests/ref/fate/${test}' [00:41:42] <CIA-99> ffmpeg: - FUZZ maximum fuzz factor in comparison, meaning depends on CMP [00:41:42] <CIA-99> ffmpeg: mru * r24134 /trunk/ (Makefile tests/fate-run.sh): [00:41:43] <CIA-99> ffmpeg: fate: add oneoff comparison method [00:41:43] <CIA-99> ffmpeg: This adds the 'oneoff' comparison method. It compares two s16le pcm [00:41:44] <CIA-99> ffmpeg: files with a max difference <= the fuzz factor treated as success. [00:41:44] <CIA-99> ffmpeg: Default fuzz is 1. On failure, the full tiny_psnr output is printed. [01:06:33] <bcoudurier> hey guys [01:06:44] <Dark_Shikari> hey bcoudurier's onjoin script [01:06:54] <bcoudurier> not today [01:11:46] <Compn> Dark_Shikari : i think thats 'hi guys' [01:12:04] * Compn is sad when mru , diego and michaelni fight :( [01:16:57] * hyc just deletes most of those emails without reading [01:17:05] * hyc remains blissfully unaware [01:17:10] <Dark_Shikari> the funniest part is that in all this time [01:17:14] <Dark_Shikari> they could have just fixed it correctly [01:17:33] <CIA-99> ffmpeg: siretart * r24136 /branches/ (0.6/libavcodec/ac3_parser.c 0.6): [01:17:33] <CIA-99> ffmpeg: ac3: make the value of codec_id during (E-)AC-3 parsing stay CODEC_ID_EAC3 [01:17:33] <CIA-99> ffmpeg: if any E-AC-3 frames have been detected instead of switching back and forth for [01:17:33] <CIA-99> ffmpeg: AC-3 core + dependent E-AC-3 substream(s). [01:17:33] <CIA-99> ffmpeg: Fixes Issue 2022. [01:17:33] <CIA-99> ffmpeg: backport r24103 by jbr [01:19:25] <hyc> yes and no. they can't commit a fix until everyone agrees, otherwise it's just a commit war [01:19:45] <Dark_Shikari> Not quite. [01:19:53] <Dark_Shikari> Everyone agrees the current one is insufficient. [01:19:56] <Dark_Shikari> Everyone agrees on how to fix it. [01:20:05] <Dark_Shikari> Look at what they're arguing about... [01:20:11] <Dark_Shikari> they're arguing about whether the partial fix was a step forward or back. [01:20:16] <hyc> but that seems to be par for the course here. all of the patches I've submitted take only a few minutes to write and test. they all take forever to get positive review... [01:20:18] <Dark_Shikari> DESPITE THE FACT THAT THEY ALL AGREE ON WHAT A COMPLETE FIX WOULD BE. [01:20:45] <mru> that's michael in a nutshelll [01:21:14] <Dark_Shikari> s/michael/michael and mru and diego/ [01:21:20] <hyc> lol [01:21:44] <Dark_Shikari> If any of you were not that, you would have committed a full fix already. [01:21:48] <Dark_Shikari> But a full fix isn't committed. [01:21:52] <Dark_Shikari> Therefore, you are all responsible. [01:22:11] <mru> look, I've been doing tons of other work [01:22:31] <mru> I had nothing to do with that commit [01:22:40] <Dark_Shikari> Then why are you involved in the whine-a-thon? [01:23:06] <mru> because I can't stand by and watch michael slaughter diego [01:23:25] <Dark_Shikari> Then commit a fix. [01:23:40] <mru> why the fuck should _I_ do it? [01:23:46] <Dark_Shikari> 09:23 <@mru> because I can't stand by and watch michael slaughter diego [01:24:13] <mru> just fixing would still let michael believe he was right [01:24:18] <mru> and that nobody opposed him [01:24:22] <Dark_Shikari> It would stop him from "slaughtering diego" [01:24:26] <Dark_Shikari> which is what you wanted. [01:25:01] <hyc> eh, I see mru's point. you have to get the point across too, not just badnage up the immediate situation. [01:25:02] <siretart> probably yes on this particular case [01:25:13] <hyc> bandage [01:25:20] <Dark_Shikari> hyc: "getting the point across" in an argument between mru and michael [01:25:35] <Dark_Shikari> is about as likely as a communist party election win in Texas [01:28:24] <hyc> I guess. I'm still a relative newbie here. I see mru's interactions on irc all the time, michael never seems to come around here. [01:29:17] <drv> michael reads the archived logs and sometimes responds on the mailing list [01:30:18] * beandog waves to michael [01:36:27] <Compn> ya i agree with Dark_Shikari , a fix could be done pretty quickly [01:36:38] <Compn> you guys just like to argue and point at each other and say its his fault! he argued! [01:37:00] <Compn> yes there are faults, but damn you guys argue a lot [01:37:07] <Compn> not important [01:38:17] <Compn> hyc : yes, patch acceptance in ffmpeg is a slow process. but you could be a reviewer and do it faster if you wanted :P [01:40:16] <hyc> eh? be a reviewer for my own patches? that doesn't sound right... [01:40:28] <Dark_Shikari> that's why so much code in ffmpeg is shit [01:40:39] <Dark_Shikari> nothing gets done unless you're your own reviewer [01:40:44] <Dark_Shikari> and if you're your own reviewer, shit gets in. [01:42:43] <siretart> do you think that better tool support for reviewing patches (like some webapp) would encourage more and better reviews? [01:42:49] <Dark_Shikari> NO. [01:47:03] <Compn> hyc : a reviewer for all patches [01:47:05] <Compn> lol siretart [01:47:13] <Compn> the thing is [01:47:23] <Compn> ffmpeg devs review a patch and let patch submitters fix them [01:47:35] <Compn> what you want are ffmpeg devs that review + fix + commit a patch themselves [01:47:38] <hyc> Compn: well, I have only studied small parts of the code [01:48:35] <siretart> Compn: no I don't. I was thinking about somethink like https://code.edge.launchpad.net/bundlebuggy, which recognizes patches to the mailing list and tracks their status, like needs work, or merged in [01:48:50] <siretart> bah, laggy ssh here in .ca [01:49:04] <Compn> ffmpeg has used roundup for that a few times [01:49:19] <mru> roundup is shit [01:49:21] <siretart> roundup has a mailinglist tracking feature for picking up patches? [01:49:25] <mru> all bug trackers are shit [01:49:35] <Dark_Shikari> +1000000000000000000000000000000000000000000 [01:50:01] <Compn> siretart : no, also i didnt say it was meant for that, just that we've used that in the past. it could be used for that purpose if we set roundup to watch ffmpeg-patches and sent patches there of course... [01:50:29] <siretart> sounds like a lot of overhead to me [01:50:32] <mru> you can mail patches to roundup and it'll open new issues for them [01:50:49] <Compn> yeah ffmpeg-issues i think [01:50:54] <mru> but that wouln't help getting them reviewed [01:51:16] <Compn> i think siretart is talking about patches that get lost [01:51:21] <siretart> exactly [01:51:55] <Dark_Shikari> Patches get lost on bugtrackers too. [01:52:17] <Compn> we have a lack of bugtracker maintainers (like carl) as well [01:54:10] <hyc> I think it's worth trying, easier to find entries in a tracker than dig thru email archives [01:54:55] <mru> a patch tracker would only work if a few conditions were met: [01:55:01] <mru> 1. all patches were entered [01:55:24] <mru> 2. the tracker is updated when patches are applied [01:55:29] <mru> 3. it doesn't suck ass [01:56:18] <hyc> the other problem is that trackers tend to be separate from the mailing list where discussions take place, things get awkward [01:56:49] <hyc> but once you have a tracker, it's easy to set a commit template that requires the tracker item # [01:56:56] <drv> i think wine uses something like that, although that works better as there is a single committer [01:57:01] <hyc> so that commit logs that are forwarded to the tracker can automatically update it [01:58:01] <Compn> siretart : while it wont work for ffmpeg, i think a patch tracker would do wonders in mplayer :) [01:58:24] <mru> it would have to be something specially designed for patches and nothing else [01:59:09] <Compn> siretart : also, no one is saying a 3rd party cant try it and see how it works. it might be a good way to show the devs how useful it is :P [01:59:13] <Compn> assuming it works well [01:59:32] <mru> sure, feel free to set up as many trackers as you like [01:59:48] <Compn> since they are all quite boneheaded :) [01:59:53] <Compn> hehe [01:59:58] <drv> this is the wine one: http://wiki.winehq.org/PatchWatcher [02:00:07] <drv> automatically picks up patches from a mailing list [02:00:42] <Compn> siretart : if you are interesting in running one temporarily, i'm sure the devs will at least take a quick look at it [02:00:50] <mru> it takes me more than 10 seconds to work out what to do => it sucks [02:02:44] <drv> actually i think that is the wrong thing, that is some kind of automated patch tester, but i'm pretty sure they have an automated tracker somewhere... [02:03:08] <drv> http://source.winehq.org/patches/ [02:03:58] <Compn> automated patch tester ala fate would be badass too [02:04:03] <mru> I already see a weakness [02:04:21] <mru> look at items 2 and 3 on that list [02:04:28] <mru> they are different versions of the same patch [02:04:49] <mru> automated patch tester is dangerous [02:05:07] <mru> anyone could send a patch full of malicious code to the ml [02:05:19] <mru> it would of course never be applied [02:05:25] <drv> yeah, they require a specific format for the subject with different tries of the same patch [02:05:53] <Compn> mru : the patch tester would just be checking for regressions, binary bloat, etc. not testing for ... security [02:05:59] <hyc> yeah, pi should just be 3. [02:06:32] <mru> Compn: ok, so I send a patch which replaces the configure script with rm -rf / [02:06:50] <drv> there's no need to actually run the patch if you're just tracking them [02:07:11] <mru> 03:03 < Compn> automated patch tester ala fate would be badass too [02:07:13] <hyc> right. you don't need an automated patch tester, or certainly not as a frontend. [02:07:24] <Compn> mru : and? the patch tracker would say that the reg tests failed ... [02:07:32] <Compn> tester* [02:07:41] <Compn> and compilation failed [02:07:42] <mru> no, there'd be nothing left of the patch tester after that patch [02:07:42] <Compn> etc [02:07:45] <hyc> can run it once any reviewer has given it a once over [02:08:01] <drv> you could do some kind of sandbox thing, but that quickly devolves into madness (or at least a lot of work) [02:08:05] <mru> now that one is of course obvious and easy to protect against [02:08:06] <Compn> so linux is the most secure os in the world but it cant sandbox ? :P [02:08:15] <mru> but what about one that turns the machine into a spambot? [02:08:36] <Compn> alright forget it [02:08:39] <hyc> notice that the linux-next tree is merged manually by a dedicated maintainer. nobody autocommits emailed patches into their tree. [02:08:51] <mru> there is no sandbox I'd trust enough to run random code off a mailing list in [02:08:55] <Compn> i'm not really interested in arguing this, if ffmpeg devs dont want it, nevermind :) [02:09:10] <mru> it would be a neat thing to have [02:09:15] <hyc> tracking is different from autocommit [02:09:15] <drv> anyway, the point is not really testing patches, just showing a list of ones that need attention [02:09:15] <mru> unfortunately it can't be done safely [02:09:56] <mru> well, michael refuses to use a web browser so there's no point discussing it [02:10:53] <Dark_Shikari> everyone vote 6 [02:10:58] <hyc> (sheesh you guys probably spent more time arguing over docs than anybody ever spent actually reading them...) [02:11:26] * mru never reads them [02:11:26] <Dark_Shikari> \6/ [02:11:26] <mru> and for the record, I'm not arguing about the docs [02:11:34] <mru> I'm arguing about the way michael is treating diego in particular [02:11:35] * Compn hasnt read ffmpeg docs [02:12:15] <hyc> the vote is already flawed because the change wasn't 1st or 3rd person. it was present vs future tense. at least the changes that I saw go by... [02:12:21] <Dark_Shikari> Hence why I propose 6. [02:13:03] <mru> I don't know what the proper name for that tense is [02:13:14] <mru> could be seen as imperative too [02:13:26] <mru> or a degenerate future [02:13:43] <mru> whatever it is, it's what dictionaries use [02:13:51] <mru> so it makes sense for documentation [02:14:01] <drv> when i do read the docs, i never think about what tense or person they are in [02:14:09] <beandog> yah me neither [02:14:24] <drv> but some people like to make everything into an engineering problem [02:14:39] <mru> I mostly think about what kind of person could have written it [02:14:44] <hyc> for the record, I prefer imperative. "Calculate X". Not "Calculates X" [02:15:11] <mru> yes, so do all good english-speakers [02:15:12] <hyc> the latter is actually incomplete, should be "This calculates X" but that's just a waste of words. [02:17:40] <hyc> and I certainly didn't join a software community to discuss grammar... [02:17:49] * Compn laughs at getting hyc stuck arguing about docs [02:18:30] <Dark_Shikari> oh god [02:18:34] <Dark_Shikari> now we have a bikeshed about grammar and pi [02:19:17] <hyc> btw, where does "bikeshed" originate? [02:19:21] <mru> there is nothing more stupid than attempting to vote on something that has an objectively correct answer [02:19:35] <mru> bikeshed.org [02:19:43] <mru> try reloading a few times [02:21:11] <saintdev> i vote pi = 2*C/D [02:21:47] <mru> oh you're one of those... [02:22:01] <saintdev> mru: no, just trolling :P [02:22:36] * drv hails from the great state that once attempted to square the circle [02:31:03] <hyc> so not only do lots of people toss in their 2cents on small issues, lots of them are wrong. :P [02:31:25] <mru> the majority is always wrong [02:31:31] <mru> that's a safe assumption [02:33:18] <beandog> heh [02:37:24] <mru> a lot of people have great difficulty differentiating between what actually is true and what they would like to be true [02:40:59] <mru> "Klingon programs don't have parameters. They have arguments and win them." -- Walter Bushell [02:42:47] <Compn> so uh [02:43:00] <Compn> did they ever show a klingon programming all that spaceship stuff ? [02:43:06] <Compn> or what [02:43:42] <mru> star trek is quite unrealistic at times [02:44:02] <mru> like there's no way many of those "people" they meet would ever manage to build a spaceship [02:45:01] <j0sh> well, at least some things are realistic about star trek [02:45:09] <j0sh> like warp speed, time travel and wormholes [02:45:22] <mru> eh, warp speed is realistic? [02:45:29] <hyc> :P [02:45:50] <mru> and what about "beaming" down to some hostile planet dressed in pyjamas? [02:46:54] <Compn> armor is for the weak i guess [02:47:29] <j0sh> yes, dermal regenerators will heal all [02:47:37] <mru> the klingons seem to be wearing some kind of armour [02:47:43] <mru> except worf of course [02:47:59] <hyc> ah, it was a 5 year mission and you only saw it once a week. you never saw them exploring the atmosphere-less planets in environmental suits. [02:48:06] <j0sh> well, that's because dermal regenerators work with energy weapons [02:48:13] <j0sh> and klingons like hand-to-hand combat [02:48:17] <j0sh> like, with their bat-leths [02:48:18] <j0sh> and stuff [02:48:29] <j0sh> thats why they need armor [02:48:57] <mru> phasers set to kill seem to, well, kill [02:49:03] <j0sh> true [02:49:25] <hyc> except when they don't. how the hell does a creature resist disintegration? [02:49:25] <mru> modern scifi shows are a bit more realistic in that regard [02:49:39] <mru> like in the stargate series, they first send a robot, then they send marines [02:49:57] <mru> _then_ they send a cute scientist who gets kidnapped by aliens [02:50:04] <j0sh> hehe [02:50:22] <hyc> yeah well, the aliens are smart enough to recognize soldiers and lay low at first [02:51:31] <hyc> I doubt anyone here has much good to say about any scifi tv or film. those writers are either lower IQ, or writing for an audience with lower IQ. [02:51:48] <Compn> hyc : you seen 'odyssey 5'? [02:51:55] <Compn> now theres some good scifi tv :) [02:51:55] <hyc> nope [02:52:13] <Compn> i highly recommend it [02:52:23] <j0sh> battlestar galalctica is pretty good scifi tv [02:52:28] <j0sh> the new one, at least [02:52:34] <Compn> too soap opera ish for me [02:52:36] <mru> only the first 3 seasons [02:52:39] <Compn> whos a robot this week durr [02:52:49] <Dark_Shikari> I never got BSG. [02:52:54] <Dark_Shikari> You want good scifi? [02:52:59] <Dark_Shikari> Ghost in the Shell: Standalone Complex [02:53:02] <Dark_Shikari> no fucking spaceships [02:53:04] <mru> and starbuck returning as some kind of angel... wtf? [02:53:15] <Dark_Shikari> no religion, no stupid kids (I'm looking at you wesley) [02:53:38] <Dark_Shikari> no episodic this-series-will-go-on-for-9-seasons-until-we-run-out-of-money-and-cancel-it [02:53:44] <Dark_Shikari> like Star Trek does [02:53:44] <mru> someone should make a new star trek series where they go back in time and kill wesley [02:53:47] <Compn> gits:sac had a lot of non-plot advancing episodes tho [02:53:54] <Dark_Shikari> Compn: those are fine [02:53:59] <Dark_Shikari> What isn't fine is when there IS no plot [02:54:01] <Compn> yeha, some are great, some not so much [02:54:02] <Dark_Shikari> i.e. it's written as they go [02:54:07] <Compn> right [02:54:07] <Dark_Shikari> and then they decide one day to end it [02:54:10] <Dark_Shikari> so they tell the writers to do that. [02:54:12] <hyc> yeah, gits was kind of annoying sometimes. meandered too much. [02:54:21] <j0sh> i enjoyed sarah connor chronicles while it was on hulu [02:54:29] <Dark_Shikari> I thought the non-main-plot episodes were great. sometimes better than the plot ones. [02:54:39] <Compn> terminator not directed by cameron? heh [02:54:43] <Dark_Shikari> It avoided what I'd call "Gundam Syndrome" [02:54:52] <Dark_Shikari> i.e. every episode starts exactly where the last ended [02:54:58] <Compn> the tachikoma episode(s) were crazy [02:55:01] <Dark_Shikari> so it might as well be one long movie with a lot of ad breaks. [02:55:28] <Dark_Shikari> Compn: Those were possibly the _best_ episodes. And an excuse for the writer to philosophize about machine intelligence, of course. [02:55:36] <Compn> oh i agree :) [02:55:38] <Compn> crazy good [02:55:43] <Dark_Shikari> The thing I liked most is how they intentionally fucked with the relationship between humans and machines [02:55:48] <Dark_Shikari> normally in every stereotypical scifi ever [02:55:51] <Dark_Shikari> machines are cold and unfeeling [02:55:53] <mru> it bugs me when they change the special effects from one season to the next [02:55:54] <Dark_Shikari> humans are, well, humans [02:55:59] <Dark_Shikari> GITS:SAC said -- fuck that [02:56:03] <Dark_Shikari> humans are cold and unfeeling, for the most part [02:56:13] <Dark_Shikari> the machines are the counterpoint to humans [02:57:39] <Compn> i did see some good scifi, 'twelve months of the summer' (swedish) and moebius (argentinian) [02:57:44] <Compn> scifi movies [02:58:34] <mru> good swedish film??? cannot be [02:59:22] <Compn> ehe [02:59:31] <Compn> it was a tv movie [03:01:09] <mru> even worse [03:01:45] <mru> everybody knows all the best swedes go elsewhere [03:01:59] <mru> there are quite a few swedish actors working in hollywood [04:17:10] <_av500_> what stopped you? [04:45:35] <pengvado> If I don't document any of my code, does that make me exempt from flamewars about documentation style? [05:09:49] <Compn> well i hope you didnt use pi at all [05:10:34] <thresh> moroning [05:12:08] <wbs> pengvado: of course not, then you'll be flamed for not documenting your code :-) [05:52:16] <hyc> I'm going to re-indent all of my code in Petrarchan sonnet form [06:54:20] <j0sh> hyc: any idea why ffmpeg's native rtmp won't handshake with rtmpsrv? [08:32:33] <markuman> i've got a question to the "missing picture in access unit" message. does parse_nal_units search for a pair of frame? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073538.html [08:53:49] <Tjoppen> kshishkov: any luck with that vc-1 bug? [08:54:31] <kshishkov> Tjoppen: not yet and I think the best way to fix it is to introduce interlaced decoding support [08:55:52] <Tjoppen> ah, ok. not a big issue for me since that was just a test. my proper files work fine in most players [08:56:03] <Tjoppen> although as said, crashes are important [08:56:08] <kshishkov> indeed [08:56:22] <Tjoppen> sadly, I have yet to manage to make a file that WMP will play :( [08:56:53] <Tjoppen> except remuxing that 1440x576 sample [09:44:21] <mru> http://varnish-cache.org/docs/phk/autocrap/ [09:44:40] <av500> yeah [09:45:07] <kshishkov> "so copy&paste became the order of the day" <- sounds like an understatement [09:47:38] <av500> ...The fourth school is the “DoxyGen” school, which lets a program collect a mindless list of hyperlinked variable, procedure, class and filenames, and call that “documentation”.... [09:47:44] <av500> :) [09:48:06] <kshishkov> well, have you ever heard of WEB? [09:48:25] <av500> a mindless list of hyperlinked pages.... [09:48:39] <mru> doxygen-type tools, if used responsibly, can serve to generate an API reference [09:48:47] <mru> API reference != documentation [09:49:04] <kshishkov> av500: no, that's really documenting language from DEK [09:49:09] <Dark_Shikari> what is a web? a miserable little pile of html! [09:49:15] <Dark_Shikari> but enough links, have at you! [09:50:03] <Tjoppen> regarding autocrap: is CMake the thing to use nowadays? I poked a bit at it and it wasn't too hard to get a library+executable style project going [09:50:43] <thresh> cmake, blergh [09:51:10] <kshishkov> scons competitor? [09:51:26] <mru> whatever happened to jam? [09:51:33] <mru> scones with jam, mmmm... [09:51:40] <av500> +1 [09:51:53] <av500> and clotted cream [09:51:55] <Honoome> kshishkov: nothing can compete with scons regarding idiocy [09:51:58] <mru> that's another problem with these newfangled tools [09:52:01] <Honoome> even though some things try [09:52:06] <mru> there's no guarantee they'll stick around [09:52:21] * kshishkov looks at M4 [09:52:26] <av500> otoh autotool hell will be there forever... [09:52:30] <mru> and M4 looks back at kshishkov [09:52:45] <ohsix> the second you need something cmake doesn't do, its untenable; and theres no corpus of standard do-ers to draw on, its all ad-hoc [09:52:45] <Honoome> well, the copy-paste of idiotic code is just the same between autoconf and cmake, to be honest [09:52:46] <mru> av500: I was implying that 'make' isn't going away [09:52:57] <Honoome> what ohsix just said [09:53:15] <Tjoppen> ohsix: that's the impression I got too [09:53:24] <mru> that's where all these fancy systems fall short [09:53:33] <Honoome> so cmake sounded cool and clean when just a few of mostly-identical things were to be done [09:53:39] <Tjoppen> if it doesn't support library X you need to add locator scripts for it anyway [09:53:45] <mru> as long as you stick to exactly the limited scenarios the authors had in mind, they sort of get the job done [09:53:47] <Honoome> give it a couple of years (even less in the hands of the kde guys) and it'll be just as bad as autohell [09:53:48] <mru> after much cursing [09:53:55] <Honoome> and the .cmake files are just the same as the .m4 ones [09:54:05] <av500> ic [09:54:25] <Honoome> (if you have never seen the kde 3 build system you never saw REAL autohell [09:54:29] <ohsix> i'd sooner ad-hoc it all in make, a target list is about what you need for simple-for-cmake stuff [09:54:43] <astrange> was kde 3 the one where all the apps were built at .so with a shell to launch them? [09:54:47] <kshishkov> Honoome: are you implying that even KDE is not worthy to be left in hands of KDE guys? [09:54:48] <astrange> *as [09:55:03] <mru> astrange: sounds familiar [09:55:17] <Honoome> they hacked so much around automake, libtool and even autoconf that you changed a single version and hell broke loose... we had to replace their admin/ directory IN EACH FUCKING PROJECT to use newer tools [09:55:22] <mru> starting any app would also start a gazillion rpc servers of various kinds [09:55:36] <Honoome> astrange: sorta, that's not the problem with the build system as much as with their trying to implement prelink-without-prelink [09:55:52] <Honoome> kshishkov: I imply that whoever does buildsystem for kde should be denied access to anything buildsystem-related [09:56:00] <mru> why do people care so much about app startup time? [09:56:09] <mru> apps I use frequently are always running [09:56:45] <Honoome> mru: there is one reason for them to hope for prelink & similar [09:57:12] <Honoome> their kdelibs package (used to, probably still) has HUGE vtables [09:57:18] <astrange> if your app quits when the last document closes it's a problem [09:57:39] <Honoome> which meant you could easily have over 100MB used in relocated .data.rel sections [09:57:43] <mru> close documents? [09:57:53] <Honoome> and if you are non-PIC... good luck with the .text that cannot be shared [09:58:03] * mru uses emacs and rarely kills buffers [09:58:30] * Honoome goes one step further and uses emacs-daemon [09:59:01] <mru> is that the same thing as gnuserv? [09:59:32] <kshishkov> no, it's their missing link to GNU Hurd+EMACS [09:59:51] <Honoome> mru: don't think so [10:00:05] <mru> then please explain [10:00:08] <astrange> is there anything left for the os to do when you have emacs? maybe that's why they didn't finish hurd [10:00:14] <Honoome> mru: it's like running emacs-23 with server-mode and then using emacsclient to open new frames, in TTY and X [10:00:24] <mru> astrange: emacs doesn't have any builtin device drivers [10:00:34] <mru> Honoome: that's gnuserv [10:00:45] <mru> and gnuclient [10:01:40] <Honoome> mru: I thought that only gave you a subset of features? [10:02:09] <mru> with xemacs at least it can open a frame anywhere you please [10:02:40] <Honoome> ah right you use the genetically-mutated version :) [10:02:57] <mru> xemacs used to be miles better than gnu emacs [10:03:03] <mru> and it's not called gnu [10:03:15] <Honoome> well with emacs-daemon I just have an init script to load with the system, and then I have emacs loaded until I shut it down (or it crashes :|) [10:03:21] <kshishkov> everything seems to be better without gnu (except zoos) [10:03:21] <mru> I haven't tried gnu emacs for ages [10:03:37] <mru> all its defaults are different though, so I get confused [10:03:43] <Honoome> mru: then RMS left the maintainership to people who actually do stuff, and emacs 23 regained popularity :D [10:03:54] <mru> oh, that's what happened [10:04:10] <mru> I wonder if rms _ever_ did anything useful [10:04:33] <Honoome> I could re-use a joke from BBC4's News Quiz [10:05:07] <Honoome> "he's like God, not believed in by the vast majority of people, hasn't done anything useful in ages, ..." [10:05:49] <kshishkov> what were original 1000 answers fitting that description? [10:06:09] <Honoome> kshishkov: it was a longer joke and was referring to politicians in general [10:06:44] <Honoome> anyway as I keep repeating, all kudos for starting the project/idea to rms... but he has definitely taken his "church of emacs" and "purity" problems to religious levels... and that makes him despisable in my view [10:06:45] <kshishkov> Honoome: well, GNU is a political system anyway [10:06:56] <Honoome> kshishkov: worse, it's a religion [10:07:27] <kshishkov> what's the difference? [10:07:32] <iive> it's worse.... it is based on reality. [10:08:01] <Honoome> you can actually look at a politician who compromises or double-talks to get his program passed as somebody that can make a difference [10:08:13] <Honoome> but gnu does nothing of that, so can't accomplish anything [10:08:30] <kshishkov> Honoome: reminds me of an old joke "There are three organizations run by a bunch of senile people - Vatican, USSR and IBM" [10:08:43] <Honoome> like idv in italy, libdems in uk, nader in usa [10:09:07] <mru> nader lol [10:09:09] <Honoome> kshishkov: well, vatican and ussr are not really "political" systems... aren't both one-sided anyway? :P [10:09:18] <mru> libdems are actually in government now [10:09:31] <Honoome> mru: and that's the first sign of the apocalypse... [10:09:45] <mru> I think it's a good thing [10:10:03] <mru> nick clegg is the only one of the leaders who's officially stated he doesn't believe in god [10:10:09] <mru> the others claim they do [10:10:13] <Honoome> yes, just so unlikely that I still haven't reformed my jokes to remind me of that fact [10:10:29] <kshishkov> Honoome: so? Actually USSR was democratical as it's said in its constitution. But political system != presence of political parties [10:10:31] <Honoome> mru: didn't he also add that his sons go to church because his _wife_ believes in god? :P [10:10:41] <mru> his wife is catholic, yes [10:10:44] <iive> Honoome: compromises with your principles always comes with a prise, that you pay much later. [10:11:09] <Honoome> iive: and you can see how well that's working out with gnu/hurd, no? [10:11:12] <iive> Honoome: my country during communist times also had 2 parties. [10:11:16] <mru> either way, I hope they can temper cameron a bit [10:12:11] <mru> Honoome: yeah, you have rms using a computer that's worse than the gdium and accesses the web by email request [10:12:43] <iive> Honoome: hurd is bad by technical design, and not because of fsf/gnu freedom principles. [10:13:04] <mru> the problem with hurd is they can't seem to settle on a design and go with it [10:13:14] <mru> they already changed microkernels something like 4 times [10:13:16] <Honoome> iive: beg you to differ, in that they rejected alternative microkernel options on the base of principles. [10:13:27] <mru> and spent the next year porting everything [10:14:32] <Honoome> iive: btw I sure hope you're not compromising by using a computer with a proprietary bios.. or a washing machine with proprietary firmware... [10:14:41] <iive> Honoome: i'm not going to argue with you on a matter I have no interest or knowledge of. [10:15:07] <iive> Honoome: i've RE the firmware of all my washing machines [10:15:24] <kshishkov> iive: me too. All zero of them [10:16:02] <Honoome> no cellphone or tv set either [10:17:09] <Honoome> [yes it's an argument for absurdity.. just shows how "no compromises" approaches only work on paper, and once you actually try to get stuff done you _have_ to compromise.. and if you do it might help (libdems docet, at this point)] [10:17:31] <iive> Honoome: the police in my country stores location report on all cellphones for 6 months. [10:18:18] <iive> but I hear that android is getting some steam. [10:18:36] <Honoome> and? I'm pretty sure my provider can tell what I have been doing for much more than that, just so you know... [10:18:59] <Honoome> and android is neither entirely free nor a "no-compromises" situation, all the opposite, rather [10:19:00] <iive> but your provider can't put you in jail. [10:19:15] <hyc> android phones home to google all the time [10:19:26] <Honoome> iive: corrupted police or generally bad laws have nothing to do with software [10:19:32] <av500> iive: isp can do worse than jail, it can cut you from ze interwebs :) [10:19:54] <hyc> unless, like me, you identify the IP addresses it tries to contact, and route them to space [10:20:05] <iive> i still keep by 56kbps modem :P [10:20:19] <mru> I don't care if the phone talks to google once in a while [10:20:22] <mru> they provide a good service [10:20:50] <hyc> when I am roaming and I need to use the data connection, I want it carrying my traffic and only my traffic. [10:20:53] <mru> I don't trust them blindly, I'd never put my credit card details on their systems [10:20:56] <hyc> not some background spy traffic... [10:21:40] <hyc> at $15/MB for data roaming, it's criminal for them to use the network without your permission [10:21:44] <mru> I do trust google to provide the service they say they do [10:21:54] <mru> that's steep [10:22:13] <mru> here I was moaning over vodafone raising it to £1/MB [10:22:17] <hyc> that's what T-Mobile charges if I use their sim outside the US [10:22:19] <mru> used to be 20p/MB [10:22:30] <mru> within europe at least [10:22:31] <iive> well, google can install and remove applications from phones... it happened already. [10:22:37] <mru> oh, shock! [10:22:51] <mru> with my old phone _I_ couldn't install or remove apps [10:23:01] <astrange> google is probably one of the safest places to give your cc to [10:23:03] <mru> so it's a net improvement [10:23:16] <Honoome> maximum betrayal, they removed _A MALWARE_ [10:23:31] <mru> astrange: I wouldn't just store it in google docs or something [10:23:37] <Honoome> who dares trying to take issue with malicious software they let through in the first place?! [10:24:09] <hyc> I suppose in some ways it's not about trust. sure, they provide a good service. But still, they shouldn't be making expensive connections to anything without first getting explicit user permission [10:24:21] <mru> astrange: I would of course not mind buying something from google using a cc [10:24:48] <mru> hyc: what if you turn off background data? [10:24:53] <hyc> that's still one of my big gripes with android. They have separate UIDs per app. they could easily implement uid-based iptables rules to control network access, but they don't. [10:25:27] <hyc> without other blocks in place, it always calls back to the home servers looking for firmware updates, every 12 hours and every time you turn the phone on [10:25:54] <hyc> even with all background/sync settings disabled [10:26:30] <hyc> s/phone on/data network on/ [10:26:59] <mru> but with data off, it doesn't, I hope... [10:27:06] <hyc> I would usually leave data roaming disabled, but if I needed to check email or use ssh I would toggle data roaming on [10:27:17] <hyc> and then see a burst of traffic before I had even done anything [10:27:39] * Honoome enabled data roaming when at FOSDEM... costed less than the sleepwell's wifi [10:27:57] <hyc> drop into shell, run netstat, see a bunch of traffic to various subnets registered to google.com [10:28:54] <hyc> so then I just put a bunch of route add net xx.xx.xx.xx gw 127.0.0.2 [10:28:58] <hyc> into a shell script [10:29:53] <hyc> dunno how much it cost me before I finally figured out what the phone was doing... [10:42:53] <DonDiego> how would i go about extracting all the commits done to subdir X into patches with git? [10:43:19] <mru> git format-patch since..until subdir [10:43:22] <mru> or something like that [10:45:49] * DonDiego tries [10:47:34] <DonDiego> git is not at all easy to get the hang of.. [10:48:05] <DonDiego> though i think i can see the valleys of glory behind the learning curve mountains.. [10:48:15] <elenril> meh, you're just too used to svn [10:48:56] <DonDiego> nope [10:49:00] <elenril> git is very easy once you read a few tutorials [10:49:05] <DonDiego> git is just weird in places [10:49:36] <DonDiego> and there are gazillions of commands, plus the lack of revision numbers makes some operations inherently difficult [10:49:46] <DonDiego> i want [10:50:02] <DonDiego> git format-patch r1 - HEAD subdir [10:50:13] <DonDiego> now i have to figure out how to specify those revisions.. [10:50:38] <DonDiego> both mercurial and bazaar use revision numbers alongside hashes without trouble.. [10:50:38] <twice11> hmm. git log goes down to beginning. [10:50:48] <twice11> I think you want "git log subdir" [10:50:57] <twice11> err, "git log -p subdir" [10:51:15] <twice11> -p shows diffs for all the displayed commits. [10:52:09] <DonDiego> that does not give me separate diffs for importing.. [10:52:23] <DonDiego> and it likely won't apply as a monolithic diff [10:52:38] <twice11> Ah, I get it. [10:53:30] <elenril> err how do you use revision number with nonlinear development again? [10:53:33] <elenril> +s [10:53:44] <twice11> The conceptual problem of git with your use case is that there is no continous stream of revisions. [10:54:20] <CIA-99> ffmpeg: mru * r24137 /trunk/libavcodec/ (Makefile libxvidff.c): Allow using libxvid RC without enabling encoding wrapper [10:54:20] <CIA-99> ffmpeg: mru * r24138 /trunk/libavcodec/ (libxvid_internal.h libxvidff.c): libxvid: add some const fixing a warning [10:54:24] <twice11> If a development model has a continous revision stream (for example order of commits on a master server), a tag like "r1" can be added on each commit to that tree. [10:54:27] <elenril> and i don't really see the difference between searching the log for a rev number vs searching the log for a hash [10:55:26] <mru> the one thing hashes lose are immediately obvious temporal ordering [10:56:10] <mru> but with non-linear development rev numbers make no sense [10:57:46] <DonDiego> i repeat: hg and bzr cope with no problem [10:58:01] <DonDiego> you can just add (local) number aliases to hashes [10:58:09] <DonDiego> no problem at all and a big usability win [10:58:10] * mru recommends "the emperor's new mind" by roger penrose [10:58:35] <mru> or for a lighter treatment, "a brief histor of time" by hawking [10:58:52] <DonDiego> i have a perfectly linear dev history here.. [10:59:16] <mru> the relativistic view of time and causality is a good analogue for branched development [10:59:35] <ohsix> it is indeed [10:59:42] <mru> bitkeeper tried to use rev numbers in a distributed system [10:59:46] <ohsix> your inertial frame or mine? [10:59:47] <mru> it got very, very confusing [11:00:25] <ohsix> if you want you can tag everything as you commit too, or at least between series of edits [11:01:42] <DonDiego> apparently none of you used either hg or bzr [11:01:51] <mru> I don't care what they do [11:01:59] <ohsix> git isn't hg or bzr [11:02:04] <DonDiego> it's very simple: each commit has an identifying hash [11:02:13] <DonDiego> each hash is given a local rev number [11:02:13] <mru> the fact is that in branched development, any kind of linear numbering is unstable [11:02:21] <mru> my r1234 isn't the same as your r1234 [11:02:29] <DonDiego> yes, but that's not a problem [11:02:41] <mru> what good does a volatile number like that do me? [11:02:44] <DonDiego> when i talk to you we can speak of hashes [11:02:46] <mru> and what about multiple branches? [11:02:54] <DonDiego> but locally i can use rev numbers, which is handy [11:03:12] <mru> but your r1234 today is not the same as your r1234 tomorrow [11:03:13] <elenril> just steal x264's script if you want rev number so much [11:03:18] <mru> time and space... all the same [11:03:27] <ohsix> i wouln'd be surprised if theres a widget you could plug in to add rev numbers [11:03:30] <elenril> most people apparrently don't need them [11:03:34] <DonDiego> my rev numbers are stable, no problem [11:03:41] <mru> elenril: the x264 script counts the revs one by one every time [11:03:41] <elenril> until you rebase [11:03:46] <mru> it clearly doesn't scale well [11:04:14] <mru> DonDiego: you still live in a classical world... [11:04:16] <mru> poor guy [11:04:19] <av500> why not use the atomic clock UTC time as rev number :) [11:04:34] <mru> av500: that doesn't exactly help [11:04:38] <DonDiego> you guys are not getting my point [11:04:42] <mru> sure we are [11:04:45] <mru> we're just not accepting it [11:04:49] <av500> there is no point :) [11:04:56] <mru> spoons are not pointy [11:04:57] <DonDiego> you are disputing that rev numbers can be useful [11:05:06] <DonDiego> which is nonsense [11:05:09] <mru> they are useful only in a strictly linear environment [11:05:11] <mru> git is not linear [11:05:19] <DonDiego> neither is hg nor bazaar [11:05:23] <DonDiego> the world is not a git [11:05:28] <mru> hashes are stable, sequence numbers are not [11:05:35] <DonDiego> i know [11:05:35] <ohsix> a rev number is less useful than a list of revisions & descriptions of them, no? [11:05:36] <av500> DonDiego: cutting git back to one central master repo, yes, it could have a rev number [11:05:45] <av500> back to svn [11:05:46] <DonDiego> NOOOOOOOOOOO [11:05:48] <mru> when the meaning of a rev number can change from one moment to the next, why should I use it? [11:05:58] <DonDiego> look guys [11:06:03] <DonDiego> I UNDERSTAND THAT [11:06:05] * av500 looks [11:06:08] <av500> ok [11:06:11] <ohsix> you could use it in your tree [11:06:15] <DonDiego> THIS IS NOOOOOOTTTT WHAT I WAS TALKING ABOUT [11:06:31] <av500> ohsix: I have a swing in my tree :) [11:06:38] <ohsix> if you're rolling patches from that instead of pushing that stuff would be left behind anyways [11:06:55] <DonDiego> the meaning of "what time is it?" changes from one second to the next, why do you ever pose the question? [11:07:07] <DonDiego> but *at that moment* it has uses [11:07:13] <DonDiego> funny isn't it [11:07:23] <DonDiego> you ask and every time you get a different answer [11:07:26] <av500> well, year 666 is always the same [11:07:27] <DonDiego> yet it is useful information [11:08:07] <Tjoppen> can't you use HEAD~1 and the like? [11:08:22] <mru> DonDiego: asking the time is only meaningful if you have a stable calendar [11:08:36] <Tjoppen> git rebase -i HEAD~100 for instance [11:08:37] <ohsix> even in a series of patches they're kind of silly, cherrypick the changes into a new branch and send patches from there [11:08:53] <av500> mru: guess why my Xmas is 13 days late :) [11:08:55] <DonDiego> nope [11:09:04] <DonDiego> it is useful if you have a stable point of referenc [11:09:05] <DonDiego> e [11:09:15] <mru> which you don't [11:09:23] <DonDiego> which i have for long enough moments in time for rev numbers to be useful [11:09:24] <mru> where is the centre of the universe? [11:09:32] <mru> answer: right here [11:09:43] <DonDiego> the center of the universe is wherever i define it [11:09:51] <DonDiego> it's like coordinate systems in physics [11:09:53] <av500> no, it is wherever we VOTE it is! [11:09:55] <av500> dammit [11:09:57] <mru> every point is the centre when viewed from that point [11:09:59] <DonDiego> physicists change them all the time [11:10:03] <DonDiego> and THEN use them [11:10:12] <ohsix> um [11:10:19] <DonDiego> you tell me coordinate systems have no uses because they are arbitrary [11:10:24] <DonDiego> *you* are missing the point [11:10:28] <ohsix> thats not a good digression in that particular discussion [11:10:33] * mru maps the ffmpeg commit history in spherical coordinates [11:10:50] <av500> git -> relativity discussion -> .... -> anime [11:10:58] <mru> profit? [11:10:58] <elenril> DonDiego: so what's the problem, nobody's stopping you from using rev numbers [11:11:11] <av500> just tag each commit with N+1 [11:11:17] <elenril> yeah, this [11:11:25] <av500> in post commit hook or so [11:11:36] <av500> that could be useful on e.g. ffmpeg master git [11:11:42] <mru> then create some branches and watch all hell break loose [11:12:00] <mru> that said, I'm intending to keep the master repo strictly linear [11:12:08] <ohsix> at the moment he isn't doing it the easy way with a branch anyways [11:12:10] <mru> so tagging each revision there could be done [11:12:13] <av500> yes [11:12:22] <DonDiego> ohsix: what would that way be? [11:12:29] <av500> and ppl can do ffgit_fetch_rev xyz [11:13:06] <ohsix> new branch, pick revs from log, possibly with browser tool like giggle; then format patch there [11:13:52] <elenril> how do i find a host on lan if i don't know its ip address [11:13:59] <mru> use dns [11:14:03] <av500> ask 8.8.8.8 [11:14:17] <ohsix> ping 255.255.255.255 & arp -a [11:14:17] <elenril> it's a dumb ap [11:14:38] <mru> that only works if it responds to bcast pings [11:14:54] <mru> nmap with the right flags should find it [11:15:07] <ohsix> smurf u [11:15:08] <kshishkov> elenril: it's _l_an, just follow the cable [11:15:27] <mru> kshishkov: could be wireless [11:15:37] <elenril> mru: i know, i did it once [11:15:41] <elenril> just forgot what flags [11:16:08] <mru> nmap -PN -T5 192.168.0.0/24 [11:16:14] <kshishkov> mru: it's called wlan then and you can use sniffer then [11:16:23] <mru> adjust for your local network address [11:16:38] <av500> kshishkov: or metal plate in back of head [11:22:10] <DonDiego> \o/ [11:22:19] <DonDiego> i managed to do it with the help of sed... [11:22:43] <av500> my favorite obj file manipulator? [11:22:46] <mru> DonDiego: http://xkcd.com/763/ [11:23:16] <elenril> managed to do what? [11:23:49] <mru> elenril: see link [11:24:00] <DonDiego> that reminds me of the day i ventured to teach my mom how to play mp3s on her computer [11:24:16] <av500> with sed? [11:24:32] <mru> hmm, is it possible to write a dct in sed? [11:24:33] <twnqx> someone did that? [11:24:35] <DonDiego> when she started the endeavour by opening word (it has a file picker after all) i immediately gave up [11:24:36] <av500> cat x.mp4 | sed -e s.... > /dev/dsp [11:24:47] <twnqx> i started a player in awk once... [11:24:51] <mru> maybe the sedtris girl can do it [11:25:08] <av500> i guess sed it turning complete... [11:25:20] <av500> is [11:25:25] <twnqx> tuning? turing? [11:25:35] <av500> turnip [11:25:52] <kshishkov> twnqx: you can play Tetris there with rotating elements [11:26:10] <twnqx> i know sedtris... [11:26:54] <twice11> if we may put one or two a strategic xxd's in the mp4 to dev/dsp pipe, it should be possible... [12:03:37] <lu_zero> $good $morning [12:03:46] <lu_zero> for any improper definition of good and morning [12:11:47] <CIA-99> ffmpeg: janne * r24139 /trunk/libavformat/nutenc.c: [12:11:48] <CIA-99> ffmpeg: rename get_length to ff_get_v_length and put_v to ff_put_v [12:11:48] <CIA-99> ffmpeg: patch by Michael Chinen < mchinen gmail > [12:15:23] <CIA-99> ffmpeg: janne * r24140 /trunk/libavformat/ (aviobuf.c nutenc.c internal.h): [12:15:23] <CIA-99> ffmpeg: move ff_get_v_length and ff_put_v from nutenc.c to internal.h/aviobuf.c [12:15:23] <CIA-99> ffmpeg: patch by Micheal Chinen < mchinen gmail > [12:16:47] <Tjoppen> grr.. either WMP sucks ass, or mainconcept does, or both [12:16:54] <kshishkov> both [12:17:20] <Tjoppen> I creave a working .vc1 file using their sdk, remux that to wmv. plays fine in ffplay and vlc, but of course not in wmp [12:17:29] <mru> mainconcept is a frankencorp [12:17:46] <mru> the elecard guys are smart [12:18:05] <mru> the german part not so much [12:18:10] <kshishkov> mru: smart - yes, but they are Russians [12:18:10] <Tjoppen> their api is even more ass. took me the better part of two days to figure out how to get the extradata out. doesn't even seem to be possible for the h264 encoder [12:18:29] <av500> Tjoppen: the lavf asf muxer produces files that wmp refuses to play [12:18:35] <mru> kshishkov: peter gubanov is a generally nice guy [12:18:39] <mru> even though he's russian [12:18:56] <Tjoppen> av500: that's.. interesting. I tried .avi though, which didn't work either [12:18:58] * thresh ahems [12:19:12] <mru> thresh: just checking if you're awake [12:19:28] <thresh> I was on a meeting playing 'bullshit bingo' [12:19:39] <thresh> won three times, then got bored [12:19:53] <Honoome> rotfl [12:22:46] * Honoome found a bug in ruby ... [12:22:57] <mru> hardly surprising [12:23:47] <kshishkov> Honoome: besides ruby itself? [12:24:21] <lu_zero> kshishkov: it was a a pythonism [12:24:50] <Honoome> now of course the problem was that I had no connectivity from within the container to the rest of the world (stupid modem) [12:25:12] <Honoome> but the fact that instead of telling me "I cannot connect", it exploded for an "invalid method" doesn't really float my boat [12:25:51] <av500> container? [12:26:03] <av500> you are trying to leave europe illegaly? [12:27:02] <kierank> has this been posted yet: http://varnish-cache.org/docs/phk/autocrap/ [12:27:25] <av500> yes [12:27:44] <av500> [11:44] <mru> http://varnish-cache.org/docs/phk/autocrap/ [12:27:46] <Honoome> av500: lxc: linux-containers [12:27:56] <mru> some discussion: http://news.ycombinator.com/item?id=1499738 [12:28:06] <Honoome> I'll reply with http://www.flameeyes.eu/autotools-mythbuster/ :P [12:28:19] <kshishkov> Honoome: sounds like Java 2 EE - e.g. not the thing I'd like to touch [12:28:35] <av500> Honoome: I tried to read that once.... [12:29:23] <kshishkov> tl;dr [12:29:30] <mru> no amount of mythbusting can alter the hard fact that every version of each autotool is incompatible with every other version and often with itself [12:29:57] <Honoome> mru: true.. that can only be fixed with hard-bashing the authors in the head with a clue-by-four [12:30:17] <Honoome> otoh people who diss autotools end up suggesting cmake and scons.. both of which have the same or worse problems [12:30:45] <wbs> ffmpeg configure has to be the best build system I've seen this far [12:30:50] <av500> I diss autotools for checking whether I have a fortran compiler [12:30:52] <DonDiego> i'll go on record to say that Honoome's autotools-mythbuster is excellent documentation [12:31:00] <DonDiego> it helped me a lot at work [12:31:02] <av500> so its not a mythbuster [12:31:26] <wbs> if it was packaged for easy reuse with other projects, it would be even better. :-) [12:31:34] <av500> ffconf [12:31:37] <DonDiego> Honoome: since you're not into beer, remind me to buy you dinner next time we meet :) [12:31:49] <av500> i'll drink the beer [12:31:58] <spaam> DonDiego: date with Honoome ? :) [12:32:15] <Honoome> gha now the situation is becoming embarassing :P [12:32:15] <ohsix> if only projects wouldn't resign themselves to dead eras when they play around with the implementation language and the build system [12:32:52] <Honoome> av500: "Autotools Mythbuster" was the title I used for a few blog posts bashing broken autotools... I reused the name for the guide [12:33:17] <Honoome> to be honest, it's quite lacunous as it is, but I work on it on spare tim [12:33:24] <twice11> av500: autotools checks for fortran if you include libtool in your build process. You can limit the languages libtool should support and remove the fortran test by that. [12:33:35] <av500> me? why me? [12:33:40] <Honoome> twice11: done already on lt2 [12:33:55] <Honoome> twice11: libtool-2 moved to NOT test for C++ or Fortran by default [12:34:02] <av500> all I do is to untar random.tgz and do ./configure [12:34:18] <Honoome> actually broke a few projects because they relied on the C++ compiler to be tested for by libtool [12:34:31] <twice11> Sometimes even these bloat-o-matic projects seem to do something sensible... [12:34:48] <Honoome> twice11: that's why I went with the name "Mythbuster" [12:35:05] <Honoome> because a lot of their bad name is for veeeery old and crappy stuff [12:35:22] <twice11> OTOH, if AC_PROG_CXX is used, it seems sensible to assume that I want C++... [12:35:38] <Honoome> or because the writers of configure.ac or Makefile.am used something that worked only out of sheer luck [12:36:10] <twice11> In my oppinion, all the automatic configuring scripts suck the one or the other way. [12:36:12] <Honoome> *cough* kde *cough* [12:36:23] * kshishkov checks whether he has Fortran 77 compiler to read that document by Honoome [12:36:42] <Honoome> just to say, autoconf 2.64 removed an internal, never-documented, now-unused macro... [12:36:50] <twice11> Didn't KDE switch to cmake because they were unhappy with auto*? [12:36:53] <Honoome> 2.65 had to add it back _because it totally fucked up the kde 3 build system that releid on that_ [12:37:09] <Honoome> twice11: they switched because they had no clue about auto* and made the worst mess with it I have seen in a very long time [12:37:38] <mru> isn't it rather telling when _nobody_ is able to use something properly? [12:37:43] <ohsix> no clue is a running theme \m/ [12:37:56] <Honoome> mru: yes, that the documentation for auto* sucks [12:38:07] <Honoome> that the autobook has been left alone for so many years that it's nowhere near covering what it should [12:38:09] <mru> when using the tool takes more skill and effort than doing without it, one should reconsider the choice of tools [12:38:15] <Honoome> that the official info pages are badly written [12:38:30] <mru> and they keep changing the bloody syntax every version [12:38:34] <Honoome> I have no idea about the nostarch press book sincerely, I haven't read that yet, I started a-m before it was published [12:38:42] <mru> anyone ever tried to build newlib? [12:38:48] <mru> it has the worst autohell I've ever seen [12:38:56] <Honoome> mru: newlib, gcc and binutils are bad.. not as bad as kde3, but bad [12:39:03] <mru> it can't work with a single autohell version [12:39:28] <mru> you have to fuck around and build some scripts with one version, some others with another, then rebuild the first ones with a third [12:39:32] <mru> or something like that [12:40:17] <ohsix> i crossed for arm w/newlib on ubunto; worked fine [12:40:42] <mru> I never managed to get the autohell to run even once [12:41:24] <ohsix> they have a wrapper that people can request given versions with [12:41:36] <mru> so does gentoo [12:41:40] <Honoome> I'm not saying that autotools are properly done [12:41:47] <mru> the problem with newlib is that _no single version_ works [12:42:07] <Honoome> but I still have to see something that solves all the problems without adding worse [12:42:30] <Honoome> beside custom-writing the scripts... and even that is not going to solve problems without adding worse unles who writes it has a clue [12:42:40] <Honoome> and trust me, that would limit the number of people A LOT [12:42:43] <mru> the solution is in not attempting to solve everything [12:42:54] <ohsix> all i had is 2.13, it worked [12:43:23] <Honoome> mru: *shrug* to me the solution is solving the worst problem with autotools: documentation that is crappy [12:43:39] <mru> you know my solution [12:44:10] <Honoome> you can afford to write your own build system.. most people don't.. [12:44:10] <mru> use a custom build system solving exactly what it needs to solve for each app [12:44:14] <Honoome> or at least they should learn NOT to... [12:45:04] <ohsix> if i wanted to use host triplets and automatic replacement stuff i wouldn't write my own D: [12:45:32] <ohsix> you end up supporting each target instead of just making large swaths of them look same enough [12:45:40] <mru> I've always wondered how something with _four_ parts can be called a _triplet_ [12:45:56] <mru> and it's all so gnu-centric anyway [12:45:59] <ohsix> one part is optional [12:46:24] <ohsix> but its replaced by unknown if it isn't there, huhuhuhu [12:46:36] <mru> what's latin for 3.5? [12:47:21] <Honoome> ohsix: uh? no [12:47:34] <Honoome> it's only where gnu is an option that it's four [12:47:38] <ohsix> the name is grandfathered from when there was only 3 or something; like gecos [12:48:10] <Honoome> x86_64-unknown-linux-gnu x86_64-unknown-linux-uclibc x86_64-unknown-freebsd8.2 x86_64-unknown-kfreebsd-gnu [12:48:14] <Honoome> see the pattern? [12:48:22] <ohsix> that sounds squishy, is there an rfc for it [12:48:23] <mru> I see the pattern [12:48:29] <mru> but it only works with gnu tools [12:55:57] <lu_zero> mru: I had to play with newlib [12:56:04] <lu_zero> and binutils was worse [12:56:47] <mru> binutils, gcc, newlib, and glibc are all horrible [12:56:55] <mru> each in their own twisted way [12:57:14] <lu_zero> still I'm a _tad_ afraid about llvm [12:58:06] <lu_zero> btw ffconf might be interesting [13:21:14] <lu_zero> hi BBB [13:21:20] <BBB> hello [13:50:12] <mru> Vitor1001: ping [13:50:27] <Vitor1001> pong [13:50:55] <mru> since you're working on tests, do you have permissions to put the samples in place? [13:53:10] <Vitor1001> mru: Yes, but since mike worked hard to keep fate-suite/ small, I'm not cluttering it with samples for tests not yet ok-ed. [13:54:02] <mru> just checking if there's anything else you need to make your work smooth [13:54:48] <Vitor1001> thanks [14:07:44] <DonDiego> how do i set up global ignore patterns with git? [14:07:53] <av500> .gitignore [14:07:54] <DonDiego> the manual is not helpful.. [14:08:01] <DonDiego> *global*, not local [14:08:13] <av500> for every git in the world? [14:08:18] <elenril> what do you mean by global? [14:08:32] <DonDiego> for every checkout/repo that my git ever touches [14:08:52] <mru> why would you want to do that? [14:09:08] <DonDiego> i was just going to say you would now tell me i don't need that feature.. [14:09:11] <elenril> Patterns read from $GIT_DIR/info/exclude. [14:09:15] <DonDiego> git fanboys.. [14:09:17] <elenril> Patterns read from the file specified by the configuration variable core.excludesfile. [14:09:21] <elenril> ^tfm [14:09:30] <DonDiego> been there, done that [14:09:50] <av500> DonDiego: gitaards [14:10:17] <DonDiego> dbiurrun@spielwiese ~ $ cat .gitconfig [14:10:18] <DonDiego> [core] [14:10:18] <DonDiego> excludesfile = ~/.gitignore [14:10:18] <DonDiego> dbiurrun@spielwiese ~ $ cat .gitignore [14:10:18] <DonDiego> *.o [14:10:52] <av500> err [14:10:56] <DonDiego> dbiurrun@spielwiese ~/src/LIBRARYUPDATEINDICATOR $ git status [14:10:56] <DonDiego> # On branch master [14:10:57] <DonDiego> # Untracked files: [14:10:57] <DonDiego> # (use "git add <file>..." to include in what will be committed) [14:10:57] <DonDiego> # [14:10:57] <DonDiego> # client/client.o [14:11:05] <DonDiego> that didn't work all that well... [14:11:18] <cartman> DonDiego: You might need to replace ~ with absolute path [14:12:22] <DonDiego> core.excludesfile [14:12:22] <DonDiego> In addition to .gitignore (per-directory) and .git/info/exclude, git looks into this file for patterns of files which are not meant to be tracked. "~/" is expanded to the value of $HOME and "~user/" to the specified user's home directory. See gitignore(5). [14:12:31] <DonDiego> this is from git-config(5) [14:12:39] <cartman> ~ didn't work for me [14:12:43] <cartman> just saying... [14:12:44] <DonDiego> gitards indeed.. [14:13:03] <mru> DonDiego must be consciously _trying_ to make git hard [14:13:58] <DonDiego> full path works, the manual is lying [14:14:07] <elenril> send a bugreport? [14:14:29] <mru> maybe the expansion is supposed to be done by some system function that's broken on your machine [14:14:32] <mru> you run debian, right? [14:15:17] <cartman> DonDiego: didn't work on MacOSX either [14:15:18] <cartman> git bug [14:15:37] <DonDiego> this is a centos machine at work in fact [14:15:44] <mru> lol centos [14:16:11] <Tjoppen> <vacation> [14:16:40] <mru> all the crap of redhat without the paid entirprisey stuff [14:16:46] <mru> absolutely no reason to use [14:16:54] <cartman> if you can't expand ~, well... [14:17:30] <mru> whoa there, where the heck did cartman come from? [14:17:36] <cartman> *magic* [14:17:40] <mru> cartman: you haven't been here for an eternity [14:17:45] <cartman> mru: true [14:17:48] <mru> welcome back [14:17:51] <cartman> turns out that I am still alive [14:17:55] <cartman> thank you mru ! [14:27:54] <DonDiego> yo gitards! [14:28:03] <DonDiego> git-svn is failing to remove directories here.. [14:28:24] <mru> never seen that [14:29:51] <lu_zero> DonDiego: it hates you [14:30:06] * mru suspects the feeling is mutual [14:30:27] <lu_zero> it feels your fear and behaves accordingly [14:30:48] * lu_zero would expect to read the news about DonDiego being mauled by git [14:31:09] <lu_zero> jokes aside, what were you trying to do? [14:31:59] <elenril> >git svn failing [14:32:02] <elenril> sounds about right [14:37:24] <markuman> i've got a question to the "missing picture in access unit" message. does parse_nal_units search for a pair of frame? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073538.html [15:13:41] <BBB> mru: libavfi depend on libavco ok with you? sounds about right to me to be honest [15:14:16] <mru> I think another lib is an execise in work creation [15:15:04] <twice11> libavfilter and libavcodec both alreasy exist, or did I get something wrong? [15:20:51] <siretart> TBH, I wouldn't mind too much if libavutil was merged back into libavcodec. but I guess there were good reasons for splitting lavu off. [15:21:21] <mru> we had our reasons [15:21:30] <mru> I don't quite remember what they were [15:22:53] <av500> were colours involved? [15:24:11] <mru> a full spectrum, I'm sure [15:24:29] <twice11> In america, only colors could have been involved. Better ask for bikesheds, I hope they are spelled the same everywhere. [15:25:09] <av500> twice11: fringe usage of english dialects is irrelevant :) [15:25:38] <av500> but, let's not argue, we can vote over it.... [15:25:48] <mru> reminds me of the time I called windows a "fringe os" [15:25:55] <mru> apparently that annoyed some people [15:26:55] <av500> the truth is always annoying to some [15:31:23] <BBB> mru: I share your opinion, I understand it was split off, I respect adn appreciate it, but I wouldn't mind at all if it was merged back [15:31:52] <BBB> I don't think there's a wide demand for a "general utility lib", where "general utility" is defined as "random stuff used in libavcodec/libavformat" [15:32:14] <BBB> which is pretty much libavutil [15:32:47] <mru> it's reasonable to avoid libav* depending the huge libavcodec unless necessary [15:32:59] <mru> that's pretty much why lavu was created [15:33:27] <mru> it wasn't even michael's idea [15:34:35] <siretart> that would make sense if there was some (important) lib that depends on lavu but not on lavc. what's that? [15:34:45] <av500> lavf? [15:34:49] <mru> libsws [15:35:01] <mru> lavfi [15:35:01] <av500> no, lavf depedns on lavc [15:35:09] <av500> important? [15:35:13] <mru> libpostproc [15:35:25] <Honoome> libxine depends on libavutil only [15:35:36] <siretart> ok [15:35:42] <mru> important? [15:35:43] <Honoome> [the ffmpleg plugin uses libavutil, but the main lib in 1.2 branch uses libavutil "standalone"] [15:35:48] * av500 discovers libpostproc in his svn checkout [15:36:09] <Vitor1001> mru: What do you think of this: http://ffmpeg.pastebin.com/vbYQaLTi ? [15:36:26] <siretart> Honoome: what's the status of 1.2 branch? is it eventually going to get released? [15:36:37] <Vitor1001> mru: There is a very simple way of getting MAXDIFF == 1: outputting 0 samples. [15:36:46] <mru> I noticed [15:40:27] <Vitor1001> mru: BTW, even without your patches, I'm getting on your PPC box: [15:40:29] <Vitor1001> TEST FATE twinvq [15:40:29] <Vitor1001> Could not open input files. [15:40:30] <Vitor1001> /home/vitor/ffmpeg/tests/fate-run.sh: line 21: [: -gt: unary operator expected [15:40:35] <Vitor1001> s/your patches/my patch/ [15:41:18] <Honoome> siretart: you got to ask ds for that :/ I really am totally out of the loop [15:42:50] <siretart> same to me [15:44:17] <mru> Vitor1001: do you have the ref file? [15:44:47] <Vitor1001> No, it is a oneoff [15:45:00] <mru> where are you pointing SAMPLES? [15:45:16] <Vitor1001> Oh, sorry, my bad. [15:45:49] <Vitor1001> I was pointing to samples, but no the good directory. [16:06:46] <CIA-99> ffmpeg: mru * r24141 /trunk/libavcodec/resample2.c: resample: check memory allocations in av_resample_init() [16:06:46] <CIA-99> ffmpeg: mru * r24142 /trunk/libavcodec/resample2.c: resample: replace VLA with malloc/free [16:06:49] <CIA-99> ffmpeg: mru * r24143 /trunk/tests/ (13 files in 2 dirs): [16:06:49] <CIA-99> ffmpeg: tiny_psnr: skip wav headers on input files [16:06:49] <CIA-99> ffmpeg: The byte count printed excludes the header, and offsets are applied [16:06:49] <CIA-99> ffmpeg: after the the headers are skipped. [16:06:50] <CIA-99> ffmpeg: Reference files updated to reflect new output. Some stddev/psnr values [16:06:50] <CIA-99> ffmpeg: have changed slightly due to headers no longer being compared. [17:11:08] <CIA-99> ffmpeg: victor * r24144 /trunk/libavcodec/libxvidff.c: Current Cygwin has mkstemp(). [17:20:37] <CIA-99> ffmpeg: vitor * r24145 /trunk/tests/fate2.mak: SIPR tests for "make fate2" [17:26:22] <mru> Vitor1001: don't forget to upload the ref files to mphq [17:27:41] <Vitor1001> mru: Already done [17:29:04] <Vitor1001> bbl [18:12:08] <dgt84> The mailing list flamewar is heating up... [18:12:35] <dgt84> This is getting a bit ridiculous [18:14:01] <mru> you say? [18:15:10] * mru wonders what he did to anger baptiste so [18:15:28] <mru> I was always defending him when he and michael were fighting [18:15:40] <mru> I'm starting to think that was a mistake [18:15:49] <jai> regarding libavutil, it would have been awesome if the bitstream read/write stuff was in libavutil [18:16:23] <mru> there is one technical reason for having it in lavc: it's faster there [18:16:50] <mru> function calls across shared libs are slower than intra-lib calls [18:17:20] <mru> I agree otherwise [18:17:25] <Compn> mru : does baptiste still harbor any anger because of the changes he has to keep forked ? [18:17:34] * Compn rememebers someone is upset and has his own fork [18:17:37] <mru> none of that was my fault [18:17:47] <mru> as I said, I WAS ON HIS SIDE [18:19:23] <jai> mru: ah, didnt think about that [18:19:29] <jai> thx for the explanation [18:19:39] <jai> right now i just copypaste parts of it [18:23:06] <neerfri> hi guys ! I get no answer in the fmpeg channel, mind if I throw in a question ? [18:23:21] <mru> why would we answer here? [18:23:27] <neerfri> avlib programming related [18:23:52] <neerfri> have been banging my head on this for couple a days... [18:24:03] * mru hands neerfri a hammer [18:24:21] <neerfri> all is fine, but av_encode_video always returns 0 [18:24:47] <neerfri> and audio is working fine, but when using interleaved writing nothing gets written... [18:25:29] <neerfri> mru: because you have a heart of gold ? :-) [18:26:03] <mru> not anymore, I sold it on ebay [18:26:08] <neerfri> :-D [18:26:45] <neerfri> know how much is it for a golden tooth ? [18:27:12] <mru> quite some pain at the dentist I'd imagine [18:27:36] <kshishkov> put some anesthesy on your wallet first [18:28:13] <neerfri> so, how about helping me with the root treatment... ? I'm so sure it's tiny... [18:28:32] <neerfri> I just lost every creativity I might have had trying to fight this... [18:28:58] <neerfri> I'm out of ideas, have been comparing my code to ffmpeg.c's code for like a whole day... [18:30:01] <lu_zero> neerfri: try to simplify/hardwire ffmpeg.c till you get it doing what you want [18:30:15] <neerfri> I sort of did. [18:30:16] <kshishkov> or look at output_example.c first [18:30:23] <neerfri> I have a 97% done app [18:30:30] * lu_zero assumed that was done already [18:30:40] <neerfri> I'm way after output_example.c... :-) [18:30:41] <mru> neerfri: here, take these: %%% [18:30:48] <neerfri> :-D [18:31:46] <neerfri> mru: you're shooting them in chains are you.... :-) [18:51:51] <mru> can someone please kill baptiste for me? [18:52:23] <kshishkov> why? [18:52:31] <mru> he's being a total jerk [18:52:42] <kshishkov> just take a vacation off the ffmpeg-devel ML [18:52:49] <hjb> what's new? [18:53:07] <hjb> I'm waiting for baptiste to start answering questions with monosyllabic grunts [18:57:43] <mru> mini-poll: have I said anything offensive to baptiste in the last few days other than maybe in the last hour? [19:02:04] <Dark_Shikari> 6: stop with the polls [19:02:48] <mru> I was asking for people's opinion [19:02:59] <mru> not asking for a vote over facts [19:03:45] <mru> I honestly don't understand how baptiste can claim to be offended by something I said [19:04:03] <mru> none of the "discussions" have been about his areas of code [19:04:21] <mru> he has barely participated in them [19:04:36] <mru> I think he said something silly in one of the voting threads, that's all [19:04:38] <hjb> I'd say calling somebody out in IRC would probably offend them [19:04:58] <mru> hjb: what did I do? [19:05:29] <hjb> I don't want to get involved, man [19:05:49] <hjb> (so I probably should have left out the snarky comment in the first place) [19:05:52] <hjb> my bad [19:05:52] <mru> just tell me what I said that was offensive [19:05:57] <mru> seriously, I want to know [19:05:58] <hjb> no farkin clue [19:06:12] <mru> so don't fuckin' go implying I did then [19:06:22] <jai> mru: maybe he took offense at the "jealousy" part [19:06:37] <mru> he claims to have been offended prior to that [19:06:49] <jai> ah [19:06:54] * jai shrugs :) [19:06:57] <mru> and he says I'm generally a bad person or something to that effect [19:08:19] <mru> oh, I did reply in slightly sarcastic tone when he declared my and Dark_Shikari's "votes" void [19:09:51] <markuman> i've got a question to the "missing picture in access unit" message. does parse_nal_units search for a pair of frame? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073538.html [19:27:57] <CIA-99> ffmpeg: mru * r24146 /trunk/tests/tiny_psnr.c: tiny_psnr: use abs() [19:28:26] <Dark_Shikari> I love the argument over the hypothetical system without abs [19:30:21] <mru> there is no argument [19:30:30] <mru> funman found one though [19:30:34] <Dark_Shikari> lol [19:30:52] <mru> on some particular version of hp-ux, if you include math.h before stdlib.h, you get no abs() [19:34:00] <mru> but we applied the patch with abs() [19:34:06] <mru> and everybody is happy [20:03:10] <_av500_> mru: i dont think it makes sense to start digging who said what when [20:03:26] <_av500_> over irc and the ML [20:04:00] <mru> I'm just curious whether anyone else interpreted anything I said as offensive [20:04:32] <mru> I'm not afraid to offend, but I want to choose when I do it [20:22:17] <lu_zero> BBB: I broke rtpdec_h264 =P [20:25:37] <lu_zero> actually av_base64_decode seems broken [20:25:48] <capitao_azeitona> Hi people! someone here knows how to install ffmpeg-php ? [20:26:30] <mru> no [20:44:15] <peloverde> Is anyone wanting on (specific) things from me? I've had a hectic week but think I'm al caught up [20:45:05] * elenril wants aacenc to not suck ;) [20:45:17] <mru> peloverde: what is the best way to go about testing aacdec? [20:46:05] <peloverde> An off-by-one or SNR based approach to a refernce rendering is the only way I can think of [20:46:30] <mru> well, we have an off-by-one testing facility now [20:46:38] <peloverde> we do? [20:46:42] <mru> since yesterday [20:48:10] <_av500_> janneg: quick, upload our BBB: http://youtube-global.blogspot.com/2010/07/whats-bigger-than-1080p-4k-video… [20:48:32] <peloverde> ok, I will look at vqf and propse something based on that [20:49:06] <lu_zero> wonderful [20:49:25] * lu_zero found 3 bugs with a single test... [20:49:32] <mru> that's efficiency [20:49:38] <mru> can you fix them with a single patch? [20:50:01] <peloverde> I think for now I will try to pick a subset of streams taht cover a wide range of bitstream features [20:50:26] <mru> yeah, do that [20:50:31] <lu_zero> mru: 2 bugs are in ffmpeg one in feng [20:57:17] <capitao_azeitona> someone here uses ffmpeg-php [20:57:18] <capitao_azeitona> ? [20:57:24] <mru> no [20:57:40] <capitao_azeitona> thanks.. [21:00:21] * lu_zero is puzzled [21:00:28] <lu_zero> idx>=FF_ARRAY_ELEMS(map2) [21:00:38] <lu_zero> idx being (unsigned)-3 [21:01:28] <lu_zero> how's possible it's valued false? [21:02:25] <lu_zero> FF_ARRAY_ELEMS(map2) should be 80 [21:03:24] <BBB> lu_zero: fix it ;) [21:05:41] <lu_zero> BBB: done [21:05:56] <BBB> h264rtp? [21:05:58] <BBB> that was quick [21:18:45] <Dark_Shikari> BBB: got the normal loopfilter done yet? =p [21:24:55] <mt> hi all [21:28:41] <lu_zero> BBB: pretty much [21:29:05] <lu_zero> once I managed to figure out why print index-something didn't do what I expected in gdb... [21:29:53] <mt> I'm working on converting wma pro to fixed point (for rockbox), I'm almost done, but run_level_decode seems to be producing an error (Not 100% sure though, still investigating), is there something obviously wrong with this : http://www.pastie.org/1036828 ? (I'm saving the samples in Q.16 format and the level table is just the same as the float one but of type int32_t) [21:29:57] <lu_zero> now I should find enough will to reread the h264 packetizer in feng and find out what's wrong with it for non avc1 packets [21:33:49] <lu_zero> apparently I didn't get the startcode correctly -_- [21:38:03] <mru> mt: don't you know the val = abs^sign - sign trick? [21:39:01] <mru> mt: I would suggest some good old-fashioned printf debugging [21:39:16] <mru> print the values read in both float and int versions [21:39:17] <mru> compare [21:40:30] <BBB> Dark_Shikari: running it in a debugger, there's a (few?) bug(s) that make it not bitexact, working on it [21:42:10] <mt> mru: Did so but couldn't find differences, at least not in the first few samples. Will try to go further. Thanks. [21:42:36] <mru> that's how I'd do it... [21:42:54] <mru> if the values are the same, the problem must be elsewhere [21:45:28] <Dark_Shikari> I fucking love xiph. It's 2010 and they're telling people to do VFR by adding null packets. [21:45:44] <mru> lol [21:45:50] <mru> in what container? [21:45:52] <Dark_Shikari> Ogg. [21:45:59] <mru> wtf [21:46:02] <Dark_Shikari> The Ogg Theora mapping is CFR-only [21:46:02] <mru> ogg has timestamps [21:46:05] <mru> oh [21:46:07] <Dark_Shikari> I AM NOT MAKING THIS UP [21:46:09] <mru> *facepalm* [21:46:20] <Dark_Shikari> They are seriously telling people to implement it with null packets [21:46:24] <Dark_Shikari> of course.... [21:46:26] <Dark_Shikari> the null packets break [21:46:30] <Dark_Shikari> MPC (so probably ffmpeg) [21:46:31] <Dark_Shikari> and VLC [21:46:46] <Dark_Shikari> so two separate independent muxers are both broken because of them [21:46:50] <Dark_Shikari> er, demuxers [21:47:02] <mru> what do the null packets look like? [21:47:12] <Dark_Shikari> I think they're 0 byte packets [21:47:15] <Dark_Shikari> Just empty [21:47:28] <mru> packets or pages? [21:47:31] <Dark_Shikari> Dunno [21:47:42] <Dark_Shikari> I don't know how libtheora does it. [21:48:04] <mru> a null _packet_ in ogg would be simply a 0 in the roman-style packet size list [21:48:44] <mru> don't know if that's allowed by the spec [21:49:24] <Yuvi> yes, that's how it's done, for dropped frames too [21:49:26] <Dark_Shikari> they say whatever they're doing is allowed [21:49:56] <Yuvi> ffmpeg works since it drops size 0 packets [21:50:09] <mru> how does our demuxer handle them? [21:50:13] <mru> I can't remember [21:50:23] <Yuvi> returns them, then they're discarded in utils.c iirc [21:50:25] <mru> I don't remember thinking about it [21:50:42] <mru> the way it's made, it ought to simply return them [21:51:27] <Yuvi> I've been meaning to to drop them in the demuxer (unless whatever flag is related to them is set) but that means you have to figure out the timestamps of the actual packets [21:52:00] <mru> if it works, I wouldn't bother [21:52:35] <mru> anyone stupid enough to mux like that deserves whatever tiny performance hit it might give [21:53:00] <Yuvi> one fun bit is that it's the same way they use to drop frames, and one complaint against ffmpeg is that we don't create duplicate frames for that case [21:53:15] <mru> wtf [21:53:16] <Yuvi> even though it's impossible to determine whether the 0 byte packet means VFR or dropped frame [21:53:32] <Dark_Shikari> it's because they don't believe in vfr [21:53:33] <mru> for display purposes there is no difference [21:53:36] <Dark_Shikari> so obviously it means a dropped frame [21:57:11] <Yuvi> mru: yep, and at the same time they complain about players that don't drop frames for the vfr case (everything that doesn't use lavf I believe ;) [22:00:38] <mru> geez, he's still cranky over those unprototyped functions [22:00:46] <Compn> oh carl meant denial of service, not dos dos [22:00:47] <Compn> ;\ [23:17:10] <peloverde> how do I set SAMPLES for fate? [23:18:01] <mru> configure --samples=/path/to/fate-suite [23:18:08] <mru> or make SAMPLES=/path/... [23:18:30] <peloverde> thanks [23:18:38] <mru> anyone want to make a few bucks telling someone how to use ffmpeg? [23:18:51] <mru> encoding for iphone [23:18:53] <Dark_Shikari> sure [23:19:49] <mru> they probably just need someone to tell them what settings to use [23:19:53] <Dark_Shikari> that's fine with me [23:19:59] <mru> ok, I'll forward it [23:26:56] <peloverde> mru: The .pcm files are interleaved? [23:27:14] <mru> they are whatever ffmpeg outputs [23:27:22] <mru> so yes, interleaved [23:27:23] <CIA-99> ffmpeg: mru * r24147 /trunk/tests/fate-run.sh: fate: exit with error immediately if test command fails [23:27:25] <CIA-99> ffmpeg: mru * r24148 /trunk/tests/tiny_psnr.c: tiny_psnr: check fread() return values [23:27:26] <CIA-99> ffmpeg: mru * r24149 /trunk/tests/tiny_psnr.c: tiny_psnr: change error exit code from -1 to 1 [23:36:56] <CIA-99> ffmpeg: mru * r24150 /trunk/tests/fate-run.sh: fate: delete output files from successful tests [23:38:07] <CIA-99> ffmpeg: mru * r24151 /trunk/Makefile: Remove dead target from .PHONY list [23:42:38] <peloverde> is fate2.mak supposed to be in some sort of order? [23:42:45] <mru> not really [23:42:49] <mru> group as you see fit [23:42:54] <peloverde> ok [23:43:04] <mru> I suggest keeping related tests together [23:44:09] <peloverde> agreed, I just wasn't sure if it was supposed to be alphabetical but needed to be fixed or something like that [23:49:06] <peloverde> Is fate supposed to spam weird shell errors on top of its own errors? [23:49:47] <mru> no [23:50:00] <mru> what are you getting? [23:50:05] <peloverde> "[: 34: -gt: unexpected operator" [23:50:20] <mru> that means your ref file is missing [23:51:34] <peloverde> yes [23:51:44] <mru> maybe I should fix that... [23:55:22] <mru> done [23:56:05] <CIA-99> ffmpeg: mru * r24152 /trunk/tests/fate-run.sh: fate: fail with a sensible error message if reference file is missing [23:56:49] <peloverde> thanks [23:58:19] <peloverde> Does anywhere in this string tell me where the max error falls? "stddev: 0.57 PSNR:101.15 MAXDIFF: 2 bytes: 727040/ 727040" [23:58:31] <mru> MAXDIFF [23:58:39] <mru> value is 2 [23:58:46] <mru> so you need FUZZ = 2 [23:59:32] <mru> see commit message for r24133 [23:59:44] <mru> perhaps not the best place for documentation

1 0

IRC log for 2010-07-08
by irc＠mansr.com 09 Jul '10

09 Jul '10

[06:04:06] <av500> Guten Morgen [06:05:07] <kshishkov> god morgon [06:07:02] <av500> lol, google is now pointing people to libavcodec/vp8dsp.c for VP8 documentation.... [06:07:26] <elenril> lol? [06:07:37] <av500> Dark_Shikari: BBB: quick, change the bitstream to your liking :) [06:08:00] <elenril> av500: link? [06:08:22] <Dark_Shikari> lol [06:08:36] <Dark_Shikari> I think that's a tactit admission that our code is better than theirs [06:09:57] <hyc> cool [06:10:11] <hyc> pipe all the comments thru piglatin [06:10:24] <astrange> we have comments? [06:10:35] <hyc> oh, never mind ;) [06:11:57] <av500> elenril: http://groups.google.com/a/webmproject.org/group/codec-devel/browse_thread/… [06:15:27] <saintdev> oops, seems we forgot to copypasta the source in that part of the spec [06:15:36] <KotH> lol [06:27:53] <cartman> how lame [07:58:29] <j0sh> wbs: nice job tracking down that leak [08:01:48] <wbs> j0sh: it was quite easy to pinpoint with valgrind :-) [08:03:06] <j0sh> wbs: all i was able to see was that it leaked 16 bytes of extradata [08:03:27] <j0sh> gdb told me it was in the aac encoder, but other than that, no other info [08:03:36] <j0sh> didnt feel like backtracking from there :) [08:03:48] <wbs> j0sh: use --leak-check=full with valgrind, then it tells you the location of the leaked allocations :-) [08:04:03] <j0sh> yeah thats what i did [08:04:19] <wbs> you may need to compile without -fomit-frame-pointer in order to get proper backtraces in valgrind though [08:05:01] <j0sh> thats probably it, i'm seeing compiler generated functions like T.676 [08:05:24] <j0sh> which is the entirety of the backtrace in ffmmpeg.c [08:05:33] <wbs> ah [08:06:11] <wbs> in my case, I got http://pastebin.org/386076 [08:07:40] <j0sh> mine looked pretty similar [08:10:16] <j0sh> http://pastebin.org/386084 [08:10:17] <j0sh> ah well [08:11:10] <wbs> after compiling without -fomit-frame-pointer, the same backtrace becomes http://pastebin.org/386088 instead [08:11:17] <wbs> and then it's quite trivial to pinpoint the leak [08:11:31] <j0sh> indeed, now i see [08:12:31] <j0sh> well, fomit-frame-pointer is a good tip to know [08:13:08] <astrange> --disable-optimizations or so [08:13:30] <wbs> yeah, that can be used, too, but that disables a whole lot more [08:14:39] <j0sh> i've never gotten --disable-optimizations to quite work [08:14:59] <j0sh> usually have to --disable-mmx or something similar too [08:15:29] <astrange> i think it works these days [08:15:52] <astrange> --disable-asm works along with it if you need to debug into dsp (and don't want to read info registers) [08:17:26] <j0sh> alright i'll keep that in mind whenever i start hacking on neon [08:17:53] <j0sh> how to disable prettyprinted compilation in configure? [08:18:00] <astrange> make V=1 [08:19:15] <j0sh> should that be documented somwhere? make --help doesn't mention anything [08:19:35] <wbs> make --help just says make-specific options, but this is a ffmpeg-makefile specific thing [08:19:53] <wbs> but yeah, I guess it should be documented somewhere. patch welcome, as always. :-) [08:39:18] <j0sh> wbs: i'm going to bed, i'll fix the things you reviewed in the AM [08:39:46] <wbs> j0sh: ok, no hurry, I guess it will take a while to discuss the timestamp handling issue, too [08:40:27] <j0sh> yeah, setting the pts might not even be needed there. i'll play around with it [08:40:58] <wbs> I do think it is needed, but it has to be done in a slightly different way [08:41:08] <hyc> woohoo. ffserver seems to return HTTP 200 even when it fails [08:41:56] <DonDiego> cartman: IIRC it was you that hosted the ffmpeg doxygen docs, right? [08:42:09] <cartman> DonDiego: indeed [08:42:12] <cartman> should still be working [08:42:15] <av500> Dark_Shikari: nice score! :) [08:42:22] <Dark_Shikari> ? [08:42:22] <DonDiego> i have just finished setting it up on mphq [08:42:27] <av500> Dark_Shikari: on vp8 [08:42:31] <Dark_Shikari> what about vp8 [08:42:40] <cartman> DonDiego: cool! [08:42:42] <DonDiego> cartman: thanks for hosting it all this time [08:42:47] <av500> Dark_Shikari: the comment on #vp8 [08:42:53] <DonDiego> you can of course keep hosting it if you want to [08:42:56] <cartman> DonDiego: it was an honour =) [08:42:56] <Dark_Shikari> =p [08:43:02] <DonDiego> but there is now an official replacement [08:43:05] <cartman> DonDiego: its a cron script, I'll let it run [08:43:17] <DonDiego> sure, just to let you know... [08:43:21] <cartman> cheers [08:59:47] <CIA-99> ffmpeg: benoit * r24104 /trunk/libavcodec/zmbv.c: [08:59:47] <CIA-99> ffmpeg: Remove a useless variable in zmbv decoder. [08:59:47] <CIA-99> ffmpeg: Patch by Eli.Friedman (gmail) [09:00:44] <CIA-99> ffmpeg: hyc * r24105 /trunk/ffserver.c: Fix "server too busy" status code [09:21:48] <CIA-99> ffmpeg: diego * r24106 /trunk/doc: Ignore generated .pod files. [09:21:49] <CIA-99> ffmpeg: hyc * r24107 /trunk/ffserver.c: Also use 503 for bandwidth limit exceeded [12:06:30] <Tjoppen> av_pix_fmt_descriptors needs to be exported via some function or you can't access that information when linking to dlls [12:07:05] <Tjoppen> assuming that user is supposed to be able to access it. ffmpeg and ffplay do [12:09:30] <mru> seems to be working on fate [12:10:31] <Tjoppen> the problem is linking i msvc [12:10:34] <Tjoppen> *in [12:11:03] <mru> don't do that then [12:11:26] <mru> are you linking against the dlls directly or using the import libs? [12:11:34] <Tjoppen> import libs. can't link against the dlls [12:11:50] <mru> ok, wasn't sure what was possible [12:12:01] <mru> windows dlls seem like huge, ugly monster hack to me [12:12:09] <Tjoppen> it can't really generate stubs for accessing global arrays :o [12:12:21] <Tjoppen> hence why a function is needed [12:12:38] <mru> so how can it work when building ffmpeg normally? [12:13:00] <Tjoppen> built in mingw, using ld instead lf link.exe [12:13:05] <Tjoppen> *of [12:13:23] <mru> and what does ld do differently? [12:13:32] <Tjoppen> no idea. maybe doesn't use import libs? [12:13:34] <hyc> current binutils claims to be able to link against DLLs directly [12:13:46] <hyc> used to be that only worked for function references [12:13:50] <Tjoppen> in fact: it does not use import libs because ffmpeg worked before I had set up %PATH% to point to lib.exe [12:13:57] <hyc> seems that now they handle data refs too [12:14:11] <mru> so how do data references get resolved? [12:14:13] <mru> at runtime [12:14:23] <Tjoppen> they can't. not in msvc anyway [12:14:30] <hyc> dunno. that used to always require an import and a fixup. [12:14:30] <Tjoppen> untill the ditch the need for import libs [12:15:11] <mru> but how does it work at runtime when ld has done its magic? [12:15:18] <Tjoppen> or maybe they could, in a rather roundabout way (have points the point to the arrays in the dll on startup) [12:15:28] <Tjoppen> s/points/pointers [12:15:56] <mru> ELF is just so much more elegant [12:16:18] <hyc> they must add something to the crt startup code to relocate data references [12:17:57] <Tjoppen> one part of it seems to be lots and lots of function stubs. check the exports of libs and you'll see lots of duplicates of all functions [12:18:54] <mru> I know function calls go through a stub [12:19:16] <hyc> those really aren't needed any more. even MSVC can call DLL functions without the stubs [12:19:38] <mru> ELF lazy symbol resolution is neat [12:20:36] <hyc> yeah, ELF does a lot of things pretty well [12:20:45] <Tjoppen> yes, I think I've seen linking directly to dlls once or twice. unfortunately link.exe refuses to link with the libav* dlls. it thinks they are corrupt [12:21:10] <hyc> but I think AIX has the best Unix file format [12:21:16] <mru> really? [12:21:23] <mru> aix is full of bizarre quirks [12:21:25] <hyc> probably because it has a lot of ideas in common with mainframe formats [12:22:01] <hyc> AIX exes can be relinked [12:22:04] <mru> "It used to be said [...] that AIX looks like one space alien discovered Unix, and described it to another different space alien who then implemented AIX. But their universal translators were broken and they'd had to gesture a lot." -- Paul Tomblin [12:22:58] <hyc> and object files are basically just a container without any other semantics [12:23:17] <hyc> the linker deals with the actual objects - functions and variables [12:23:40] <kshishkov> mru: look at another IBM creations [12:23:41] <hyc> every symbol has its size, and the linker just pulls in what it wants from whatever files you give it [12:24:36] <hyc> and everything is PIC by default, a shared lib can be linked dynamically or statically [12:25:11] <mru> PIC is annoying [12:25:15] <mru> it slows things down [12:25:42] <mru> although on ppc64/power it doesn't really matter [12:25:44] <hyc> yeah, I guess so. worse on x86. [12:26:02] <mru> on ppc64 you always have a TOC anyway [12:26:27] <mru> and there's some serious linker voodoo around calling external functions [12:26:30] <mru> to set up the TOC pointer [12:27:14] <mru> function descriptors... [12:27:16] <mru> ugh [12:27:22] <hyc> yeah... also reminiscent of mainframes [12:27:43] <kshishkov> mru: what about PIC on MIPS? [12:27:56] <mru> mips is also annoying [12:27:59] <hyc> on 68K PIC was faster. [12:28:11] <hyc> function references using PC-relative addressing [12:28:27] <hyc> and variables using basereg-relative [12:28:30] <mru> that doesn't work when start using shared libs [12:29:16] <mru> which is why you need GOT/PLT/TOC indirection [12:29:20] <hyc> true [12:29:57] <mru> on mips each function with external linkage has a prologue to set up the GOT [12:30:10] <DonDiego> Yuvi, are you ok with the doxy change to vp8.c from r23979? [12:30:13] <hyc> sparc did that too [12:30:20] <mru> calls from within the same object bypass the prologue [12:30:24] <mru> since they have the same got [12:30:57] <mru> ppc64 has the caller load the toc from the function descriptor before calling [12:31:02] <mru> same end result [12:31:10] <mru> but more code [12:31:34] * kshishkov saw PIC in PPC code - brain-damaging [12:31:58] * mru points at altivec fft [12:32:02] <hyc> the prologue trick requires MMU games. [12:32:17] <mru> not really [12:32:33] <mru> to the code, it's all a flat address space [12:32:39] <hyc> it uses fixed offsets, that are remapped for each process [12:32:42] <kshishkov> only OS requires MMU games [12:33:23] <mru> that's just describing virtual addresses as used on any sane OS [12:33:59] <hyc> if the caller loads instead of callee, you can share without an MMU. which we did on 68000. [12:34:35] <mru> mmu has nothing to do with this [12:35:06] <mru> mmu-less shared libs are interesting in their own way of course [12:35:29] <kshishkov> yes, like Windows ones [12:36:13] <hyc> hmmm. yeah, having to run rebase was always such a treat. [12:38:40] <mru> one thing I don't understand about the ppc abi is why the stack frame is described in such minute detail [12:38:57] <hyc> setjmp/longjmp ? [12:39:03] <mru> insisting on specific offsets being used to store each saved register [12:39:04] <Tjoppen> I'll post a thread requesting the lavu API be extended with av_get_pix_fmt_descriptor() [12:39:11] <mru> Tjoppen: please do [12:39:17] <mru> it's a real problem and we need to fix it [12:39:19] <Tjoppen> minor version bump as well I guess [12:39:24] <hyc> I think all of the SVR4 ABI manuals go to that detail [12:39:38] <hyc> I have i860, m68k, and sparc here [12:39:41] <Tjoppen> I'll roll them into the same patch for atomicity :) [12:41:15] <mru> hyc: but why does it matter? [12:41:41] <mru> ARM abi allows you to use the stack in any manner you see fit [12:41:51] <mru> as long as you maintain alignment [12:42:49] <hyc> hmmm. probably to allow stack unwinding by standard tools [12:45:38] <mru> somehow arm tools manage it just fine [12:46:12] <mru> the debug notes for each function can specify where everything is saved [12:48:51] <mru> imo it's better to put less constraints on the code [12:55:53] <Tjoppen> thread posted [12:56:08] <Tjoppen> ice cream in five minutes \o/ [12:56:50] * mru has ice cream in the freezer [12:57:24] * kierank ate all his [12:57:40] <mru> kierank: no supermarkets in your area? [12:57:44] <av500> Tjoppen: you posted a whole thread? epic, with flames and bikesheds? [13:01:11] <Tjoppen> oh yes [13:01:29] <Tjoppen> sock puppets and all [13:36:36] <CIA-99> ffmpeg: diego * r24108 /trunk/ (3 files in 2 dirs): Restore array sizes in doxygen parameter names. [13:39:39] <DonDiego> BBB: are you ok with the doxy change to vp8.c from r23979? [13:47:47] <BBB> uhm... does doxy not like [] in the comments? [13:48:00] <mru> DonDiego: says so [13:48:07] <BBB> can we escape it? [13:50:47] <DonDiego> the problem is that you document two parameters where the function has only one [13:51:24] <av500> according to what I read it meabs the function has to have 2 as well, no? [13:51:36] <DonDiego> BBB: while we're at it, maybe you could fix the doxygen warnings about undocumented parameters in vp8.c? [13:52:00] <BBB> oh, so it doesn't recognize? [13:52:04] <BBB> how about the following: [13:52:21] <BBB> change it so it says @param array [0] ac dequant factor, [1] dc dequant factor [13:52:29] <BBB> or something like that [13:53:10] <DonDiego> btw, can anybody see the mistake in r23983? afaict it's correct [13:54:14] <mru> removing the comma looks correct [13:54:20] <DonDiego> to me as well.. [13:54:35] <benoit-> FWIW, to me too. [13:55:19] <benoit-> I'd be tempted to add an s to the first 'initialize' too. [13:55:39] <BBB> DonDiego: keep it [13:55:47] <BBB> benoit-: nooooooooooooooooooooooo [13:55:51] <BBB> benoit-: not that discussion again :-p [13:55:58] <DonDiego> BBB: keep what? [13:56:05] <BBB> DonDiego: keep the commit [13:56:10] <BBB> the commit is fine, the comma is wrong [13:56:27] <benoit-> BBB: it seems I was not here when the first one took place :) [13:56:51] <mru> benoit-: be very, very careful [13:57:11] <benoit-> mru, BBB: oh, you mean that 3rd person thing? [13:57:15] <benoit-> I didn't mean that [13:57:37] <benoit-> we have a subject for this one... its '0/1' [13:57:40] <benoit-> it's [13:58:08] <mru> I'm not so sure the number should be treated as a subject [13:58:43] <benoit-> mru: -1 is treated as such in the second part of the comment [13:58:56] <benoit-> anyway, I don't care, really. [13:59:06] <mru> that could be the error [13:59:48] <benoit-> I picked the wrong one then :) [14:00:02] <mru> people have an outstanding knack for doing that [14:01:38] <benoit-> mru: in this case, both solutions would be ok... I mean, I would accept the two if it was in French, grammatically. [14:10:32] <av500> stupid user question: how good is rtsp in ffmpeg compared to e.g. live555? [14:11:12] <kierank> av500: --> #ffmpeg ;) [14:13:19] <wbs> av500: in libavformat in general, I'd say it's decent for those formats/protocol variants that are supported [14:13:30] <wbs> combined with ffplay there are a few gotchas [14:13:51] <av500> ic [14:21:19] <av500> hmm, m.youtube.com gives rtsp link with AAC LATM [14:21:49] <wbs> yeah, that's one of the things we don't support yet :-) [14:22:05] <kierank> hmmm so latm is used in the wild in something other than ts [14:22:06] <wbs> don't know how much extra work it's on the rtp layer, but I'd figure it's easier once we have support for latm in general [14:23:10] <av500> kierank: yes, I was surprised [14:23:23] <av500> given that m.youtube is for like all the mobile phones out there... [14:24:47] <mru> I thought google policy was do no evil... [14:24:51] <mru> clearly that was a lie [14:25:25] <av500> :) [14:25:30] <av500> you caught them! [14:25:44] <kshishkov> mru: it's ok until you think of it as an evil act [15:01:39] <CIA-99> ffmpeg: rbultje * r24109 /trunk/libavcodec/wmavoice.c: Fix two doxy warnings. [15:02:52] <CIA-99> ffmpeg: rbultje * r24110 /trunk/libavcodec/vp8.c: Add missing doxy for function arguments. [15:30:39] <KotH> if i'd have to use a lossles encoding for RGB data in a comercial product, what would you recomend? [15:31:13] <CIA-99> ffmpeg: mru * r24111 /trunk/Makefile: Beautify make messages when generating test data files [15:31:14] <CIA-99> ffmpeg: mru * r24112 /trunk/Makefile: Clean up make rules for calling codec test scripts [15:31:15] <CIA-99> ffmpeg: mru * r24113 /trunk/Makefile: [15:31:15] <CIA-99> ffmpeg: Create the regtest reference files only when necessary [15:31:15] <CIA-99> ffmpeg: This avoid recreating the ref files every time an individual test [15:31:15] <CIA-99> ffmpeg: is run from the command line. [15:31:35] <mru> KotH: depends on the requirements [15:31:44] <mru> fast encoding? fast decoding? best compression? [15:31:52] <mru> standard codec? [15:32:26] <kshishkov> raw video - even commercial products should be able to understand it [15:35:34] <KotH> mru: 640x480 @ 60fps RGB, probably higher resolution (but not that much higher, limited by camera size). being able to store it on not too large file [15:35:49] <KotH> mru: currently it's mostly about a demonstrator, whether the project is feasible at all [15:35:55] <KotH> ie, should be rather low cost [15:36:01] <mru> sounds like you need realtime encoding [15:36:12] <KotH> juup [15:36:17] <mru> storage medium? [15:36:25] <KotH> harddisk [15:36:36] <KotH> so we can guestimate a 80MB/s [15:36:47] <KotH> hmm.. [15:37:00] <mru> don't assume more than 30MB/s sustained writes to a disk [15:37:08] <mru> they'll all do more in bursts [15:37:16] <mru> and purely sequential writes [15:37:23] * KotH isnt afraid of putting an SSD into such a device [15:37:36] <mru> but once you fill up the write caches and have to do the odd seek, rates drop [15:37:53] <KotH> those few bucks are much cheaper than developing a fast encoding scheme :) [15:38:02] <mru> raid0 of 4 SSDs? [15:38:05] <mru> that should be fast enough [15:38:18] <KotH> even one should be enough [15:38:30] <KotH> they have usually sustained write rates of 100MB/s [15:38:33] <kshishkov> mru: raid of DDR :P [15:38:36] <KotH> often much higher [15:38:39] <mru> kshishkov: that exists [15:38:48] <spaam> expensive ;D [15:38:53] <kshishkov> mru: yes, and it's hard to beat that in speed [15:39:10] <KotH> spaam: gues how much it'll cost if have to code for one day [15:39:27] <spaam> KotH: dunno.. tell us [15:39:29] <KotH> mru: oh.. and i should be able to play it back with "standard" players (like mplayer ;) [15:39:46] <mru> but not necessarily quicktime or wmp? [15:40:02] <KotH> mru: customer asked for "if possible linux" :) [15:40:47] <reynaldo> mornings [15:40:55] <KotH> hey reynaldo! [15:40:55] <mru> morning reynaldo [15:41:09] <KotH> mru: beside: it's a demonstrator [15:41:14] <mru> how's winter coming along? [15:41:20] <spaam> KotH: if you buy 24SSD and put that in raid0.. you can write 2.0 gigabyte/sec ;) [15:41:26] <reynaldo> hi there mru, KotH [15:41:40] <reynaldo> mru: it keeps raining and raining.. [15:41:46] <reynaldo> quite boring, humid and cold [15:41:48] <KotH> mru: first prio is getting a system that works. [15:41:51] <mru> sunshine here [15:41:56] <mru> although KotH won't believe that [15:41:57] <KotH> reynaldo: come over here [15:42:26] <reynaldo> oh, I would have to sell my kids to be able to afford the travel expenses :P [15:42:29] <KotH> mru: i believe you, if you say sunshine... but i wouldnt belive if you'd say warm ;) [15:42:31] <mru> ugh, next week I'll be working office hours again :-( [15:42:31] <reynaldo> but thanks for the invite [15:42:38] <KotH> reynaldo: i'd buy them ;) [15:42:52] <mru> KotH: it's rather warm here [15:42:55] <mru> 25 degrees or so [15:43:04] * KotH doenst belive that [15:43:11] <reynaldo> KotH: hehe, will keep that in mind :D [15:43:27] <KotH> ROTFL [15:43:33] <KotH> they want to use matlab for the demonstrator [15:43:44] <mru> lol [15:43:52] <KotH> so much for real time [15:43:54] <reynaldo> kiss performance good bye then [15:45:07] <reynaldo> what happened with the guy that wanted a QCELP encoder for his company? [15:46:43] <KotH> has anyone ever worked with v4l? [15:46:52] <mru> yes, sadly [15:46:59] <mru> av500: ^^ [15:47:00] <KotH> what is your verdict? [15:47:12] <spaam> reynaldo: hope that he make some patches ;D [15:47:13] <mru> it suffers from alsa syndrome [15:47:15] <reynaldo> oh, that reminds me I need to get this isdb-t adapter working one of these days [15:47:22] <KotH> mru: ? [15:47:34] <mru> huge, complex interface that nobody understands [15:47:41] <mru> and never quite works [15:48:01] <spaam> haha [15:48:17] <KotH> then, if you'd have to write a driver for a custom video device, would you use v4l or write full custom driver? [15:48:21] <spaam> mru: so you can make it better if you get large number of $$$ ? ;) [15:48:50] <KotH> spaam: given enough time and money, even you could make it better [15:48:52] <mru> if you have a device that needs a driver, v4l2 is still the best choice [15:48:57] <kshishkov> spaam: sure, just give enough to hire undertakers and priest [15:49:00] <mru> driver interface proliferation is never good [15:49:13] <KotH> ack [15:49:19] <reynaldo> spaam: sure, it would be rather nice if he payed for developing a native encoder though [15:49:27] <mru> it's not quite as bad as alsa [15:49:35] <spaam> KotH: i like "even you" part ;D [15:50:17] <spaam> kshishkov: hehe :) but do you think KotH can do it?:) [15:50:18] <KotH> spaam: you arent so stupid taht you cannot hit the right keys on a kbd -> given enough money and time, even you can do it [15:50:42] <mru> million monkeys, serial version [15:50:44] <KotH> spaam: even if it needs a damn lot of money and more than hundred years [15:50:58] <spaam> haha [16:04:16] <KotH> how was that CCD -> RGB recoding process called? [16:04:31] <KotH> CCD = CCD data [16:05:13] <reynaldo> didn't know that existed as a named process [16:15:20] <mru> KotH: bayer? [16:17:37] <KotH> mru: demosaicing [16:26:09] <KotH> does anyone here have any knowledge of the MIPI camera interface? [16:34:42] <mru> sounds almost like midi [16:34:49] <mru> musical instrument picture interface? [16:34:55] <_av500_> almost [16:35:11] <_av500_> KotH: i know mipi for displays [16:35:18] <mru> _av500_: just reverse it then [16:35:22] <_av500_> yes [16:35:28] <_av500_> ipin [16:35:31] <_av500_> ipim [16:35:48] <KotH> _av500_: i could find very little information on it [16:35:50] <_av500_> KotH: put GND to VCC and VCC to GND [16:36:04] <KotH> _av500_: what kind of interface is it? how does it look like electrically? how logically? [16:36:28] <_av500_> we use mipi sdi [16:36:31] <_av500_> dsi [16:36:35] <_av500_> mipi dsi [16:36:36] <_av500_> serial [16:37:01] <_av500_> omap3 trm has something about it [16:37:07] <mru> hdcp over rs232 [16:37:54] <_av500_> KotH: ping me in office tomorrow [16:45:14] <reynaldo> KotH: do you know how to calculate the reflector 'mesh' optimum spacing giving a desired frequency/wavelength range and a desing like the one descrived here? [16:45:17] <reynaldo> http://uhfhdtvantenna.blogspot.com/ [16:45:55] <reynaldo> also the spacing between the reflector and the halfwave dipoles array, guess one should take that into account too [16:46:22] <_av500_> yes [16:46:42] <_av500_> ask a HAN [16:46:49] <_av500_> HAM [16:46:54] <reynaldo> I built one and I'm geting enough signal to be able to tune but the reception can still be greatly improved, I guess that adding a reflector might help [16:47:59] <reynaldo> _av500_: oh, KotH is my EE of choice, has been for years [16:49:32] <_av500_> im EE too, but have no idea about antenna design [16:51:10] * mru has no idea about antenna design anymore [16:51:29] <mru> there was something elegant about it [16:51:53] <reynaldo> I think that reflector mesh interspacing is not rocket science, I thinnk to remember you can easily calculate it from wavelenght without knowing too much about antenna design [16:52:10] <reynaldo> I thinnk/I seem [16:54:44] <reynaldo> mru: sure, up to the point you put it somewhere visible :D [16:55:48] <mru> one of the professors teaching that stuff was apparently particularly interested in physical manifestations of antennas [16:55:57] <mru> to the point where he'd go around town taking pictures of them [16:56:30] <mru> once he got in a bit of trouble when he was seen taking pictures of the antennas of some secret military installation [16:56:52] <mru> he had no idea what it was, just thought their antenna looked interesting [16:57:06] <KotH> _av500_: ack.. thanks! [16:57:08] * j0sh thinks disgused cell phone towers are really cool [16:57:29] <mru> disgusted? [16:57:36] <j0sh> disguised* [16:58:06] <KotH> reynaldo: uhm.. i could look it up, but i dont know it from the top of my head [16:58:19] <KotH> reynaldo: i've never done any antenna design, but i've enough books :) [16:59:16] <reynaldo> KotH: please do, I will keep googling while I wait [16:59:20] <reynaldo> Its nothing urgent [16:59:25] <mru> the only antenna I've ever designed and put to use consisted of a 10m wire to a tree [16:59:55] <reynaldo> a random wire antenna? [17:00:04] <mru> not random [17:00:12] <reynaldo> I recently discovered thats an actual design [17:00:14] <mru> it was exactly the wire I had at home that was long enough [17:00:28] <kshishkov> the best kind of wire indeed [17:01:09] <reynaldo> hi kshishkov [17:02:27] <mru> http://www.theonion.com/video/new-apple-friend-bar-gives-customers-someone-… [17:02:33] <KotH> reynaldo: rothammel says 0.65\lambda for highest gain, usually between 0.1 and 0.3, at ca 0.2 you get very little influence on the antenna impedance [17:04:15] <reynaldo> KotH: got it, then I guess one should aim for 0.2 if building a custom matching transformer its not desired [17:04:39] <KotH> the impedance of the antenna is mostly dependent on the design of the elements [17:05:08] <KotH> i could give you there hints too, but i'd have to read more on that kind of stuff [17:05:23] <KotH> btw: isnt there any english equivalent of the rothammel? [17:05:28] <reynaldo> that antenna is supposed to have 300 Ohms impedance, but I don't know if thats calculated or they are just whishfully threating it like a halfwave dipole [17:05:49] <reynaldo> KotH: dunno [17:07:25] <KotH> eh.. no [17:07:30] <KotH> there is no ^^ [17:08:06] <KotH> maybe the arrl antenna book, but it looks rather thin [17:09:43] * KotH puts it on his to buy list anyways [17:16:25] <reynaldo> he, I found a neat fractal antenna design. I will try it out [17:16:33] <reynaldo> http://www.instructables.com/id/How-to-make-a-fractal-antenna-for-HDTV-DTV-… [17:24:25] * KotH wouldnt trust an antenna design that has not been tested and measuremed by someone who knows his stuff [17:26:39] <reynaldo> I'd trust whatever I can get to work well, antenna design has too much black magic into it [17:26:59] <mru> nah, it's just maxwell's equations [17:27:00] <reynaldo> for a mortal being like myself that is :) [17:27:48] <KotH> mru: antenna simulation is still a lot of black magic [17:28:11] <KotH> very few simulation tools get actually the right gain [17:28:17] <KotH> most are 10-20% off [17:28:24] <KotH> if not 50% [17:32:29] <mru> does this look about right? pcm_test_deps=$(echo pcm_{{a,mu}law,u8,s8,{s{16,24,32},f{32,64}}{be,le},s24daud,zork}_{en,de}coder) [17:33:20] <KotH> it looks cryptic [17:34:15] <mru> but much more compact than listing them all separately: pcm_alaw_encoder pcm_alaw_decoder pcm_mulaw_encoder pcm_mulaw_decoder pcm_u8_encoder pcm_u8_decoder pcm_s8_encoder pcm_s8_decoder pcm_s16be_encoder pcm_s16be_decoder pcm_s16le_encoder pcm_s16le_decoder pcm_s24be_encoder pcm_s24be_decoder pcm_s24le_encoder pcm_s24le_decoder pcm_s32be_encoder pcm_s32be_decoder pcm_s32le_encoder pcm_s32le_decoder pcm_f32be_encoder pcm_f32be_decoder pcm_f32le_encoder pc [17:34:30] <pJok> mru, you got cut off there [17:34:39] <mru> doesn't matter [17:34:47] <mru> only proves my point [17:50:19] <BBB> mru: [su]8 instead of s8,u8? [17:50:23] <BBB> both 5 characters though... [17:50:28] <CIA-99> ffmpeg: michael * r24114 /trunk/libavutil/random_seed.c: Change i to unsigned in get_generic_seed() [17:53:46] <mru> BBB: not the same thing [17:53:52] <mru> this is not pattern matching [17:56:32] <CIA-99> ffmpeg: diego * r24115 /trunk/libavcodec/cook.c: Improve variable names in imlt_window_float() and mlt_compensate_output(). [18:07:40] <Vitor1001> mru: Any news on the new FATE? [18:07:49] <mru> no [18:09:36] <Vitor1001> mru: Would you ok a "make fate2" target? [18:09:48] <mru> depends on what it did [18:10:04] <Vitor1001> Same thing as "make fate" but for tests not in Mike's database. [18:10:14] <mru> like what? [18:10:31] <Vitor1001> mp3 fixed point [18:10:39] <Vitor1001> http://wiki.multimedia.cx/index.php?title=FATE_Test_Coverage#TODO [18:11:09] <Vitor1001> And first and foremost giving people the ability to add a test to it when mike is busy. [18:12:00] <mru> s/when mike is busy// [18:12:21] <Vitor1001> yes, exactly. [18:13:33] <Vitor1001> So? Are you fine with it in principle as the build (and test) system maintainer? [18:14:12] <DonDiego> we should move away from mike's fate [18:14:20] <CIA-99> ffmpeg: michael * r24116 /trunk/libavutil/random_seed.c: Fix infinite loop with clock() returning (clock_t)-1. [18:14:26] <Vitor1001> DonDiego: Looks more a long term goal. [18:14:32] <DonDiego> we're at the whim of a single dev there [18:15:24] <Vitor1001> DonDiego: How many times we needed to add a test and didn't because of it? If there were a "make fate2", we could at least add all that stuff there. [18:15:37] <DonDiego> yes, excellent first step [18:15:44] <Vitor1001> DonDiego: And try to convince mike to run "make fate2" in his farm. [18:15:44] <DonDiego> everybody should be able to run fate locally [18:15:54] <DonDiego> once that is done, doing the web stuff becomes trivial [18:16:55] <Vitor1001> I agree... I'll look at this patch. [18:17:40] <mru> not trivial, but it can be done later [18:17:54] <mru> anyway, I'm messing with the regtests right now [18:18:40] <Vitor1001> mru: So, do I give a try at it or do you want to try first? [18:19:06] <mru> I'm in the middle of a cleanup operation right now [18:19:14] <mru> anything you do now might not apply in 10 minutes [18:19:33] <Vitor1001> ok. [18:19:45] <Vitor1001> But looking at the Makefile, it sounds _really_ trivial :D [18:20:04] <mru> I never said it was hard [18:20:26] <mru> but there's a difference between grafting something on and properly integrating it [18:28:28] <DonDiego> BBB: got you! [18:28:51] <DonDiego> BBB: you introduced the bug i am flaming about with michael in r18351 [18:32:31] <Vitor1001> mru: Well, besides that, would you complain to use the following patch to test float codecs: http://ffmpeg.pastebin.com/kFBsVDxf ? Or do you find parsing the string too ugly? [18:33:28] <Vitor1001> MAXDIST == 1 meaning no regression [18:34:50] <mru> svn is evil [18:35:07] <mru> it doesn't let me replace a directory with a file previously inside the directory [18:35:24] <mru> git handles it no problem [18:39:18] <DonDiego> what file would that be? [18:40:05] <BBB> DonDiego: remove the comment [18:40:16] <BBB> DonDiego: it's a static function where the pointer prototype already contains the comment [18:40:19] <BBB> the comment is thus duplicate [18:44:47] <CIA-99> ffmpeg: mru * r24117 /trunk/tests/ref/ (vsynth1/yuv vsynth2/yuv vsynth1/rgb vsynth2/rgb): [18:44:47] <CIA-99> ffmpeg: regtest: put rgb and yuv reference files in correct place [18:44:47] <CIA-99> ffmpeg: SVN design flaw requires deleting dirs in separate step [18:44:47] <CIA-99> ffmpeg: mru * r24118 /trunk/tests/ref/ (vsynth1/yuv vsynth2/yuv vsynth1/rgb vsynth2/rgb): regtest: put rgb and yuv reference files in correct place [18:44:51] <CIA-99> ffmpeg: mru * r24119 /trunk/configure: [18:44:52] <CIA-99> ffmpeg: configure: add print_enabled() function [18:44:52] <CIA-99> ffmpeg: The print_enabled() function prints all elements in a list which [18:44:52] <CIA-99> ffmpeg: are enabled. [18:44:52] <CIA-99> ffmpeg: mru * r24120 /trunk/ (Makefile configure): [18:44:52] <CIA-99> ffmpeg: Move regression test dependencies to configure [18:44:53] <CIA-99> ffmpeg: This allows expressing complex dependencies more easily. [18:44:53] <CIA-99> ffmpeg: mru * r24121 /trunk/Makefile: Simplify regtest reference makefile dependencies [18:45:52] * mru feels somewhat sorry for thilo [18:46:09] <BBB> poor guy [18:46:55] <mru> lol, svn dumped core [18:47:16] <CIA-99> ffmpeg: diego * r24122 /trunk/Doxyfile: Do not generate documentation for .d files; they do not contain source code. [18:47:24] <DonDiego> BBB: suggest that to thilo, he just volunteered to fix the issue(s) [18:48:13] <BBB> well, I fixed wmavoice/vp8 [18:48:21] <BBB> did you figure out how to fix the remaining wmavoice issues? [18:48:26] <BBB> according to the docs, I do it correctly [18:48:42] <DonDiego> yes, saw it, thx [18:50:04] <DonDiego> are you sure you are looking at the docs for the correct version of doxygen? [18:50:15] <DonDiego> and where are those docs? [18:51:30] <BBB> what you just told me in privmsg a few hours ago [18:58:20] <DonDiego> BBB: do you need those explicit links? [19:25:33] <DonDiego> the evil overlord has spoken: i must bend to his democratic powers or be gone... [19:37:06] <DonDiego> i'm out for a beer in the sun [19:37:12] <DonDiego> keep flaming without me ;) [19:41:47] <mru> whaaaat???? debian /bin/sh doesn't support {} substitution [19:50:13] <Rathann> isn't it dash nowadays? [20:00:40] <mru> grmbl, it's not actually standard [20:00:46] * mru should check better next time [20:02:27] * Dark_Shikari reminds the arm people that x264 now needs new chroma MC asm [20:02:32] <Dark_Shikari> and ppc [20:02:41] <Dark_Shikari> (we're committing the patch to convert the internals to nv12) [20:03:18] <mru> interesting [20:03:54] <Dark_Shikari> it reduces L1 cache misses by 10% on x86 [20:04:25] <Dark_Shikari> ~1% overall performance boost [20:04:33] <Dark_Shikari> ~4% on a Secret Chip With Less Cache. [20:08:08] <Vitor1001> mru: you own me a beer [20:08:16] <Vitor1001> ;) [20:08:25] <mru> Vitor1001: can you prove there is _no_ system without abs()? [20:08:39] * mru goes off to make a bsd fork without abs [20:08:40] <Vitor1001> none that ffmpeg compiles... [20:08:47] <Dark_Shikari> lol [20:11:00] <mru> Vitor1001: but sure, I'll buy you a beer next time [20:12:02] <Vitor1001> mru: Yeah, last time in paris we barely met... [20:16:43] <CIA-99> ffmpeg: mru * r24123 /trunk/configure: [20:16:43] <CIA-99> ffmpeg: configure: fix pcm test deps [20:16:43] <CIA-99> ffmpeg: 10l to me for using non-standard shell syntax [21:10:36] <Vitor1001> mru: That's what I mean with fate2 tests: http://ffmpeg.pastebin.com/gq0fUWac . What do you think? [21:21:14] <mru> it's a bit hackish in some parts [21:21:22] <mru> let's try to make it better [21:58:09] <CIA-99> ffmpeg: bcoudurier * r24124 /trunk/libavformat/movenc.c: [21:58:10] <CIA-99> ffmpeg: In mov muxer, write pixel aspect ratio tag in mov files. [21:58:10] <CIA-99> ffmpeg: Based on a patch by Daniel Kristjansson, danielk at cuymedia dot net [22:04:42] <CIA-99> ffmpeg: bcoudurier * r24125 /trunk/libavformat/mpegtsenc.c: In mpegts muxer, print VBR instead of dummy 1 when displaying muxrate [22:23:21] <CIA-99> ffmpeg: stefano * r24126 /trunk/ (3 files in 2 dirs): Reindent after r24101. [22:36:34] <CIA-99> ffmpeg: mru * r24127 /trunk/ (Makefile tests/seek-regression.sh tests/regression-funcs.sh): Change names of regtest output files to closer match the reference files [22:40:45] <BBB> hm... [22:40:52] <BBB> a segfault in fft_sse [22:40:54] <BBB> :( [22:42:24] <CIA-99> ffmpeg: mru * r24127 /trunk/ (Makefile tests/seek-regression.sh tests/regression-funcs.sh): Change names of regtest output files to closer match the reference files [22:42:24] <CIA-99> ffmpeg: stefano * r24128 /trunk/libavutil/avutil.h: [22:42:24] <CIA-99> ffmpeg: Bump minor after read/write_line() to av_read/write_image_line() [22:42:24] <CIA-99> ffmpeg: rename, done in r24101. [22:42:44] <CIA-99> ffmpeg: stefano * r24129 /trunk/doc/APIchanges: Update APIchanges after the recent avfilter.h and pixdesc.h changes. [22:55:13] <CIA-99> ffmpeg: stefano * r24130 /trunk/doc/APIchanges: Perform minor style fixes. [23:04:29] <mru> Vitor1001: still awake? [23:04:38] <Vitor1001> mru: yes [23:04:41] <Vitor1001> way too hot here [23:06:15] <mru> for the off-by-one test, don't we need to set the threshold to 2 to be safe? [23:06:25] <Vitor1001> why? [23:06:38] <mru> in case the reference happens to be created on a machine that goes one way from some ideal and the tested system goes the other way [23:06:40] <Vitor1001> Anyway, the threshold is a parameter of the function ($3) [23:07:20] <Vitor1001> It is more based in testing. Mike tested and saw one is enough [23:07:31] <mru> his testing was limited [23:07:38] <Vitor1001> we just set it to the most restrictive that pass in all boxes. [23:07:50] <Vitor1001> for instance, for amr, I think we will need way more than 1. [23:08:16] <mru> well, then it's not really one-off anymore... [23:08:32] <mru> in some cases it may be better to look at psnr [23:08:41] <Vitor1001> Well, Mike called it this way and the name stick ;) [23:08:57] <mru> it also depends on where the reference came from [23:09:00] <Vitor1001> I think that while it is off by just one, it is better to look at it than psnr. [23:09:19] <mru> sure, if it's off by one only [23:09:29] <mru> but you said amr might need much more [23:09:47] <Vitor1001> Yes, I have no good idea atm to test amr. [23:10:21] <Vitor1001> But twinvq, mp3float, mp2float, mp1float, sipr, ra288, binkaudio, should be fine [23:10:46] <Vitor1001> ok, maybe not ra288, but certainly everything not celp-related. [23:11:02] <Vitor1001> The full list: [23:11:19] <Vitor1001> ATRAC3, RealAudio Cooker, DCA (DTS), IMC, Musepack SV7 & SV8, Nellymoser, QDesign, Truespeech, Vorbis, WMA v1, ATRAC1, WMAPro, TwinVQ, BinkAudio and float MP3 decoder [23:11:37] <mru> anything using pseudo-random noise generators will depend on the implementation use to create the reference [23:12:14] <Vitor1001> everything using a pseudo-random generator uses by now a integer-based prng with a fixed initial seed. [23:12:25] <mru> yes, _our_ decoders do that [23:12:34] <mru> if we use some official reference we don't know what it used [23:13:00] <mru> like the aac test suite [23:13:05] <Vitor1001> Ahh, my code is supposed to compare with a ffmpeg output "known work fine" [23:13:13] <Vitor1001> test suites are a different thing. [23:13:49] <Vitor1001> The goal is to catch an "optimization" that reduces quality of a few percent [23:14:16] <Vitor1001> Like forgetting to properly round the last sample of each frame or something [23:14:40] <Vitor1001> It is just to catch regressions. [23:18:18] <mru> when official test suites exist we should try to use them [23:19:27] <Vitor1001> I'm not sure. I normally like to know when a commit changed a file of more that -+1, even though it is officially still pass the tests. [23:40:08] <CIA-99> ffmpeg: diego * r24131 /trunk/libavcodec/ (escape124.c fraps.c rl2.c): Add back previously removed non-existing function params in doxygen comments. [23:51:59] <mru> Vitor1001: ok, here's my idea of how to do it: http://git.mansr.com/?p=ffmpeg.mru;a=summary [23:52:24] <Vitor1001> I don't get the point of your last message. [23:52:39] <mru> meta-not-getting-the-point... [23:52:40] <Vitor1001> How else do you want to add a test instantly, with no intervention from mike? [23:52:49] <mru> make fate-$newtest [23:53:09] <mru> or plain old "make fate" which would include both mike's tests and the extras [23:53:16] <Vitor1001> That work locally. [23:53:35] <Vitor1001> I want it also to run in mike's ppc box in his basement that runs fate. [23:53:52] <Vitor1001> As soon as I commit it. [23:54:24] <mru> that's why we need to replace mike in the not-too-long term [23:54:35] <mru> replace him with a script [23:54:50] <Vitor1001> Yes, and in the very short term, I suggest "make fate2". [23:55:10] <mru> anyway, separating those targets is easy to do or not do [23:55:11] <Vitor1001> Three years ago, we were going to use lavfi in the not-too-long term too [23:55:22] <mru> what do you think of the commits in my git? [23:55:30] <Vitor1001> I like all of it. [23:55:54] <Vitor1001> Where is the output file written? [23:56:06] <mru> somewhere under tests/ [23:56:20] <mru> tests/data/fate/ apparently [23:56:47] <mru> maybe we should delete the output afterwards [23:56:48] <Vitor1001> I wanted to use a pipe to avoid it. [23:56:51] <Vitor1001> Yes. [23:56:57] <Vitor1001> At least in make clean [23:57:02] <mru> it already does [23:57:23] <Vitor1001> nice [23:57:33] <mru> how about deleting the output on success and keeping it on failure? [23:57:43] <mru> if it fails, you'll probably want to look at it [23:57:54] <Vitor1001> Looks a good idea. [23:58:12] <Vitor1001> BTW, "make V=2 fate" has atm the same effect as "make fate" [23:58:23] <mru> iKnow [23:58:33] <Vitor1001> When a test fails, I normally run it again with V=2 and then cut and paste it. [23:58:54] <mru> I've done the same on occasion... [23:59:02] <mru> I can fix that for fate [23:59:37] <Vitor1001> That would be nice, but not really urgent.

1 0

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

08 Jul '10

[00:44:14] <peloverde> What advantage does libxine have over directly using FFmpeg? [00:46:51] <peloverde> I ask because of the KDE phonon libxien back end and stuff like this http://people.gnome.org/~michael/blog/2010-07-06-ooo-gstreamer.html [01:31:01] <Honoome> peloverde: libxine has a few more layers [01:31:14] <peloverde> wrappers all the way down? [01:31:17] <Honoome> peloverde: but seriously I'd count it dead (and I say that as one of the developers) [01:31:29] <Honoome> it doesn't use libavformat [01:31:50] <Honoome> it has its own demuxers and input protocols, including smb and a gvfs one (and the phonon system has its own kio plugin) [01:32:10] <Honoome> it can use other libraries beside libavcodec (like faad, mad, ...) [01:32:17] <peloverde> I never really understood why kde and/or kubuntu chose it as the default phonon backend [01:32:34] <Honoome> *shrug* I'm not sure why they did so... I guess at the time gstreamer didn't look so clean [01:32:44] <Honoome> and they wanted something abstract enough... [01:33:24] <Honoome> I did suggest a couple of times they should have been looking at vlc [01:33:41] <Honoome> up to two years ago there were two active xine devs, me and _ds_... [01:33:57] <Honoome> and I was of the idea that most of xine had to be rewritten from scratch anyway, maybe using glib rather than trying to reinvent the wheel [01:34:35] <Honoome> I started a 1.2 branch that had a bunch of fixes, and used libavutil rather than inventing new things for it, but then I had personal trouble and other priorities stepped up [01:35:13] <Honoome> now I look back, I maintain it was a very good learning experience, but I think it's not worth trying to keep it alive [01:35:45] <peloverde> I'm happy that these days most players aren't implementing their own codecs anymore [01:36:03] <Honoome> even the plugins system is totally fucked up, it can easily use up over 1MB of memory per-instance, simply because of the way the plugins are loadedd [01:37:31] <Honoome> well, I think most of the game formats' demuxers that Mike added are originally coming from xine :) [01:38:02] <peloverde> A bunch of code started as Mike's in xine, was ported to mplayer then ported to ffmpeg [01:38:50] <Honoome> while a bunch of code developed by I-don't-want-to-ask-who as RTSP demuxer in xine was ported to vlc and mplayer and caused a string of security vulnerabilities [01:38:51] <Honoome> hrm [01:39:14] <Honoome> [half of which I fixed months before reports, but I never noticed they were security vulnerabilities in the first place] [01:40:26] <peloverde> There are still so many potential buffer disasters it is kind of funny [01:40:39] <peloverde> indeo3 frightens me [01:40:44] <Honoome> in the rtsp code from xine or in ffmpeg in general? :P [01:40:50] <peloverde> ffmpeg in general [01:41:18] <Honoome> heh I wonder why Google didn't unleash their security team over the FFmpeg codebase since they are using it [01:41:26] <Honoome> probably they focused on h264 and webm [01:41:31] <peloverde> They did over the parts they use [01:41:43] <peloverde> aac, vorbis, h.264, mov, ogg, and theora [01:41:50] <peloverde> (plus any sucked in common code) [01:42:02] <peloverde> forgot mp3 [01:42:17] <peloverde> but they also have some ugly patches like a checked git_bits() [01:42:46] <peloverde> My guess is youtube just runs in a sandbox [01:42:47] <Honoome> they are a bunch of ugly patchers in general, worse I ever only seen in FreeBSD [01:44:51] <peloverde> In general certain features are very hard to fuzz because they require intracte structure to even be activated [01:45:13] <peloverde> To fuzz SBR I had to start after the first SBR I-frame [01:45:52] <peloverde> PS is even messier, to fuzz it you need to choose very narrow ranges to get good coverage [01:46:37] <Honoome> I'm afraid I'm not experienced enough in fuzzying, I'm more for static analysis even though I know its limits [01:47:44] <Honoome> I could be reading the Fuzzying book rather than the diabetes one before sleeping but I'm not sure if that's going to be an improvement [01:49:32] <Honoome> one will scare the heck out of me, the other will keep me reasoning on how to make good use of it on my projects... nah, not goodnight books for sure [03:07:13] <peloverde> Does binutils include a c++ nameunmangler? [03:19:05] <hyc> yes [03:19:07] <hyc> :P [03:19:33] <hyc> someone else can answer again when he comes back... [04:21:05] <_av500_> 42 [05:03:20] <hyc> hmmm. reading the opencore source code, they do support RTP/TCP [05:03:28] <hyc> I just haven't found out how they specify to use it [05:54:13] <hyc> bahh. //For transport options, we only let server choose between "RTP/AVP/UDP" or "x-pn-tng/tcp" [06:16:34] <Tjoppen> morrn [06:19:59] <av500> gm [06:21:00] <Tjoppen> ooh, srt parser/muxer/demuxer on ml [06:22:55] <Tjoppen> shouldn't the demuxer end the packets just before the next "foo --> bar" line? [06:31:46] <Tjoppen> ah, it sets itself to AVSTREAM_PARSE_FULL. maybe I should look into exactly how parsing works [06:37:26] <wbs> hyc: actually, when looking at the latest opencore code, it does seem to support rtsp/tcp, using rtspt:// urls... but I'm not sure how to launch such an url, at least in the browser, it just doesn't recognize the url scheme [06:37:37] <wbs> hyc: (I'm testing on android 2.2) [06:39:18] <av500> wbs: write a small test app that opens this url in a VideoView or so... [06:39:56] <wbs> yeah, I guess that's an option [06:43:05] <wbs> agh, nah, I don't think there's any point in that yet at least - the rtspt url handling in opencore doesn't seem to exist in the version tagged for 2.2 [06:45:10] <av500> wbs: you know, android is open source, you could send them a patch :) [06:46:03] <wbs> yes, but how do you send a patch that says "please use the latest master branch of this project for the next release, instead of just using a year old branch"? [06:46:15] <wbs> it seems that the code for this was added in august last year or so [06:46:28] <wbs> but even the 2.2 release that came out just recently still doesn't include it [06:46:56] <wbs> av500: and I've already got a handful of patches merged in android [06:47:11] * av500 bows to wbs [06:47:46] <wbs> the gerrit code review system is quite neat in one way, for those projects that actually use it properly [06:48:31] <wbs> opencore is nasty though... you send in a patch, they approve it, but don't merge the actual git commit that you sent in, instead they do a similar (but not necessarily identical) change in their own code tree, that gets propagated out in the next code dump, and then tell you to close your patch ticket [06:48:42] <wbs> so there's hardly any traceback to the original author of the fix [06:57:54] <wbs> it's a bit disgruntling when patch handling, such as this one, https://review.source.android.com/10904 or https://review.source.android.com/10906 end up like this: https://android.git.kernel.org/?p=platform%2Fexternal%2Fopencore.git;a=comm… [06:58:12] <wbs> "This patch should now be present in the head of the master master branch. Please confirm and then abandon this change. Thank you for the contribution." [07:02:39] <av500> wbs: ic [07:03:56] <wbs> with other android repos, that uses the code review system properly though, the contributions end up as proper git commits merged into the history, with all the original author info preserved properly, such as https://android.git.kernel.org/?p=platform%2Fbionic.git;a=commit;h=c88110e2… [07:05:19] <av500> I guess the opencore stuff gets fwd'ed to oc themselves... [07:05:39] <wbs> yeah, and maintained in their own repo, and then just exports commits from there out into the public git [07:05:53] <av500> yeah [07:06:08] <wbs> earlier, they actually did merges of public contributions in the public git tree, which then partially were overwritten by accident by the next code drop [07:06:16] <av500> :) [07:06:16] <wbs> so in that sense, this approach at least is less error prone [07:31:38] <hyc> wbs: I only have 2.1 on my G1 [07:32:12] <wbs> hyc: ok.. well, they still seem to have too old opencore version in 2.2, too [07:32:23] <wbs> they're still using an opencore based on something from march 2009 [07:32:55] <hyc> oh well [07:32:55] <wbs> with lots of new fancy features in the master branch, seemingly just gathering dust since the official releases don't use it [07:33:10] <hyc> I found the rtspt stuff in this tree too, but right, the browser doesn't pass it thru [07:34:09] <hyc> and even if it did, I'm not sure that tunneled RTSP is what we want... [07:35:33] <lu_zero> hi [07:36:01] <hyc> rtspt -> PVMF_MIME_DATA_SOURCE_RTSP_TUNNELLING [07:36:15] <lu_zero> rtspt ? [07:36:37] <wbs> lu_zero: in the opencore media framework, they use rtspt:// urls to indicate that they want tcp interleaving [07:36:48] <hyc> lu_zero: I was looking for a way to use RTP/TCP in opencore on android [07:36:50] <lu_zero> -_- [07:36:59] <hyc> I am not convinced rtspt is actually RTP/TCP tho [07:37:05] <wbs> umm, yes it is [07:37:45] <hyc> maybe things look different in your tree, perhaps I should update [07:38:53] <wbs> rtspt:// seems to be handled by opencore/nodes/streaming/streamingmanager/plugins/rtsptunicast..., and this sets rtspExtIntf->SetStreamingType(PVRTSP_3GPP_TCP); [07:38:55] <lu_zero> hyc: if you happen to get an application for android please tell me if opencore is interoperable with feng [07:39:24] <hyc> I can probably tell you that right now, if you have a feng server handy [07:39:25] <lu_zero> Honoome: you tried something on it as well [07:39:40] <hyc> I have the code here but I never installed/configured it [07:39:55] <hyc> wbs: ok that makes more sense [07:40:24] <wbs> the terminology tunneling vs interleaving for rtsp/tcp is mostly just what you prefer to call it [07:40:26] <hyc> I saw the code in pvmf_streaming_manager_node.cpp that says "check if tunelling plugin is to be instantiated" [07:40:32] <lu_zero> rtsp://backstage2.esof2010.org/live/live_12.sd [07:40:35] <hyc> but I hadn't found the plugin itself [07:40:43] <lu_zero> live with mpeg2 stuff inside [07:40:56] <hyc> mpeg2 probably won't work [07:41:03] <hyc> mpeg4, h.263, h.264bp [07:41:37] <lu_zero> rtsp://media.lscube.org/tests/tc.mov [07:42:23] <lu_zero> h264+mp3 might work? [07:42:27] <hyc> could not be played [07:42:32] <hyc> (tc.mov) [07:42:33] <wbs> don't think mp3 is supported there [07:42:37] <lu_zero> -_- [07:42:40] <lu_zero> sigh [07:42:42] <lu_zero> just amr? [07:42:46] <hyc> aac [07:42:55] <lu_zero> let me find a file like that [07:44:20] <av500> amr or aac [07:44:48] <hyc> wbs: ah, my plugins directory only has rtspunicast, no rtspstunicast [07:45:02] <hyc> rtspt ... [07:45:08] <lu_zero> rtsp://backstage6.esof2010.org/esof_greetings.mov [07:45:37] <lu_zero> that might work [07:45:43] <lu_zero> h264+aac [07:46:02] <hyc> failed [07:46:12] <lu_zero> how? [07:46:12] <hyc> it has to be h.264BP [07:46:21] <lu_zero> sigh -_- [07:46:21] <hyc> lemme see what ffprobe / ffplay tells me [07:46:26] <lu_zero> that picky? [07:46:42] <wbs> lu_zero: very few phones support h264 main profile [07:46:49] <hyc> yep, very picky [07:46:54] <av500> base profile [07:47:13] <lu_zero> sigh [07:47:31] <hyc> ffprobe has some error messages on that stream too [07:47:35] <av500> lu_zero: it plays in my own media player stack! :) [07:47:48] <av500> but spits out a lot of h264 errors from lavc.. [07:47:51] <wbs> lu_zero: I'm testing against sample_100kbit.mp4 from DSS, with feng... it stays at "Loading video" for forever, and then stops with "cannot be played" after >30 sec [07:48:04] <hyc> by the way, it seems like something broke re h264 between r239xx and r24034 [07:48:43] <hyc> I can no longer play H.264 flv streams from ffserver [07:48:56] <hyc> and it was working at r239xx [07:49:13] <wbs> lu_zero: that particular file works just fine when served by DSS [07:49:22] <lu_zero> auhmm [07:49:31] <lu_zero> add another bug about compatibility ^^ [07:49:48] <lu_zero> hyc: can you bisect it? [07:49:51] <hyc> wbs: probably the hint tracks [07:50:02] <wbs> hyc: umm, no [07:50:11] <hyc> ffserver barfed on them, anyway [07:50:22] <hyc> lu_zero: I'll try to narrow it down later [07:50:44] <wbs> hint tracks are necessary for DSS to serve it, but feng has its own packetizers and doesn't use the hint track, but they don't matter if they're present [07:51:02] <hyc> ok [07:51:03] <wbs> the same file works fine when served by feng, when watching using ffplay [07:52:02] <hyc> lu_zero: oh, I just noticed, your esof_greetings.mov is 480x368, my G1 can only play up to 480x320 [07:52:35] <hyc> so that may also be the reason it refused to play... [07:54:31] <hyc> cool, SRT parser. muxer/demuxer? shouldn't it just be a track in some other muxed file? [07:57:46] <hyc> anyone have any suggestions on https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/091570.html ? [07:58:31] <hyc> Luca's patch worked, but he's still fretting over code duplication [07:59:15] <hyc> and we're only talking about 1-2 lines of code here. refactoring h264.c seems to be more effort than it's worth. [08:00:25] <Tjoppen> if you can demux SRT in .avi it makes sense to be able to demux regular .srt files [08:01:05] <hyc> Tjoppen: ok, was just curious [08:01:29] <wbs> lu_zero: actually, it seems to work with the android player, but it seems like you've broken http://bugs.lscube.org/show_bug.cgi?id=3 again [08:01:51] <hyc> without Luca's patch ffserver is totally broken for flv h.264. (but with his patch it's still broken right now, I need to figure out why.) [08:02:18] <Tjoppen> I was actually thinking a bit about this earlier.. noone really protested to my idea of having subtitle demuxers. good to see someone finally getting around to it [08:02:44] <lu_zero> no [08:02:49] <lu_zero> =E [08:02:51] <hyc> I was thinking of adding subtitle mux/demux for FLV [08:03:05] <hyc> but at the moment it seems like a lot of hassle and probably few players support it [08:03:07] <lu_zero> how so? [08:03:23] <Tjoppen> I'm going to add an EBU/STL demuxer later [08:03:30] <av500> hyc: there are flvs with subs inside? [08:03:44] <hyc> av500: there can be, but there's no single standard for them [08:03:53] <av500> any in the wild at all? [08:03:55] <hyc> FLVs can contain an event list in the metadata [08:04:05] <hyc> and one of the event types is text [08:04:05] <av500> yes, I remember now, we talked about it [08:04:08] <hyc> yep [08:04:17] <hyc> I had actually dug up some samples [08:04:21] <hyc> don't remember where I left them [08:04:48] <KotH> hyc: i hope you left them on mphq ;) [08:05:05] <hyc> mmmmmm.... oops [08:06:03] <KotH> hmm^2 [08:06:11] <KotH> why are there only 3g free space left in incomming? [08:06:14] <hyc> sigh. don't remember at the moment. and I would hate to accidentally upload a porn clip instead... [08:06:33] <KotH> we dont mind porn clips as long as it's not gay porn ;) [08:06:41] <hyc> lol [08:07:18] <hyc> av500: I think I got derailed by the whole "closed captions are not the same as subtitles" thing [08:07:50] <av500> KotH: maybe you should state porn preference in sample upload rules.... [08:08:08] <hyc> support for both is so obscure in FLV, it all seemed too fractured [08:08:09] <av500> so ppl know [08:08:14] <KotH> av500: i dont have a porn preference, it's just that i dont mind it :) [08:08:30] <av500> no, which kind is ok to upload... [08:19:29] <lu_zero> av500: that's remind me the 1s april idea of committing a porn-optimized codec [08:21:39] <kshishkov> whom shall we ask for test data to tune it? [08:24:15] <lu_zero> pff [08:26:04] <twice11> I heard rumors of sites where you can download many .flv samples. [08:26:16] <kshishkov> youtube? [08:26:24] <twice11> For porn samples, I mean. Without need of special firefox extensions. [08:26:40] <kshishkov> I don't care anyway [08:30:42] <lu_zero> wbs: how to test the regression? [08:32:29] <wbs> lu_zero: you print source=... in the Transport header in SETUP replies [08:32:55] <wbs> lu_zero: if you print source=0.0.0.0, you probably used the same ip for binding the local udp socket, too [08:41:37] <ohsix> peloverde: c++-filt? [08:50:47] <hyc> nm will already demangle for you [08:51:15] <Tjoppen> the vc1 decoder seems to be very flaky. I've managed to crash it several times today [08:51:42] <kshishkov> huh? [08:53:19] <Tjoppen> I'm hacking with mainconcept, and about half of its output crashes the decoder [08:55:46] <Tjoppen> the short story is it crashes in the call to MPV_common_end() in vc1_decode_end() [08:56:40] <kshishkov> any details [08:56:56] <kshishkov> while I'm mere maintainer of VC-1 decoder, I may be interested in that [08:57:17] <Tjoppen> yes, I suspected that. I'll post an issue [08:59:25] <Tjoppen> another interesting thing is that it thinks the file is 720x576 when it's 1440x576 [08:59:41] <Tjoppen> but that might be mainconcept screwing up [09:04:20] <hyc> how ironic. watching my G1 phone on my G1 phone freezes up. http://m.youtube.com/watch?gl=US&client=mv-google&xl_blz_off=xl_blz_off&hl=… [09:21:45] <Tjoppen> kshishkov: https://roundup.ffmpeg.org/issue2076 /MPlayer/incoming/vc1-double-free [09:24:03] <kshishkov> thanks [09:29:07] <kshishkov> hmm, looks like it tries writing past the picture [09:30:03] <av500> onto the wooden table? [09:34:29] <lu_zero> av500: onto the wall [09:34:32] <lu_zero> in the other room [09:34:47] <av500> so you get room access violation? [09:36:39] <lu_zero> and the guard complains [09:38:05] <elenril> lu_zero: why are we still using svn ;) [09:44:13] <lu_zero> mru: you got time next week? [09:44:21] <lu_zero> elenril: complain in ml [09:44:44] <lu_zero> hi DonDiego [09:44:49] <mru> time for what? [09:46:01] <lu_zero> migrate to git once the elenril email lands [09:47:09] <elenril> meh, complaining here is easier ;) [09:49:42] <lu_zero> elenril: do that or no git till the next meeting =P [09:50:49] <KotH> elenril is complaining? [10:01:52] <lu_zero> KotH: we should pick a day to move roundup tell me when you are free [10:02:03] <KotH> lol [10:02:06] * KotH is never free [10:02:15] <KotH> ok, maybe in december or so [10:02:40] <KotH> tell me when you want to do it and i try to make it free [10:05:57] <lu_zero> 5 months and the server will be dismissed ^^ [10:08:04] <lu_zero> otherwise give me an account on the place or I'll give you the accounts on the server/other server [10:08:13] <superdump> lu_zero, mru : did you figure out how you wanted to manage accounts? [10:08:21] <superdump> iirc mru didn't want to give people shell accounts [10:10:01] <KotH> we dont give out shell accounts unless there is a need for it [10:10:13] <iive> superdump: KotH is the "owner" of the server. [10:10:27] <KotH> and only to those people we trust enough that they can keep their ssh key and their own machine secure enough [10:10:41] <kshishkov> i.e. nobody [10:10:46] <KotH> iive: owner is the wrong word. i'm only the legal representative [10:11:08] <lu_zero> KotH: gitolite or gitosis [10:11:36] <iive> KotH: that's why I used "" [10:11:48] <superdump> gitolite? not heard of that one [10:11:54] <superdump> is the project actively maintained? [10:11:55] <lu_zero> gitosis in perl [10:12:13] <kshishkov> lu_zero: why both sound like a disease names? [10:12:20] * KotH trusts perl coders more than python coders [10:12:26] <lu_zero> gitosis is in python and is more or less maintained by gentoo [10:12:35] <lu_zero> KotH: install gitolite then =) [10:12:53] <lu_zero> http://github.com/sitaramc/gitolite [10:12:54] <KotH> lu_zero: open a bug on bugzilla using the mphq cateogry :) [10:13:01] <lu_zero> KotH: ok [10:13:39] * KotH has first to see who can produce this damn PCB within 3 weeks [10:13:48] <mru> it doesn't take more than 5 lines of shell script to set up a shared account [10:14:31] <lu_zero> KotH: which bugzilla btw? I cannot see the mphq category [10:15:06] <lu_zero> mru: a bit more if you want to expand the concept [10:15:35] <KotH> lu_zero: bugzilla.mphq [10:15:47] <mru> my main concern is with accounting, how to know which real person did what [10:16:30] <KotH> .o0(japanese invasion) [10:17:08] <lu_zero> hi henry_ [10:21:13] <CIA-99> ffmpeg: cehoyos * r24079 /trunk/libavformat/img2.c: Associate .tga with format image2. [10:22:50] <lu_zero> mru: you'd like to use gpg signed commits? [10:23:31] <mru> no, that solves a different problem [10:24:18] <mru> I want every access to the 'git' account logged in a way I can trace back to a real person [10:24:28] <thresh> uhm, ssh logins? [10:24:39] <mru> I do not want to hand out ssh logins to everybody [10:24:54] <thresh> how would you enable someone to commit without it? [10:25:03] <mru> shared account and ssh keys [10:25:12] <mru> read the backlog dammit [10:25:17] <thresh> doesnt git push involve ssh login? [10:25:21] <thresh> not involve i mean [10:25:25] <CIA-99> ffmpeg: cehoyos * r24080 /trunk/libavcodec/wmadec.c: [10:25:25] <CIA-99> ffmpeg: Silence warning "new qualifiers in middle of multi-level [10:25:25] <CIA-99> ffmpeg: non-const cast are unsafe". [10:25:25] <CIA-99> ffmpeg: Patch by Eli Friedman, eli d friedman a gmail [10:26:12] <mru> anyway, ssh has means of identifying the key used for login [10:26:17] <mru> that's good enough for me [10:27:00] <lu_zero> thresh: you can have a single ssh account restricted for the gitosis/gitolite/whatever daemon [10:37:19] <CIA-99> ffmpeg: michael * r24081 /trunk/libavcodec/mpegaudiodec.c: [10:37:19] <CIA-99> ffmpeg: Move ff_dct_init(context) out of if(one time init) [10:37:19] <CIA-99> ffmpeg: fixes calling a null pointer in issue658 [10:39:57] <CIA-99> ffmpeg: michael * r24082 /trunk/libavformat/asfdec.c: [10:39:57] <CIA-99> ffmpeg: Ignore extradata & w/h in asf/dvr. [10:39:57] <CIA-99> ffmpeg: The w/h values are wrong and extradata contains a fake seq header that causes [10:39:57] <CIA-99> ffmpeg: decoding to fail later, a valid seq header is in the stream itself. [10:39:57] <CIA-99> ffmpeg: Fixes issue658 [10:58:06] * mru lols at the clueless idiots on doom9 [10:58:18] <mru> "AFAIK, floating point decoding is most useful when you're doing transcoding. I don't think it's THAT important for playback" [10:59:17] * elenril thinks the dshow guy responses were more lulzy [10:59:32] <mru> "I know float is slower, but most people care more about quality. [10:59:37] <iive> you should probably thank tomshardware benchmarks on flaskmpeg mpeg2->4 tanscoding tool for that. [11:01:21] <lu_zero> ?? [11:02:05] <elenril> lu_zero: http://forum.doom9.org/showthread.php?t=155516 [12:28:42] <CIA-99> ffmpeg: mru * r24083 /trunk/libavcodec/motion_est.c: [12:28:42] <CIA-99> ffmpeg: motion_est: fix implicit truncation warnings [12:28:42] <CIA-99> ffmpeg: Patch by Reimar D?ffinger and Eli Friedman (independently). [13:11:53] <CIA-99> ffmpeg: aurel * r24084 /trunk/libavformat/ (assenc.c assdec.c): imporve long_name for ass (de)muxer [14:34:02] <Tjoppen> heh, michael worrying about libavutil containing multimedia stuff. look at the name of the library :) [14:34:48] <mru> it was created by splitting some parts off lavc [14:35:19] <kshishkov> does that mean lavc contains multimedia stuff too? [14:35:25] <Tjoppen> gasp! [14:36:34] <av500> Tjoppen: here "av" = absolutely versatile [14:36:52] <mru> ambiguously vague [14:37:01] <av500> +1 [14:37:17] <av500> btw, wtf is that lowres? [14:37:31] <mru> downscaling a la IJG [14:37:39] <mru> partial idct [14:37:39] <av500> and that is needed where? [14:37:43] <mru> nowhere [14:37:47] <av500> ah like IJG [14:37:53] <mru> it's obviously a tad faster [14:38:03] <av500> the 80s are over, no? [14:38:28] <mru> judging by prevailing hairstyles, yes [14:39:29] <av500> http://www.flickr.com/photos/av500/4767108775/in/set-72157624309805057/ [14:40:01] <Tjoppen> :) [17:28:32] <CIA-99> ffmpeg: mru * r24085 /trunk/libavutil/intmath.h: intmath: whitespace cosmetics [17:28:32] <CIA-99> ffmpeg: mru * r24086 /trunk/libavutil/ (intmath.h common.h): Remove macro duplication between common.h and intmath.h [17:28:33] <CIA-99> ffmpeg: mru * r24087 /trunk/libavutil/common.h: Allow arch-overrides for all common.h clip and log2 functions [17:28:34] <CIA-99> ffmpeg: mru * r24088 /trunk/libavutil/arm/intmath.h: ARM: intmath.h cosmetics [17:28:34] <CIA-99> ffmpeg: mru * r24089 /trunk/libavutil/arm/intmath.h: ARM: optimised integer clip functions [17:48:07] <peloverde> I don't think anyone is ever going to use libavutil without at at least one other FFmpeg library [17:48:18] <mru> of course not [17:48:21] <Honoome> I wonder what would happen if xorg and the various desktop environments started using libavutil to provide common optimised routines [17:48:31] <skal_zZzZzz_> av500: nice pic :) [17:48:41] <Honoome> peloverde: gha I was thinking the opposite at this point :P [17:48:49] * _skal_ back on earth [17:49:30] * Honoome wonders about an API/ABI-compatible libpng using libavutil... :P [17:49:57] <Honoome> if lu_zero dares me to I might even take a stab at that ;) [17:50:54] <_av500_> Honoome: libavoil? [17:51:11] <Honoome> _av500_: hope not [17:51:24] <Honoome> libavtomic wouldn't be bad though [17:51:35] <Honoome> to repalce that crud that goes under the name libatomic_ops [17:58:33] <_av500_> libikeshed [18:00:54] <Honoome> _av500_: sole maintainer michaelni? [18:04:32] <_av500_> we should vote [18:04:55] <kierank> vote to have a vote too [18:06:06] <_av500_> ffmpeg 0.7 "code, don't vote" [18:07:16] <mru> isn't 0.7 "troll driven development"? [18:07:25] <Honoome> rotfl [18:08:15] <_av500_> mru: we never voted on that, did we? [18:08:21] <mru> trolls don't vote [18:08:39] <kierank> I think _av500_ is becoming a bigger troll than mru [18:10:10] <mru> we should set up another trolling session some weekend while I'm in .de [18:12:10] <_av500_> +1 [18:13:59] <kierank> I want to do that thing KotH suggested a while ago [18:14:05] <kierank> massive meetup of all free multimedia people [18:14:12] <kshishkov> kierank: av500 is the biggest troll indeed [18:14:24] <kierank> except I would expect streetfights to occur [18:15:10] <kierank> like mru vs monty [18:15:20] <Honoome> kierank: like half of us poking sharp sticks at the xiph guys [18:15:48] <kierank> it would end up just turning into various factions [18:15:51] <CIA-99> ffmpeg: jai_menon * r24090 /trunk/ffplay.c: FFplay : Fix segfault when playing monoaural streams. [18:15:52] <kierank> gstreamer, xiph etc [18:17:48] <kshishkov> somebody should invite people from companies like Real or Adobe too (not Mike though) [18:18:25] <mru> inviting Real would be a good troll [18:20:08] <peloverde> Why not Mike? [18:20:22] <mru> not only mike [18:20:28] <jai> asking them for sponsorship might be a nicer troll [18:20:33] <mru> lol [18:21:01] <Honoome> why? Real's still alive? [18:21:18] <iive> is there something left for RE from Real? [18:21:24] <jai> ralf [18:21:52] <iive> ? what is that? [18:21:55] <j0sh> iive: the port-knocking sequence in real's rtsp-http variant [18:21:58] <kierank> some troll codec [18:22:04] <jai> their homegrown lossless codec [18:22:05] <Honoome> j0sh: they use port-knocking?! [18:22:13] <kshishkov> lossless codec named after Ralf Wiggum (from Simpsons) [18:22:28] <j0sh> Honoome: yup, i discovered it in the wild a few weeks ago when working on ffmpeg rtsp-http [18:22:51] * Honoome wonders if feng should be compatible on the server side [18:23:06] <j0sh> i haven't made much of an effort to document it yet [18:23:18] <mru> client-side compat is easy [18:23:26] <mru> just display "buffering..." [18:24:43] <CIA-99> ffmpeg: stefano * r24091 /trunk/libavfilter/avfilter.h: Implement avfilter_copy_picref_props(). [18:24:50] <iive> j0sh: are you sure it doesn't try to use the older protocols first? [18:25:46] <j0sh> iive: it might, from my brief testing it worked OK without the port-knocking urls [18:25:52] <CIA-99> ffmpeg: stefano * r24092 /trunk/ (7 files in 4 dirs): Add pixdesctest filter and corresponding test. [18:26:05] <Honoome> wbs: are you sure the local socket is left with 0.0.0.0? I thought it would have been bound to the correct addres... well, at least I guess I can check it out now on the APUE [18:26:41] <Honoome> saste: uhm since you're around :P -- did we lose the ability to rotate a video or am I blind? [18:27:08] <saste> did we ever had that feature? [18:27:13] <dgt84> Can anybody help me to use eval.h and declare function pointers? [18:27:18] <saste> i mean without libavfilter? [18:27:19] <mru> I don't think we ever did [18:27:44] <mru> dgt84: what kind of function pointers? [18:27:44] <saste> did you tried with rotate in libavfilter-soc? the last time i tried it was working... [18:27:47] <Honoome> saste: good question, I _thought_ we had and lu_zero suggested we had as well, but I wouldn't be ready to bet on that [18:28:04] <Honoome> saste: ah that might be the trick... [18:28:07] <mru> dgt84: will these do? int (*(*(*(*foo)[4])(int (*)(int *)))[2])(int); [18:28:35] <wbs> Honoome: yes, I'm quite sure [18:28:37] <Honoome> mru: ... please tell me you have those on a post-it and you just copy paste them and not re-create them on the fly [18:28:49] <dgt84> mru, whatever crazy structure I need to make to pass to eval.h's av_parse_expr() for funcs2. I'm able to do the const stuff but am not that strong with C for the functions. [18:28:51] <mru> Honoome: yes, I had this one saved [18:29:04] <wbs> Honoome: as a response to setup, it replies "Transport: RTP/AVP;unicast;source=0.0.0.0;client_port=5000-5001;..." [18:29:20] <wbs> Honoome: where the source= address is the same as it used to bind the udp socket a few lines earlier in the same file [18:29:24] <mru> dgt84: just take a suitable function prototype and change funcname to (*funcname) [18:29:38] <Honoome> saste: erm... happen to have the link at hand for the repo? ^^;; [18:29:47] <dgt84> mru, it says it wants "double (* const *funcs2)(void *, double, double)". How would I declare a function for that and how would I make a list of them that complies with the FFmpeg style guidelines? [18:29:48] <Honoome> wbs: okay will check it out... [18:29:57] <saste> ffmpeg.org/libavfilter.html ;-) [18:30:19] <saste> near the top of the file there is the checkout command [18:30:29] <mru> oh, that's a pointer to pointer to function [18:30:43] <dgt84> <head explodes> [18:30:57] <mru> an array of function pointers is probably what you want [18:31:19] <mru> each function should be "double func(void *, double, double)" [18:31:29] <saste> exactly [18:31:47] <saste> dgt84: did you already grepped the libavcodec code for examples? [18:31:57] <mru> then you make an array like so: double (funcs[])(void *, double, double) = { func1, func2, ... } [18:32:12] <Honoome> saste: thanks :) I owe you a coffee or something if one day we get an italian devs meetup (*prod* lu_zero *prod*) [18:32:12] <dgt84> saste, I did not, figured people here knew and could provide a quick answer so I don't get stuck on something stupid ;-) [18:32:28] <mru> sorry, that was wrong [18:32:33] <mru> that was an array of functions [18:32:37] <mru> and that doesn't exist [18:33:05] <mru> should be double (const *funcs[])(void *, double, double) = { ... } [18:33:46] <mru> then you can simply pass "funcs" to the eval.h function [18:34:24] <dgt84> mru, hmmm, this seems to give me "expected identifier or ‘(’ before ‘const’" [18:34:38] <dgt84> using the latest line you pasted [18:34:44] <mru> it was untested [18:35:06] <saste> dgt84: libavcodec/ratecontrol.c [18:35:13] <mru> without the const? [18:35:18] <saste> dgt84: look the definition of func1 [18:36:24] <dgt84> saste, mru, thanks will check out that example and try to get it working [18:36:50] <mru> here's an example straight from the C spec: void (*signal(int sig, void (*func)(int)))(int); [18:37:21] <saste> dgt84: ok, waiting for reviewing your scale patch [18:58:22] <dgt84> saste, argh... what do you recommend for string splitting on ":" in C? strtok seems to stop processing when it reaches the ',' in e.g. "round(H, 16)" [19:04:52] <mru> strtok() isn't threadsafe [19:04:56] <mru> use strtok_r [19:10:47] <blight_> hi is svn broken? [19:11:30] <dgt84> mru, how do you initialize the third parameter (char **save_ptr)? I set it to NULL and get a segfault :-/ [19:12:28] <mru> char *foo; ...; strtok_r(s, sep, &foo); [19:12:37] <mru> oh, and foo=NULL before [19:13:07] <mru> scratch that [19:13:12] <mru> doesn't need init [19:13:19] <mru> but only pass on first call [19:13:30] <dgt84> mru, cool that does work. Still seems to want to stop processing on reaching a comma though... wtf [19:13:52] <mru> damn, I'm confused [19:13:55] <mru> that's strsep [19:14:01] <dgt84> mru, const char *delim = ":"; [19:14:09] <dgt84> you would think that would mean only delimit on ":" right? [19:14:13] <mru> yes [19:14:28] <mru> you can pass a literal ":" to the strtok call if you want [19:14:45] * Honoome would use static const char delim[] = ":"; if you really want to declare it as named var [19:15:13] <mru> Honoome: doing that makes sure you get a private copy of it [19:15:27] <Honoome> mru: note my "if you really want" [19:15:49] <mru> using a pointer you may use a shared string literal [19:16:03] <mru> and the compiler will hopefully not allocate any actual space for the pointer [19:16:17] <Honoome> you'd then need a const char *const delim then [19:16:51] <mru> string constants are not writable by default [19:16:56] <mru> sharing them is perfectly safe [19:17:37] <Honoome> mru: it really makes a difference between const char *const and const char * last I checked with GCC [19:17:43] <dgt84> even passing as a literal it seems to crap out on commas [19:17:49] <mru> Honoome: then gcc is being stupid [19:17:52] <mru> which is hardly news [19:17:54] <Honoome> even within a function context [19:17:59] <Honoome> [it is expected on unit-context] [19:18:29] <Honoome> anyway I'd say the literal is the right choice for strtok_r most of the times ;P [19:18:33] <dgt84> input = "round(W, 2)", calling strtok_r("round(W, 2)", ":", save_ptr) => "round(W" [19:18:57] <mru> dgt84: &save_ptr [19:19:15] <Honoome> char *save_ptr = NULL; and then call it as &save_ptr [19:19:15] <blight_> libavfilter/libavfilter.so: undefined reference to `read_line' <-- i think SVN is broken [19:19:28] <dgt84> mru, yeah I am doing that, sorry. It works between calls, it's just not liking commas for some reason I'm not getting [19:19:29] <mru> blight_: I think not [19:19:52] <mru> dgt84: your font renders : as ,? [19:20:17] <dgt84> I highly doubt that lol [19:20:37] <mru> blight_: sorry, you're right, some idiot (stefano) broke it [19:20:40] <mru> thanks [19:20:46] <blight_> it's broken on windows too i believe [19:21:01] <blight_> libavformat/img2.c: In function 'av_str2id': [19:21:03] <blight_> libavformat/img2.c:112: error: implicit declaration of function 'strcasecmp' [19:21:19] <blight_> the function is called stricmp on windows iirc [19:21:46] <mru> nonstandard [19:21:52] <mru> strcasecmp is standard [19:22:05] <Dark_Shikari> our configure adapts itself for many nonstandard systems [19:22:08] <Dark_Shikari> why is windows different? [19:22:20] <Dark_Shikari> log2 is standard, but BSD doesn't have it. [19:22:23] <Dark_Shikari> So we configure check for it. [19:22:29] <Dark_Shikari> Even though it's required by the C spec. [19:22:47] <mru> nobody ever complained about strcasecmp before [19:22:50] <blight_> mru: i know but it should still compile on windows shouldn it? [19:22:53] <mru> we've been using it for years [19:23:07] <mru> I don't care if it fails on windows [19:23:10] <blight_> ok [19:23:27] <Dark_Shikari> mru: well, then lets roll back the bsd compatibility code, ok? [19:23:32] <Dark_Shikari> we've been using log2 for yeras [19:23:35] <Dark_Shikari> I don't care if it fails on bsd. [19:23:40] <Dark_Shikari> it's a waste of code. [19:24:17] <mru> look ffmpeg works on windows _NOW_ [19:24:23] <mru> it uses strcasecmp _NOW_ [19:24:25] <Dark_Shikari> no it doesn't [19:24:29] <mru> ergo, there is no problem with strcasecmp [19:24:32] <Dark_Shikari> it only works because the people doing windows builds hacked it to work [19:24:34] <Dark_Shikari> to avoid exactly that problem [19:24:39] <mru> hmm [19:24:40] <Dark_Shikari> It's one of the patches that they include [19:24:42] <mru> I didn't know that [19:24:58] <Dark_Shikari> it's a problem related to a define [19:25:07] <Dark_Shikari> the strcasecmp defines are wrapped in ifndef D_STRICT_ANSI [19:25:08] <Dark_Shikari> or something [19:25:11] <Dark_Shikari> (in system headers) [19:25:22] <mru> lol [19:25:34] <mru> it's in iso c99 [19:25:47] <Dark_Shikari> It could be that their implementation isn't strict-ansi compliant or something [19:25:58] <peloverde> I thought *BSD was finally catching up with c99 [19:25:59] <Dark_Shikari> Either way I don't like it when peopel downstream have to apply patches. [19:26:06] <Dark_Shikari> peloverde: yes, in 2018 [19:26:11] <Dark_Shikari> afk, going to work [19:26:45] <peloverde> http://www.freebsd.org/projects/c99/index.html [19:28:39] <dgt84> mru, actually I don't think this is an issue with how I'm calling strtok, but an issue in libavfilter maybe? "error initializing filter 'scale' with args 'round(W:flags=0xA0000004'" [19:29:25] <dgt84> It is chopping my stuff off after the comma because libavfilter uses a comma to delimit filters... so how can one even use eval on filter arguments if you want multiple args? [19:30:04] <dgt84> saste, any ideas ^ [19:30:52] <mru> oh my god [19:30:56] <mru> I can't believe this [19:37:02] <blight_> latest revision committed by mru works on linux [19:37:55] <mru> no [19:38:03] <mru> shared libs are broken at the moment [19:39:00] <iive> you know, richard have made alternative simple libc, we could solve all problems by using it... [19:39:26] <_av500_> fflibc [19:39:39] <mru> libavc [19:39:50] <_av500_> yup [19:40:55] <iive> it is in the mphq svn repository. imho it lacks some of the mind breaking forking and threading gimmics... [19:41:17] <_av500_> autoforking? [19:42:11] <Honoome> hmmm [19:42:52] <j0sh> wbs: how do you track the leaks in ffmpeg's "T.676" functions that valgrind sometimes gives? [19:43:06] <mru> doesn't it give a line number? [19:43:07] <j0sh> actually, where do these even come from? [19:43:13] <j0sh> mru: yeah, it does [19:43:14] <mru> those are generated by the compiler [19:43:33] <mru> it sometimes breaks parts of a function out into a separate function [19:43:35] <j0sh> but everything afterwards is kind of messed up, like it says av_mallocz is in mem.c [19:43:41] <mru> it is [19:44:04] <j0sh> oh, there *is* a mem.c. my bad [19:44:14] <astrange> functions shouldn't be named T.676, iirc newer gcc gives better function names in the interprocedural optimizations [19:44:42] <j0sh> time to update gcc then? [19:44:44] <astrange> but it still has problems like emitting warnings for "get_bits.clone.0" instead of "get_bits" [19:44:58] <j0sh> im using 4.4.3 [19:45:05] <astrange> try 4.5.whatever then [19:45:08] <j0sh> ok [19:46:14] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-r24078/ if someone wants to go through the noise [19:47:25] <j0sh> astrange: that's a really cool tool. does it come with clang? [19:47:51] <peloverde> kind of [19:47:59] <Honoome> hm that's a nice one indeed [19:48:02] <astrange> http://clang-analyzer.llvm.org/ [19:48:15] <Honoome> lu_zero: if it's not in portage I want it now! :P [19:48:36] <astrange> clang --analyze works but emits something annoying instead of that html page, if you aren't on os x [19:48:53] <astrange> you might be able to get it to print analyzer stuff like regular warnings [19:53:46] <mru> ah, _now_ I understand why they're called static analysers [19:54:10] <mru> the output resembles static (line noise) [19:54:28] <Dark_Shikari> clang actually is pretty accurate IMO [19:54:35] <Dark_Shikari> if you ignore the dead stores, it's only about 90% noise [19:54:38] <mru> only 97% noise eh? [19:54:41] <Dark_Shikari> which is actually enough to work through [19:54:44] <Dark_Shikari> unlike, say, lint. [19:54:51] <mru> lint is totally rubbish [19:54:55] <Dark_Shikari> Exactly [19:54:55] <mru> it does one statement at a time [19:55:07] <Dark_Shikari> lint has both problems [19:55:08] <mru> there's now way that can be accurate _or_ useful [19:55:10] <Dark_Shikari> it doesn't give useful results [19:55:16] <mru> s/now/no/ [19:55:17] <Dark_Shikari> and the useless non-results are mixed in with thousands of junk reuslts [19:55:28] <Dark_Shikari> YOU FORGOT FIVE EXTRA PARENS HERE. [19:55:48] <mru> my favourite is when it whinges about a+b+c [19:55:52] <Dark_Shikari> speaking of which, I think we should keep the gcc extra paren warnings [19:55:53] <mru> it wants (a+b)+c [19:55:56] <Dark_Shikari> re that mailing list thread [19:56:03] <Honoome> Dark_Shikari: hm is it intended that the presets for ipod640 and ipod320 are tfu? :P [19:56:25] <mru> yeah, as long as gcc doesn't go too over the top with them [19:56:31] <mru> it's got worse over the years [20:00:01] <j0sh> http://www.tbray.org/ongoing/When/201x/2010/06/29/No-Defaults [20:00:40] <j0sh> i agree with him [20:00:51] <j0sh> eg, keeping sorta-extraneous things like parens to make the code readable [20:01:14] <mru> but only when it makes it more readable, not less [20:01:41] <mru> you can often achieve a natural grouping with whitespace instead [20:02:11] <mru> write not (a << 24) | (b << 16) | (c << 8) | d [20:02:19] <mru> but a<<24 | b<<16 | c<<8 | d [20:02:23] <j0sh> sometimes if the operator precedence rules aren't completely clear, parens are the safer way [20:02:46] <Dark_Shikari> as long as our code doesn't look like theora's [20:02:50] <Dark_Shikari> aka "no spaces, no parens" [20:03:18] <mru> j0sh: only when you can't remember the rules, or the precedence differs radically from what formatting makes it look like [20:03:22] <Honoome> Dark_Shikari: no sense! [20:04:04] <CIA-99> ffmpeg: alexc * r24093 /trunk/libavformat/adtsenc.c: Cosmetics: whitespace [20:04:11] <j0sh> from the article: "I’ve learned a lot of programming languages over the years, and I’ve taken care never to learn the operator precedence rules in any of them." [20:04:29] <mru> idiot and proud of it [20:04:33] <j0sh> whether that's smart or not is up for debate, heh [20:04:50] * Honoome cries because of x264 presets! [20:04:59] <mru> placebo ftw [20:05:03] <_av500_> when i started i sprinkled parens all over the code [20:05:21] <_av500_> nowi try to use the precendce rulez [20:05:21] <peloverde> I wonder if he does that for all his "+"s and "*"s too [20:06:16] <mru> C is not Lisp dammit [20:06:22] <mru> if you want parens, code in lisp [20:06:43] <peloverde> Also anyone who has studied boolean algebra knows the order of operations for logical operators [20:06:52] <mru> the irony is that those who complain the most about precedence rules have the hardest time using postfix or prefix notation [20:07:08] <mru> peloverde: and anyone who hasn't has no business near a computer [20:07:13] <peloverde> indeed [20:08:57] <mru> the C operator precedence is quite sane too [20:09:06] <mru> it minimises the amount of parens in common situations [20:10:27] <CIA-99> ffmpeg: mru * r24094 /trunk/libavcodec/arm/fft_neon.S: ARM: hide a .size directive on non-ELF targets [20:10:28] <CIA-99> ffmpeg: mru * r24095 /trunk/libavcodec/arm/asm.S: [20:10:29] <CIA-99> ffmpeg: ARM: set section to .text in 'function' macro [20:10:29] <CIA-99> ffmpeg: This ensures code always goes into the .text section and avoids the [20:10:29] <CIA-99> ffmpeg: need to specify it explicitly after changing sections. [20:10:29] <CIA-99> ffmpeg: mru * r24096 /trunk/libavcodec/arm/simple_idct_neon.S: ARM: remove unnecessary .previous directive [20:10:40] <peloverde> WTF! Why did CT decide to make the first signaling test file have a slightly different payload than the others? [20:24:48] <CIA-99> ffmpeg: mru * r24097 /trunk/libavcodec/aacdec.c: aacdec: remove checks for impossible error conditions [21:10:14] <saste> someone has an idea about what's going on with read_line / write_line? [21:10:25] <saste> that's killing half fate builds... [21:14:02] <mru> it's not exported from the shared lib [21:14:05] <mru> missing av_ prefix [21:18:32] <saste> weird don't we have lots of non av_ prefixed functions? [21:18:59] <saste> but maybe they are the only one in lavu... [21:22:57] <BBB> omg @ several 100 kb of headers on ffmpeg-soc [21:24:33] <CIA-99> ffmpeg: cehoyos * r24098 /trunk/libavcodec/ (20 files): Add new decoder property max_lowres and do not init decoder if requested value is higher. [21:29:06] <j0sh> BBB: at least they are very well commented :) [21:29:19] <BBB> no, they have a lot of comments [21:29:25] <BBB> that doesn't mean they are well commented [21:29:30] <j0sh> heh [21:31:38] <j0sh> BBB: what's the different between sebastian and hemanth's projects? [21:31:56] <BBB> hemanth does avfilter for audio [21:32:02] <BBB> sebastian does mod file support [21:35:17] <j0sh> a mod file? [21:35:30] <kierank> some random amiga thing [21:35:48] <kierank> that sebastian takes very seriously [21:36:01] <BBB> google for (lib)modplug or (lib)mikmod [21:36:03] <_av500_> ;) [21:39:13] <mru> saste: it would be nice if you prefixed you're patch mail subjects with just [PATCH] [21:39:21] <mru> not [random-junk PATCH] [21:46:05] <mchinen> anyone want to help me commit my patch from a few days ago? [21:46:18] <mchinen> move put_v [21:49:47] <CIA-99> ffmpeg: alexc * r24099 /trunk/libavcodec/aacenc.c: aacenc: Enforce LFE bitstream restrictions. [21:50:27] <BBB> mchinen: ping it once... if nobody's done it toorrow, I'll do it [21:50:33] <BBB> mchinen: usually carl eugen or someone will commit [21:51:41] <CIA-99> ffmpeg: alexc * r24100 /trunk/libavcodec/aacenc.c: Cosmetics: whitespace [21:51:59] <mchinen> thanks [22:09:34] <BBB> j0sh: nice patch! [22:09:42] <BBB> I basically have no comments ;) [22:09:45] <Dark_Shikari> BBB: status on loopfilter btw? =p [22:10:01] <BBB> Dark_Shikari: was reviewing stuff yesterday/daybefore, I restarted work today [22:10:17] <Dark_Shikari> k [22:10:19] <BBB> for V-inner, I have most checks complete, I have about 10-20 instructions for filter_common to write [22:10:22] <BBB> it's pretty much done [22:10:34] <BBB> I already added the transpose steps for H, so H should be easy [22:10:44] <BBB> after that I'll do mbedge [22:10:55] <BBB> or the U/V combined one [22:11:09] <BBB> I'm now looking at sebastian's code for modfile support [22:11:12] <BBB> ... [22:34:09] <merbanan> BBB: omg, qdm2 rtp packetization [22:34:17] <merbanan> why in the world [22:34:19] <BBB> I wrote that a long time ago [22:34:23] <merbanan> is it used by someone ? [22:34:25] <BBB> yes [22:34:31] <BBB> also, quicktime/apple supports it [22:34:48] <merbanan> mein godt [22:34:50] <BBB> it was my first succesful RE project :-p [22:34:56] <merbanan> he ;) [22:35:04] <BBB> "how to do something productive in IDA" [22:35:08] <BBB> just before wmavoice [22:43:36] <j0sh> BBB: sweet [23:42:30] <CIA-99> ffmpeg: mru * r24101 /trunk/ (3 files in 2 dirs): [23:42:31] <CIA-99> ffmpeg: Rename read/write_line() to av_read/write_image_line(). [23:42:31] <CIA-99> ffmpeg: The old names were not av_ prefixed, and they were causing linking [23:42:31] <CIA-99> ffmpeg: failure on many platforms. The new names are also more descriptive. [23:42:31] <CIA-99> ffmpeg: Patch by Stefano Sabatini. [23:48:39] <CIA-99> ffmpeg: michael * r24102 /trunk/libavutil/random_seed.c: get_generic_seed() for the cases without /dev/random and AV_READ_TIME [23:50:06] <mru> auughh, I hate michael's "var= value" style [23:50:33] <kierank> i also hate that [23:50:42] <kierank> especially where it's mixed [23:51:28] <Dark_Shikari> +1 [23:53:13] <CIA-99> ffmpeg: jbr * r24103 /trunk/libavcodec/ac3_parser.c: [23:53:13] <CIA-99> ffmpeg: ac3: make the value of codec_id during (E-)AC-3 parsing stay CODEC_ID_EAC3 [23:53:13] <CIA-99> ffmpeg: if any E-AC-3 frames have been detected instead of switching back and forth for [23:53:13] <CIA-99> ffmpeg: AC-3 core + dependent E-AC-3 substream(s). [23:53:13] <CIA-99> ffmpeg: Fixes Issue 2022. [23:57:50] <saste> mru: thanks, I'll commit reindent and APIchanges tomorrow, i badly need to sleep now [23:58:01] <saste> goodnight [23:58:03] <mru> I didn't know you were still awake [23:58:13] <mru> so I committed it [23:58:19] <saste> good thanks

1 0

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

07 Jul '10

[00:07:07] <CIA-99> ffmpeg: mru * r24068 /trunk/libavcodec/aacenc.c: [00:07:07] <CIA-99> ffmpeg: aacenc: replace VLA with fixed size [00:07:07] <CIA-99> ffmpeg: Number of channels is restricted to 6 so the size is acceptable [00:07:07] <CIA-99> ffmpeg: for the stack. [00:10:00] <Honoome> I hate summer >_< [00:10:25] <mru> heat knock out your server? [00:10:41] <Honoome> no it's knocking out me :/ [00:11:39] <Honoome> and I can't get to my office where I have firefox (yamato is online, and building... it's _hot_) here I don't have it and the tyan website fails [00:12:38] <mru> feel free to investigate the fate failures [00:12:49] <Honoome> which fate failures? [00:12:58] * Honoome hopes nothing related to tablegen [00:13:05] <mru> regtest-mxf and one other [00:13:15] <mru> a commit by stefano broke them [00:13:30] <Honoome> mxf reminds me of something [00:13:41] <mru> r24066 is the bad one [00:14:18] <Honoome> oh by the way, the util-linux-ng rewritten buildsystem is published, and Kay Sievers seems to be in favour of it :P [00:14:30] <mru> :-) [00:14:51] <mru> he seems mostly resonable from what I've seen [00:15:18] <Honoome> yeah, he just dislike hacks, can't blame him [00:15:53] <mru> if everybody did that, the world would be a better place [00:16:59] <Honoome> most people are too busy with correcting people with "it's GNU/Linux.." [00:18:41] <Honoome> or in the case of monty trying to get back "his"sql :P [00:20:31] <Katrinplommon> is there anyone in here who is unemployed with alot of time on their hands and likes looking into odd vcd standards from the mid 1990s [00:23:25] <Katrinplommon> or where is the correct place to paste codec requests on the official forum? [03:29:05] <peloverde> Katrinplommon: Format requests can be filed in the bug tracker [03:29:49] <peloverde> http://roundup.ffmpeg.org [03:42:13] <Dark_Shikari> Yuvi: thought on storing words for deblocking [03:42:51] <Dark_Shikari> if the deblocking filter stores 2 bytes, it might be better to store 1 byte at a time when on mb edge [03:42:54] <Dark_Shikari> in case it crosses a cacheline [03:42:55] <Dark_Shikari> (on intel) [03:43:14] <Dark_Shikari> cost of normal store: 1 clock [03:43:18] <Dark_Shikari> cost of cacheline store: 14 clocks [03:43:26] <Dark_Shikari> amortized for mbedges: 1 * 0.75 + 14 * 0.25 [03:43:40] <Dark_Shikari> = 4.25 clocks [03:43:43] <Katrinplommon> peloverde it's very weird that roundup is in the chrome virus filter [03:44:29] <Dark_Shikari> storing byte-at-a-time will save 2.25 clocks amortized, times 16 = 32.5 clocks per edge [03:44:46] <Dark_Shikari> one could even detect cacheline-split if one wanted [03:51:07] <peloverde> Katrinplommon: That's the expired certificate warning [03:55:04] <Katrinplommon> so it's nothing to worry about then [03:57:36] <peloverde> correct [04:07:54] <Katrinplommon> https://roundup.ffmpeg.org/issue2073 [04:07:58] <Katrinplommon> joy to the world. [04:08:11] <Katrinplommon> probably very easy for a skilled ffmpeg coder to ad [04:08:25] <Katrinplommon> More a question of interest;) [04:09:10] <peloverde> mike likes old game formats [04:09:29] <Katrinplommon> yeah i just mailed him a pile of converted 3DO videos i've been going through [04:10:01] <Katrinplommon> pity his wiki doesn't have any irc chan cause i'm mainly just intersted in game formats [04:10:44] <Katrinplommon> this is what a 3DO .film file looks like after being converted to xvid with ffmpeg http://www.youtube.com/watch?v=DjO9HlDBoiE :) [04:11:54] <Katrinplommon> only about 10 3do games used .film so it's very fun when you actually find something that ffmpeg eats:) [04:12:53] <peloverde> If the FFmpeg decoder is old enough you should be able to directly upload to youtube [04:24:03] <Katrinplommon> nah it's too dated [04:24:10] <Katrinplommon> black screen+audio [05:19:42] <Tjoppen> god morgon [05:20:29] <av500> gm [05:20:44] <kshishkov> god morgon [05:21:35] <thresh> moroning [05:21:44] <Compn> and good night [05:21:49] <Compn> way too late for me :P [05:22:03] <Tjoppen> :) [05:22:22] * Compn dreams of multimedia formulas and codecs [07:41:39] <CIA-99> ffmpeg: diego * r24069 /trunk/libavcodec/h264.h: [07:41:39] <CIA-99> ffmpeg: Add av_unused to decode_mb_skip declaration to fix the following warning: [07:41:39] <CIA-99> ffmpeg: libavcodec/h264.h:1260: warning: ?decode_mb_skip? defined but not used [07:41:39] <CIA-99> ffmpeg: patch by Eli Friedman, eli.friedman gmail com [09:18:33] <lu_zero> hi Honoome [09:18:46] <Honoome> need caffeine [09:44:43] <Tjoppen> looking a bit at dolby-e. might have patch the mpegts demuxer to handle it [09:45:56] <Tjoppen> I assume it wouldn't be too much of a problem adding CODEC_ID_DOLBY_E and an entry in on of the tables in mpegts.c [09:46:52] <Tjoppen> apart from there being no decoder or encoder of course.. [09:50:18] <mru> adding an ID for a (to be) major codec without having a decoder should be ok [09:51:46] <mru> http://www.linuxjournal.com/content/openofficeorg-use-gstreamer-multimedia [09:53:17] <KotH> this sint something new [09:53:30] <mru> shows my ignorance of openoffice [09:53:30] <KotH> oo on debian had a gstreamer dependency for at least a year [09:53:56] <KotH> well... how many people do actually know what kind of framework is up to the task? [09:54:22] <KotH> everyone talks about gstreamer, it cannot be that bad! [09:54:24] <Tjoppen> mru: cool. we could trivially add the ability to remux mpegts <-> mxf with dolby-e :) [09:54:53] <Tjoppen> looks like kierank has done some RE work on it [09:55:35] <mru> < av500> will we have DSP accelarated spell checking soon? [09:55:45] <av500> heh [09:56:19] <kshishkov> Digital Simian Processing? [09:56:28] <mru> KotH: a framework must both provide a frame _and_ work [09:56:32] <mru> gst is all frame and no work [09:57:23] <av500> ffmpeg is all work and no frame... [09:57:47] <KotH> mru: yes, but you've to start to think like a mere mortal coder, not like an ffmpeg coder [09:58:13] <mru> mortal coders produce only mortal apps [09:58:16] <KotH> mru: for a mere mortal, ffmpeg, if he ever heard about it, is a very low level, dubious, half complete, cryptic library that is very hard to use [09:58:44] <mru> the last part of that, from dubious and on, fits gst as well [10:10:56] <av500> mru: <amaraemerson> hi guys, building libvpx with different compilers and optimizations, the resulting encoders produce ifferent files [10:11:02] <av500> specifically, enabling ARM neon vectorisation causes vastly improved performance but the file is about 30% larger. it's still playable [10:11:17] <mru> someone is doing something horribly wrong [10:11:25] <av500> of course [10:11:52] <mru> I guess he's talking about the neon asm in libvpx [10:12:12] <mru> merely enabling neon in the compiler wouldn't give a speedup [10:32:46] <lu_zero> btw [10:33:14] <lu_zero> to split an mpeg2video+audio in mpeg I had to resort to mencoder... [10:33:25] <lu_zero> ffmpeg does not streamcopy correctly ^^; [10:33:37] <mru> tell us something new [10:34:08] <lu_zero> the streams in esof are eventually working properly [10:34:21] <lu_zero> we had to accomodate a _bit_ of network glitches [10:52:25] <Honoome> and some sleep calls in a custom demuxer using posix mqs... just to say [10:55:28] <lu_zero> Honoome: I'll replace it with something saner soon [10:56:20] <lu_zero> still we'll need to reconsider that lock [11:21:05] <Katrinplommon> https://roundup.ffmpeg.org/issue2073 [11:21:34] <Katrinplommon> hmm what should i do, the movie file on the disc is a 600meg chunk that gets errors when i extract it with isobuster [11:21:39] <Katrinplommon> so making a sample is impossible [11:21:47] <Katrinplommon> should i just upload the whole thing somewhere [11:23:37] <KotH> Katrinplommon: how about starting with what carl eugen requested? [11:23:52] <KotH> Katrinplommon: and beside, this is a development channel, not a user support channel [11:24:03] <KotH> Katrinplommon: such questions belong to #ffmpeg [11:24:20] <Katrinplommon> ok [11:33:24] <mru> Dark_Shikari: ping [11:43:57] <CIA-99> ffmpeg: mru * r24070 /trunk/libavformat/file.c: file_protocol: remove redundant #include sys/time.h [11:43:58] <CIA-99> ffmpeg: mru * r24071 /trunk/libavformat/rtpenc.c: rtpenc: remove unnecessary #include unistd.h [11:43:59] <CIA-99> ffmpeg: mru * r24072 /trunk/libavformat/os_support.c: os_support: include some headers only when needed [11:50:29] <Honoome> mru: are you doing that by hand or you found a lint-like tool that does it? [11:50:58] <mru> I found them when building for a target that doesn't have those headers [11:51:13] <Honoome> kk [11:51:30] * Honoome really needs to find a tool that can list those itself...and then run it on multiple OSes [11:51:38] <Honoome> FreeBSD is known for not including the stuff it needs [11:51:42] <mru> yeah [11:51:47] <mru> contrary to specs [11:52:43] <kshishkov> that's why it's "Free" BSD, free of stuff [11:52:44] <Honoome> heh... well if I find another project including <malloc.h> I'll cry though [11:53:00] <mru> we only do it conditionally [11:53:09] <Honoome> mru: is there any target still needing that? [11:53:18] <Honoome> [please don't say mingw...] [11:53:20] <mru> you never know [11:53:30] <mru> if the header exists, including it won't do any harm [11:53:40] <Honoome> depends how you check whether it exists [11:53:52] <mru> try to include in a test [11:54:03] <Honoome> some projects used to check its presence with test -f /usr/include/malloc.h ... on fbsd it causes #error :P [11:54:15] <mru> lol [11:54:23] <mru> well, we check_header it [11:54:57] <Honoome> still afaik it's only ever needed by way-too-old glibc-versions, and all the modern systems support malloc() in stdlib.h.... so myself I try to stay away from it [11:55:01] <av500> mru: [13:54] <amaraemerson> manual assembly is 70% faster than generic, gcc autovec is 5% faster (don't think it's really doing much neon), and armcc is about 30% faster than _manual_ assembly, but it produces a larger video file [11:55:04] <mru> nonstandard things like memalign() are often declared in malloc.h [11:55:14] <BastyCDGS> hey @ all [11:55:25] * av500 hides [11:55:30] <mru> av500: well, that's coming from an arm employee [11:55:31] <kshishkov> Honoome: other *BSDs also have problems with it, like MacOSX [11:55:50] <Honoome> kshishkov: osx is 99% fbsd for the libc if I recall correctly [11:55:54] <mru> av500: ask if those figures are on real code or some synthetic test case used to show off the compiler [11:56:03] <av500> mru: you can tell that by the a's r's and m's in the name :) [11:56:15] <av500> mru: libvpx [11:56:16] <mru> av500: no, from the hostname [11:56:17] <BastyCDGS> hope you are all fine [11:56:28] <mru> BastyCDGS: we were, until you arrived :-) [11:56:39] <_troll_> precautionary measure [11:56:44] <BastyCDGS> *gg* [12:15:11] <av500> _troll_: http://www.flickr.com/photos/av500/sets/72157624309805057/ [12:16:52] <kierank> i see a suprising number of macs [12:17:17] <janneg> av500: the camera is too old to have colours? [12:17:26] <av500> yeah, they held a mac addicts self help meeting [12:17:32] <av500> janneg: yep [12:17:57] <kshishkov> av500: where's the biggest FFmpeg contributor (i.e. you)? [12:18:12] <av500> there was no mirror [12:18:33] <av500> I can photoshop myself in.... [12:18:54] <thresh> ha nice t-shirts [12:19:34] <kshishkov> guess what troll made them? [12:19:46] * _troll_ waves [12:19:47] <thresh> there is only one _troll_ in here! [12:20:11] * av500 votes for the _troll_ [12:20:28] <kshishkov> av500: you should feed him instead [12:21:12] * av500 feeds the troll with neon intrinsics [12:21:35] * _troll_ spits [12:22:01] * kshishkov offers troll altivec ABI instead [12:22:27] * _troll_ chokes [12:23:04] <kierank> what about amiga? [12:23:06] * kshishkov adds Loongson MMX for a side dish [12:23:50] <av500> kierank: he got that already today... [12:24:35] <av500> kshishkov: btw, did you upgrade to the NanoNote yet? [12:25:12] <kshishkov> av500: yes, of course. But if people see *you* using it, it would be more impressive [12:25:42] <av500> I had one here in my pocket, cant find it atm.... [12:26:00] <kshishkov> use brush and tweezers [12:26:27] <kshishkov> well, in theory it should be an interesting player [12:26:55] <_troll_> if they stuck a real SoC and a better display in it, it might be interesting [12:27:10] <av500> and a different case and .... [12:27:24] <av500> i heard pandora ships.... [12:27:35] <kshishkov> anything to say about those XBurst CPUs though? [12:27:43] <_troll_> yuck [12:27:53] <_troll_> reminds me of netburst [12:28:04] <kshishkov> could remind of Loongson [12:28:10] * _troll_ is not impressed with chinese mips clones [12:28:49] <kshishkov> av500: still, have you found any usage for it except for trolling? [12:29:34] <av500> no, I dont have one [12:30:39] * kshishkov thinks what exotic CPU arch to pursue next [12:30:57] <_troll_> VAX [12:31:06] <av500> Z1? [12:31:39] * kshishkov thinks what exotic and portable CPU arch to pursue next. With FFmpeg running on it. [12:32:00] <av500> put VAX on VAZ [12:32:05] <_troll_> there is only one viable portable cpu [12:32:20] * kshishkov has BBB6 and BBC4 [12:37:17] <CIA-99> ffmpeg: mru * r24073 /trunk/libavfilter/vf_pad.c: vf_pad: restore use of _CCIR colourspace conversion macros [12:37:23] <Tjoppen> av500: a little hard with only 64 words RAM. and float only :) [12:38:08] <av500> so I guess large precomputed tables are a out... [12:38:28] <_troll_> a.out? [12:38:49] <av500> hey, thats my filename as well! [12:40:39] * kshishkov thought that was a format [12:41:16] <Tjoppen> http://www.iwi.uni-hannover.de/lv/ueinedv/z1-demo2.avi [12:41:38] <Tjoppen> all computers should be operated via crank [12:42:32] <kshishkov> those were called arithmometers [12:43:22] <kshishkov> Russian ones were most advanced ones (since they were invented by some KTH graduate) [12:45:31] <Tjoppen> well, no. the z1 is programmable [12:46:10] <Tjoppen> you can even do loops, if you join ends the tape togeter [12:48:17] * _troll_ joins the tape ends into a möbius strip [12:48:47] <av500> _troll_: go write code that executes from both LTR and RTL :) [12:49:01] <_troll_> of course, no fun otherwise [12:49:04] <Tjoppen> like certain bacterial dna [12:49:10] <kshishkov> _troll_, it won't work - punch tapes had special column to prevent that [12:49:20] <Tjoppen> can be read six or twelve ways. I forget which [12:49:31] * av500 gives the punch tape punch a punch [13:05:18] <CIA-99> ffmpeg: mru * r24074 /trunk/libavcodec/ (libxvidff.c utils.c): Move av_tempfile() to libxvidff.c as only the xvid wrapper needs it [13:23:35] <CIA-99> ffmpeg: mru * r24075 /trunk/libavcodec/ (libxvid_internal.h libxvid_rc.c libxvidff.c): Rename av_tempfile() to ff_tempfile() [13:41:30] <BBB> merbanan: I just arrived at work ;) [13:41:48] <BBB> ohwell [13:41:54] <merbanan> :) [13:49:13] <mchinen> anyone know why time_base for mp3s at 44100 sample rate produce have values like 1/90000 which cause rounding errors? [13:49:59] <mchinen> thinking about changing this to be multiples of the sample rate instead [13:50:35] <kshishkov> IIRC it's standard clock for MPEG [13:51:08] <mchinen> ah [13:51:43] <mchinen> to get sample accurate dts right now I have to do some weird rounding hacks [13:53:02] <kshishkov> sounds like an overkill, your next task will be "pixel-accurate seeking" [13:53:11] <mchinen> haha [13:53:25] <mchinen> but for audacity we need sample accurate seeking [13:53:44] <mchinen> or else make the user wait till the entire file loads [13:54:03] <BBB> 1/90k for mp3 sounds weird [13:54:05] <BBB> you can change it [13:54:10] <BBB> for mp2-in-mpeg, 1/90000 is normal [13:54:25] <BBB> that's mpeg clockrate and it's about as exact as pts/dts will ever get in there [13:55:15] <av500> mchinen: ??? [13:55:56] <av500> for sample accurate seek in mp3 you have to parse the file anyway, no? [13:56:34] <mchinen> av500: yes but av_seek_frame does this for you [13:57:22] <mchinen> and if you have cbr, no you don't with the changes i hopefully will commit [13:59:40] <av500> mchinen: how do you know it is CBR? [14:00:52] <merbanan> xing header [14:00:52] <mchinen> assume a framesize by looking at the first few and compute desired length till end of file. If the real filesize is off by less than one frame its most likely cbr [14:01:18] <mchinen> yeah or some header thing if it exists [14:01:22] <pross-au> xing headers!! [14:01:28] <mchinen> i don't know if we have parsers for this? [14:01:40] <kshishkov> unlikely [14:01:55] <av500> VBRI header ftw! [14:02:08] <av500> merbanan: XING header is in every CBR mp3? [14:02:24] <kshishkov> nope [14:02:42] <kshishkov> only the ones produced by certain encoders [14:02:50] <av500> iKnow [14:03:21] <kshishkov> av500: that is lawsuit-firendly trademark you've just used [14:03:29] <av500> ? [14:03:47] <av500> it is not a trademark [14:03:56] <kshishkov> tell that to Apple lawyers [14:04:09] <av500> apple invented the Fraunhofer VBRI tag? [14:04:32] <av500> the conspiracy is deeper than me thought.... [14:04:58] <kshishkov> I meant "lowercase-i-before-uppercase-letter" word [14:05:58] <merbanan> av500: YES!!! [14:06:11] <jai> the mp3 demuxer can parse xing and vbri [14:06:17] <jai> we cant write them out though [14:07:20] <mchinen> okay good, that'll help too. [14:07:55] <lu_zero> BBB: you around? [14:08:26] <Honoome> kshishkov: is it just me or apple had a huge "in your face cisco" moment by renaming the iPhoneOS into iOS? :P given that Cisco was the one having a trademark over iPhone iirc [14:08:57] <kshishkov> Honoome: it's just you [14:09:11] <BBB> lu_zero: a little [14:09:21] <BBB> I'll look at the mpeg thing after the worldcup game [14:09:21] <lu_zero> cisco will produce a touch table called ipad [14:09:32] <BBB> ? [14:09:39] <kierank> Honoome: they have a licensing agreement [14:09:47] <Honoome> kierank: yeah I know that [14:09:47] <lu_zero> BBB: ok =) [14:10:06] <Honoome> but it was just funny to think after that mess that they called it iOS... given that IOS for me reminds of something else :P [14:10:25] <av500> Honoome: sjobs did not care about you... [14:13:46] <mru> Honoome: cisco? [14:13:53] <Honoome> mru: yeah [14:29:21] <CIA-99> ffmpeg: mru * r24076 /trunk/libavformat/file.c: Add #ifdefs around code specific to file and pipe protocols [15:03:35] <Compn> DonDiego : any idea why we are keeping these samples >> http://samples.mplayerhq.hu/mov/animatrix/ [15:03:44] <Compn> i dont see any bugzilla or roundup, havent searched the lists tho [15:04:22] <KotH> hmm.. because tehy are animatrix? [15:04:33] <DonDiego> try playing them [15:04:50] <DonDiego> they are tricky beasts [15:04:54] <KotH> hmm.. 2008? [15:04:57] <DonDiego> edit lists and whatnot [15:04:59] <Compn> ah editl ist [15:05:01] <KotH> they are quite new... too new actually [15:05:13] <KotH> Compn: feel free to relable the directory :) [15:05:48] <Compn> i'll just move it from there to editlist dir :) [15:05:57] <KotH> or that :) [15:06:04] <DonDiego> no, check them first [15:06:12] * Compn wonders why he didnt think to play them first [15:08:31] <KotH> probably because elenril infected you with his lazynes [15:08:51] <Compn> DonDiego : would symlinks to editlist dir be good or would that screw up mirroring ? [15:09:04] * elenril throws some tropes at KotH [15:09:27] <DonDiego> no, mirroring can handle that [15:10:03] <av500> DonDiego: http://www.flickr.com/photos/av500/sets/72157624309805057/ [15:10:29] <DonDiego> seen those, neat [15:11:10] <DonDiego> http://www.flickr.com/photos/av500/4767125825/in/set-72157624309805057/ [15:11:17] <DonDiego> lol@beos [15:11:32] <av500> well, it is true [15:11:41] * Compn pretends he remembers how to symlink [15:11:55] <Compn> ln -s something something [15:12:03] <av500> like copy [15:12:06] <av500> src dst [15:12:14] <KotH> DonDiego: you removed beos support? [15:12:26] <av500> KotH: look at the picture [15:12:33] <kshishkov> yep, in mmu_man online presence [15:12:38] <av500> the reflection in his glasses has the commit message [15:13:05] * KotH enlarges the picture [15:13:17] <av500> you needs some CSI foo of course... [15:13:18] * KotH sees the secret message inbetween the pixels [15:13:53] * KotH starts to fear for av500 [15:14:21] <kshishkov> why? because he's the biggest FFmpeg contributor? [15:15:42] <DonDiego> how can i commit individual diff hunks with git? [15:15:49] <Honoome> DonDiego: git add -p [15:15:56] * DonDiego tries [15:16:43] <Compn> hooray, animatrix samples symlinked into editlist [15:16:56] <av500> commit! [15:26:51] <BBB> Vitor1001: did I mention that inline asm (or maybe it's float asm) is headache-inducing? [15:26:56] <BBB> I'm getting a headache when reading it :-p [15:27:20] <mru> inline asm is nightmare [15:27:52] <av500> mru: the arm fellow finally found out that armcc was slower than gcc for libvpx :) [15:27:53] <BBB> so why do we do it [15:27:58] <av500> for the decoder... [15:28:06] <av500> suddenly, speed did not matter any more..... :) [15:28:52] <mru> armcc slower than gcc is unusual [15:29:10] <mru> 5-10% faster is typical [15:29:40] <av500> well, I do not think he know much (yet), gg puts him as recently graduated... [15:29:46] <BBB> libvpx is written in a very obscure way [15:29:52] <BBB> might change how compilers apply optimizations [15:29:58] <BBB> their loops are really really really weird [15:30:33] <av500> really? [15:30:48] <BBB> imo [15:30:53] <BBB> different than usual [15:31:01] <mru> armcc does best on canned benchmarks [15:31:16] <mru> but then so does gcc [15:31:31] * kshishkov gets a fresh can of FFmpeg [15:31:51] <av500> mru: http://ffmpeg.pastebin.com/GPtiRNt9 [15:31:56] <mru> kshishkov: shall I bring you some spam? [15:32:25] <kshishkov> mru: yes, please [15:33:03] <BBB> pengvado: why if it's ==7? [15:33:28] <BBB> I thought 0-7 were caller-save (or whatever you call that) [15:33:34] <mru> "armcc is about 30% faster than _manual_ assembly, but it produces a larger video file" [15:33:46] <mru> that means it generated fast code doing the wrong thing [15:34:01] <BBB> it means, more logically, that the settings were wrong [15:34:02] <kshishkov> sounds like icc [15:34:04] <mru> it's easy to be fast if you don't need to be correct [15:34:05] <BBB> or different [15:34:50] <mru> a simple way to make it appear ludicrously fast would be to have the block compare functions always return zero [15:35:06] <mru> then ME would "finish" immediately [15:35:19] <mru> the rest would still produce a valid file [15:35:27] <mru> albeit with horribly bad motion vectors [15:35:30] <av500> mru: I assume something like that [15:35:43] <pengvado> 0-5 are caller-saved on win64 [15:35:52] <mru> and that would indeed make the encoded file larger if targeting constant quality [15:35:52] <kshishkov> personally I consider (0,0) to be rather neat motion vector [15:36:19] <av500> mru: but I had not time today for xkcd #368 [15:36:29] <av500> err 386 [15:37:41] <mru> av500: too busy with 598? [15:38:13] <av500> indeed [15:38:39] <mru> where's this discussion happening anyway? [15:38:44] <kshishkov> mru: please do panel 3 from todays Dilbert strip [15:38:47] * mru sees trolling potential [15:39:36] <av500> #vp9 [15:39:38] <av500> #vp8 [15:39:56] <kshishkov> stick to vp7 [15:40:17] <mru> that channel is full of trolls already :-) [15:40:26] <av500> yes [15:40:52] <av500> it is slowly being taken over by ffdevs [15:41:22] <jai> av500: epic tshirts btw [15:41:36] <av500> jai: we had one for you as well [15:41:42] <BBB> link to dilbert strip with troll? [15:42:02] <jai> av500: orly :) [15:42:30] <av500> former gsoc student have free entry to the booth.... [15:42:31] <spaam> BBB: http://www.dilbert.com/dyn/str_strip/000000000/00000000/0000000/000000/9000… [15:42:48] <spaam> oh [15:42:56] <BBB> heh :) [15:43:53] <av500> finally: gopher for android... http://gopher.floodgap.com/overbite/ [15:44:16] <lu_zero> av500: please... [15:45:01] <Vitor1001> BBB: sorry, was away from the keyboard [15:45:06] <BBB> is ok [15:45:19] <BBB> all I said was that the simd inline code is headache-inducing :-p [15:45:29] <Vitor1001> BBB: Why? [15:45:36] <BBB> I don't know yet [15:45:39] <Vitor1001> It is almost the same as non-inline. [15:45:42] <BBB> but I got a headache while reading it ;) [15:45:50] <Vitor1001> Is it "op input, output" the problem? [15:45:59] <BBB> it might just be my head [15:46:38] <spaam> ffmpeg website need gopher support [15:46:45] <spaam> ;) [15:47:10] <BBB> Vitor1001: what are the BYTTERFLY2/3/4/5? [15:47:26] <BBB> are they direct copies of similar operations in the C file? [15:47:36] <Vitor1001> BBB: mostly so. [15:47:41] <Vitor1001> See libavcodec/dct32.c [15:48:06] <lu_zero> that reminds me that I have to find a weekend to prepare the foundation website [15:48:19] <BBB> that's only BF/BF0/1/2 [15:48:26] <lu_zero> assuming everybody stated their opinion on the mockups [15:48:30] <av500> ? [15:48:40] <BBB> lu_zero: yes, very pretty, please finish that :) [15:48:47] <lu_zero> =P [15:49:08] <Vitor1001> Mostly BUTTERFLY* are different version of BF(). [15:54:21] <Vitor1001> BBB: Actually, it applies basically BF() to four consecutive vectors BF(a[0],b[0],c[0],1);BF(a[1],b[-1],c[1],1); BF(a[2],b[-2],c[2],1); BF(a[3],b[-3],c[3],1). [15:55:07] <Vitor1001> When the three components of a[] and b[] overlap, I have to special case it. [16:00:08] <BBB> got it [16:00:24] <Vitor1001> Note that the xorps trick is a multiplication by {-1, -1, 1,1} [16:00:50] <Vitor1001> BBB: Actually, it was pretty close to the C code until I started removing shuffles ;) [16:01:15] <BBB> right now it's not at all close to the c code :-p [16:01:50] <BBB> so basiclly the only thing I find unexpected is the high amount of stores to memory and loads from memory, I assume each of these are actually necessary given lack of registers or so? [16:02:49] <Vitor1001> Yes. Unfortunately, I cannot fit all the 32 floats in the registers without having no further register to do the calculations. [16:04:56] <BBB> for example at the bottom: [16:04:57] <BBB> + "addss 60(%1), %%xmm0 \n\t" [16:04:57] <BBB> + "movl 60(%1), %0 \n\t" [16:05:11] <BBB> I'm wondering if that slows it down any [16:05:56] <BBB> I guess it's ok... is this the expected ~4x faster than C code? [16:06:12] <Vitor1001> just a min. [16:06:42] <Vitor1001> That big block at the end is code that is hard to SIMD-fy. [16:06:55] <mru> try harder [16:06:58] <Vitor1001> The only reason I wrote it in asm is to be sure gcc will not screw it up. [16:07:17] <Vitor1001> mru: Last time I did I got something 40% slower, but full SIMD [16:07:34] <mru> then you didn't try hard enough [16:07:39] <Vitor1001> Actually, gcc gave me a hand writing this block. [16:07:54] <Vitor1001> mru: Wanna see the C code? [16:10:25] <Vitor1001> mru: http://ffmpeg.pastebin.ca/1895535 [16:11:11] <Vitor1001> BBB: That big block at the end will not be much faster than C. It is not SIMD. [16:16:03] <mru> inline asm, ugh [16:16:11] <BBB> pastebin.ca is always so slow for me :( [16:16:45] <spaam> pastie.org is nice ;) [16:16:49] <av500> pastebin.com [16:17:59] <BBB> PERM should be simd'able [16:18:21] <BBB> not sure about those odd serial adds [16:18:52] * BBB will have to think a little, and probably read some more float simd [16:19:10] <Vitor1001> BBB: Perm got slower: http://ffmpeg.pastebin.com/vMVr66LE [16:19:39] <hyc> hmm, I'm feeling dense. I don't understand how this patch helps to get what I want. https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-July/092509.html [16:19:46] <Vitor1001> BBB: err, http://ffmpeg.pastebin.com/6nVixzR5 [16:21:46] <pengvado> how much faster does it get on x86_64 where you can fit all the samples in regs at once? [16:22:36] <hyc> let's see. ok, scale w:h can be arithmetic expressions instead of simple integers, and you can get the input video's W and H. hmmm. [16:23:03] <Vitor1001> pengvado: No idea, I don't have a 64-bit dev environment. [16:23:41] <Vitor1001> It should avoid some 6 stores. [16:24:38] <Vitor1001> BBB: It is hard to beat C PERM() because the C version is just 4 adds. [16:25:49] <Vitor1001> pengvado: The non-simd part has a considerable register-pressure itoh... [16:47:23] <BBB> Vitor1001: I'd say in the end that I could look more into it, but you're smart enough to have done a good at that yourself, probably better than me, so it basically looks good to me, provided that you add a one-or-two line comment as for what BUTTERFLY1/2/3/4/5/6/7/8/9 are and why/how they are different [16:47:31] <BBB> and besides, who cares, it's faster \o/ [16:47:52] <Vitor1001> BBB: Nice. I was doing exactly that. [16:48:04] <BBB> ty [16:48:10] <Vitor1001> And BTW, your comment about why so many different macros gave me an idea: [16:48:35] <Vitor1001> BBB: http://ffmpeg.pastebin.com/vfNrRVqu [16:48:53] <Vitor1001> Way more readable this way :D [16:49:14] <BBB> much better :) [16:50:44] * BBB goes on to review spyfeng's work then [16:51:57] <Vitor1001> BBB: Thanks! [16:52:11] <BBB> so I see we all move down the same path [16:52:15] <BBB> we start at a voice codec [16:52:17] <BBB> then we start doing simd [16:52:20] <BBB> what comes next? [16:52:32] <Vitor1001> BBB: Buy a beagle board ;) [16:52:44] <BBB> 3) buy beagle board, 4) $$$profit [16:52:49] <BBB> somehow it doesn't connect [16:53:12] <BBB> I'll just buy a new iphone4g and do neon on there :-p [16:53:20] <Vitor1001> BBB: Looks good too [16:53:26] <Vitor1001> But a BB is way cheaper [16:53:31] <BBB> really? [16:53:32] <BBB> how much [16:53:41] <BBB> the advantage of an iphone4g is that it makes phone calls [16:53:52] <BBB> and it gets you girls [16:53:52] <Vitor1001> $150 [16:54:11] <BBB> girls dig the iphone much more than a beagleboard, I bet [16:54:33] <Vitor1001> _And_ if you get girls using a beagle board, that would be really impressive ;) [16:54:40] <BBB> very true [16:54:41] <Honoome> BBB: depends if you attach the beagleboard to a real beagle [16:54:46] <BBB> heh :) [16:54:48] <Honoome> and use it to make it speak [16:54:56] <BBB> mru: I guess we'll need a guid to best neon programming from you ;) [16:58:04] <Transport> http://www.arm.com/community/partners/display_product/rw/ProductId/4353/ looks better kited out than a beagle board though! [16:59:49] <CIA-99> ffmpeg: vitor * r24077 /trunk/libavcodec/ (fft.h x86/fft.c x86/fft.h dct.c x86/fft_sse.c): SSE optimized 32-point DCT [17:14:15] * Vitor1001 brakes FATE again :p [17:15:30] <mru> fix it [17:16:12] <Vitor1001> mru: I want your opinion: it is braking because fft_sse.c is only configured if CONFIG_YASM [17:16:13] <mru> is it really that hard to test things before committing them? [17:16:38] <Vitor1001> mru: Compile it no matter if have yasm or not or put the dct32 in its own file? [17:17:15] <Vitor1001> mru: Do you want me to test every non-obviously yasm-related patch with --disable-yasm? [17:17:41] <mru> no, but I want you to think about it [17:17:57] <Vitor1001> mru: Maybe a script that try every possible parameter combination to configure. [17:18:31] <Vitor1001> I wasn't expecting a .c file full of inline asm being conditional to YASM. [17:18:46] <Vitor1001> Even thought it makes sense after the fact... [17:18:55] <mru> I'd simply move the dct32 to a separate file [17:19:03] <mru> it's not like the file will be small... [17:19:38] <mru> and why the #include common.h? [17:22:01] <mru> you are however missing includes for libavutil/mem.h and stdint.h [17:22:19] <Vitor1001> ok, will try to fix all of it. [17:22:34] <mru> so why did you #include common.h? [17:23:49] <Vitor1001> Because some old version of it used FFSWAP(). [17:31:22] <Vitor1001> mru: Is "SSE-OBJS-$(HAVE_DCT)" well defined in ffmpeg makefiles? [17:32:11] <mru> no, it's CONFIG_DCT [17:32:34] <Vitor1001> And SSE-OBJS? [17:33:31] <Vitor1001> mru: Finally got it to compile. No, SSE-OBJS does not exist. [17:33:42] <mru> indeed it doesn't [17:33:49] <Vitor1001> Should I add it? [17:34:24] <mru> all the existing sse code uses MMX-OBJS [17:34:36] <Vitor1001> not the yasm ones. [17:34:42] <Vitor1001> Ok, I'll use MMX-OBJS. [17:34:47] <mru> they do too [17:34:52] <mru> just with more indirection [17:35:03] <Vitor1001> YASM-OBJS-FFT-$(HAVE_SSE) [17:35:11] <Vitor1001> They are not compiled if there is no SSE support. [17:35:32] <mru> right [17:35:46] <mru> just use MMX for now [17:35:49] <Vitor1001> Ok. [17:36:22] <mru> like add it next to x86/fft.o [17:36:30] <mru> or not [17:36:36] <mru> use CONFIG_DCT of course [17:36:42] <mru> no, that will break [17:36:43] <Vitor1001> mru: Any comment: http://ffmpeg.pastebin.com/Fwi7Smxx ? [17:37:18] <mru> that will fail with fft on and dct off [17:37:22] <Vitor1001> I did a svn cp to revert my patch to fft_sse.c. [17:37:36] <Vitor1001> Why? [17:37:36] <mru> I don't care about that [17:37:46] <mru> because fft.c references it [17:38:00] <mru> with only a HAVE_SSE guarding it [17:43:03] <Vitor1001> mru: Ok, indeed. [17:43:10] <Vitor1001> mru: This one should be better: http://ffmpeg.pastebin.com/TjdhNrmi [17:43:38] <mru> no [17:43:43] <Vitor1001> Why? [17:43:44] <mru> that will break if sse is disabled [17:43:59] <mru> if (HAVE_MMX) ff_dct_init_mmx(s); [17:44:06] <mru> and that line is correct [17:44:32] <mru> just stick an #if CONFIG_DCT around the function in fft.c [17:46:23] <Vitor1001> ok, will commit it then. [17:46:25] <Vitor1001> Thanks. [17:46:39] <Vitor1001> Ow, btw, do you prefer dct32_mmx.c? [17:46:48] <mru> it's sse code inside [17:47:03] <Vitor1001> In case someone add other x86 optimizations to it... [17:47:11] <mru> they can go in a separate file [17:47:32] <Vitor1001> ok. Will commit them. [17:47:55] <mru> but why did you do this in inline asm? [17:47:58] <mru> why not yasm? [17:49:14] <CIA-99> ffmpeg: vitor * r24078 /trunk/libavcodec/x86/ (Makefile fft.c dct32_sse.c fft_sse.c): [17:49:15] <CIA-99> ffmpeg: Move SSE optimized 32-point DCT to its own file. Should fix breakage with YASM [17:49:15] <CIA-99> ffmpeg: disabled. [17:50:27] <Vitor1001> mru: It will not give us headaches with not enough registers anysoon... [17:50:47] <mru> it will give other headaches [17:50:48] <Vitor1001> mru: So I supposed that for this case, yasm/inline is just bikeshed. [17:51:10] <mru> you have the clobber issue [17:51:21] <mru> and the fact that inline asm is a monster to read [17:51:57] <Vitor1001> Just because the "\n\t" ? [17:52:07] <mru> because of everything [17:52:19] <mru> scrolling around to see wtf %3 is [17:52:25] <mru> all the quotes and \n\t [17:52:39] <mru> lack of syntax highlighting [17:52:49] <mru> generally awkward asm syntax [17:52:55] <mru> should I go on? [17:53:02] <mru> portability issues [17:53:27] <Vitor1001> I will learn yasm someday ;) [17:53:30] <Vitor1001> brb, dinner... [17:53:38] <mru> today is a good day [17:55:01] <thresh> to die [18:08:11] <BBB> Vitor1001: learn it [18:08:13] <BBB> yasm is awesome [18:51:04] <Dark_Shikari> mru: pong [18:51:30] <Dark_Shikari> BBB: http://pastebin.org/384636 [18:54:12] <_av500_> Dark_Shikari: BBB is watching the game [18:54:36] <mru> Dark_Shikari: would you pop in to coredev for a bit? [19:49:14] <kierank> i can't wait to hear what bizzare reason ffdshow will give for not removing faad [19:49:35] <J_Darnley> "better quality" [19:49:42] <kierank> "bugs" [19:49:56] <kierank> I'm going to make the patch and shove it down their throats if necessary [19:50:11] <J_Darnley> not limited to 16bit output [19:50:39] <kierank> hmmm maybe that's why they don't use lavc's ac3 decoder [19:51:19] <kierank> clsid will come up with some bizzare reason [19:51:34] <Dark_Shikari> they don't even use ffmpeg [19:51:41] <Dark_Shikari> they use their insane fork [19:54:41] <mru> is there a name for the letters gcc allows in the %0 things in inline asm? [19:54:58] <mru> like %h0 for the ah register (iirc) [19:56:06] <kierank> wtf why does ffdshow need tremor [19:59:35] <Dark_Shikari> kierank: to make it bigger [20:00:05] <kierank> same goes with libdts/liba52 and others [20:00:38] * kierank considers creating ffdshow-debloat [20:01:37] <elenril> kierank: mplayer? ;) [20:01:50] <kierank> elenril: note the "dshow" [20:02:18] <elenril> kierank: note the ;) [20:02:29] <elenril> anyways, isn't dshow deprecated? [20:02:33] <kierank> yes [20:02:54] * kierank decides not to create ffdshow-debloat but instead start a flamewar on doom9 [20:03:11] * elenril approves [20:03:17] <elenril> trolling is more fun [20:05:22] <kierank> neuron2 will lock it anyway [20:06:15] <elenril> where did you get that nut file from [20:06:26] <Compn> does ffdshow have any patches for ffmpeg/mplayer ? [20:06:28] * Compn goes afk [20:06:38] <kierank> doubt it [20:06:44] <kierank> probably destructive patches [20:06:59] <Dark_Shikari> Compn: they maintain their own fork [20:07:12] <Dark_Shikari> as in, so many changes that they have to go to great effort to merge updates [20:07:27] <elenril> yay for open development [20:08:01] <kierank> the same guy that runs the ffdshow fork did the same thing to mpc many years ago and now only he knows how to update mpc-hc's ffmpeg :/ [20:09:19] <elenril> do they have a web interface for their repo? [20:10:04] <kierank> yes [20:10:16] <kierank> ffflame on http://forum.doom9.org/showthread.php?p=1415132#post1415132 [20:10:53] <peloverde> nice\ [20:11:17] <elenril> where's aac? [20:11:17] <kierank> also the repo's been checking out for 20 minutes now... [20:11:22] <kierank> whoops [20:11:32] <kierank> fixed [20:13:57] <spaam> kierank: good luck with that :) [20:14:49] <kierank> I will reply with a similar level of logic to the answers [20:16:50] <elenril> InsaneTrollLogic? [20:17:12] <twnqx> ™ [20:17:13] * elenril should write an irssi script for autogenerating tvtropes links [20:17:58] <kierank> elenril: yes. if the logic is super twisted i'll invoke the rule about not arguing with stupid people [20:22:38] <merbanan> libdts/dca has several bugs that causes wrong decoding [20:22:48] <merbanan> the LFE channel is silent [20:22:57] <merbanan> just a small detail [20:23:48] <merbanan> and no Xch support either [20:24:29] <twnqx> lol, no LFE? [20:24:45] <merbanan> there is a LFE channel, it's just very silent [20:25:01] * elenril recalls some problems with downmixing dts in lavc [20:25:20] <merbanan> the ffmpeg decoder is like 100% faster also [20:27:10] <peloverde> ffdshow internals are hideous [20:32:01] <Vitor1001> kierank: Funny thing you started your message with MP1/2/3. Until very recently, mp3lib was _way_ faster. [20:32:39] <kierank> well it's more a case of duplication than speed [20:32:54] <kierank> mp3 isn't really going to be taxing on any x86 in the last 10 years [20:33:27] <Vitor1001> kierank: Yes, but they can always cry about battery life or stealing cycles from h264 decode. [20:33:44] <Vitor1001> kierank: it's harder to argue with "it's much faster!" [23:23:47] <Compn> kierank / Dark_Shikari : you know faad supports a few formats not supported by ffaac right ? latm , sbr/ssr etc [23:23:56] <Compn> or was latm just added hmm [23:24:17] <mru> we support sbr [23:24:26] <mru> so stop trolling [23:24:36] <peloverde> We have supported SBR for months (ages in FFmpeg time) [23:24:58] <peloverde> Point to SSR in the wild if you think it is important [23:25:17] <peloverde> janneg: LATM ping? [23:26:03] <kierank> Compn: latm doesn't work in ffdshow though [23:26:17] <mru> so that argument is invalid [23:29:44] <janneg> loas demuxer works on samples extracted from DVB captures, trying to integrate it into the mpeg-ts demuxer atm [23:29:53] <Compn> mru / peloverde : erm, sorry, i forgot which 3 letter acronymn was supported :P [23:30:49] <janneg> I probably should clean it up and submit it first [23:33:07] <janneg> does anyone has loas/latm samples with more than 1 program/stream? [23:37:10] <kierank> i would speculate bbc hd on dvb-t2 has multiple streams [23:37:25] <kierank> one normal and one audio description [23:37:37] <kierank> but afaik there are no decent usb receivers yet [23:42:46] <janneg> kierank: but probably two different loas on different pids with one audio stream each

1 0