Ffmpeg-devel-irc

Download

ffmpeg-devel-irc@ffmpeg.org

August 2010

1 participants
30 discussions

IRC log for 2010-08-30
by irc＠mansr.com 31 Aug '10

31 Aug '10

[00:55:36] <saintdev> no more decimated frames after short blocks \o/ [06:32:54] <superdump> merbanan: ping? [06:37:15] <superdump> http://idle.slashdot.org/story/10/08/26/1254245/Drunken-Employee-Shoots-Ser… <--- mru don't get any ideas with your shotgun [06:41:26] <KotH> moin [06:42:14] <Tjoppen> morrn [06:42:52] <drv> heh, i followed a link on the original story there, and it's got lorem ipsum text [06:42:55] <drv> http://www.sltrib.com/sltrib/home/50184124-76/kanab-utah-dignissim-lake.htm… [06:45:20] <KotH> and it's copyrighted [06:58:11] <superdump> aha [06:58:14] <superdump> merbzt: ping/ [06:58:16] <superdump> ? [06:58:45] <merbzt> superdump: ? [06:58:54] <superdump> http://rss.slashdot.org/~r/Slashdot/slashdot/~3/pOVLPqLwEoY/story01.htm <--- that's pretty good though [06:59:05] <superdump> merbzt: marcelo sent a response to vitor that also hasn't got through [06:59:21] <superdump> can we raise the attachment limit on ffmpeg-soc for now? [06:59:33] <superdump> or turn it off or something [07:00:08] <superdump> i mean how much spam do you get to that list? [07:00:51] <merbzt> much [07:01:10] <merbzt> but how much do you want to raise the limit ? [07:10:35] <benoit-> merbzt: I cannot connect to https://lists.mplayerhq.hu, can you? [07:11:12] <merbzt> benoit-: yes [07:11:23] <merbzt> limit set to 1MB [07:12:02] <benoit-> hmmm, I have to see if this is because of some IT rule here [07:20:51] <superdump> merbzt: thanks - and did you authorise the pending mail from marcelo too? :) [07:22:24] <merbzt> of coz not [07:28:35] <merbzt> fixed [07:31:04] <superdump> thanks [09:27:15] <lu_zero> good morning [09:27:38] <lu_zero> av500: how hard is adding additional demuxers to android? [09:28:29] <av500> lu_zero: hmm [09:28:45] <av500> i never looked deeply into opencore [09:29:06] <merbzt> opencore is deprecated [09:29:12] <av500> we go around it and replace the whole thing [09:29:20] <av500> merbzt: not yet fully [09:29:22] <merbzt> lu_zero: what demuxers do you want to add ? [09:29:41] <merbzt> av500: yeah they will support it ad infinitum [09:32:15] <lu_zero> mpegts mostly [09:40:15] <av500> lu_zero: our android products support mpegts :) [09:46:52] <lu_zero> av500: I already suggested them =) [10:55:36] <KotH> can someone tell me what all this fuss about mmx on i686 is? [10:58:35] <J_Darnley> KotH: As far as I can tell, it started with whether people who use --cpu=i686 actually want MMX do be disabled [10:58:44] <J_Darnley> *to be [10:58:54] <av500> and why not autodetect mmx? [10:58:56] * av500 hides [10:59:09] * cartman detects av500 and disables [11:00:20] <J_Darnley> I'm sure that "why" must be covered somewhere in between the flames [11:00:24] <KotH> J_Darnley: uhmm.. if you talk about i686, you cannot say for sure whether it has mmx or not, so it should be disabled [11:00:32] <KotH> selam cartman [11:00:42] <cartman> merhaba KotH ;-> [11:00:46] <KotH> cartman: np: domates biber patlican [11:00:55] <cartman> lol [11:00:56] <KotH> :-) [11:00:57] <cartman> good choice [11:01:14] * KotH has his baris manco day :) [11:01:26] <J_Darnley> KotH: Yes, but what about system builders who use i686 but users expect their MMX, SSE, etc options to be used? [11:01:32] <KotH> unfortunately, i dont have all the CDs :-( [11:02:17] <av500> KotH: as long as it can be autodetected, why care [11:02:20] <cartman> KotH: try spotify? :D /me has no cd/mp3 whatsoever [11:02:30] <KotH> J_Darnley: how about the idiots who think that wasting water is ok, because we have enough of it, as it just comes out of the faucet? [11:02:44] <av500> KotH: and what do we waste with mmx? [11:03:10] <KotH> J_Darnley: because people do stupid things, we should not encourage them [11:03:50] <KotH> cartman: no thanks... i like to own the music i play.. at least in form of mp3s [11:04:11] <KotH> av500: bits, precious bits! [11:04:11] <iive> KotH: do you have x86 cpu without mmx? [11:04:13] <J_Darnley> Exactly, I'm on the side of making people explicitly disable simd if that's what they really want [11:04:26] <J_Darnley> But I'm leaving the debate now [11:04:37] <av500> with the shed half painted? [11:04:54] <KotH> iive: yes [11:04:57] <KotH> iive: one in my drawer [11:05:07] <KotH> iive: no, actually two of them in my drawer [11:05:11] <J_Darnley> Yes, I don't care about sheds [11:05:17] <KotH> iive: one PPro and a P-90 [11:05:28] * av500 threw away his ppro [11:05:32] <av500> last week [11:05:45] <av500> so for me, 686 without mmx does not exist :) [11:05:53] <KotH> lol [11:05:53] <iive> KotH: then clean up the dust and run ffmpeg on it. Then fill bugreport, because it crashes with illegal instruction. [11:06:00] <KotH> hehe [11:06:09] <ohsix> i'm irc'ing from a p6 without mmx [11:06:16] <KotH> iive: if i had a mainboard to put it in, i would :) [11:06:31] <KotH> ohsix: fill the bugreport for us! [11:06:33] <av500> ohsix: irc must be unbearable without mmx :) [11:06:40] <ohsix> huhu [11:06:40] <iive> and I had hopes that this could end the flamewar. [11:07:01] <av500> i still dont get why not just autodetect as much as possible [11:07:04] <ohsix> one time, justin frankel made a special build of avs without mmx so i could check it out :] [11:07:42] <av500> if i686 can have mmx, compile it in and autodetect at runtime [11:07:45] <KotH> av500: well, autodetect does not work for distros... and if i got it right, that's the main point for this bikeshed discussion [11:07:46] <iive> av500: we actually autodetect everything. the only exception is emms_c from week ago. [11:07:57] <av500> KotH: not at runtime? [11:08:20] <KotH> av500: runtime detection costs precious cycles [11:08:28] * av500 slaps KotH [11:08:29] <KotH> _my_ precious cylces ;) [11:08:42] <BBB> I think we do detect runtime [11:08:45] <av500> if that is the line of argument, I'm out too.... [11:08:49] <BBB> at least in libavcodec everything is rutime [11:09:00] <av500> so, where is the harm to add mxx to 686? [11:09:00] <BBB> don't know about libswscale [11:09:30] <BBB> I think the problem with emms is that it's a very short function which is called a lot [11:09:39] <BBB> so to do if have_mmx() { emms } is very slow [11:09:57] <BBB> we'll eventually settle the flamewar, I don't think we have much of a choice [11:10:12] <KotH> well, the alternative would be to burn everything down [11:10:18] <KotH> not a very nice prospect [11:10:30] <av500> Nero liked it [11:10:56] <BBB> does swscale do runtime detection? [11:10:58] <BBB> I never tested [11:11:46] <KotH> with mplayer yes, no idea about inside ffmpeg [11:11:47] <iive> BBB: have actually somebody benchmarked the emms change? [11:12:19] * microchip_ benchmarks iive... hmm, pretty slow :p [11:12:53] <iive> from what I assume, it is generally called on exit of api functions. And these are not that speed critical. [11:13:49] <iive> also, on K6 cpus, it is better to use femms, because normal emms burns around 300 cycles. [11:14:19] <Yuvi> I think it was changed more because mm_flags wasn't global anymore and noone really cares about running on pre-mmx cpus [11:14:31] <iive> (or 30, don't remember anymore). [11:15:53] <KotH> iive: i know only one person who still uses a k6 for anything :) [11:16:08] <iive> and he have mac laptop? [11:16:17] <KotH> on the other hand... there are people who still use a G200... [11:22:11] <microchip_> KotH: only those who fail epically :p [11:22:40] <iive> the solution to this is very simple - there should be a way to make emmc_c build-in or runtime-detect, according to user wishes. [11:23:28] <iive> then same principle could be applied to PREFETCH, and this is probably going to be much more beneficial [11:25:08] <ohsix> and the k6 2 has mmx and emms but not cmov, i got hit by that quite a bit before i threw that machine away [11:28:45] <av500> k6 is back, it is called bobcat now [11:40:34] <lu_zero> bobcat isn't a cuter atom from amd? [11:44:40] <BBB> Yuvi: do you know why http://fate.ffmpeg.org/ppc-linux-gcc-4.0/20100830000143 fails on all vp8 tests? [11:44:56] <BBB> Yuvi: it fails only all vp8 tests, and all other ppc machines run vp8 just fine [11:45:12] <Yuvi> gcc 4.0 being buggy is my guess [11:45:36] <Yuvi> specific bug is probably due to implicit vec_ld [11:46:08] <BBB> is that worth "fixing" (workarounding, I guess)? [11:57:31] <av500> lu_zero: yes, afaik based on k6 [12:01:33] <xxthink> Are there some restrictions on the gap between the audio and video PTS? [12:01:39] <xxthink> for example, can I first write a 5 min audio, then 5 min video and so on [12:01:53] <av500> depends [12:02:15] <av500> there is e.g. non-interleaved AVI [12:02:24] <av500> the gap = length of clip [12:03:16] <xxthink> does flv support this format? [12:03:32] <av500> what format? [12:03:35] <av500> flv is a format [12:03:46] <xxthink> yes [12:04:29] <xxthink> first I should read the flv spec again, [12:05:21] <xxthink> I just want to put many audio tracks in the flv format [12:05:34] <xxthink> though the flv format doesn't support [12:05:53] <merbzt> xxthink: flv supports 1 audio track and 1 video track [12:05:58] <xxthink> yes [12:06:16] <merbzt> mp4 supports many [12:06:30] <xxthink> it will waste the bandwidth [12:07:10] <xxthink> let me first read the flv spec again. [12:27:28] <KotH> somewhen, i have to memorize the c99 standard... [12:27:30] <KotH> ^^' [12:30:38] <BBB> Dark_Shikari: would you mind if we move the h264pred init stuff in h264dsp_mmx.c into a new file, e.g. h264pred_init.c? it's all yasm anyway [12:32:35] <KotH> cartman: np: daglar daglar ;) [12:56:51] <janneg> av500: amd claims that bobcat is a new design. but even if it is based on k6, 64bit and S?SSE[1-3] are significant improvements [12:57:12] <av500> janneg: gee, dont take it so serious :) [13:02:19] <KotH> janneg: yes, you shouldn't take av500 serious [13:02:37] <KotH> janneg: as a rule of thumb: the +v in a non-moderated channel marks the channel idiot(s) [13:02:40] <KotH> ;-> [13:02:57] * av500 wears his +v with pride [13:03:07] <spaam> KotH: why dont you have +v ? ;P [13:03:30] <KotH> because i'm the channel _BofH_ [13:03:33] * MrNaz_YMAtv stands on his head in the hope of getting a +v [13:03:53] <av500> MrNaz_YMAtv: send a patch [13:04:00] <MrNaz_YMAtv> oh [13:04:14] <MrNaz_YMAtv> i see by "idiots" you actually mean "useful people" [13:04:17] <MrNaz_YMAtv> sorry, i dont count [13:04:23] <av500> idiots who send patches [13:05:00] <MrNaz_YMAtv> best i can do is to send encouragement to someone who will send a patch [13:05:12] <BBB> I think that only counts for 25% [13:05:16] <KotH> send me swiss chocolate [13:05:17] <BBB> so you need to do that 4x to get a +v [13:05:23] <MrNaz_YMAtv> hmm... perhaps i can encourage 4 people then [13:05:55] <av500> MrNaz_YMAtv: send them EncouragmentCurrencyUnits [13:05:57] <MrNaz_YMAtv> BBB not that i'm after accolades, but you do realize that most of the work of the last 2 years or so on ffserver has been either requested by me or paid for by me? :P [13:06:13] <MrNaz_YMAtv> av500 i did better... i sent RealCurrencyUnits [13:06:21] <av500> RCU? [13:06:32] <MrNaz_YMAtv> more like EURO :P [13:07:13] <av500> KotH: give him a +$ [13:08:57] <MrNaz_YMAtv> which reminds me... i need to actually deploy the changes [13:09:19] <MrNaz_YMAtv> heh on the streaming boxes i'm still using 1 oct 2009 build [13:09:37] <av500> what boxes? [13:09:46] * kierank runs away at MrNaz_YMAtv's camelcase [13:09:48] <KotH> av500: sorry, i dont deal with non-currencies [13:09:49] <MrNaz_YMAtv> the boxes that are responsible for handling the live streaming that we do [13:09:54] <av500> ah [13:10:13] <MrNaz_YMAtv> although all the encoding happens on the encoding machines... they are never more than 2 weeks behind the current build [13:10:39] <KotH> MrNaz_YMAtv: is your name by any chance "marc" ? [13:10:45] <MrNaz_YMAtv> no [13:10:46] <MrNaz_YMAtv> its Naz [13:10:52] <MrNaz_YMAtv> as shocking as that may be :P [13:10:56] <av500> Mr NAZ? [13:11:00] <MrNaz_YMAtv> yes [13:11:02] * KotH is shocked [13:11:02] <MrNaz_YMAtv> www.mrnaz.com [13:11:04] <janneg> just because my reply sounds serious does not mean it is serious [13:11:12] * KotH needs chocolate to overcome that shock [13:11:35] <MrNaz_YMAtv> KotH that's some serious shock... sorry [13:11:51] <KotH> hmm zan, naz... sounds like a pseudonym [13:12:04] <kierank> maybe he is ZUN [13:12:13] <MrNaz_YMAtv> KotH no... full name is Nazeer... everybody, including my parents, call me Naz for short [13:12:49] <Tjoppen> hey, I finally got around to poking at dllimport:ing the exported global variables in MSVC again. does AV_DLLIMPORT seem like a good macro name for such a thing? [13:12:51] <thresh> what's wrong with 'naz' anyway [13:12:57] <KotH> MrNaz_YMAtv: btw: you know that it is "illegal" to use a wrong name or pseudonym in domain registrations? [13:13:16] <MrNaz_YMAtv> but if you would like to imagine it is a pseudonym used by a masked outlaw hero who works on ffmpeg based video systems by day and fights criminals and other social miscreants by night then go right ahead [13:13:42] <MrNaz_YMAtv> KotH i believe i've updated it in my registrar... no-ip does have my real details... [13:13:43] <KotH> MrNaz_YMAtv: lol [13:13:46] <thresh> :D [13:14:10] <KotH> MrNaz_YMAtv: check the whois entry. they have your home adress, but the name is wrong :) [13:14:26] <MrNaz_YMAtv> hmm [13:14:28] <MrNaz_YMAtv> that's not good [13:14:38] <MrNaz_YMAtv> i shall update it with alacrity [13:15:10] * KotH imagines MrNaz_YMAtv being a superhero like the ones in "watchmen" [13:16:10] <MrNaz_YMAtv> you mean the ones that have illicit affairs in flying ships with no obvious means of staying aloft and blow fire at the most euphemistic moment? [13:16:50] <KotH> and get blown to atomic pieces because they try to reveal that one of their friends killed million of peoples [13:16:55] <KotH> s/s$// [13:17:01] <MrNaz_YMAtv> yes [13:17:05] <MrNaz_YMAtv> that's a pretty morbid scene [13:17:43] <KotH> the whole comic is very morbid [13:17:54] <KotH> people dying left and right [13:18:23] <MrNaz_YMAtv> although i do like the title song... i hadnt heard bob dylan's times are changin' in ages [13:18:33] * KotH likes the raft in the pirate story [13:18:44] * KotH has not seen the movie yet [13:20:47] <BBB> MrNaz_YMAtv: oh yeah, weren't you going to send me a dinner check? :-p [13:21:06] <BBB> but I believe that might earn you a +v [13:21:18] <BBB> too bad I'm not a channel admin so I can't give them :-p [13:21:31] <MrNaz_YMAtv> heh that's ok [13:21:47] <MrNaz_YMAtv> i'd rather keep my currency and spend it on ffserver work than a +v :) [13:23:01] * BBB goes introduce some bugs in ffserver [13:23:29] <MrNaz_YMAtv> haha [13:23:29] <BBB> (if ffmpeg were closed-source, they'd already be there and I'd push for a new "security release, update quick NOW!") [13:23:44] <MrNaz_YMAtv> one patch per bug [13:24:17] <BBB> the truly skilled can introduce multiple hidden, dark bugs per single patch even though it looks like it's only one bug [13:32:15] <av500> wonder which bug got BBB [13:32:26] <KotH> the truly skilled convinces someone else to fix a bug in a way that adds a few non-obvious bugs [13:32:35] <kierank> av500: three rodents throwing apples [13:32:55] <av500> the apples he uses to login to irc? [13:33:03] <KotH> kierank: rodents arent bugs [13:33:20] <kierank> doesn't matter - it was in the film [13:33:40] <KotH> the only bugs that film has are butterflies [13:33:52] <KotH> though, if we are talking about vermin.... [13:53:37] <xxthink> does anyone know the advantage of f4v compared to flv? [13:53:43] <xxthink> flv can also use h.264 now [13:53:59] <kierank> flv is much simpler than f4v [13:54:09] <xxthink> yes [13:54:11] <kierank> you can do "http streaming" with flv [13:54:13] <xxthink> but why f4v? [13:54:15] <kierank> but not with f4v [13:54:58] <xxthink> I can't find some benifits on f4v [13:57:21] <av500> f4v is what? mp4? [13:57:57] <wbs> yes [13:58:02] <spaam> Video for Adobe Flash Player [13:58:09] <spaam> ;D [13:58:35] <av500> well, mp4 is betterer because it was invented by a fruit company and is an international standard [13:58:46] <av500> and because you cannot stream it [13:58:49] <wbs> yeah [13:58:52] <wbs> and insanely more complex :-) [13:58:56] <av500> and because it wastes memory [13:59:08] <xxthink> mp4 is better? [13:59:20] <kierank> f4v is a subset of mp4 [13:59:26] <xxthink> yes [13:59:30] <av500> it is so good that even apple uses mpegts for streaming :) [13:59:40] <xxthink> :) [13:59:57] <ohsix> does anything in particular in mp4 make it easier to do the awesome scrubbing quicktime does? [14:00:19] <av500> the fact that you know the location of every frame in advance? [14:00:34] <av500> or just that appl put :effort: into making it fast [14:01:27] <ohsix> effort is cool [14:01:49] <kierank> don't question steve jobs [14:02:40] <av500> shoot 1st, question later [14:10:08] <funman> janneg: on which version of gcc did you test r24910 ? [14:11:18] <funman> 4.4.3 doesn't know about atom [14:13:40] <janneg> funman: 4.5 http://gcc.gnu.org/onlinedocs/gcc-4.5.0/gcc/i386-and-x86_002d64-Options.htm… [14:16:20] <av500> lol, chrome barfs on avutil50.dll when running a system that has the DLL exploit "worked around" [14:17:46] <funman> fwiw --cpu=atom worked before this rev but just disabled fast_clz [14:27:23] <Tjoppen> slow ML day today [14:27:56] <Tjoppen> maybe because school's started :) [14:29:38] <cartman> av500: uhm why? The DLL is not in the search path? [14:29:57] <janneg> funman: "worked" only in the sense that it gave you a generic cpu. r24910 fixes --cpu=host for gcc 4.5 on atoms [15:13:16] <Dark_Shikari> BBB: of course not, do it [15:13:23] <BBB> I already did [15:13:25] <BBB> patch on ML [15:13:45] <BBB> I'm now splitting h264dsp_mmx (H264DSPContext) and dsputil_mmx (DSPContext), which isn't too difficult [15:13:58] <BBB> then I'll see if it's possible to yasmify either one easily [15:24:09] <Dark_Shikari> mru: hmm, __builtin_clz acts on unsigned int, not uint32_t [15:24:21] <Dark_Shikari> how can I write code that works even if int is larger than 32 bits? [15:24:44] <Dark_Shikari> 31 - CLZ(x) ---> sizeof(int)*8-1 - CLZ(x)? [15:46:03] <kierank> is there anywhere where you can download some channel lineup bars? [15:49:46] <Compn> you mean [15:50:06] <Compn> some guy saying what speaker is which ? [15:50:44] <kierank> yes. but there's an official one that people use (maybe just in europe?) [15:50:52] <kierank> and it uses tones [15:51:17] <Compn> ah i dont remember if i found that one [15:51:21] <Compn> prob not [15:51:59] <Compn> http://download.microsoft.com/download/winmediatech40/Utility/1.0/W98NT42KM… [15:52:03] <Compn> http://download.microsoft.com/download/6/b/1/6b17045c-6ce8-4dc4-a3b5-2717b8… [15:52:15] <Compn> i think those are the .wav files (auto extractor) [15:52:19] <Compn> http://www.microsoft.com/windows/windowsmedia/howto/articles/Multichannel.a… [15:53:08] <kierank> lol typical microsoft using auto extractor for audio/video [15:53:11] <funman> iirc you can unzip them [15:53:59] <Compn> http://alsa.opensrc.org/index.php/Speaker-test [15:54:02] <Compn> alsa has a speaker test [15:54:54] <kierank> the microsoft one isn't bad [15:55:00] <kierank> it has a decent lfe test tone at least [15:58:28] <Kovensky> !skip http://i35.tinypic.com/jazx2t.jpg [15:58:35] <Kovensky> er, wrong window [15:58:36] <Kovensky> lol [16:04:45] <BBB> Dark_Shikari: can I commit that patch? [16:04:57] <BBB> I'm going to commit the yasmifications also, they make it faster after all [16:08:33] <Dark_Shikari> I'm not objecting [16:09:53] <Compn> anyone in here read chinese ? [16:13:14] <Dark_Shikari> what do you need read? [16:13:21] <Dark_Shikari> (I don't, but I know people who might) [16:14:29] <av500> gg translate? [16:17:55] <Compn> Dark_Shikari : trying to find the name of the program in this list, the MQ.exe program >> http://bbs.ikaka.com/showtopic-8404740.aspx [16:18:27] <Compn> av500 : gtranslate translates it as something generic, like 'video' or so [16:18:37] <Compn> i'm trying to find the exact name, maybe i'll get lucky [16:19:44] <Dark_Shikari> what do you mean? [16:20:00] <Dark_Shikari> ah damn, my native-level speaker isn't online right now. [16:20:27] <Compn> it lists a program installed in d:\program files](chinesename)\MQ.exe [16:20:45] <Dark_Shikari> 360SA... is chinese? [16:20:59] <Compn> if possible i'd like to get the exact chinese name, since google translate gives me ... "Jimmy circle " [16:21:02] <Dark_Shikari> 麦圈 [16:21:05] <Dark_Shikari> looks like a company name [16:21:09] <Dark_Shikari> I would guess HangZhou YiRen ;) [16:21:21] <Compn> well , find me hangzhou yirens' website then :P [16:21:36] * Compn tried copypaste into google but not good results [16:22:17] <av500> Compn: I get "Michael Ring" :) [16:23:00] <Compn> in the end, i'm just looking for the the program so i can get this WaWv.dll file, to test a binary codec :P [16:23:15] <Compn> so if you find that dll , that would be quicker ;P [16:23:36] <CIA-11> ffmpeg: rbultje * r24987 /trunk/libavcodec/x86/ (8 files): [16:23:36] <CIA-11> ffmpeg: Put ff_ prefix on non-static {put_signed,put,add}_pixels_clamped_mmx() [16:23:36] <CIA-11> ffmpeg: functions. [16:24:06] <av500> Compn: http://process.dll-free-download.org/m/mq.exe-hangzhou-yiren-inc.html [16:24:27] <Dark_Shikari> lol [16:25:43] <Compn> av500 : ya i found that site too, hows it help ? [16:25:50] <av500> ah: http://wakoopa.com/developers/hangzhou-yiren-inc [16:26:01] <av500> "A mysterious new application" [16:26:03] <av500> :) [16:26:11] <Compn> lol [16:27:03] <CIA-11> ffmpeg: rbultje * r24988 /trunk/libavcodec/x86/ (7 files): [16:27:03] <CIA-11> ffmpeg: Move VP3 IDCT functions from inline ASM to YASM. This fixes part of the VP3/5/6 [16:27:03] <CIA-11> ffmpeg: issues on Win64. [16:27:24] <Compn> Dark_Shikari : i wonder if that ?? is just 'hangzhou' because thats the results i get in google [16:27:46] <Compn> now if only i could figure how to type 'yiren' in chinese... [16:28:22] <av500> yilen? [16:29:53] <Compn> hah [16:30:09] * Compn types the ?? and mq and gets results for program downloads [16:30:10] <Compn> simple [16:32:06] <CIA-11> ffmpeg: rbultje * r24988 /trunk/libavcodec/x86/ (7 files): [16:32:06] <CIA-11> ffmpeg: Move VP3 IDCT functions from inline ASM to YASM. This fixes part of the VP3/5/6 [16:32:06] <CIA-11> ffmpeg: issues on Win64. [16:32:09] <CIA-11> ffmpeg: rbultje * r24989 /trunk/libavcodec/x86/ (7 files): [16:32:09] <CIA-11> ffmpeg: Move H264 chroma MC from inline asm to yasm. This fixes VP3/5/6 and VC-1 [16:32:09] <CIA-11> ffmpeg: fate failures on Win64. [16:34:01] <Compn> http://www.91mq.com/DownLoad.asp [16:34:04] <Compn> seems to be it [16:34:50] * BBB awaits fate final verdict [16:35:10] <CIA-11> ffmpeg: rbultje * r24990 /trunk/libavcodec/x86/ (Makefile h264_intrapred_init.c h264dsp_mmx.c): [16:35:10] <CIA-11> ffmpeg: Split intra prediction initialization (i.e. assigning of function pointers) [16:35:10] <CIA-11> ffmpeg: into its own file, it doesn't belong in h264dsp_mmx.c (much less so in [16:35:10] <CIA-11> ffmpeg: dsputil_mmx.c). [16:36:55] <Compn> WaWv MPEG-4 Video Codec [16:36:58] <Compn> bwahahaha [16:39:10] <Dark_Shikari> it's all the same shit [16:40:05] <Compn> yes , yes it is [16:40:23] <Compn> but at least ffmpeg will now be able to decode one more fourcc [16:44:23] <BBB> mru: who maintains the fate darwin boxes? [16:44:25] <CIA-11> ffmpeg: compn * r24991 /trunk/libavformat/riff.c: add WAWV fourcc, works on V-codecs/WAWV.avi [16:48:28] <mru> BBB: mike [16:53:12] <av500> Compn: I remember a time what I assumed every non-matching fourcc to be MPEG4 :) [16:53:16] <av500> what->when [16:56:34] <Compn> its not a bad idea :P [16:56:46] <Compn> at least now i have proof its mpeg4 [16:57:11] <Compn> find codec, encode sample, test with ffodivx :) [17:36:25] * kshishkov has reached Ultima Lule and going back [17:37:00] <wbs> kshishkov: is it cold up there north already? [17:38:25] <kshishkov> wbs: yes, I couldn walk in only T-shirt [17:38:58] <wbs> it's gotten quite cold around here, in just a few days :-( [17:39:06] <av500> kshishkov: you needed trousers too? [17:39:09] <wbs> av500: ;P [17:39:16] <wbs> kshishkov: enjoyed sweden so far? :-) [17:39:27] <kshishkov> wbs: javisst! [17:40:16] <kshishkov> av500: maybe it's customary to Darmstadt to walk without trousers, but not in the rest of the world [17:40:57] <av500> very free spirited here [17:41:32] * kshishkov thinks it should be moved closer to Köln then [17:42:42] <kshishkov> wbs: and now Iǘe tasted Trocadero from five different breweries! [17:44:03] <wbs> kshishkov: whoa, congrats :-) [17:44:33] <kshishkov> wbs: maybe I should discover more [17:45:13] <spaam> kshishkov: which one is the best? :) [17:45:16] <wbs> kshishkov: another quite local thing you could try is Hartwall Limonadi Omena, a local finnish lemonade that's quite unique :-) [17:45:20] <wbs> kshishkov: http://fi.wikipedia.org/wiki/Tiedosto:Hartwall_limonadi_omena.jpg [17:46:53] <kshishkov> spaam: Vasa Bryggeri, any other options? [17:48:39] <kshishkov> wbs: okay, Iĺl try it when I visit Finland [17:49:04] * kshishkov still has an untested bottle of Portello [17:50:14] <Dark_Shikari> I fucking love this [17:50:18] <Dark_Shikari> I'm being paid to rip apart a shitty encoder. [17:50:21] <Dark_Shikari> it's like heaven =p [17:50:42] <kierank> which encoder ;) [17:50:52] <Dark_Shikari> Broadcom VC4 [17:51:03] <Dark_Shikari> Supah Sekrit omg-1080p-in-3ms encoder [17:51:15] <Dark_Shikari> (but it can't keep a frame size cap, so the "3ms" is entirely moot) [17:51:17] <kshishkov> VC-4? Isn't that DNxHD or H.264? [17:51:39] <Dark_Shikari> No [17:51:41] <Dark_Shikari> VC4, not VC-4 [17:51:45] <Dark_Shikari> VideoCore [17:51:55] <Dark_Shikari> it's h264 [17:52:57] <spaam> kshishkov: mmm. dont remeber wich one i have tasted.. [17:53:19] <bcoudurier> hi guys' [17:53:21] <iive> i think kshishkov got scared that he missed so many iterations of vc1 - vc2,vc3 ... [17:53:59] <kshishkov> spaam: in Sundsvall it's Vasa Bryggeri, in Luleaa it's Nyckel-Bryggeri (or Spendrups/Carlsberg everywhere) [17:54:39] <kshishkov> iive: not at all, I know SMPTE VC-2 and VC-3 (and we have decoders for them ;) [17:55:49] <iive> :O [17:55:58] * iive got scared and runs around [17:56:38] * kshishkov trows a can of surströmming [17:57:52] <BBB> \o/ [17:58:00] <BBB> only mpegenc fails on win64 now [17:58:00] <spaam> kshishkov: going to eat surströmming?:) [17:58:08] <spaam> BBB: gz! [17:58:15] <BBB> where on earth do I start fixing that? [17:58:27] <BBB> gz? [17:58:52] <kshishkov> spaam: well, I like to try it once a lifetime but I won't ever buy a can of it [17:59:22] <spaam> BBB: gratz. [17:59:43] <spaam> Contgratulations.. [18:01:41] <spaam> kshishkov: they are not that expensive :) you can buy smaller cans with it. [18:03:05] <kshishkov> spaam: yes, I saw them. The problem is where I can eat one and even small can may be too much for me [18:03:55] <spaam> kshishkov: eat one with merbanan ? :) [18:04:33] <kshishkov> spaam: ok, but you convince him [18:05:14] <merbanan> not gonna happen [18:05:18] <spaam> you know him better then me. so it will be much easier for you to do it :) [18:05:46] <spaam> merbanan: kom igen nu. ställ upp ;D han vill ju testa :) [18:06:23] <kshishkov> merbanan: do you have the same number as 16 months ago? I sent you a SMS [18:07:13] <merbanan> changed jobs [18:07:20] <merbanan> got my old one [19:05:30] <peloverde> Has anyone talked to the audacity people about abusing private symbols? [19:05:57] <kshishkov> probably not [19:06:15] <kshishkov> but if you screw some of those they use they'll talk to us, I'm sure [19:06:44] <BBB> which ones do they use? [19:07:16] <peloverde> match_ext [19:07:23] <peloverde> which doesn't exist anymore [19:08:03] <BBB> it's a public symbol now :) [19:08:04] <BBB> \o/ [19:08:38] <peloverde> Really? I though av_match_ext was a public symbol [19:08:40] <peloverde> http://code.google.com/p/audacity/source/browse/audacity-src/trunk/src/FFmp… [19:18:59] <BBB> peloverde: that's what I meant; no more reason to abuse match_ext [19:19:47] <Dark_Shikari> just change its name to break audacity? [19:19:48] <Dark_Shikari> ;) [19:20:31] <peloverde> If you were paying attention you would notice we did change its name [19:20:43] <janneg> peloverde: talk to mchinen when he's around [19:21:21] <peloverde> On their list I see other non av_* symbols too [19:21:22] <kshishkov> janneg: I remember you did so at LinuxTag ;) Not about audacity though [19:21:50] <kshishkov> and IIRC there was some guy with nick LCG or something responsible for FFmpeg integration into Audacity [19:22:51] <peloverde> 75% packet loss really makes my Internet connection unusable :( [19:23:47] <kshishkov> peloverde: well, this train connection is not very stable too [19:41:37] <kshishkov> see you later guys [20:09:58] <siretart> peloverde: FYI: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=593162 [20:10:19] <peloverde> siretart: thnaks [20:10:32] <peloverde> I have a patch I'm testing in my PPA at the moment [20:11:23] <siretart> peloverde: wow, thanks. If your patch turns out to work for you, please pass a copy via email to 593162(a)bugs.debian.org. thanks in advance! [20:11:34] <peloverde> ok [20:15:41] <BBB> \o/ [20:15:52] <BBB> I split out h264dsp_mmx from dsputil_mmx and stuff didn't completely break [20:16:51] <cartman> BBB: only half broken? :D [20:17:03] <BBB> I like to look it at from the positive side [20:17:06] <BBB> it's half-working [20:25:09] <janneg> Dark_Shikari: have you heard of http://www.ta2-project.eu/ ? Frauenhofer IIS videoconferencing with less than 100ms delay using aac eld and h264 [20:31:41] <CIA-11> ffmpeg: rbultje * r24992 /trunk/libavcodec/x86/dsputil_mmx.c: Fix compilation failure if yasm is disabled (missing vp3 symbols). [20:35:12] <Dark_Shikari> 100ms? that's really high [20:37:11] <siretart> peloverde: btw, the issue seems known at audacity upstream: http://wiki.audacityteam.org/index.php?title=Known_Issues, search for av_match_ext [20:41:08] <peloverde> yeah I saw that, Yeah but av_match_ext() was made public in March, so they've had plenty of time to fix it [20:41:33] <peloverde> also looking at their source they use other private functions too [20:42:18] <janneg> Dark_Shikari: depends how much of it is transmit latency. they somehow imply that it is for home to home video chats over DSL. [20:43:12] <janneg> less than 100ms is impressive if home to provider latency is over 50ms on both sides [20:43:12] <Dark_Shikari> true [20:43:23] <Dark_Shikari> home to provider latency at 50ms? [20:43:26] <Dark_Shikari> where, in new zealand? [20:43:51] <Dark_Shikari> 50ms is longer than east to west coast latency in the US [20:44:09] <janneg> interleaved DSL, germany [20:44:36] <Dark_Shikari> then how do our bandwidth/latency tests in europe show western germany having <20ms latency to AMS-IX? [20:45:11] <saintdev> and, yet it takes more than 50ms just to get to the colorado boarder :/ [20:46:01] <janneg> depends on the provider. I have 19ms to the first hop with 50/10mbits VDSL [20:47:26] <Dark_Shikari> janneg: try running http://kyoka.test.gaikai.com/test and pastebin the result. [20:48:49] <janneg> it requires flash? [20:50:07] <Dark_Shikari> Java [20:50:15] <Dark_Shikari> since Javascript is not very useful for sending UDP packets. [20:50:25] <Dark_Shikari> (nor is Flash, for that matter) [20:54:05] <peloverde> Site tells me "Please update your Flash Player now" [20:55:00] <Dark_Shikari> probably just the generic plugin version script thingy [20:55:44] <Dark_Shikari> here's example results: http://pastebin.com/2A08EkeS [20:56:49] <kierank> http://pastebin.ca/1929381 [20:57:02] <lu_zero> <@Dark_Shikari> 100ms? that's really high [20:58:02] <Dark_Shikari> kierank: oh wow, it linked you to the US datacenter [20:58:04] <Dark_Shikari> instead of the AMS-IX one [20:58:07] <Dark_Shikari> lemme check if that's intended. [20:58:14] <Dark_Shikari> Wow @ the jitter though [20:58:16] <Dark_Shikari> amazingly low [20:58:22] <janneg> Dark_Shikari: in my java enabled browser (konqueror) I only get "kyoka is currently offline" [20:58:39] <Dark_Shikari> odd. [20:59:17] <elenril> yay, the java plugin goes into an infinite loop [20:59:21] <cartman> Please update your Flash Player now [20:59:22] <cartman> :D [20:59:26] <cartman> yay for plugin blocking [20:59:29] <lu_zero> Dark_Shikari: which is the expected latency of x264? [20:59:58] <Dark_Shikari> zero [21:00:03] <Dark_Shikari> more specifically, the time it takes to encode one frame [21:00:23] <Dark_Shikari> Plus transmit time, which can actually be interleaved with encoding time via the new low-latency callback api [21:00:31] <Dark_Shikari> (x264 can output slices before the frame is done encoding) [21:00:36] <lu_zero> uhmm [21:01:04] <Dark_Shikari> Oh, it seems I gave out the wrong test URL. [21:01:10] <Dark_Shikari> it was using another network. [21:01:13] <Dark_Shikari> http://kyoka.demo.gaikai.com/test <--correct one. [21:01:27] <Dark_Shikari> .test. is a one-server test network [21:01:32] <lu_zero> so for something low latency one could hack use x264 and stitch an rtp packetizer and be done with it... [21:01:34] <Dark_Shikari> .demo. is the live network (tons of servers all over the place) [21:01:36] <Dark_Shikari> lu_zero: yes [21:01:47] <lu_zero> anybody did already? [21:01:47] <Dark_Shikari> well, it gets a bit trickier in practice [21:01:49] <Dark_Shikari> you need UDP [21:01:53] <Dark_Shikari> and you want to deal with error correction [21:01:55] <Dark_Shikari> and concealment [21:01:59] <Dark_Shikari> etc [21:02:00] * lu_zero has sctp [21:02:13] <Dark_Shikari> Much better, now I get 10ms latency via http [21:02:14] <Dark_Shikari> 6ms via udp [21:02:16] <Dark_Shikari> 0.6ms jitter [21:02:30] <saintdev> and chrome decides the page has locked up for me :P [21:02:33] <Dark_Shikari> It seems the real network is much better than the one-machine test network [21:02:35] <Dark_Shikari> whodathunkit [21:02:49] <Dark_Shikari> lu_zero: we did that ;) [21:02:58] <Dark_Shikari> though it's only one-way. i.e. server/client instead of client/client [21:03:02] <lu_zero> udp or sctp? [21:03:06] <Dark_Shikari> udp [21:03:52] <kierank> it's stuck on "Testing Video Stream" [21:03:54] * lu_zero should fix udp and add sctp in ffmpeg... [21:03:58] <kierank> oh no wait [21:04:00] <kierank> it's gone [21:04:11] <Dark_Shikari> kierank: it can take a while [21:04:19] <Dark_Shikari> especially on slow connections [21:04:20] <BBB> Dark_Shikari: please review the h264dsp_mmx split patch :-p [21:04:25] <BBB> otherwise I have to wait 3 days again [21:04:30] <saintdev> Dark_Shikari: you should probably tell them to test bandwidth over a more extended period of time [21:04:59] <Dark_Shikari> BBB: >123k [21:05:00] <Dark_Shikari> big patch [21:05:02] <Dark_Shikari> saintdev: They know. [21:05:09] <Dark_Shikari> And they don't, for money reasons, and because they don't need to [21:05:10] <BBB> Dark_Shikari: it moves a lot of code around [21:05:20] <Dark_Shikari> i.e. they don't care if you're 40mbit or 400mbit [21:05:39] <BBB> which part of h264dsp shall I move to yasm first? [21:05:39] <Dark_Shikari> BBB: it's not really my code, so I can't really review [21:05:40] <saintdev> Dark_Shikari: but what about 8mbit vs 2mbit.. [21:05:47] <BBB> Dark_Shikari: hm... michael wrote it? [21:05:51] <BBB> or loren? [21:05:55] <Dark_Shikari> probably both [21:05:58] <Dark_Shikari> saintdev: the http bandwidth is measured via tcp [21:06:00] <Dark_Shikari> what matters is udp [21:06:04] <Dark_Shikari> hence the "stream packet loss" [21:06:07] <Dark_Shikari> tcp takes time to ramp up [21:06:33] <saintdev> but things like comcast's 'powerboost' can throw a short test like that off [21:06:53] <lu_zero> 62 ms http [21:06:57] <Dark_Shikari> lu_zero: pastebin the whole thing [21:07:00] <lu_zero> udp is Unknown [21:07:03] <Dark_Shikari> o.0 [21:07:10] <saintdev> lu_zero: i get the same [21:07:14] <Dark_Shikari> I think that happens if the udp test fails [21:07:21] <Dark_Shikari> is your java version really old or something? [21:07:32] <saintdev> Java 1.6.0.21 [21:07:34] <lu_zero> dev-java/icedtea6-bin-1.8.1 [21:07:39] <lu_zero> freshly installed [21:07:50] <kierank> http://pastebin.ca/1929393 [21:07:52] <Dark_Shikari> er, icedtea? [21:07:53] <Dark_Shikari> what [21:08:08] <saintdev> Dark_Shikari: it's a browser plugin version [21:08:09] <lu_zero> http://pastebin.com/xSZzJWr4 [21:08:14] <Dark_Shikari> saintdev: ah [21:08:31] <lu_zero> Java 1.6.0.18 [21:08:34] <Dark_Shikari> kierank: nice connection [21:08:46] <lu_zero> but I guess you can see from the pastebin [21:09:21] <kierank> lol tiscali [21:09:36] <lu_zero> kierank: what's up? [21:09:44] <kierank> worst ISP evah [21:09:46] <astrange> iced tea is redhat's java [21:09:52] <kierank> well tiscali UK anyway [21:09:57] <astrange> they don't license JCK so they can't call it java, i think [21:10:20] <lu_zero> kierank: tiscali IT was that nice that got swamped with requests... [21:10:31] <lu_zero> severely swamped [21:10:46] <kierank> isn't fastweb supposedly good [21:10:56] <kierank> fastweb or fastnet or something like that [21:11:21] <lu_zero> kierank: fastweb is a sort of private network with part of it in fiber [21:11:44] <Dark_Shikari> btw, we will be getting a datacenter in london for obvious reasons [21:11:46] <lu_zero> so it has a number of shortcomings [21:11:47] <peloverde> siretart: I fixed the av_match_ext issue but a bunch of other stuff is masked by the FFMPEG_STABLE macro [21:18:32] <CIA-11> ffmpeg: aurel * r24993 /trunk/libavformat/ (15 files): move pcm demuxers to their own file [21:30:43] <janneg> Dark_Shikari: I can't get the udp latency and jitter tests to work even with successfully detected java plugin. http response time is around 40ms [21:30:51] <Dark_Shikari> odd. [21:33:31] <BBB> mru: is it possible to get a backtrace for the segfaults in wmavoice-11/19k in http://fate.ffmpeg.org/arm-linux-armcc-4.1/20100830182338 ? [21:33:53] <mru> I'll look into those [21:34:22] <mru> I've already filed bug reports to arm about some of those failures [21:36:06] <spaam> upstream bug? :) [21:36:41] <BBB> that's convenient [21:37:45] <mru> quite blatantly compiler bug [21:38:10] <BBB> and who's in charge of freebsd? [21:38:10] <BBB> http://fate.ffmpeg.org/x86_32-freebsd-clang/20100830172252 [21:38:15] <BBB> I'd like to work on that one also [21:38:56] <BBB> mik = mike melanson? [21:39:02] <mru> no [21:39:15] <mru> kostylev [21:39:45] <BBB> mik(a)it-1.ru? [21:40:00] <peloverde> BBB: I thought that was a stack alignment issue [21:40:03] <mru> it is [21:40:12] <mru> icc has the same problem [21:40:17] <BBB> peloverde: compiler bug or code bug? [21:40:23] <mru> some troll ifdeffed those functions for icc [21:40:29] <BBB> hahaha :) [21:40:38] <mru> code bug imo [21:40:40] <BBB> I can do icc then if it's the same bug [21:40:48] <mru> the asm relies on 16-byte aligned stack [21:40:52] <peloverde> It would be great to see a clang/os x machine on fate btw [21:40:55] <mru> which x86 abi doesn't promise [21:41:11] <BBB> I only see icc for x86-64 [21:41:15] <BBB> and h264 works fine there [21:41:34] <mru> yes, it only breaks on 32-bit [21:41:47] <mru> I didn't get icc working in 32-bit mode on my 64-bit linux [21:42:22] <BBB> oh [21:42:27] <BBB> ohwell [22:05:34] <BBB> gcc does funny stuff to ff_h264_biweight_8x4_mmx2 [22:06:07] <BBB> all other biweight functions are unrolled partially or in full, so that there's only a single jmp or jxx in the function [22:06:15] <BBB> this particular function, gcc decides to give it to jmps [22:06:21] <BBB> for no apparent reason [22:07:20] <mru> yes, it has to dump all the jumps it didn't use elsewhere somewhere [22:07:34] <BBB> you can never make too many jmps? [22:08:28] <BBB> looks easy enough [22:08:33] <BBB> I guess I'll yasmify that next [22:10:59] <Dark_Shikari> if there aren't already, make ssse3 versions of the biweight functions [22:11:02] <Dark_Shikari> see x264 for reference [22:11:38] <BBB> there are already [22:11:42] <BBB> only 8x8 16x16 [22:11:47] <BBB> why not 8x16/16x8? [22:12:09] <Dark_Shikari> I thought the MC in ffh264 is square only [22:12:17] <Dark_Shikari> but the 8x4 confuses me then [22:12:42] <BBB> 4x2,4x4,4x8,8x4,8x8,16x8,8x16,16x16 [22:12:43] <mru> weighted isn't only square [22:12:51] <mru> qpel is [22:12:57] <BBB> but ssse3/sse2 is only 8/16 square [22:13:09] <BBB> looks like someone was lazy [22:13:20] <BBB> I'll add those after yasmifying the mmx2 ones [22:13:31] <Dark_Shikari> BBB: while you're at it, make the MC variable-height [22:13:43] <Dark_Shikari> that will involve modify arm/ppc though, but mru can probably help you with the former [22:13:48] <Dark_Shikari> and ppc is trivial since it's intrinsics [22:14:07] <BBB> MC is ... qpel? [22:14:48] <mru> modifying qpel is not trivial _at all_ [22:15:11] <BBB> huh, qpel is a mess [22:15:16] <BBB> that's so much macros that it makes me dizzy [22:15:19] <Dark_Shikari> mru: changing the height isn't that bad though [22:15:29] <mru> yes, it is [22:15:41] <Dark_Shikari> it's changing the size of a for loop [22:15:46] <mru> not the neon code [22:15:50] <Dark_Shikari> oh, the neon. [22:15:58] <Dark_Shikari> did you manually schedule it out for all 16/8 iterations? [22:16:05] <mru> yes [22:16:08] <BBB> holy shit [22:16:10] <Dark_Shikari> oh god [22:16:15] <mru> there are some loops [22:16:20] <astrange> does modulo scheduling work for arm? [22:16:20] <mru> but a lot is unrolled [22:16:22] <Dark_Shikari> that sounds like a code size nightmare [22:16:53] <Dark_Shikari> especially given that each qpel function is really a combination of h and v [22:16:56] <Dark_Shikari> calling each other, etc [22:17:03] <Dark_Shikari> inlining/unrolling it all would be at least 50-100KB of code [22:17:12] <mru> it's not fully unrolled [22:17:34] <mru> but you can't just go and change the height [22:17:37] <mru> it won't work [22:17:42] <Dark_Shikari> could you do it? [22:17:49] <Dark_Shikari> hence why I said "mru could help" =p [22:17:52] <mru> given a week of spare time, sure [22:17:57] <Dark_Shikari> it's that hard ?? [22:18:03] <BBB> I break, he fix o_o [22:18:06] <mru> it would be a rewrite [22:18:12] <Dark_Shikari> ..... [22:18:18] <mru> so please... [22:18:24] <BBB> ok, I'll stay off [22:18:26] <BBB> for now... [22:18:27] <mru> what's the problem? [22:18:37] <astrange> i can't get clang/darwin/x86 to error compiling mpegvideo_mmx... [22:19:07] <BBB> bbl [22:19:31] <astrange> ah [22:19:44] <astrange> is freebsd building without -fomit-frame-pointer? [22:19:52] <mru> Dark_Shikari: why would the qpel mc need to change? [22:20:26] <peloverde> saintdev: I think I found the bug [22:20:29] <peloverde> It's ugly [22:20:32] <astrange> mv partitions that are longer vertically currently call the MC function twice [22:20:34] <saintdev> peloverde: sweet [22:20:35] <astrange> which is slower [22:20:45] <Dark_Shikari> mru: the idea was to fix the functions to take variable height [22:20:46] <saintdev> peloverde: not in my code, is it? [22:20:52] <Dark_Shikari> to avoid multiple calls for non-square partitions [22:21:12] <mru> variable height in the neon qpel would be really nasty [22:21:16] <peloverde> saintdev: It preexisted but your code exacerbates it [22:21:28] <saintdev> just what i thought :) [22:21:50] <saintdev> what is it? [22:22:17] <Yuvi> ...why would anyone use uint16_fast_t as a loop counter [22:22:27] <mru> insanity? [22:22:41] <Dark_Shikari> mru: then you could call the constant height ones multiple times [22:22:52] <Dark_Shikari> it would be the same speed as now [22:22:56] <Dark_Shikari> we'd just be outsourcing it to the asm instead of the C [22:23:04] <Dark_Shikari> thus allowing x86/ppc to do things differently. [22:23:10] <peloverde> wait nevermind, this isn't it :( [22:23:29] <saintdev> :/ [22:23:51] <Dark_Shikari> anyways, let's move it to yasm before we do that. [22:24:09] <peloverde> It looked like I found some per-channel data that was being clobbered [22:24:23] <saintdev> peloverde: that's what it sounds like [22:25:00] <mru> Dark_Shikari: actually, I've already done that adaptation [22:25:04] <Dark_Shikari> ? [22:25:06] <mru> at least for some block sizes [22:25:16] <Dark_Shikari> 16x16 calls 8x8 a lot? [22:25:34] <mru> I have code fro 16x8 etc [22:25:43] <mru> the non-square ones [22:26:02] <Dark_Shikari> well the way ffmpeg does sizes is a bit weird [22:26:08] <Dark_Shikari> mc[0] is 16x16, [1] is 8x8, etc [22:26:12] <Dark_Shikari> it should be like x264 [22:26:23] <Dark_Shikari> [PIXEL_16x16], 16x8, 8x16, 8x8, 8x4, 4x8, 4x4, 4x2, 2x4, 2x2 [22:26:29] <Dark_Shikari> as [0], [1], [2]... [22:26:41] <Dark_Shikari> this avoids the extra argument _and_ lets you keep the optimizations. [22:27:03] <mru> any difficulty in making it like that? [22:27:17] <Dark_Shikari> nope. instead of [X+1] for chroma, it's now [X+3] [22:27:29] <Dark_Shikari> but still just as formulaic [22:27:48] <mru> then let's do that instead of variable height [22:28:00] <mru> less work for me... [22:28:02] <Dark_Shikari> well it has the same problem as variable height in that its a big refactor [22:28:06] <Dark_Shikari> and affects lots of shit [22:28:15] <mru> shit that I've already done though [22:28:19] <Dark_Shikari> I meant non-asm shit [22:28:23] <mru> oh [22:28:28] <Dark_Shikari> dsputil hacking [22:28:31] <Dark_Shikari> stupid shit. [22:28:35] <mru> and variable height doesn't affect lots? [22:28:39] <Dark_Shikari> Oh it does too [22:28:42] <Dark_Shikari> 08:28 <@Dark_Shikari> well it has the same problem as variable height in that its a big refactor [22:28:47] <Dark_Shikari> both are a lot of work. [22:35:04] <CIA-11> ffmpeg: conrad * r24994 /trunk/libavcodec/vorbis_dec.c: [22:35:04] <CIA-11> ffmpeg: vorbisdec: Use int instead of uint16_fast_t for index variables [22:35:04] <CIA-11> ffmpeg: uint16_fast_t is unsigned int (or long) on Linux, which when compared [22:35:04] <CIA-11> ffmpeg: with int results in an unsigned compare. [22:35:21] <astrange> rename libavcodec/x86/vp6dsp_mmx.h => libavformat/nullenc.c (62%) [22:35:32] <astrange> guess it's the license header [22:35:42] <Dark_Shikari> lol? [22:38:00] <saintdev> astrange: git seems to pick random files for renames sometimes [22:39:25] <peloverde> This shouldn't be this hard to find [22:40:03] <saintdev> peloverde: is it possible the window/mdct is reusing data? [22:40:38] <peloverde> It reuses a temporary buffer called "output" (misnomer) [22:41:03] <saintdev> peloverde: because the initial hack i did, where i set the ics window types to be the same worked also [22:43:15] <CIA-11> ffmpeg: aurel * r24995 /trunk/libavformat/ (raw.c Makefile pcmenc.c): move pcm muxers to their own file [22:43:20] <peloverde> what did that patch look like again? [22:43:58] <saintdev> the original one, or the 'fixed' hack that sets the ffpsywindow structs [22:44:40] <saintdev> ...and pastebin.org is down :/ [22:45:39] <spaam> pastie.org is nice [22:46:26] <saintdev> pastie.org doesn't have my old patches on it ;) [22:46:39] <spaam> ah ;D [22:46:54] <spaam> but why do you store them there? :P [22:47:22] <saintdev> because it's easy to use with wgetpaste [22:47:47] <saintdev> i wonder if pastie.org works [22:48:02] <saintdev> hmm, would have to add it. maybe a project for later [22:53:29] <saintdev> peloverde: what i have currently http://dpaste.com/hold/236515/ [22:54:16] <CIA-11> ffmpeg: aurel * r24996 /trunk/libavformat/ (raw.c rawvideodec.c Makefile): move raw video demuxer to its own file [22:58:25] <j0sh> why do some dependencies in configure use pkg-config and others don't? [22:59:10] <saintdev> peloverde: but http://dpaste.com/hold/236519/ also fixes it [22:59:45] <saintdev> peloverde: the second link doesn't force common windows, just has the same effect on apply_window_and_mdct() as a common window [23:05:56] <saintdev> but both eliminate any window decision made for the second channel, so they don't rule out a bug in my code. [23:06:45] <saintdev> however, my code only ever reads from the input buffers so it would be near impossible for it to mess anything up like what we are getting. [23:17:33] <CIA-11> ffmpeg: aurel * r24997 /trunk/libavformat/ (24 files): split raw.c into rawdec.c and rawenc.c [23:24:46] <peloverde> It wouldn't surprise me if it had something to do with s->cur_channel [23:30:35] <saintdev> is s->cur_channel actually used anywhere, before it is set again in the next loop?? [23:30:44] <peloverde> o.O if(!common_window) put_ics_info(s, &sce->ics); [23:30:54] <peloverde> saintdev: it's rarely used, mostly by stuff in the coder [23:31:03] <peloverde> I've been slowly trying to kill it [23:31:13] <peloverde> It is terrible design [23:31:42] <saintdev> i think where it's set just before apply_window can be removed. [23:31:48] <peloverde> yes [23:32:06] <peloverde> also never mind that o.O [23:32:10] <peloverde> sce is set properly [23:34:14] <saintdev> peloverde: how about just after where it decides to set common_window = 1/0 [23:34:23] <saintdev> s->cur_channel = start_ch; [23:35:17] <peloverde> almost all the stuff until the next cur_channel is CPE only [23:37:16] <peloverde> The only thing that isn't is writing tag.elem_id [23:38:57] <peloverde> adjust_frame_information()! [23:39:08] <peloverde> we try to do M/S when not common_window [23:39:16] <peloverde> if (!ch && cpe->ms_mask[w + g]) [23:39:35] <peloverde> add an if(!cpe->common_window) abort(); and watch it explode [23:39:36] <saintdev> o.O [23:41:11] <peloverde> I'll cleanup and commit it [23:41:20] <peloverde> Than probably do some other cleanup [23:43:53] <CIA-11> ffmpeg: alexc * r24998 /trunk/libavcodec/aacenc.c: aacenc: Only apply M/S if common_window is set. [23:44:11] <peloverde> feel free to test it on your end and smack me if it doesn't work [23:44:42] <peloverde> also you lead me in the right direction because it was in that pile of CPE stuff after common_window is decided [23:45:27] <saintdev> :) [23:49:23] <CIA-11> ffmpeg: alexc * r24999 /trunk/libavcodec/ (psymodel.h psymodel.c aacpsy.c): psymodel: Const correct FFPsyWindowInfo. [23:52:05] <saintdev> peloverde: didn't fix it [23:52:18] <saintdev> peloverde: although it does seem a little better [23:52:51] <CIA-11> ffmpeg: alexc * r25000 /trunk/libavcodec/aacenc.c: aacenc: Write tag.elem_id early. [23:53:04] <saintdev> \o/ 25000 [23:53:06] <peloverde> hmm, I was only testing with a small sample, there may be other problems [23:53:41] <saintdev> me too, first 30s of becoming insane by infected mushroom [23:53:57] <saintdev> there's a like a metallic echo unless you do the common window hack [23:56:19] <peloverde> I'm not hearing it on my sample from starwars [23:57:47] <peloverde> Still seeing artifacts in al17 [23:58:28] <saintdev> oh there's still artifacts with forced common_window, just not as bad [23:58:50] <peloverde> http://streams.videolan.org/Mpeg_Conformance/ftp.iis.fhg.de/mpeg4audio-conf…

1 0

IRC log for 2010-08-29
by irc＠mansr.com 30 Aug '10

30 Aug '10

[00:02:19] <BBB> lu_zero: (A) it is nicer to read and (B) it makes marking registers as clobbered much easier than inline asm (particularly because most inline asm uses multiple smaller blocks instead of one big block, in which case it's impossible to mark registers since they'd lose their value at the end of the block) - this isn't an issue on osx/linux, but is a big issue that prevents using optimizations on win64, so it's a big issue for apps such as vlc [00:04:12] <lu_zero> uhm [00:04:41] <BBB> you know, like it or not, ~90% of people use windows :-p [00:05:01] <lu_zero> so instead of merging blocks or make gcc preserve register values [00:05:11] <BBB> it's not that easy [00:05:12] <lu_zero> you rewrite the whole function ^^ [00:05:16] <BBB> it's C mixed with asm [00:05:34] <BBB> I didn't rewrite it, I just copied it [00:05:57] <lu_zero> from the gcc generated code? [00:05:57] <BBB> "statement src, dst\t\n\r" \ becomes statement dst, src [00:06:02] <Dark_Shikari> lu_zero: we only have a single developer who is willing to work with inline asm [00:06:06] <BBB> no, from the inline source [00:06:08] <Dark_Shikari> and he isn't doing any actual work [00:06:09] <Dark_Shikari> end of story [00:06:22] <BBB> yeah, that ^^^ [00:06:33] <BBB> loren, jason, me, vitor and so on can all read and write yasm [00:06:36] <BBB> it's easier to maintain [00:06:42] <BBB> I'm sure more people can write yasm [00:06:49] <BBB> it'll get more developers interested in optimizing [00:07:18] <BBB> if michael dies one day (god forbid), half of ffmpeg is unmaintained and a quarter is not-understood ;) [00:07:33] <lu_zero> as I stated "optimizing" in asm is a single target endeavour. [00:07:37] <Dark_Shikari> "gets hit by a bus" is the technical terminology [00:07:49] <Dark_Shikari> lu_zero: what do you mean? [00:08:34] <lu_zero> that I'd rather see C optimizations [00:08:46] <Dark_Shikari> C alone is useless [00:08:47] <BBB> right, but you need both [00:09:10] <lu_zero> and once you got intrinsics up to a working state I'd move back to them [00:09:12] <Dark_Shikari> it does no good to optimize the primary C functions if 90% of your time is spent in 3 DSP functions that are 4 lines long [00:09:20] <Dark_Shikari> intrinsics are worthless even if the compiler is perfect [00:09:40] <lu_zero> Dark_Shikari: vmx ones shown me the opposite ^^ [00:09:41] <Dark_Shikari> First of all, they don't solve the problem of targets [00:09:49] <lu_zero> how so? [00:09:55] <Dark_Shikari> the only way to get good intrinsic performance is to use arch-specific ones [00:10:01] <Dark_Shikari> generic vector SIMD systems ALWAYS SUCK. [00:10:14] <Dark_Shikari> because every arch has its unique, bizarre, cool instructions that nothing else has quite the same. [00:10:19] <Dark_Shikari> and you can't magically use them [00:10:23] <Dark_Shikari> without explicitly doing so [00:10:29] <BBB> pshufw <3 [00:10:29] <Dark_Shikari> See Orc. [00:10:38] <Dark_Shikari> afaik, Yuvi wrote his own ffdirac [00:10:41] <Dark_Shikari> it's like 2x faster than orc [00:10:42] <BBB> hehe, I was about to mention orc, that's liboil, right? [00:10:46] <Dark_Shikari> er, than the real dirac [00:10:48] <Dark_Shikari> BBB: no [00:10:51] <Dark_Shikari> it's to replace liboil [00:10:58] <Dark_Shikari> orc is an extremely barebones generic simd system [00:10:59] <BBB> ... [00:11:04] <Dark_Shikari> it can't even do things like tranposes iirc [00:11:12] <lu_zero> ehm [00:11:21] <lu_zero> then it's unfair evaluating orc now [00:11:33] <Dark_Shikari> now, I don't doubt a generic simd system can be better than orc is now [00:11:39] <Dark_Shikari> And it's useful for one reason [00:11:46] <Dark_Shikari> you can write once, and get _half-decent_ opts on a dozen architectures. [00:11:55] <Dark_Shikari> They won't be anywhere near optimal in many cases, but they'll be far better than C. [00:11:58] <BBB> I guess generic simd sounds fantastic and if one ever exists that's great, I'll use it [00:12:04] <BBB> but they don't exist... :-p [00:12:04] <Dark_Shikari> That is, if an MC function takes 1000 clocks in C [00:12:08] <Dark_Shikari> and 70 clocks in optimal asm [00:12:12] <Dark_Shikari> orc might get you 150. [00:12:15] <lu_zero> BBB: gcc provides one, stay clear of it [00:12:17] <Dark_Shikari> compared to the C, that's really nice. [00:12:27] <Dark_Shikari> And if it's on an arch you'll never ever write real simd for, that's nice too. [00:12:35] <Dark_Shikari> But it's not a replacement for writing the code properly. [00:12:43] <lu_zero> agreed [00:12:48] <Dark_Shikari> Now, the primary problem with arch-specific intrinsics [00:13:00] <Dark_Shikari> even if the compiler was perfect [00:13:05] <Dark_Shikari> is that the place a barrier between you and the output asm [00:13:07] <Dark_Shikari> For example [00:13:21] <Dark_Shikari> suppose you're writing some SIMD, and you realize that the way you've written it, it'll need 10 xmm registers, and you only have 8. [00:13:28] <Dark_Shikari> So you'll have to throw stack stores/loads all over the place. [00:13:37] <Dark_Shikari> But you realize that if you just tweak a few small things, you can get down to 8. [00:13:45] <Dark_Shikari> If you wrote intrinsics, you'd never know that your code actually took 10 registers. [00:13:52] <Dark_Shikari> And how many it took would depend on the compiler's mood that day. [00:14:00] <Dark_Shikari> So you wouldn't be able to go tweak it to eliminate the stack accesses. [00:14:05] <lu_zero> that's up to the compiler [00:14:17] <Dark_Shikari> the thing is, "tweaking it" is an algorithmic change [00:14:19] <Dark_Shikari> a change the compiler cannot make [00:14:31] <lu_zero> I mean emit a warning [00:14:43] <BBB> it might be on purpose [00:14:45] <BBB> warning is bad [00:14:45] <Dark_Shikari> there are compilers that emit warnings about needing the stack? [00:14:50] <Dark_Shikari> that would be a lot of warnings [00:14:54] <BBB> :) [00:15:04] <BBB> warning, int i is located on the stack [00:15:16] <BBB> warning, for (int i=0;i<h;i++) access stack loads of times [00:15:18] <Dark_Shikari> or in the case of gcc [00:15:26] <Dark_Shikari> "warning: everything has been tossed on the stack, for no reason" [00:15:38] <BBB> yeah it tends to do that [00:15:45] <BBB> and then directly after storing it, it loads it again [00:15:53] <lu_zero> Dark_Shikari: I think openmp or tree-vectorze had some warning about failing to do stuff like that [00:16:03] <Dark_Shikari> tree-vectorize is hilarious [00:16:11] <lu_zero> is a wishful thinking [00:16:24] <lu_zero> same for openmp [00:16:38] <Dark_Shikari> what's openmp, that thing that automatically turns loops into threads? [00:16:51] <lu_zero> more or less [00:16:53] <BBB> lu_zero: well, keep working on good optimization systems, I'll always use the best tool for the job... (un?)fortunately, today that's yasm [00:16:59] <BBB> and yasm is quite pleasant [00:17:08] <Dark_Shikari> oh, also, yasm lets you do certain things that a compiler will never, ever be able to output [00:17:13] <Dark_Shikari> at least not with C [00:17:18] <BBB> SWAP!!! [00:17:19] <lu_zero> Dark_Shikari: I don't doubt that [00:17:21] <Dark_Shikari> (or, better said, at least not with anything higher level than asm) [00:17:23] <Dark_Shikari> Specifically [00:17:25] <Dark_Shikari> computed jumps [00:17:32] <Dark_Shikari> no compiler I have ever seen is capable of doing that. [00:18:14] <lu_zero> I guess we digressed a lot [00:18:22] <BBB> yeah [00:18:30] <lu_zero> you asked me what I meant with single target [00:18:36] <Dark_Shikari> speaking of which, computed jumps are awesome [00:18:42] <Dark_Shikari> every time I do one, I feel extra leet [00:18:42] <lu_zero> and why I'm concerned about overusing it [00:18:46] <lu_zero> theheh [00:18:55] <BBB> is that like jmp x ? thislocation : thatlocation? [00:18:58] <Dark_Shikari> no [00:19:11] <Dark_Shikari> lea tmp, [r1+r2*4] [00:19:14] <Dark_Shikari> jmp/call tmp [00:19:28] <BBB> segfault? [00:19:36] <Dark_Shikari> it's like calling a function pointer array, except instead there's no lookup [00:19:43] <Dark_Shikari> it's used in x264 in two places for cacheline-split stuff [00:19:43] <lu_zero> with tmp not being a label in any case? [00:19:47] <Dark_Shikari> correct [00:19:47] <j0sh> isnt a computed jump basically what a switch statement does [00:19:51] <Dark_Shikari> j0sh: no [00:19:52] <Dark_Shikari> that's a jump table [00:19:59] <Dark_Shikari> computed means there's no table [00:20:01] <Dark_Shikari> here's a simple example [00:20:06] <Dark_Shikari> suppose you have code to handle 16 possible alignments [00:20:07] <lu_zero> j0sh: switch are implemented in hmm [00:20:11] <Dark_Shikari> each alignment case is 64 bytes long [00:20:13] <lu_zero> 3 ways I think [00:20:14] <Dark_Shikari> and aligned accordingly [00:20:30] <Dark_Shikari> you jump to (FirstCase + (Alignment*64)) [00:20:45] <BBB> I've seen that once [00:20:50] <BBB> in a quicktime binary [00:21:02] <BBB> I think [00:21:03] <j0sh> hmm ok [00:21:04] <lu_zero> that is nice till you don't change one case after that [00:21:08] <lu_zero> and you forget ^^; [00:21:12] <Dark_Shikari> ? [00:21:20] <Dark_Shikari> well the cases are just a single macro repeated 16 times [00:21:24] <Dark_Shikari> and this only even exists because intel is LAME [00:21:27] <kierank> [01:17] <@Dark_Shikari> no compiler I have ever seen is capable of doing that. --> couldn't you do that with conditional gotos? [00:21:30] <Dark_Shikari> and pslldq/psrldq/palignr only take immediates [00:21:41] <lu_zero> ah [00:21:53] <Dark_Shikari> kierank: that's just a jump table in disguise, and way slower than a jump table [00:22:09] <Dark_Shikari> you'd have to branch for each one [00:22:32] * lu_zero see another digression branching out [00:22:45] <kierank> we need threaded irc [00:22:45] <Dark_Shikari> there is nothing wrong with digressions [00:22:47] <BBB> digresisons are fun [00:22:51] <lu_zero> yup [00:22:59] <BBB> wasn't google wave supposed to fix irc? [00:23:03] <BBB> until they canned it [00:23:06] <kierank> yes [00:23:13] <kierank> it was meant to fix everything else too [00:23:20] <lu_zero> but then we'll all know lots of interesting thing [00:23:20] <Dark_Shikari> just like everything google does [00:23:31] <lu_zero> but not the main point [00:23:54] <lu_zero> that's you optimize for one target that might get too specific [00:24:24] <Dark_Shikari> it's the job of maintainers of other arches to optimize for them [00:24:57] <lu_zero> so once other similar but not quite appears you might have to spend more than necessary time recycling [00:25:03] <Dark_Shikari> I do x86. I don't do ppc. [00:25:10] <Dark_Shikari> If I do lots of x86, that doesn't take away from ppc. [00:25:20] <lu_zero> eh eh [00:25:36] <BBB> if only there was someone caring about ppc [00:25:42] <BBB> people only care about arm and x86 nowadays [00:25:54] <j0sh> Dark_Shikari: but won't some things possibly regress in say, whatever comes after nehalem [00:25:55] <lu_zero> BBB: ppc got less cpus around [00:25:58] <j0sh> if you optimize too closely [00:26:15] <j0sh> for the timing of particular instructions, etc [00:26:18] <lu_zero> j0sh: regress/break/subtly/break in order [00:26:43] <BBB> j0sh: if that's a reason to not optimize, then what was the point? [00:26:44] <Dark_Shikari> j0sh: doesn't work that way [00:26:49] <lu_zero> was fun with Cell [00:26:54] <Dark_Shikari> "optimizing more" doesn't increase the chance of regression [00:27:12] <lu_zero> when the C compiler wasn't exactly perfect [00:27:30] <j0sh> well im referring more along the lines of optimizing already optimized code [00:27:34] <lu_zero> and you didn't consider which instruction got microcoded and which is not [00:28:19] <lu_zero> (same happened with g3 vs g4 vs g5 and multiple load/store) [00:30:09] <lu_zero> Dark_Shikari: if in one target you can use some nifty instructions to do cache manipulation and in the next one those instructions luckily map to nops you just have a regression [00:30:25] <lu_zero> if you have a nice instruction to wipe a cache line [00:30:49] <lu_zero> and then in the next cpu the cache line size changes you have surprises ^^ [00:31:27] <Dark_Shikari> that doesn't happen with x86 [00:31:42] <lu_zero> yet [00:31:44] <Dark_Shikari> "luckily map to nops" [00:31:48] <Dark_Shikari> no. [00:31:57] <lu_zero> how so? [00:31:59] <Dark_Shikari> we do not change our optimization strategy because of some hypothetical thing that "may happen" [00:32:09] <Dark_Shikari> godzilla may hypothetically eat all of our sse-supporting chips [00:32:11] <lu_zero> s/may/had/ [00:32:12] <Dark_Shikari> but we don't worry about that. [00:32:23] <BBB> if the cache size increases, it means we can micro-optimize even better for future cpus [00:32:50] <BBB> basically the big problem with x86 optimizations is that "soon", there'll always be a "yet newer" set of simd insturctions that you'll have to support [00:32:59] <Dark_Shikari> anyways you're acting as if somehow development isn't an ongoing process [00:32:59] <lu_zero> BBB: then you have to branch optimizations [00:33:01] <j0sh> what about for things like OOE [00:33:04] <BBB> other than that, I don't think any of the problems you explained exist for lu_zero [00:33:09] <j0sh> like atom [00:33:13] <BBB> lu_zero: function pointers, like the dsp setup :) [00:33:24] <Dark_Shikari> j0sh: for that you have to write a custom version of everything you care about [00:33:30] <Dark_Shikari> though really, you can get most of the benefit just by not using pshufb [00:33:31] <lu_zero> BBB: I'm describing what is happening [00:33:44] <j0sh> yeah i suppose so [00:33:49] <Dark_Shikari> lu_zero: what color is the sky in your world? [00:33:50] <lu_zero> Dark_Shikari: and that's why I'm wary of abusing that [00:33:50] <BBB> what's so bad about pshufb? [00:33:58] <Dark_Shikari> BBB: 6/6 on atom [00:34:08] <BBB> now in english? [00:34:09] <Dark_Shikari> lu_zero: um... it takes one line to say "don't use this on atom" [00:34:10] <Dark_Shikari> done [00:34:15] <Dark_Shikari> BBB: um, you know that notation.... [00:34:30] <Dark_Shikari> latency/invthroughput [00:35:22] <BBB> I've probably seen it and forgotten about it straight after [00:36:15] <BBB> can someone review my patches? I want to commit and say \o/ yay as the win64 fate results come in [00:37:24] <Dark_Shikari> maybe a bit later [00:37:31] <Dark_Shikari> honestly it's prolly fine [01:09:20] <kierank> hmmm oktoberfest or stockholm, i can't decide where to visit [01:10:02] <Dark_Shikari> ffbeer [01:12:32] <kierank> hmmm vienna looks nice as well [07:53:45] * elenril pokes siretart [07:53:52] <elenril> what happened to x264 in debian main? [10:17:44] <CIA-11> ffmpeg: mstorsjo * r24962 /trunk/libavformat/rtsp.c: [10:17:44] <CIA-11> ffmpeg: rtsp: Check the RTCP file handle for new packets, too [10:17:44] <CIA-11> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail [10:20:33] <CIA-11> ffmpeg: mstorsjo * r24963 /trunk/libavformat/rtpdec.c: [10:20:33] <CIA-11> ffmpeg: rtpdec: Read RTCP compound packets [10:20:33] <CIA-11> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail [10:21:07] <CIA-11> ffmpeg: mstorsjo * r24964 /trunk/libavformat/rtpdec.c: [10:21:07] <CIA-11> ffmpeg: Reindent [10:21:07] <CIA-11> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail [10:26:11] <CIA-11> ffmpeg: mstorsjo * r24965 /trunk/libavformat/ (rtsp.c rtsp.h rtpdec.c): [10:26:11] <CIA-11> ffmpeg: rtsp: Return AVERROR_EOF when all streams have received an RTCP BYE packet [10:26:11] <CIA-11> ffmpeg: Patch by Josh Allmann, joshua dot allmann at gmail [13:16:37] <DonDiego> moin [13:22:17] <BBB___> mru: ping [14:45:58] <lu_zero> BBB: what news? [14:46:08] <BBB> no news? [14:51:48] <lu_zero> =| [14:55:33] <BBB> lu_zero: I meant: what news are you expecting me to bring? [14:56:22] <lu_zero> this night you were preparing stuff to thin asm file of unasked stuff iirc [14:56:41] <BBB> I need mru to fix me a config.asm for that [14:56:51] <BBB> I'll discuss briefly with him to see if he likes the idea [14:57:04] <BBB> the problem isn't quite as easy as it seems, b/c it's not just h264/vc1/rv40... [14:57:11] <lu_zero> hm? [14:57:30] <BBB> rv3/4 uses h264/rv40 depending on i-dont-know-what, vp6 uses h264, mpeg uses h264, and some other formats use h264 also [14:57:38] <BBB> I don't want to create an #ifdef hell [14:57:49] <BBB> so I'll ask mru for suggestions on how to better do this in configure or so [14:58:35] <lu_zero> uhm [14:59:07] <lu_zero> I'd look at the makefile if you have a deps problem [14:59:39] <BBB> it's not a deps problem [14:59:41] <BBB> it's the opposite [14:59:45] <lu_zero> uhm? [14:59:49] <BBB> right now, we always compile in all mc functions [14:59:56] <BBB> so you get a big chunky fat binary [14:59:59] <lu_zero> yes [15:00:30] <BBB> I'm wondering if we can trim it down if, say, the user disabled most decoders except e.g. vp8 or h264 or [15:00:53] <BBB> clearly if you have only vp8, you don't need any... if you have only vp6, you need h264 chromamc[0][0] at least. if you have h264, you need them all [15:00:59] <lu_zero> so you need a way to trace what uses what [15:01:04] <BBB> right [15:01:11] <BBB> and I don't want to split the .asm file in 10 smaller ones [15:01:27] <BBB> so I'm going to ask mru for suggestions whether a configure trick like for h264pred can be done here [15:01:29] <lu_zero> and the configure should already know [15:01:47] <BBB> no, because this problem has always been there :( [15:01:55] <lu_zero> uhm [15:01:56] <BBB> all mc was always compiled in [15:01:58] <lu_zero> basically [15:02:01] <lu_zero> you need to have [15:02:02] <BBB> just because it was in dsputil [15:02:17] <lu_zero> h264_mc_dep="something" [15:02:32] <lu_zero> vp6_mc_dep="h264_mc" [15:02:35] <lu_zero> and such [15:02:38] <BBB> yes [15:02:47] <BBB> that's the first half [15:02:59] <BBB> then the second half is that in the asm file, you only want to compile those bits that you need [15:03:11] <BBB> this one asm file now contains functions for rv, vc1 and h264 [15:03:18] <BBB> if vc1 is disabled, you want to disable vc1 functions [15:03:21] <BBB> right? [15:03:27] <BBB> but yasm cannot include config.h [15:03:36] <BBB> so we need a config.asm that is like config.h except asm'ified [15:03:40] <BBB> *yasm'ified [15:03:58] <lu_zero> ok [15:04:14] <lu_zero> test_deps is probably what you want =) [15:04:28] * BBB not familiar with configure at all [15:04:32] <BBB> that's why I ping mru :-p [15:05:10] <lu_zero> ^^ [15:05:27] <BBB> :-p [15:05:34] <lu_zero> do you have already a list of deps? [15:06:00] <lu_zero> you will end up with something like [15:06:33] <lu_zero> vp6_decode_select="huffman h264_mc" [15:06:49] <lu_zero> s/decode/decoder/ [15:07:22] <lu_zero> how much space you'd spare this way? [15:30:58] <lu_zero> mru: btw would make sense have a way to autogenerate the configure help out the _LISTs ? [15:47:26] <CIA-11> ffmpeg: vitor * r24966 /trunk/libavcodec/ws-snd1.c: Include stdint.h instead of inttypes.h, it is enough for what this file need. [16:19:13] <CIA-11> ffmpeg: aurel * r24967 /trunk/libavformat/ (raw.c Makefile aacdec.c): move ADTS AAC demuxer to its own file [16:36:36] <CIA-11> ffmpeg: aurel * r24968 /trunk/libavformat/ (raw.c Makefile raw.h idroqenc.c): move id roq muxer to its own file [16:37:45] <BBB> lu_zero: sorry, ran away for a bit... I don't think it'd save much, maybe a few kb, but that's always a few kb [16:38:27] <CIA-11> ffmpeg: aurel * r24969 /trunk/ (4 files in 2 dirs): rename idroq.c to idroqdec.c [16:41:03] <lu_zero> uhmm [16:59:52] <BBB> lu_zero: the whole file is 16kb, about half of that is h264 and a quarter (each) is rv40 and vc1 [16:59:56] <BBB> so removing vc1 would save 4kb [16:59:59] <BBB> (this is all stripped) [17:03:12] <lu_zero> give me the deps relations [18:28:56] <CIA-11> ffmpeg: aurel * r24970 /trunk/libavformat/Makefile: 10l: aacdec and idroqenc still depend on raw.o [18:34:29] <CIA-11> ffmpeg: aurel * r24971 /trunk/libavformat/raw.c: simplify code by using the AV_NE() macro [19:01:36] <CIA-11> ffmpeg: aurel * r24972 /trunk/libavformat/ (dtsdec.c raw.c Makefile raw.h): move DTS demuxer to its own file [19:16:59] <CIA-11> ffmpeg: aurel * r24973 /trunk/libavformat/ (raw.c ingenientdec.c Makefile raw.h): move ingenient demuxer to its own file [19:45:40] <lu_zero> yawn [19:45:46] <lu_zero> BBB: you there? [19:46:37] <drecute> question: what can I do when client refuse to pay on time for service rendered [19:47:39] <lu_zero> ask till he paid [19:47:45] <lu_zero> or use lawyers [19:48:06] <drecute> great [19:48:30] <lu_zero> uhm? [19:58:58] <Compn> drecute : install backdoors and blackmail them! :P [19:59:12] <drecute> lol [19:59:28] <drecute> then they will stop being ur client [19:59:33] <drecute> then i will lose money [19:59:42] <drecute> i want to maintain a relationship [19:59:45] <Compn> can you call them a client if they dont pay ? :P [20:00:00] <drecute> they dont pay on it [20:00:04] <drecute> they dont pay on time [20:00:12] <drecute> that's it [20:00:15] <Compn> well then just expect not to get paid on time [20:00:28] <drecute> even thouugh they like the service [20:00:31] <Compn> heh [20:00:36] <Compn> charge them double next time [20:00:37] <Compn> :P [20:02:44] <lu_zero> that works as well [20:37:18] <CIA-11> ffmpeg: aurel * r24974 /trunk/libavformat/ (raw.c mpegvideodec.c Makefile): move mpegvideo demuxer to its own file [20:44:24] <BBB> lu_zero: pong [20:44:34] <BBB> sorry, little busy, not in front of the screen all the time [21:15:48] <CIA-11> ffmpeg: aurel * r24975 /trunk/libavformat/ (raw.c Makefile cavsvideodec.c): move cavsvideo demuxer to its own file [21:24:22] <CIA-11> ffmpeg: aurel * r24976 /trunk/libavformat/ (raw.c Makefile m4vdec.c): move m4v demuxer to its own file [21:24:22] <CIA-11> ffmpeg: aurel * r24977 /trunk/libavformat/m4vdec.c: cosmetic [21:29:46] <CIA-11> ffmpeg: aurel * r24978 /trunk/libavformat/ (raw.c Makefile h264dec.c): move h264 demuxer to its own file [21:35:14] <CIA-11> ffmpeg: aurel * r24979 /trunk/libavformat/ (raw.c Makefile h263dec.c): move h263 demuxer to its own file [21:38:29] <CIA-11> ffmpeg: aurel * r24980 /trunk/libavformat/ (raw.c h261dec.c Makefile): move h261 demuxer to its own file [21:45:19] <CIA-11> ffmpeg: aurel * r24981 /trunk/libavformat/ (raw.c Makefile diracdec.c): move dirac demuxer to its own file [21:52:40] <CIA-11> ffmpeg: aurel * r24982 /trunk/libavformat/ (raw.c Makefile dnxhddec.c): move dnxhd demuxer to its own file [22:03:37] <CIA-11> ffmpeg: aurel * r24983 /trunk/libavformat/ (raw.c Makefile ac3dec.c): move ac3/eac3 demuxer to its own file [22:07:39] <CIA-11> ffmpeg: aurel * r24984 /trunk/libavformat/raw.c: cleanup includes which are not used anymore in raw.c [22:16:41] <CIA-11> ffmpeg: aurel * r24985 /trunk/libavformat/ (raw.c Makefile nullenc.c): move null muxer to its own file [22:22:29] <CIA-11> ffmpeg: aurel * r24986 /trunk/libavformat/raw.c: simplify code by using the AV_NE() macro [23:07:24] <BBB> hi j0sh, how's the startup going? :-p [23:11:53] <Dark_Shikari> 1 [23:11:59] <Dark_Shikari> bah, irssi local editing fail [23:17:24] <j0sh> BBB: excellent [23:18:08] <j0sh> dont have much to show for it yet, but hopefully soon enough :) [23:37:10] <BBB> saste: nice catch on the preprocessor thingy ;)

1 0

IRC log for 2010-08-28
by irc＠mansr.com 29 Aug '10

29 Aug '10

[00:34:08] <spaam> jaja :) [04:18:53] <peloverde> saintdev: people are reporting breakage on the window decision patch [04:19:00] <saintdev> eek [04:19:03] <saintdev> like what? [04:19:46] <astrange> cehoyos says "ffmpeg -i appletrailer.mov -ab 256k test.aac" sounds "heavily distorted" [04:19:47] <peloverde> http://lists.mplayerhq.hu/pipermail/ffmpeg-cvslog/2010-August/032344.html [04:21:31] * saintdev looks [04:29:30] <saintdev> could it be because of non common windows? [04:30:11] <saintdev> hmm, need a way to force common windowing [04:31:27] <saintdev> it sounds 'echoy' but there's no way block switching (even if it's incorrect) could cause that. that i know of. [04:33:40] * saintdev doesn't really want to be debugging stereo right now [04:34:46] <saintdev> peloverde: do common short windows need to have the same grouping? [04:35:54] <peloverde> I don't remember [04:36:13] <peloverde> It wouldn't surprise me [04:36:55] <saintdev> kshishkov: ^^ [04:38:08] <peloverde> Look at the spec or at how it gets decoded/encoded in the bitstream [04:40:22] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/aacdec.c;h=62aab349e1d1… [04:40:39] <saintdev> found the check later on [04:40:46] <peloverde> decode_ics_info is only called once on common_window [04:49:50] <saintdev> yep, seems to be a bug in non-common windowing [04:50:22] <saintdev> if i force common widowing with lame attack detection it sounds just as bad as 3gpp [04:50:38] <saintdev> if i give it free reign, it sounds worse [04:54:26] <saintdev> the thing is after a certain length of time, 3gpp will bias heavily tword long windows [04:54:26] <peloverde> huh? shouldn't forcing common_window=0 be essentially dual mono? [04:54:34] <saintdev> peloverde: other way around [04:54:49] <saintdev> i'm forcing common_window=1 [04:55:08] <saintdev> not just setting common_window=1, actually setting the window types so that it selects it [04:55:56] <saintdev> so i'm guessing that 3gpp uses common windows on most everything (along with long blocks) [04:56:20] <peloverde> common_window = 1 implies the signals are fairly similar [04:56:50] <saintdev> well sure [04:58:11] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/aacenc.c;h=0fa33e87b1b2… [04:58:28] <saintdev> yeah i know [04:58:43] <peloverde> groupings shouldn't be copied, they should be part of the test [04:59:09] <saintdev> peloverde: http://pastebin.org/791748 [04:59:11] <saintdev> peloverde: ok [04:59:28] <saintdev> oops forgot to remove the #if 0 there :P [05:00:59] <peloverde> I'm missing somethign, taht doesn't make sense to me [05:01:25] <saintdev> how so? [05:01:51] <saintdev> i'm just copying channel 0's window decision to all subsequent channels [05:01:57] <peloverde> yes... why? [05:02:01] <saintdev> which forces common_window=1 [05:02:13] <peloverde> why do you want to force common_window=1? [05:03:16] <saintdev> because it fixes the problem (not a solution, just a test to see if my hunch was right) [05:05:31] <saintdev> peloverde: with common_window unset (free to choose) http://saintdevelopment.com/temp/test1.mp4 [05:05:56] <saintdev> peloverde: with the above hack to force common_window=1 http://saintdevelopment.com/temp/test2.mp4 [05:06:17] <peloverde> what do yo umean by free to choose? [05:06:35] <saintdev> unmodified code [05:07:12] <peloverde> How about you only set common_window=1 if the window is common to both channels? [05:07:37] <saintdev> it does that unmodified [05:08:11] <peloverde> No it doesn't, it ignores groupings [05:08:54] <saintdev> if (wi[0].grouping[j] != wi[1].grouping[j]) { cpe->common_window = 0; break; } [05:09:48] <peloverde> hmmm... then something else seems off [05:10:51] <peloverde> Why is there distortion if the windows aren't identical and common_window=0? That's the dual_mono case [05:11:15] <saintdev> maybe it uses M/S? [05:11:39] <peloverde> It shouldn't [05:11:47] <peloverde> M/S can only be used if common_window is 1 [05:11:51] <saintdev> ahh [05:12:01] <peloverde> I can't look at this now, i'm in the wrong os [05:13:15] <saintdev> see if i can do this proper-like. modifying all channels windows to match the current. [05:14:07] <peloverde> none of this is making sense, i'm too tired, if you have ideas try some stuff out, otherwise I will look at it in the morning [06:02:15] <saintdev> actually, erm what [06:02:17] <saintdev> ugh [06:03:09] <saintdev> i need to get to bed :/ [06:17:57] <saintdev> ok, more correct hack has the same results, whew [06:23:19] <saintdev> peloverde: 'fixed' hack http://pastebin.org/791965 [06:27:12] <saintdev> although not proper, not seeing a way to do it cleanly at the moment, and i need to get to bed. [06:29:16] <kshishkov> god morgon [06:41:11] <kshishkov> hejsan [06:59:30] <superdump> saintdev: you're working on aacenc i see, excellent! :) [06:59:56] <superdump> i hope stereo gets fixed soon, as it's probably the more common use case than any other :) [07:00:20] <superdump> peloverde: what do you think is broken in stereo mode? [07:00:27] <superdump> hej kshishkov ;p [07:13:45] <kshishkov> superdump: any idea what conference is being held in Stockholm and when it ends? [07:14:31] <superdump> kshishkov: there's this: http://www.digitaldays.se/ [07:14:36] <superdump> not foss, just stuff [07:14:57] <superdump> http://communityhack2.eventbrite.com/ [07:15:01] <superdump> that's foss methinks [07:15:08] <kshishkov> no, I mean some conference not related to us [07:15:14] <superdump> when? [07:15:25] <kshishkov> it's the reason why all hotels in Stockholm are full [07:18:09] <superdump> no idea [07:18:30] <superdump> there's some concert called popaganda on [07:18:37] <superdump> but i can't imagine it being that big [07:19:21] <kshishkov> ah, something on cardiology till 1st of September [07:22:03] <kshishkov> well, I wanted to visit Sundsvall anyway [07:29:39] <merbanan> kshishkov: are you in sundsvall now ? [07:30:12] <kshishkov> merbanan: no :( Uppsala [07:30:17] <merbanan> ah ok [07:30:26] <kshishkov> but I'll go there today [07:30:31] <merbanan> ok [07:31:21] <merbanan> I'll be gone over the weekend [07:31:34] <kshishkov> what a coincidence ;) [07:31:37] <merbanan> but I'll be in stockholm during the weekdays [07:32:01] <merbanan> then I'll be bizzy on the weekend again [07:32:07] <kshishkov> eventually I'll be too [07:32:32] <kshishkov> but I think I know how to lure you to meeting with me [07:34:23] <merbanan> ;) [07:35:22] * kshishkov tries to remember what was the capital of Sweden between Birka and Stockholm [07:53:51] <kshishkov> time to explore vicinity [08:12:11] <KotH> .o0(why did i read "explode"?) [08:49:28] <cartman> mru: does fate test clang on OSX? [08:49:37] <mru> doesn't look like it [08:49:48] <mru> someone with an osx machine would have to do that [08:49:53] <cartman> hmm it seems to be able compile it at least :D [08:49:55] <cartman> nice warnings too [08:51:43] <cartman> libavcodec/pcm-mpeg.c:294:36: warning: if statement has empty body [-Wempty-body] [08:51:43] <cartman> retval, *data_size); [08:51:47] <cartman> might be worth to look at [08:52:36] <mru> if () { /* blank */ } or what? [08:52:40] <cartman> doesn't seem to be able to compile mmx code [08:53:06] <mru> it's just a dprintf [08:53:10] <mru> nothing to worry about [08:53:16] <cartman> yup [08:53:28] <cartman> why would clang warn for that anyway [08:53:34] <mru> because it's anal [08:53:49] <cartman> libavcodec/x86/cavsdsp_mmx.c:428:1: error: unrecognized instruction [08:53:50] <cartman> QPEL_CAVS(avg_, AVG_3DNOW_OP, 3dnow) [08:53:52] <cartman> end of the road :D [08:53:52] <Yuvi> haven't seen that warning as of late [08:53:53] <Yuvi> if you're using svn it defaults to using its integrated assembler which can't assemble 3dnow [08:54:02] <cartman> Yuvi: svn yup [08:54:05] <Yuvi> so use --no-integrated-as [08:54:14] <cartman> Yuvi: oh :) [08:54:21] <mru> 3dnow is obsolete anyway :-) [08:54:31] <cartman> 3dneverever [08:54:35] <cartman> Yuvi: is there a bug for that? [08:55:03] <Yuvi> http://llvm.org/bugs/show_bug.cgi?id=7352 [08:55:20] <cartman> Yuvi: thanks [09:03:16] <cartman> make test passes [09:04:09] <cartman> is there a fate howto somewhere? [09:04:15] <cartman> how do I checkout & test [09:06:40] <cartman> mru: any help there? [09:06:46] <cartman> I am willing to burn my MBP :P [09:41:50] <wbs> cartman: http://lists.mplayerhq.hu/pipermail/fate/2010-July/000260.html [09:42:43] <cartman> thanks wbs [11:47:04] <CIA-11> ffmpeg: vitor * r24954 /trunk/tests/ (5 files in 2 dirs): CCITT Fax Group compression fate tests [12:17:19] * _av500_ is back from smaland [12:21:08] <KotH> oh.. you were in lichtenstein? how much money did you "save" this time? [12:25:30] <janneg> s/lichtenstein/sweden/ [12:25:42] * janneg gives _av500_ an 'Ã¥' [13:50:46] <BBB> Dark_Shikari: if I have a define as in %define AVG(x, y) which is either nothing or pavgb x, y (called like AVG(m100, [addr])), can I make this define a multi-instruction statement somehow? e.g. AVG2(x,y,z) would expand to movd y, z; pavgb x, y; %define AVG2(x,y,z) movd y,z\<newline>pavgb x, y doesn't work [14:08:06] <CIA-11> ffmpeg: aurel * r24955 /trunk/libavcodec/vp56dsp.c: cosmetic [14:46:44] <CIA-11> ffmpeg: vitor * r24956 /trunk/tests/ (ref/fate/fax-g4 ref/fate/fax-g4s fate2.mak): [14:46:44] <CIA-11> ffmpeg: Remove CCITT fax G4 tests (partial revert of r24954). This test is [14:46:44] <CIA-11> ffmpeg: corrupting memory somehow and segfaulting in the BSDs. [14:52:53] <CIA-11> ffmpeg: vitor * r24957 /trunk/tests/ (ref/fate/ws_snd fate2.mak): Add fate test for Westwood SND1 codec [15:06:56] <Dark_Shikari> BBB: make it a macro [15:07:06] <BBB> yeah I ended up doing that [15:07:12] <BBB> so there's no way to do that using direct defines? [15:07:39] <Dark_Shikari> what's wrong with a macro? [15:07:42] <Dark_Shikari> a macro is just a multi-line define [15:07:43] <BBB> nothing [15:07:54] <BBB> it's a few more lines of code, it seems [15:08:00] <BBB> but it's nothing important [15:46:52] <BBB> if I specify that a function should use 8 registries on x86-64, I get this: "warning: (ASSERT:2) assert failed" (i.e. cglobal func, 6, 8) [15:47:28] <BBB> Dark_Shikari: what should I do if I want to use 8 regular registries on x86-64? is func, 6, 7 enough? [15:48:46] <Dark_Shikari> look at x264, deblock-a.asm [15:48:48] <Dark_Shikari> and the x86_64 functions [15:50:40] <BBB> cglobal deblock_h_luma_sse2, 5,7 [15:50:40] <BBB> movsxd r10, r1d [15:50:47] <BBB> so r10 is caller-save? [15:51:04] <BBB> (or rather, callee-can-fuck-it-up-as-it-wishes) [15:52:06] <Dark_Shikari> yes [15:52:16] <Dark_Shikari> it's one of a few extra free registers [15:52:23] <Dark_Shikari> we never created a unified system for handling functions with >=8 regs [15:53:49] <BBB> got it [15:53:56] <BBB> I only needed 1, r10 is perfect [15:53:57] <BBB> thanks [16:04:35] <kierank> anybody up for ffoktoberfest? [16:04:51] <mru> where and when? [16:05:20] <KotH> münchen, oktober? [16:05:28] <kierank> yes [16:05:34] <kierank> oktoberfest runs from Sep 18 Oct 4 [16:05:35] <mru> oktober is a bit vague [16:06:09] <KotH> kierank: wrong range of date for me [16:06:20] <mru> I'll be in karlsruhe through september [16:06:38] <mru> guess I could pop over to mÃŒnchen for a weekend [16:07:13] <mru> 18th or 25th would work [16:10:08] * BBB has make fate passing with rv40/h264/vc1 mmx-mc converted into yasm [16:10:09] <BBB> \o/ [16:10:17] <BBB> now to do the ssse3 parts [16:10:28] <mru> nice work [16:10:35] <BBB> it's a lot less code also [16:10:44] <BBB> not code as in binary code [16:10:49] <BBB> just code as in "crap around it" [16:33:39] <Dark_Shikari> BBB: god damn this will be so much easier to maintain now [16:33:43] <Dark_Shikari> you are awesome [16:33:45] <BBB> I know [16:33:53] <BBB> I already see tons of ways to optimize this now that I can read it [16:34:15] <Dark_Shikari> but we need to do xvp8 eventually =p [16:34:16] <BBB> you have no^devery idea how much more readable yasm is over inline asm [16:34:23] <BBB> I know, I want to do that [16:34:28] <BBB> but this needs to be done also [16:34:37] <Dark_Shikari> at this rate we won't be done in time for xiphcon ;) [16:34:51] <Dark_Shikari> but yes I agree. [16:34:58] <BBB> some people have asked me about my ideas on vp8 encoding already [16:35:06] <BBB> I might just push them a little so we get funding [16:35:11] <BBB> much better than doing it for free ;) [16:35:19] <BBB> everyone complains libvpx performance is horrible [16:35:24] <Dark_Shikari> eheheheheh [16:35:26] <BBB> these are the freetards btw :-p [16:35:58] <Dark_Shikari> the evil x264 plan to take over the world [16:37:53] <BBB> I always wonder how that will work... so will phones in 5 years from now use x264 for encoding plus a stripped ffmpeg for decoding when they do video-chat? [16:38:06] <BBB> phones = android phones I guess, since that's currently the best seller in the US [16:39:00] <BBB> please port yasm to support neon or so :-p [16:39:52] <funman> what's wrong with gas? [16:41:30] <Dark_Shikari> horrible preprocessor [16:41:32] <Dark_Shikari> ugly syntax [16:42:36] <roxfan> you can use c preprocessor o.o [16:43:03] <pengvado> which is horrible [16:43:05] <roxfan> and arm syntax is pretty much standard [16:43:11] <Dark_Shikari> what pengvado said [16:43:54] <Dark_Shikari> asm has no syntactical sugar like function calls and more-than-one-op-per-line like C [16:43:58] <Dark_Shikari> so you need a very good preprocessor to compensate [16:44:05] <roxfan> hmm [16:47:21] <BBB> funman: yasm compared to any old-as is like comparing a ferrari to a ford from the 30s [16:47:24] <BBB> they're both cars [16:47:27] <BBB> that's where it ends [16:55:17] <Dark_Shikari> oh btw, BBB, the new cavlc trellis will allow us to write a vp8 trellis in about 5 minutes [16:55:21] <Dark_Shikari> "trellis" [16:55:29] <Dark_Shikari> (we can write a real trellis later, since vp8 is relatively easy to trellis) [16:55:55] * BBB accepts the poke :-p [16:57:13] <BBB> shit I'm slow, should head out or I'll miss dinner [16:57:17] * BBB forgot it was 1PM already [16:57:32] <Dark_Shikari> 1 PM? dinner? [17:02:38] <mru> gas is fine [17:02:47] <mru> it's not exactly the same as yasm [17:02:52] <mru> and therefor Dark_Shikari can't stand it [17:12:34] <Dark_Shikari> mru: er... no [17:12:53] <Dark_Shikari> I'm fine with things that aren't yasm [17:12:53] <pengvado> arm gas syntax isn't as horrible as x86 gas syntax [17:12:58] <Dark_Shikari> and yeah, what pengvado said [17:13:05] <Dark_Shikari> "GAS" is not one particular syntax [17:13:08] <Dark_Shikari> "gas x86" is one particular syntax [17:13:26] <mru> there are two x86 syntaxes in common use [17:13:28] <Dark_Shikari> the preprocessor still sucks, but on ARM scheduling is so important than you can't macro things up that effectively anyways [17:14:17] <mru> I don't think you've explored the full potential of gas macros [17:15:16] <Dark_Shikari> what can you use besides the C preprocessor in inline asm? [17:15:44] <mru> the gas builtin macro processor [17:15:46] <Dark_Shikari> you certainly can't redefine register names [17:15:52] <mru> can too [17:15:56] <Dark_Shikari> can you override ops? [17:16:00] <mru> sure [17:16:09] <mru> why you'd want to I have no idea [17:16:13] <Dark_Shikari> simple reason [17:16:22] <funman> %define NOP RET [17:16:22] <Dark_Shikari> on x86, "add REG, 128" is larger than "sub REG, -128" [17:16:29] <Dark_Shikari> because of how the immediates are coded [17:16:33] <Dark_Shikari> therefore, we do [17:16:35] <Dark_Shikari> %macro add 2 [17:16:42] <Dark_Shikari> %ifnum %2 [17:16:42] <mru> that's a quirk of x86 [17:16:46] <mru> also not a problem on arm [17:16:46] <Dark_Shikari> %if %2 == 128 ... [17:16:53] <Dark_Shikari> Yes, but you didn't say ARM. [17:16:54] <mru> but it could be done with gas [17:17:04] <Dark_Shikari> Is there an "ifnum" in gas? [17:17:17] <Dark_Shikari> i.e. an if that returns true if the operand is a number, false if not. [17:17:30] <mru> don't remember [17:17:43] <Dark_Shikari> anyways it's all besides the point since all this shitty x86 asm is inline in C, not separate gas files [17:17:49] <Dark_Shikari> and is this a pile of bollocks [17:17:54] <Dark_Shikari> *thus [18:54:32] <peloverde> wow, winamp's aac decoder is really good [18:55:01] <elenril> better than ffaac? [18:55:38] <Dark_Shikari> as in fast? [18:58:26] <peloverde> As in compliant [18:58:48] <peloverde> It seems to play everythign except Main and LTP and I have a feeling in that case it's the demuxer rejecting them [19:03:20] <peloverde> as opposed to FAAD which afaict doesn't actually support ANY whole profiles [19:05:09] <spaam> kshishkov: SkÃ¥l! [19:06:55] <saintd3v> peloverde: don't think i've ever looked into who's decoder they licensed [19:09:23] <peloverde> I think it was inhouse [19:09:43] * saintd3v wonders what strings in_mp3.dll says [19:09:55] <peloverde> "Fraunhofer IIS MP3 Decoder" [19:10:00] <kshishkov> spaam: well, I got a bottle of Trocadero by Vasa Bryggeriet [19:10:18] <spaam> kshishkov: nice :) i got some carlsberg beer : ) [19:10:23] <kshishkov> spaam: but mysteriously it turned to be half-empty [19:10:35] <spaam> haha :D [19:10:48] <spaam> going to drink some more .. c u later :D [19:11:08] <kshishkov> hej daa [19:11:39] <saintd3v> peloverde: guess that solves that mystery :P [19:12:19] <kshishkov> depends on version [19:12:44] <kshishkov> could it be actuall beta of MP3 licensed to EA? [19:14:03] <saintd3v> or they could have done like Real, and changed a few things to make their 'own' format [19:14:15] <kshishkov> why should one main a licensed codec - itÅ all work and they were not going to compete on general market [19:14:22] <kshishkov> *maim [19:14:54] <saintd3v> vendor lock-in? [19:15:33] <kshishkov> no need for that [19:16:13] <kshishkov> could be for preventing unauthorised decoding (i.e. by user) though [19:16:49] <peloverde> every elem_id=0 stream crashes winamp o.O [19:18:16] <kshishkov> heh [19:19:59] <Dark_Shikari> "better than faad" is not really that much to brag about [19:20:57] <peloverde> everyone thought faad was "good enough" for years [19:23:23] <kshishkov> thatÅ because nobody tried to look closely at its source code [20:26:18] <kierank> does oprofile work in a vm? [20:26:37] <Dark_Shikari> yes, but you have to change the timing mode [20:26:46] <Dark_Shikari> normally it uses CPU counters [20:27:02] <Dark_Shikari> it'll tell you that only one counter is available, and that's the kernel timer [20:34:42] <kierank> doesn't seem to do anything in virtualbox [20:35:08] <Dark_Shikari> the kernel counter does not require CPU support [20:35:12] <Dark_Shikari> it will work in virtualbox [20:59:36] <saintd3v> peloverde: you looked at the issue in aacenc at all? [21:04:04] <CIA-11> ffmpeg: lorenm * r24958 /trunk/libavcodec/x86/fft_mmx.asm: cosmetics in imdct_sse [21:18:42] <CIA-11> ffmpeg: vitor * r24959 /trunk/libavcodec/ws-snd1.c: Hopefully fix the fate-ws_snd breakage on PPC [22:59:23] <BBB> Dark_Shikari: more dark-gray yasm questions [22:59:42] <mru> paint it black [22:59:44] <BBB> Dark_Shikari: say I'm running a function that calls another one (idct), so I use jmp to call the second question [22:59:54] <mru> tail call? [23:00:00] <BBB> Dark_Shikari: however, on win64, I need to pop some registers before I do that [23:00:04] <BBB> Dark_Shikari: how do I do that? [23:00:18] <BBB> mru: jmp is like a tail call, no? [23:00:24] <mru> jmp is jmp [23:00:30] <mru> no more, no less [23:00:31] <BBB> or can I just do call func instead of jmp func? [23:00:59] <mru> you should optimise tail calls of course [23:01:17] <Dark_Shikari> BBB: look in x264 [23:01:18] <lu_zero> BBB: those functions are big? [23:01:19] <Dark_Shikari> there's stuff like [23:01:22] <Dark_Shikari> %ifdef UNIX64 [23:01:23] <Dark_Shikari> jmp [23:01:27] <Dark_Shikari> %else [23:01:30] <Dark_Shikari> call, ret [23:02:16] <BBB> ok, I don't need to pop regular regs, so I guess I'd do %if win64 call, ret %else jmp .. %endif? [23:02:22] <BBB> or is that considered unsafe? [23:02:55] <Dark_Shikari> you mean call, RET [23:03:03] <Dark_Shikari> I think that's fine [23:05:47] <BBB> right, call+RET [23:05:52] <BBB> let's see if that fixes my last problem [23:06:17] <BBB> yay! [23:06:23] <BBB> ea-vp60 fate test passes on win64 now [23:06:51] <BBB> also someone could write rv40 ssse3 mc functions if he wants to kill himself [23:07:34] <Dark_Shikari> copy vp8's [23:07:38] <Dark_Shikari> change coefficients [23:08:54] <BBB> rv40 uses the h264 one [23:09:01] <BBB> but yeah you could do that too [23:09:13] <BBB> but if it all uses yasm that's already great progress [23:17:49] <BBB> I think my patch fixes vc1 fate test on win64 also [23:17:56] <BBB> goody [23:18:28] <BBB> I wonder why h264 isn't breaking on win64, it has unmarked clobbering of xmm registers also [23:21:15] <Dark_Shikari> BBB: luck? [23:21:32] <Dark_Shikari> we actually have this issue with avisynth64 [23:21:35] <Dark_Shikari> avisynth64 + x264 breaks [23:21:50] <Dark_Shikari> because avisynth64 clobbers an xmm register that contains a double [23:21:59] <Dark_Shikari> this double changes to a value that causes a runtime failure [23:22:28] <BBB> probably luck indeed then [23:38:19] <BBB> Dark_Shikari: does yasm have access to config.h defines? [23:38:25] <BBB> e.g. CONFIG_VC1_DECODER [23:38:30] <Dark_Shikari> If it doesn't, it should. [23:38:39] <Dark_Shikari> well... I guess it's a bit harder [23:38:41] <Dark_Shikari> because you can't include it [23:38:46] <BBB> I guess I meant "does it include config.h"? [23:38:48] <Dark_Shikari> just use separate files [23:39:18] <BBB> hm... [23:39:28] <BBB> how hard is that to fix? [23:39:36] <BBB> it'd be nice if it did have access to it [23:41:19] <Dark_Shikari> why do you need it? [23:43:52] <BBB> I'm wondering how hard it would be to trim the asm file if you run, say, --disable-everything --enable-decoder=h264 [23:44:07] <BBB> (i.e. then don't compile in the rv40/vc1 mc functions to decrease binary size) [23:44:11] <BBB> it's not very important [23:44:17] <BBB> but would be nice to have [23:44:34] <lu_zero> BBB: create a config.mac and include it ^^ [23:44:41] <Dark_Shikari> couldn't you use multiple asm files for that? [23:44:46] <BBB> I could [23:44:48] <Dark_Shikari> and yeah you could do that [23:45:14] <BBB> have the macro in h264_mc_template.asm and then use h264/vc1/rv40_mc.asm, include that and define the actual functions [23:45:26] <BBB> but then you have 4 instead of 1 files, it's a little messy [23:45:32] <BBB> it might be the best way, not really sure [23:45:57] <BBB> I guess I'll bug mru to see if he's ok with a config.asm [23:46:01] <BBB> I bet he'll object [23:46:07] <BBB> "x86'ism" [23:46:15] <Dark_Shikari> config.h is a Cism ;) [23:46:29] <BBB> mru: ping [23:48:30] <lu_zero> BBB: provided you can use it on gas and yasm I don't see it that x86'ism [23:51:55] <BBB> true [23:53:43] <lu_zero> still I'm wondering why this frenzy with yasm... [23:56:18] <CIA-11> ffmpeg: rbultje * r24960 /trunk/libavformat/mmsh.c: [23:56:18] <CIA-11> ffmpeg: stream_selection can be freed in the fail case, in which case it's unassigned. [23:56:18] <CIA-11> ffmpeg: Therefore, init it with NULL to prevent a crash on invalid streams. [23:56:18] <CIA-11> ffmpeg: Patch by Zhentan Feng <spyfeng gmail com>. [23:57:45] <CIA-11> ffmpeg: rbultje * r24961 /trunk/libavformat/mmsh.c: Fix two compiler arnings related to printf-format of sizeof()-statements.

1 0

IRC log for 2010-08-27
by irc＠mansr.com 28 Aug '10

28 Aug '10

[00:31:40] <jonwil> Someone has figured out the EALayer3 MPEG audio-derived codec. Is there somewhere usefull that I could put some links/docs/etc in case someone wants to support this codec in FFMPEG? [00:31:49] <jonwil> Also, the code was released under this license [00:31:51] <jonwil> http://pastebin.com/Dr5BTizw [00:31:57] <jonwil> Is that license compatible with FFMPEG license? [00:34:03] <Dark_Shikari> that's BSD, so yes [00:35:13] <Yuvi> jonwil: http://wiki.multimedia.cx/ [00:35:41] <jonwil> so if I put the relavent info on that wiki, the people who need to see it will see it? [00:36:02] <Yuvi> and a mail to ffmpeg-devel I guess [00:36:57] <jonwil> ok, thanks [00:40:29] <jonwil> on the wiki, should I list this under "audio codecs" or "game formats" (given that its used in games) [00:42:05] <Yuvi> game formats is for the plethora of old codecs only ever used for games [00:42:31] <Yuvi> so audio codecs probably [00:45:59] <Compn> jonwil : yes, the wiki is the best place, you probably will have to email mike(a)multimedia.cx to get an account [00:46:08] <jonwil> I already have an account [00:46:13] <Compn> oh ok :D [00:46:51] <jonwil> Just trying to figure out where all the info should go, given the existence of http://wiki.multimedia.cx/index.php?title=EA_Command_And_Conquer_3_Audio_Co… and its relevance to EALayer3 [00:47:05] <jonwil> I think http://wiki.multimedia.cx/index.php?title=EA_Command_And_Conquer_3_Audio_Co… should describe the "container" format [00:47:16] <jonwil> a new page titled EALayer3, the codec [00:47:24] <mru> "audio codec" doesn't sound like a container to me [00:48:02] <jonwil> well the text on that page describes the header and some bits about the ADPCM variant [00:48:24] <jonwil> I think we need 3 pages then, one for the container-ish format, one for the MP3 variant and one for the ADPCM variant [00:49:11] <jonwil> I think one called EA_SAGE_Audio_Files for the container makes sense (SAGE is the name of the game engine) [00:51:52] <jonwil> also, where can I upload some more samples of this format? [00:52:12] <jonwil> as in how do I upload to the samples archive? [01:03:31] <Compn> jonwil : ftp://upload.mplayerhq.hu/MPlayer/incoming [01:28:43] <jonwil> ok, uploading samples to the samples archive now [01:38:05] <jonwil> uploaded [01:38:20] <jonwil> does anyone have access to move the files to the right place? [01:38:43] <jonwil> the "right place" being http://samples.mplayerhq.hu/game-formats/cc3-audio/ [01:56:36] <saintdev> ...and short blocks are (mostly) working [01:56:38] <saintdev> \o/ [01:58:24] <peloverde> nice [01:58:37] <jonwil> short blocks for what? [01:58:42] <Dark_Shikari> legos [01:59:39] <saintdev> jonwil: ff-aac with lame-psymodel [01:59:53] <jonwil> ok, nice [02:00:02] <jonwil> this is an AAC encoder I take it? [02:01:08] <saintdev> the ffmpeg aac encoder [02:02:05] <jonwil> ok [02:02:36] <saintdev> although legos would be more fun :/ [02:02:43] <jonwil> :) [02:09:57] <saintdev> now to get rid of this 2 block delay on return from short [02:35:27] <peloverde> go for it [02:36:50] <saintdev> peloverde: it zeroes all thresholds for two blocks after a short sequence [02:38:05] <saintdev> i suspect it's because lame has a 1 block delay even for analysis [02:38:24] <saintdev> just didn't feel like looking into it, until I had both working :) [02:39:49] <peloverde> well I'm glad someone is working on it [03:01:07] <peloverde> Does anyone have the link to the article where the on2 ceo said that the company was unable to attract and retain talent [03:02:42] <Dark_Shikari> well that's obvious [03:02:44] <Dark_Shikari> just try using their software [03:03:19] <peloverde> well I'm arguing with people on reddit [03:03:23] <Yuvi> http://on2.com/docs/on2-google-merger-faq.pdf [03:03:35] <Yuvi> near the bottom of page 4 [03:03:50] <Yuvi> I guess there was something before that too [03:04:34] <peloverde> Also I stumbled into an article about real using vp4 [03:04:42] <peloverde> I know vp4 has kind of been a mystery [03:04:58] <astrange> i got someone on reddit trying to argue with me that you can restore overwritten files from an hd if you try really hard [03:06:01] <peloverde> On reddit I said Divx 4/5/6 was 14496-2 and got modded down [03:06:18] <astrange> er, trying to argue me by telling me that... [03:07:49] <Dark_Shikari> arguing on reddit is retarded... [03:16:29] <peloverde> I don't have an FFmpeg related project at the moment so trolling on the internet is my only refuge [03:17:15] <peloverde> http://www.reddit.com/r/technology/comments/d5o4a/mpeg_la_will_not_charge_r… [03:21:42] <Dark_Shikari> work on aac [03:22:37] <saintdev> what he said ^ [03:27:13] <peloverde> LTP, Error Resilience, and DR(adio)M aren't particularly interesting [03:28:26] <saintdev> >encoder [03:39:06] <peloverde> I could take another stab at that but my previous attempts weren't very successful and I've been interviewing with a semicondictor company that would probably want me to stop working on FFmpeg [03:39:59] <saintdev> o.O [03:43:07] <peloverde> It would at least get me out of the rust belt to California [03:43:17] <saintdev> rust belt? [03:44:03] <peloverde> Western NY, Western PA, Ohio, Indiana, Michigan [03:44:15] <Dark_Shikari> there's nobody who wants a good aac encoder? [03:45:11] <saintdev> they probably just license nero [03:45:37] <peloverde> http://en.wikipedia.org/wiki/Rust_Belt The area used to have a lot of heavy manufacturing and steal jobs and now is economically depressed [03:45:42] <peloverde> hence rusted [03:46:22] <saintdev> never heard that before [05:08:16] <kshishkov> peloverde: I heard Nero AAC encoder creator saying that iTunes AAC encoder was very good [05:08:50] <kshishkov> mostly because they hired a student of original MP3 and AAC creator to improve^W totally rewrite psychoacoustic model [05:26:49] <pJok> god morgon kshishkov [05:29:06] <thresh> moroning [05:31:20] <kshishkov> god morgon [05:36:49] <astrange> http://www.freepatentsonline.com/y2010/0070287.html [06:37:56] <Tjoppen> god morgon [06:44:50] <Tjoppen> epic drama yesterday it seems [06:57:02] <av500> yes [07:07:24] <superdump> ? [07:07:52] <superdump> Tjoppen: drama? [07:07:58] <superdump> i guess i missed it [07:08:44] <Tjoppen> mmx/pentiumpro flamewar sort of [07:11:34] <superdump> oh [07:11:38] <superdump> i see it [07:19:06] <thresh> and no flame on a64 :( [07:20:05] <kshishkov> and it takes a long time to roast elefant^Wlibavsequencer [07:24:59] <thresh> kshishkov: http://www.youtube.com/watch?v=TrXIB8qm14Q [07:26:00] <av500> ? [07:26:01] <kshishkov> thresh: Ðº ÑÐµÐŒÑ Ð±Ñ ÑÑÐŸ, [07:26:18] <kshishkov> av500: nothing to do with your name, don't worry [07:26:22] <av500> :) [07:26:33] <av500> who is the guy? [07:26:40] <thresh> the president of ukraine [07:26:43] <av500> ah [07:27:01] <thresh> says hello to both Putin and Medvedev, "Vladimir" and "Anatolyevich" [07:27:53] <thresh> kshishkov: ÐŽÐ° ÑÐ°Ðº, Ð² Ð¿ÐŸÑÑÐŽÐºÐµ ÑÑÑÐµÐœÐœÐµÐ³ÐŸ Ð¿ÐŸÑÑÐµÐ±Ð»ÐµÐœÐžÑ ÐºÐŸÑÐµ [07:27:55] <kshishkov> does that mean he revers Medvedev more? [07:28:38] <kshishkov> thresh: ÐžÐœÑÐµÑÐµÑÐœÐŸ, Ð° ÐŒÐœÐŸÐ³ÐŸ Ð»Ðž Ð»ÑÐŽÐµÐ¹ ÐœÐ°Ð·ÑÐ²Ð°ÑÑ Ð¿Ð°ÑÑ ÐÐµÐŽÐ²ÐµÐŽÐµÐ²-Ð¯ÐœÑÐºÐŸÐ²ÐžÑ "ÐÐžÐœÐœÐž-ÐÑÑ Ðž ÐÑÑÐ°ÑÐŸÐº"? [07:29:34] <thresh> is there any built-in way to benchmark ffmpeg? [07:29:47] <thresh> i need to test with various --enable-foo flags [07:29:47] <av500> with or without mmx? [07:30:02] <thresh> well, i want to enable cmov in my builds for i586 [07:30:04] <kshishkov> thresh: ffmpeg -benchmark -i infile outfile [07:30:29] <thresh> kshishkov: at first I thought this is a joke [07:30:39] <thresh> when will ffmpeg have --make-coffee? [07:30:59] <kshishkov> when you add it [07:31:08] * kshishkov has no need in coffee anyway [07:31:32] <thresh> well there is RFC2324... [07:32:55] <kshishkov> ffmpeg -i infile.mp4 -f espresso coffee://output.file [07:33:51] <kshishkov> it would be hard to convince people to add "java" flavour though [07:40:51] <Tjoppen> is there a reason why lavc refuses to resample > 2 channels, even though the input and output channel counts are the same [07:41:07] <kshishkov> yes, retarded resampler [07:41:30] <Tjoppen> indeed. I can understand it refusing to make 5.1 -> stereo for instance, but just 4.0 -> 4.0 ought to work [07:41:38] <kshishkov> somebody, including you, hasn't worked on multichnnel resampling and it's hardwired for mono/stereo only [07:42:15] <Tjoppen> I actually did dig into the resampling code quite a bit. I discovered several WTFs [07:43:13] <Tjoppen> like it introducing unacceptable delay without any way to ask how many milliseconds the filters delay the output for [07:43:37] <Tjoppen> fun experiment: resample 48 kHz to 8 kHz. receive flapping mouths [07:47:48] <pJok> *grmbl* [07:48:57] <kshishkov> Tjoppen: I heard of Zelda CD-i games [07:50:06] <Tjoppen> kshishkov: yes, such games exist. the angry video game nerd reviewed them [07:50:25] <Tjoppen> I'm not sure what they have to do with resampling though :) [07:50:52] <kshishkov> for some reason "flapping mouths", out-of-pitch and desynced sound reminded me of them [07:51:25] * kshishkov also is disappointed - why http://www.vasabryggeri.nu/ does not feature a colour umbrella on start page [07:52:12] <Tjoppen> heh [07:55:05] * kshishkov also finds another reason to visit Sundsvall - see red seal on http://sv.wikipedia.org/wiki/Fil:Trocadero_karameller.JPG [07:56:12] <av500> "only eat while its raining"? [07:56:39] <kshishkov> nope [07:58:27] <Tjoppen> we have them in the fik at school [07:58:58] <Tjoppen> hm.. "cafeteria" is a suitable translation [07:59:45] * kshishkov smiles at Swedish definition of "semester" [08:01:07] <kshishkov> it's definitely better than semester in any other country [08:02:11] <superdump> isn't it like holiday or something? [08:02:18] <kshishkov> vacation [08:02:27] <superdump> whereas in english it seems to be a period of work [08:02:31] <superdump> :) [08:02:37] <Tjoppen> germany's is like twice as long, right? [08:02:54] <kshishkov> superdump: in .ua it's period of study [08:02:55] <av500> ? [08:03:07] <av500> germany has 2 semesters/year at uni [08:03:11] <superdump> normally is in english too [08:03:13] <superdump> yeah [08:03:25] <superdump> many universities have two semesters [08:03:30] <superdump> the one i went to had trimesters [08:03:33] <superdump> 3x10 weeks [08:03:43] <kshishkov> but in .ua study at university usually has little to do with work [08:03:44] <superdump> but the swedish meaning is nicer [08:10:40] * pJok hates it when he is put to work on broken audio [08:10:53] <pJok> im a technician, not an audio guy >_< [08:11:33] * KotH hands pJok a screwdriver [08:11:39] <av500> how do you unbreak audio? [08:11:50] <av500> force people to unlisten? [08:12:13] <KotH> is that something like unseen? [08:12:19] <av500> unheard of [08:12:21] <pJok> av500, something like that... my problem is that ffmpeg trashes an audiofile completely... but that ffmpeg isn't a box standard one [08:12:40] <pJok> so i can't even file a bug report :P [08:13:15] <av500> you can try and get ridiculed :) [08:13:31] <pJok> but the problem hasn't occured before, so im kinda wondering what else i can do about this... since ffmpeg can't deliver same peak levels on output as on input :) [08:13:47] <pJok> (which is what the non-box standard ffmpeg i have does) [08:13:52] <av500> well, are the non std changes to ff audio related? [08:14:23] <pJok> no, i just had my ffmpeg patched in a very ugly way to help me out with delivering peak perfect audio [08:34:28] <lu_zero> moin [08:43:48] <spaam> god morgon [08:44:10] <kshishkov> precis [09:12:37] * av500 lols at url: http://tagesschau.vo.llnwd.net/d3/video/2010/0827/TV-20100827-0501-4001.web… [09:13:23] <spaam> Nice [09:13:28] <av500> putting .webm. in your filename makes you l33t [09:17:41] <Tjoppen> do I-frames in open GOPs count as key frames? [09:19:23] <av500> I count them as that, but I am not authorative :) [09:38:27] * KotH gives av500 some authority ;-) [09:39:02] <av500> thx [09:39:05] <spaam> nooo :O [09:40:14] <av500> KotH: I can now ban all? [09:40:17] <av500> :) [09:40:34] <KotH> all but me and the master troll :) [09:52:31] <thresh> enabling cmov with --cpu='i686' on my c2d results in 0.8% faster in average [10:00:56] <KotH> thresh: is that statistically significant? [10:01:43] <av500> what is the variation? [10:02:41] <av500> hmm: http://ondioline.org/mail/cmov-a-bad-idea-on-out-of-order-cpus [10:06:06] <thresh> KotH: i'm waiting for results from older CPUs yet [10:06:20] <thresh> and yeah, it's a good idea to try to remember probability theory once in a while [10:07:38] <KotH> thresh: that's the answer to a different question [10:07:39] <av500> if its half/half 150.8% faster and 50% slower, its still 0.8% faster on average :) [10:07:58] <thresh> nah, it's always faster [10:08:08] <KotH> thresh: if 0.2% is smaller than the stddev, then it's definitly not statistically siginificant [10:08:18] <thresh> KotH: yes, I remember that :) [10:08:28] <thresh> 0.8% you mean [10:08:40] <KotH> er.. yes 0.8% [10:20:42] <av500> mru: http://bloggingthemonkey.blogspot.com/2010/08/ffpv8-neon-720p24.html [10:20:49] <mru> av500: yes, I know [10:20:55] <av500> k [10:20:57] <mru> I've been helping him [10:21:01] <av500> :) [10:21:16] <av500> it does 720p? [10:21:19] <spaam> ffpv8? [10:21:24] <av500> yes [10:21:28] <mru> I haven't tested it [10:21:42] <av500> as soon as it hits 720p I can deploy it :) [10:21:49] <spaam> ffpv8 is that a typo or what does the p stand for? [10:22:08] <av500> p as in 720p :) [10:22:21] <spaam> ok :) [10:23:16] <kshishkov> but why it's spoiled by mentioning gst? [10:24:29] <av500> coz he is from wtfbu [10:34:58] <av500> mru: 20% faster than libvpx will not make 720p play :( [10:35:41] <mru> he's been working on an omap4 [10:36:56] <av500> yes [10:37:02] <av500> i just realized [10:37:26] <spaam> omap4 is fast? [10:37:46] <av500> yes, if you can do mt [10:37:55] <av500> dual core [10:38:03] <mru> it's fast on a single core too [10:38:35] <mru> it's 1GHz, and each cycle does more [10:38:40] <mru> and the memory is faster [10:40:15] <kshishkov> so it's better all around [10:40:27] <mru> it's omap4, it's one better [10:40:37] <av500> same for the A9 cpu [10:41:03] <mru> so two better in all [10:41:11] <cartman> omap4 boards out yet? [10:41:14] <av500> some [10:41:16] <av500> few [10:41:21] <av500> they are all with linaro [10:41:24] <cartman> neato [10:41:27] <mru> inside wtfbu they have plenty [10:41:36] <av500> and inside canonical :) [10:41:38] <cartman> WTF Business Unit or what [10:41:43] <av500> WBU [10:41:47] <av500> wireless bu [10:41:49] <av500> os TI [10:41:50] <mru> wtbu [10:41:55] <mru> wbtu [10:41:58] <mru> can't remember [10:42:02] <av500> i think they dropped the "t" [10:42:05] <mru> oh [10:42:05] <cartman> :D [10:42:22] <av500> coz terminals was to phone centric [10:43:38] <mru> and the f? [10:43:51] <av500> f? [10:44:50] <kshishkov> av500: it definitely was WTFBU and you claim it's WBU now [10:45:13] <av500> it was wtbu, wtfbu only to close "friends" [10:45:43] <kshishkov> so 'f' was for "friends-only" [10:49:16] <mru> friends-only is an accurate description of that unit [10:49:23] <mru> as in who they'll talk to [10:49:59] <av500> once you friend them, you are allowed to shout at them :) [10:56:51] <mru> that cmov rant was a bit lacking [10:56:59] <mru> there's much more to it than that [10:57:28] <mru> mispredicting a branch even 10% of the time might cause a slowdown [10:57:43] <mru> and even if it predicts correctly 100% of the time, it uses up a branch predictor slot [10:57:53] <av500> mru: thats why I added a "hmm" :) [11:02:28] <mru> and is there really only one physical set of flags? [11:02:40] <mru> I'd expect any register renaming machine to have several sets [11:10:15] <jonwil> hmmm, ffmpeg-devel mailing list is not as noisy as I thought it would be :) [11:10:29] <jonwil> Means I can stay subscribed and not worry about being overrun by messages [11:10:46] <mru> you can't have been subscribed yesterday... [11:11:18] <thresh> -benchmark sometimes give ridiculous values :/ [11:11:21] <thresh> gives [11:11:41] <mru> did you decode a ridiculous video? [11:11:56] <mru> it only prints whatever the OS told it [11:11:57] <thresh> like bench: utime=24.446s maxrss=39948kB and then bench: utime=18.541s maxrss=39956kB and then bench: utime=1.384s maxrss=39952kB for 800MB h264 -> mpeg2 using ffmpeg -benchmark -i Futurama.\[S06E01\].mp4 foo.mp4 [11:12:03] <thresh> mru: yeah I just read the code and WTFed myself [11:12:25] <thresh> s/mpeg2/mpeg4 [11:12:49] <thresh> and ffmpeg does that conversion on slow machine in like 40 minutes [11:12:59] <mru> OS? [11:13:12] <mru> roughly how long does it actually take on this machine? [11:13:15] <thresh> 32bit Linux [11:14:03] <thresh> mru: reporter says 'tens of minutes' [11:14:14] <mru> oh, it's a luser report? [11:14:17] <mru> ignore it then [11:14:49] <thresh> he's a develolper more.. [11:15:10] <thresh> and is not cluless.. never can be sure though [11:17:12] <janneg> I've seen strange results with time ffmpeg -benchmark too [11:24:46] <Tjoppen> setting AVInputFormat::codec_tag looks like a good idea [11:25:13] <Tjoppen> also simplified my codec_id lookup code thanks to ff_codec_get_id() :) [11:25:40] <mru> setting codec_tag is pointless [11:25:45] <mru> the field has no defined meaning [11:26:08] <twice11> great field for job security, then ;) [11:29:22] <Tjoppen> maybe if previously unknown tags pop up. before being commited to svn, the user can hackishly detect them and set codec_id manually [11:30:03] <Tjoppen> also, for remuxing data belonging to unknown codecs to/from the same container. but yeah.. [11:31:03] <mru> codec_tag might make sense in AVStream [11:31:08] <mru> not in AVCodec [11:31:11] <mru> context [11:31:58] <Tjoppen> indeed. well, at sort of makes sense for choosing IDCT [11:32:06] <mru> no [11:32:36] <mru> you have no fucking clue what idct the encoder used [11:33:12] <mru> if the encoder put an identifying comment in the bitstream itself, you might be able to guess [11:33:19] <kshishkov> yes, it was fun with Xvid [11:33:48] <Tjoppen> yes, that's the case I'm thinking of. for xvid it appearently had a point [11:33:49] <mru> if everybody used a spec-compliant idct it wouldn't be so much of a problem [11:34:05] <mru> Tjoppen: yes, but the codec_tag doesn't identify the xvid version accurately enough [11:34:17] <mru> and even the same version might use different idcts [11:34:24] <mru> depending on mmx available etc [11:34:26] <Tjoppen> ah, true. should probably use its own field any way, if detectable at all [11:35:02] <Tjoppen> I think we elaborated on this earlier. I was wtf:ing about codec_tag being used to signal which pixel format is used for rawvideo [11:37:08] <mru> yes, that's one of the dirtier parts of ffmpeg [11:54:44] <Tjoppen> there. now my LXF demuxer works fairly well with all the samples that I've got. any suggestions before I post it on the ML? apart from uploading samples of course [11:54:56] <mru> lxf? [11:55:07] <Tjoppen> Leitch VR native stream format [11:55:07] <mru> how mane ?xf formats are there? [11:55:08] <janneg> patcheck [11:55:18] <janneg> 26? [11:55:39] <Tjoppen> lxf is nothing like gxf or mxf. it's basically a binary dump of their LLM hardware memory [11:55:58] <Tjoppen> at least I think so. the "specs" are fairly vague [11:58:36] <Tjoppen> for instance, it doesn't even hint at how to handle B-frames, and I don't have any samples to look at [11:58:50] <Tjoppen> samples with B-frames that is [12:03:08] <merbzt> Tjoppen: splendid :) [12:03:34] <merbzt> is it a HD camera or something ? [12:05:05] <Tjoppen> 19" rack equipment of some kind [12:06:43] <mru> now you can get that HD footage of fans you've always wanted [12:07:48] <KotH> Tjoppen: "nice rack" gets a whole new meaning ;-) [12:08:16] <Tjoppen> :) [12:16:21] <Tjoppen> forgot to bump minor version. good catch by the FAQ :) [12:16:55] <Tjoppen> ah, and documentation. of course [12:18:48] <merbzt> patch for old unused code ! \o/ [12:19:34] <kshishkov> merbzt: you forgot to add that YUVJ420 is deprecated too [12:19:59] <kshishkov> since such colourspace details should not belong to pixfmt [12:20:16] <merbzt> didn't know that [12:20:26] <merbzt> I just made it work for me :) [12:21:45] * kshishkov goes offline for the rest of the day [12:21:57] <av500> you get a ram upgrade? [12:26:18] <pJok> digital delivery for broadcasters will probably kill me... [12:26:35] <pJok> since they all want something different... with a digibeta tape it was much easier [12:47:16] <jonwil> hmmm, damn, FFMPEG doesn't have a MP3 encoder, it just uses LAME. Thats going to make producing an EALayer3 encoder harder :( [12:47:34] <mru> you could write an mp3 encoder first [12:47:44] <mru> that would be most welcome [12:47:54] <jonwil> I know zilch about MP3 audio [12:48:04] <jonwil> and how the actual compression part works [12:48:24] <mru> qmf+mdct [12:48:31] <mru> +quant+huff [12:48:35] <av500> jonwil: hos does EALayer3 differ from mp3? [12:48:42] <av500> how [12:48:51] <jonwil> The compression is the same, the difference is in the granule header [12:48:59] <av500> so, just bitstream changes [12:49:03] <jonwil> yes [12:49:15] <av500> so, use lame and postprocess [12:49:20] <Tjoppen> just have the encoder look for a suitable mp3 encoder then [12:49:23] <av500> bitstream filter [12:50:37] <jonwil> The other difference is that EALayer3 supports more than 2 channels [12:52:31] <jonwil> And there are a couple of WTFs in the format too (like the fact that some granules can include extra uncompressed samples after the compressed MPEG data) [12:53:10] <av500> you dont have to implement that on encoder side, no? [12:53:21] <jonwil> well it exists for a reason I would guess [12:53:42] <av500> until u know that reason, you cannot implement it anyway [12:53:49] <jonwil> true [12:53:53] <av500> how would you decide what not to compress? [12:54:09] <jonwil> Its a pity we dont have an official encoder for this format :( [12:54:25] <av500> send a pcm sample for ea :) [12:54:26] <jonwil> But EA said "We cant release an encoder due to patents" or some crap :P [12:54:28] <av500> to ea [12:54:50] <av500> jonwil: they might be afraid of mp3 patents [12:55:00] <av500> but they could release the diff on top of mp3 [12:56:44] <jonwil> hmmm, I should look around some of the Sims communities, aparently one of the Sims games uses EALayer3 in some form, people there might have info or connections to EA... [13:42:50] <thresh> kshishkov: still here? [13:43:18] <thresh> kshishkov: http://www.darip.ru/files/file/pochtofon 45 billion roubles for a MFD! [14:01:54] <BBB> does anyone mind if I commit my yasmification of inline asm? I'm not getting any review [14:02:12] <BBB> make fate-vp3 passes with sse2 disabled and enabled on x86-64 and x86-32 [14:03:04] <mru> did you send a patch? [14:03:05] <av500> thresh: postofon, wtf? [14:03:39] <mru> ah yes, you did [14:04:21] <BBB> I did, and fixed it [14:04:24] <BBB> can send a new one [14:04:29] <mru> no, I see it [14:04:35] <BBB> I made some changes [14:05:01] <mru> since the second patch? [14:06:05] <BBB> yes [14:06:14] <mru> then send it [14:06:17] <BBB> just did [14:06:54] <BBB> I'm working on slowly moving h264_chroma_mc code to yasm also, but that takes a little longer... [14:07:08] <BBB> because it's such an entangled mess with rv40 && vc1 [14:07:23] <av500> ignore fringe formats :) [14:07:23] <mru> yes, it is [14:07:57] <jonwil> VC1 isnt a fringe format :P [14:08:06] <mru> oh yes it is [14:08:26] <mru> I bet rv40 is more widely used even [14:08:30] <av500> yes [14:08:33] <mru> china is big.. [14:08:37] <av500> in that tiny .cn [14:08:52] <jonwil> Isn't VC1 an official format for Blu-Ray disks? [14:08:59] <av500> yes [14:09:28] <BBB> jonwil: you need encoders for people to create disks carrying vc1 content [14:09:33] <mru> but few discs use it [14:09:37] <av500> but only used for tv stuff [14:09:44] <av500> bbc docus [14:09:51] <av500> not for movies [14:09:52] <mru> I have a regular film in vc1 [14:09:54] <jonwil> Most people I guess would use MPEG4 for blu-ray [14:09:56] <mru> don't remember which one [14:10:12] <jonwil> because its more widely supported with good encoders [14:10:15] <mru> on bluray, that is [14:10:17] <BBB> that sounds like "I have one of those antique fringe barbie games that you won't find anywhere else" [14:10:32] <BBB> "it uses this awesome tucomposer mod file format that you won't find anywhere else" [14:10:41] <BBB> "IT IS USED!!!!11223" [14:11:17] <BBB> I wonder why I agreed to have him implement tcm for gsoc, rather than regular mod formats such as x3m or so [14:12:31] <jonwil> if I was still a student, I would go for GSOC, so many formats it would be usefull to me to have an en/decoder for... :P [14:13:18] <av500> BBB: tcm is for barbie games? [14:13:23] <mru> BBB: I wonder why he was accepted at all [14:13:37] <jonwil> Although someone already did a Bink encoder [14:13:53] <jonwil> I mean decoder [14:14:32] <elenril> hey, bink is useful =p [14:14:39] * elenril has more bink videos than vc1 [14:14:39] <jonwil> yes its usefull [14:14:49] <jonwil> but someone already did it [14:17:31] <mru> BBB: flim? [14:21:11] <thresh> av500: another 'innovative device' [14:25:48] <twice11> I think they started with tucomposer, because that format has such an overdesigned overcomplication that *all* other module formats can be converted into it. [14:26:02] <twice11> So if you can play tcm, you can play everything. [14:26:10] <twice11> maybe except s3m with FM-synth voices. [14:29:19] <jonwil> The way FFMPEG is going, I wouldn't be surprised to see MIDI support in there at some point :P [14:29:33] <av500> that way is going slow [14:30:05] <jonwil> I guess like anything the answer is "if you want it, write some code or stop complaining" :P [14:31:20] <twice11> Can we have a DirectMusic based mixer? (/me hides away) [14:32:05] <twice11> Yeah, and EAX, OpenAL and Emu8K/Emu10K linux drivers, too!!! [14:32:24] <jonwil> The hard part with MIDI is finding a free-as-in-free set of music instrument samples to use in your synth. [14:32:35] * KotH wouldnt mind some working sound drivers for linux [14:32:55] <av500> and dont forget, we need sub ms latency [14:32:56] * twice11 knows about the problem with free patch sets. [14:33:35] <twice11> Yes, wee need sub-ms synth latency and have to kope with systems that have 50ms scheduling latency at the same time! [14:33:58] <mru> eawpatches used to be good... [14:34:36] <BBB> mru: flim is a term that happens all over the place in vp8, I don't know what it is [14:34:42] <BBB> mru: vp8 has a "flim" also [14:34:57] <mru> so it's cargo cult? [14:35:11] * av500 knows flim flam [14:35:40] <BBB> yeah [14:36:05] <restrex> how can I disable swscale on ffmpeg? [14:36:22] <av500> --disable-swscale? [14:36:26] <restrex> on the configure I put --disable-swscale, but it return: Unknown option "--disable-swscale". [14:36:43] <mru> lib [14:37:00] <av500> --disable-libswscale? [14:37:08] <BBB> yeah [14:37:11] <av500> a/?/!/ [14:37:13] <av500> s [14:37:18] * mru invokes koen rule #3 [14:37:56] * av500 reminds mru of ?id=19 [14:38:30] <mru> thanks [14:41:22] <restrex> Unknown option "--disable-libswscale". av500 [14:42:04] <mru> --disable-swscale it is [14:42:05] <av500> --disable-swscale disable libswscale build [14:42:16] <av500> straight from grepping configure.... [14:42:44] <av500> mru: btw, got 96db of rain atm.... [14:43:07] <mru> what's the baseline? [14:43:29] <av500> havent seen baseline that for weeks.... [14:43:35] <av500> -that [14:43:56] <twice11> restrex: --disable-swscale works (for recent ffmpeg versions). [14:44:01] <twice11> Tested right now. [14:44:01] <mru> I mean what's 0dB [14:44:07] <av500> mru: I know [14:44:49] <av500> Taklamkan Desert [14:45:42] <av500> +a [14:45:54] <restrex> twice11, I'm compiling the rev. 20231 [14:46:07] <av500> ancient [14:46:11] <restrex> --disable-swscale seems not to work there [14:46:30] <restrex> av500, I need it to use this patch http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-October/077506.html [14:46:52] <restrex> it makes CBR MPEG-2 Transport Streams [14:46:57] <av500> restrex: u cant disable it in this version [14:47:18] <av500> at least configure gives no option [14:47:27] <av500> but that you have seen yourself, havent you [14:47:34] <restrex> then I wonder what's the problem with it... It gets stuck when compiling swscale [14:47:48] <av500> libswstuck then [14:47:53] <J_Darnley> Did you get a matching version of libswscale? [14:48:18] <twice11> How do you find out which version matches? [14:48:25] <J_Darnley> Get one from the same date [14:48:46] <J_Darnley> IIRC: -r '{DATE}' [14:49:06] <twice11> Ah, nice to have date support. [14:49:26] <restrex> J_Darnley, twice11, I think the libswscale is already included in the source code... so I didn't have to find any matching version for it. One of the 20+ errors is: "error: PIX_FMT_PAL undeclared (first use in this function)" [14:50:10] <J_Darnley> If you get an old ffmpeg, you need to get an old libswsacle [14:50:37] <J_Darnley> If you got it vis svn anyway [14:50:41] <J_Darnley> *via [14:50:49] <restrex> yes, via svn [14:51:27] <twice11> I'm afraid you end up with ancient ffmpeg + up-to-date swscale if you are not very careful. [14:52:05] <BBB> hi J_Darnley, will your team go to ovc, as we discussed earlier? [14:52:14] <restrex> ok, I'm going to get versions of ffmpeg and libswscale from the same date of the ffmpeg rev. 20231 [14:52:22] <J_Darnley> My team? [14:52:33] <J_Darnley> I think you mean someone else [14:52:40] <BBB> uhm... [14:52:44] <restrex> thanks guys. [14:53:14] <BBB> let me find the right one, maybe I'm confused [14:55:29] <superdump> merbzt: ping? [14:56:35] <BBB> superdump: nice work on amrwb btw [14:56:46] <superdump> wasn't me [14:56:50] <BBB> you mentored? [14:56:52] <cartman> shaggy [14:56:56] <superdump> i merely guided marcelo through it when he got stuck [14:57:03] <superdump> he did all the work [14:57:09] <BBB> is marcelo on irc? [14:57:31] <superdump> nope [14:57:32] <restrex> twice11, libswscale is in the ffmpeg code... ls -la | grep libswscale > drwxr-xr-x 8 user user 4096 2010-08-27 10:30 libswscale [14:57:43] <superdump> merbzt: never mind :)) [14:58:58] <twice11> libswscale is an external reference pulled in by svn. [14:59:28] <restrex> so... what version would you suggest to get? [15:00:12] <twice11> Go into the libswscale directory and run svn log | less [15:00:27] <twice11> Or even better, use the data syntax suggested in this channel. [15:01:37] <twice11> so that's "cd libswscale; svn update -r '{2009-10-14}' [15:03:33] <restrex> thanks twice11! [15:04:50] <restrex> it worked now :) [15:05:20] <Tjoppen> </work> [15:05:26] <Tjoppen> <beer> [15:05:47] <restrex> haha [15:19:07] <restrex> the patch that makes the output cbr seems not to work... [15:19:19] <restrex> how should I stuff null packets on a TS to make it CBR? [15:20:07] <restrex> it's really VBR and it causes my receiver to put freezing frames and some other quirks... but when I look at it with VLC it seems to work awesomely... [15:25:59] * restrex is frustrated [15:37:01] <restrex> guys... any ideas to make a true cbr mpeg-2 video? [15:38:46] * KotH wonders whether perl6 will become the new hurd [15:39:17] <av500> restrex: add padding? [16:01:09] <restrex> av500, thanks, I will try that [16:01:11] <restrex> :) [16:01:45] <av500> [17:19:07] <restrex> the patch that makes the output cbr seems not to work... [16:01:53] <av500> what does not work? [16:02:12] <restrex> the output video is still not even near to CBR [16:02:31] <restrex> it fluctuates between 2.47 to 2.66 MB/s [16:02:54] <restrex> which makes my MPEG-2 receiver to freeze frames [16:04:04] <restrex> the parameters I'm using to make it CBR are: -vcodec mpeg2video -b 2600k -maxrate 2600k -minrate 2600k -bf 2 -bufsize 1800000 [16:04:04] <av500> then i guess you need to improve the patch [16:05:49] <restrex> av500, oh you're from Germany. I was there a month a ago... i really loved it! I loved curry wursts, hehe. [16:09:46] <av500> mahlzeit [16:49:08] <av500> http://arstechnica.com/media/news/2010/08/mpeg-la-counters-google-webm-with… [16:51:38] <Tjoppen> if only the us would drop software patents. and germany [16:51:48] <peloverde> These idiots on the web don't realize that if you are using H.264 you are supposed sign an agreement with MPEG-LA even if you don't owe them any royalties [16:52:41] <peloverde> I;m sick of these people who think they are qualified to comment on this just because they use a web browser [16:52:53] <ohsix> they're realizing a lot less than that :P [16:53:58] <jonwil> Software patents are evil and should never have been allowed [16:54:23] <av500> its not a sw patent [16:55:02] <ohsix> that sir is irony [16:58:42] <Dark_Shikari> it's a "patent" [16:58:45] <Dark_Shikari> it may apply to software [16:58:49] <Dark_Shikari> (it may also apply to other things) [17:01:08] <iive> it's not only sw patents, patents as institution should be abolished. At least in their current form and implementation. [17:01:55] <av500> patents should be required to "disclose" something [17:02:08] <av500> if i can figure out how it works without reading the patent, it should be void [17:03:14] <mru> it discloses that I filed for it [17:03:28] <mru> and that I'm a prick [17:03:52] <Tjoppen> I think we'd get a long way with just some reform [17:03:59] <av500> shoot [17:04:01] <av500> all [17:04:02] <av500> patent [17:04:04] <av500> lawyers [17:04:07] <Tjoppen> *trolls [17:06:39] <KotH> av500: well.. you can figure out everything w/o reading a patent.. given enough time and money [17:06:59] <av500> KotH: yes, it cost you time and money [17:07:13] <KotH> or brain [17:07:16] <av500> so disclosing helps the common good [17:07:28] <av500> if there is nothing to disclose e.g. one-click-buy [17:07:32] <av500> it serves no common good [17:07:42] <av500> or pinch zoom [17:07:55] <iive> well, if it costs you less time than patent duration, then maybe it is too obvious. [17:08:12] <ohsix> if you have multiple inputs its an obvious gesture, thats a decent example [17:08:48] <av500> patent system was disclosure to further common good in return for royalties [17:08:54] <ohsix> theres just too much stuff thats obvious as stuff changes [17:08:56] <av500> these days, it is not any more [17:09:14] <av500> today it is disclose obvious stuff [17:09:22] <av500> and troll others [17:10:00] <ohsix> and keep some district courts in texas busy [17:10:06] <av500> yes [17:10:07] * KotH discloses how to troll people [17:10:10] <av500> been there, done that [17:10:16] <av500> not fun [17:10:27] <mru> KotH: that's obvious to anyone skilled in the art [17:11:16] <KotH> mru: i'll forumlate it in a way that even people skilled in the art will not be able to tell what i'm discolsing [17:11:39] <mru> now _that_ is an art [17:12:26] <KotH> practiced by many patent lawyers [17:12:58] <av500> KotH: its a tricky thing [17:13:11] <av500> you want a court in the end to be able to tell what you are disclosing [17:14:14] <mru> no, you want to tell the court what you are disclosing [17:14:23] <mru> i.e. whatever that other guys is selling [17:14:33] <KotH> exactl [17:14:56] <KotH> the last company i worked for had a patent dispute with a company in australia over one part of the algo they were using [17:15:36] <av500> lol: "âThe MPEG-LA announcement doesnât change anything for the next four years, since this promise was already made through 2014,â he says in the statement shared with the The Reg. âGiven that IEC [International Electrotechnical Commission] has already started accepting submissions for patents in the replacement H.265 standard, and the rise of unencumbered formats like WebM, it is not clear if H.264 will still be relevant in 2014. [17:15:36] <KotH> and that part was structure, that had some stricing resamblance to a wavelet filter.... [17:15:55] <av500> mpeg2 is how old and relevant today.... [17:16:35] <janneg> over tweny years? [17:16:46] <ohsix> mpeg2 has hardware investmentstuff [17:16:53] <av500> so will h264 have [17:16:58] <av500> in 2014 [17:17:10] <av500> it will not evaporate into h265 over night [17:17:30] <jonwil> I hope WebM takes over as the dominant format for web video (which is what Google wants) [17:17:32] <ohsix> not to the same degree, you can do tons in software [17:17:45] <janneg> I would say even mpeg2 will have some relevance in 2014 [17:17:56] <peloverde> H.264, MPEG-2 and MPEG-1 audio are here forever [17:18:10] <ohsix> all the STB's i've got aren't going to be replaced before 2014 :D [17:18:24] * KotH thinks that by 2014 we will care more about how to convert that parking lot across the street into a field than what video format is still relevant and why [17:18:56] <jonwil> Given the number of DVDs I have of films that are never likely to be released on blu-ray, MPEG2 ain't going anywhere for me anytime soon :P [17:19:06] <av500> jonwil: we say "hope dies last" :) [17:19:38] * KotH kills av500 [17:19:47] <av500> i had no hope anyway [17:19:51] <KotH> now we can kill this hope guy [17:20:00] <av500> gogogo [17:20:14] <twice11> And then no one dies anymore? [17:20:29] <KotH> no, everyone else is already dead [22:09:04] <astrange> http://arstechnica.com/software/reviews/2010/08/rockplayer-brings-ffmpeg-vi… so ars just posts obviously pirated video screencaps now? [22:38:15] <_av500_> yeah [22:52:02] <BBB> Dark_Shikari: in yasm, if I want to do an if/else statement (regular asm, not simd pcmp*), if I do a jmp (e.g. jne) to something after (instead of before, as in a loop) the statement, does that still work? [22:52:09] <BBB> I get errors when the label is after a RET [22:53:22] <Dark_Shikari> you have to do functionname.label [22:54:12] <BBB> in the jne? [22:54:22] <BBB> ok [23:06:02] <pengvado> any instance of ".label" is implicitly converted to "currentfunctionname.label", so if it's in a different function you need to explicitly specify that functionname. [23:06:36] <pengvado> before/after doesn't matter [23:06:39] <pengvado> RET doesn't matter [23:34:59] <mru> multiple entry points? [23:35:00] <mru> fun [23:37:17] <BBB> x86 is so much fun [23:37:38] <roxfan> no shit

1 0

IRC log for 2010-08-26
by irc＠mansr.com 27 Aug '10

27 Aug '10

[18:09:28] * Terminating due to: TERM [18:09:40] * /join #ffmpeg-devel ... [18:09:42] *** TOPIC: Welcome to the FFmpeg development channel. | Discussions about the development of FFmpeg itself are ontopic here. | Questions about using FFmpeg or developing with the libav* libraries should be asked in #ffmpeg. | FFmpeg 0.6 has been released! | This channel is now publicly logged. [18:09:42] *** TOPICINFO: peloverde!~alex(a)cpe-173-88-148-20.neo.res.rr.com, 1276886342 [18:09:42] <mru> and you promised not to commit war [18:09:47] <Dark_Shikari> I'm not commit warring [18:09:51] <mru> and you were about to [18:09:55] <Dark_Shikari> I'm reverting something that you committed to something I maintain (x86) [18:10:01] <Dark_Shikari> which is something you don't maintain [18:10:02] <Dark_Shikari> you maintain ARM [18:10:04] <mru> since when do you maintain anything? [18:10:11] <Dark_Shikari> since Michael said so? [18:10:16] <Dark_Shikari> Michael said I'm an x86 co-maintainer [18:10:18] <mru> when did he say that? [18:10:18] <Dark_Shikari> repeatedly [18:10:27] <mru> show me [18:10:27] <Dark_Shikari> every bloody time there's an x86 patch [18:10:38] <mru> show me [18:10:41] <Dark_Shikari> Me and Loren, that is [18:10:48] <janneg> mru: he did [18:10:52] <mru> so bloody show me [18:10:58] <mru> or I'll have to ban you all [18:11:02] <Dark_Shikari> .... [18:11:06] <Dark_Shikari> so I'm the one "warring" [18:11:06] <peloverde> Look we all are behaving like children Dark_Shikari: You shouldn't have tried to revert the commit, mru: You shouldn't have block his access, and I should have tried to fix this rather than just pissing and moaning about it [18:11:10] <Dark_Shikari> but you're threatening to ban everyone? [18:11:30] <mru> peloverde: I blocked his access because he threatened to start a commit war [18:11:31] <Vitor1001> Just wondering, any reason not to simply drop "--cpu=i686"? [18:11:48] <Dark_Shikari> Because it works as a generic "give me cmov" option. [18:11:52] <Dark_Shikari> People use it for that. [18:11:58] <Dark_Shikari> It's also a pretty standard identifier across linux distros. [18:12:01] <mru> I don't fucking care [18:12:03] <Vitor1001> If you want CMOV and no MMX, you have a pentiumpro then you should use --cpu=pentiumpro [18:12:03] <Dark_Shikari> Even if you don't like it, people use it. [18:12:15] <Dark_Shikari> mru: then don't remove my fucking commit access [18:12:26] <Dark_Shikari> If you don't care, stop acting like you do. [18:12:26] <peloverde> Vitor1001: The problem with that is it drops runtime detection for MMX [18:12:29] <mru> Dark_Shikari: then don't commit stuff you're not supposed to [18:12:33] <Vitor1001> We can just fail and suggest either "--cpu=pentiumpro2orlater" or --cpu=486 [18:12:34] <Dark_Shikari> I'm supposed to commit things to code I maintain. [18:12:42] <Dark_Shikari> Vitor1001: read what mru said again [18:12:47] <Dark_Shikari> he wants --cpu=pentium3 to remove sse2 [18:12:52] <Dark_Shikari> he wants --cpu=pentium4 to remove ssse3 [18:12:57] <Dark_Shikari> this applies _generally_ [18:13:25] <Vitor1001> bbl [18:14:24] <Dark_Shikari> mru: stop it. [18:14:24] <Dark_Shikari> now [18:14:27] <Dark_Shikari> give me back my svn access [18:14:38] <mru> what will you do? [18:14:46] <Dark_Shikari> I will commit that patch. [18:14:52] <mru> which patch? [18:15:06] <Dark_Shikari> r24946, reversed. [18:15:12] <Dark_Shikari> I will not revert emms. [18:15:33] <Dark_Shikari> reasoning: there are three possible solutions to this problem [18:15:41] <Dark_Shikari> 1) Revert everything, give up. (not going to do this yet) [18:15:49] <Dark_Shikari> 2) Your solution (too many problems, many people disagree) [18:15:56] <Dark_Shikari> 3) some other solution which doesn't involve reverting emms [18:16:08] <Dark_Shikari> we're holding out in the hope that someone can come up with a good solution for 3) so we don't have to do 1). [18:16:17] <Dark_Shikari> however, neither 1) nor 3) involves r24946. [18:16:21] <Dark_Shikari> therefore, r24946 should be reverted. [18:16:28] <peloverde> which one is r24946? [18:16:37] <Dark_Shikari> the one that makes --cpu=i686 disable mmx. [18:16:46] <peloverde> until this is fixed r24946 should stand [18:16:51] <Dark_Shikari> I don't even 100% disagree with that patch [18:16:57] <Dark_Shikari> but rather, it doesn't inform users at all of the consequences [18:17:00] <Dark_Shikari> because we _changed_ behavior [18:17:15] <Dark_Shikari> so I think it's better to have that "bug" than to have that patch [18:17:20] <Dark_Shikari> that patch will break about 98% of distro builds [18:17:29] <Dark_Shikari> and the ffmpeg win32 builds too [18:17:40] <BBB> DS is right, silently disabling mmx is BAD BAD BAD [18:17:46] <BBB> we assume distro people know what they're doing [18:17:49] <BBB> yet we know they don't [18:17:51] <BBB> it's BAD [18:17:58] <Dark_Shikari> it's really just a matter of hassle, I do not want to deal with users who have broken builds because of this [18:18:01] <Dark_Shikari> I have no time [18:18:02] <BBB> silently disabling mmx is the worst thing in the world [18:18:10] <Dark_Shikari> what BBB said [18:18:18] <peloverde> BBB: having a build with --cpu=i686 SIGILL on i686 is BAD BAD BAD [18:18:23] <Dark_Shikari> peloverde: no, actually it isn't [18:18:27] <Dark_Shikari> It's not nearly as bad as silently disabling mmx [18:18:38] <peloverde> I think it's far worse [18:18:39] <Dark_Shikari> because the latter affects 99.9% of users [18:18:42] <Dark_Shikari> the former affects 0.1% [18:18:53] <Dark_Shikari> x264 SIGILLs (well, it errors out) on i686. [18:18:57] <Dark_Shikari> It has done so for the past 2 YEARS [18:19:00] <Dark_Shikari> only two people have complained [18:19:01] <Dark_Shikari> in that entire time [18:19:06] <peloverde> If users want i686+mmx they can bump to pentium2 [18:19:15] <Dark_Shikari> peloverde: but mru is arguing that pentium2 should disable sse. [18:19:26] <peloverde> Dark_Shikari: I'm talking about for the time being [18:19:34] <BBB> peloverde: well, so fail the build then [18:19:34] <Dark_Shikari> peloverde: that's simply not reasonable [18:19:38] <peloverde> until we fix this emms issue [18:19:41] <BBB> don't cripple the build either way [18:19:44] <Dark_Shikari> if you're going to do that, you have to magically tell every single person in the world [18:19:44] <BBB> fail it [18:19:47] <Dark_Shikari> to use pentium2 instead [18:19:53] <peloverde> fail to build with i686 but not disable-mmx is ok by me [18:19:58] <BBB> let the user explicitely state --disable-mmx or --enable-mmx or change --cpu [18:20:01] <Dark_Shikari> here is my advice [18:20:04] <BBB> so we know what he wants [18:20:07] <Dark_Shikari> it should be IMPOSSIBLE TO BUILD FFMPEG WITHOUT MMX [18:20:09] <Dark_Shikari> without using --disable-mmx [18:20:12] <Dark_Shikari> end of story. [18:20:13] <BBB> agreed [18:20:19] <BBB> I said that in a post also [18:20:25] <Dark_Shikari> That is why we need to revert that patch [18:20:26] <peloverde> mumble mumble mumble yasm [18:20:31] <Dark_Shikari> peloverde: unrelated [18:20:31] <BBB> peloverde: working on it [18:20:35] <BBB> peloverde: help me converting asm please [18:20:39] <peloverde> very related [18:20:41] <BBB> it's a pain and a lot of junkwork [18:20:51] <peloverde> BBB: not converting things to yasm [18:20:56] <peloverde> my yasm patch from this morning [18:21:13] <BBB> oh that [18:21:15] <BBB> please apply [18:21:18] <mru> no [18:21:22] <BBB> I think mru already had such a patch earlier [18:21:26] <BBB> I Don't know why it changed [18:21:32] <mru> dying if yasm is absent and mmx disabled is wrong [18:21:40] <BBB> that's true [18:21:46] <Dark_Shikari> mru: thank you. [18:21:52] <peloverde> I'm updating it now [18:21:53] <CIA-11> ffmpeg: mru * r24949 /trunk/configure: [18:21:53] <CIA-11> ffmpeg: Revert "Disable MMX for i686 and pentiumpro" [18:21:53] <CIA-11> ffmpeg: To avoid being burned at the stake by an angry mob, I am forced to [18:21:53] <CIA-11> ffmpeg: revert this commit. [18:21:55] <BBB> excellent [18:22:45] <BBB> thanks for the email also, I'm sure we can solve this quickly in a angry-mob-style way :-p [18:23:57] <peloverde> why doesn't disable-asm imply disable-mmx and disable-yasm? [18:24:41] <mru> yasm is just a tool [18:24:50] <mru> do you want --disable-asm to delete it? [18:25:20] <brad0> it'll find yasm but just not use it if disable-asm, right? [18:25:21] <mru> it won't be used with --disable-asm [18:25:26] <peloverde> no I'm trying to come up with a sane check [18:25:27] <mru> brad0: yes [18:25:36] <mru> sane check for what? [18:25:41] <brad0> that makes sense to me IMO. [18:25:47] <peloverde> if ! disabled yasm && ! disabled mmx; then ... triggers true if --disable-asm [18:26:21] <Dark_Shikari> mru: I'm writing up a summary of a few options for you [18:26:22] <Dark_Shikari> this shoudl help [18:26:35] <mru> http://pastebin.ca/1926107 [18:26:58] <brad0> peloverde: what triggers true? [18:27:07] <Dark_Shikari> mru: hah, nice [18:27:42] <peloverde> mru: that still errors with configure --disable-asm [18:28:35] <mru> add that to the list too then [18:28:44] <peloverde> I'll do that [18:29:07] <brad0> argh! stupid pastebin.ca. [18:29:20] <mru> they're all stupid [18:29:28] <Dark_Shikari> mru: check my list [18:29:47] <brad0> mru: even more so when their network is busted. [18:29:54] <mru> works for me [18:30:27] <CIA-11> ffmpeg: alexc * r24950 /trunk/configure: x86: Require yasm OR --disable-asm OR --disable-mmx OR --disable-yasm to build. [18:30:37] <Dark_Shikari> Looks good peloverde [18:30:42] <Dark_Shikari> mru: which of my 4 solutions do you prefer? [18:30:49] <mru> just got the mail [18:31:09] <mru> peloverde: mike's ppc box doesn't seem to have yasm [18:31:11] <Dark_Shikari> ok [18:31:16] <Dark_Shikari> mru: hah! [18:31:19] <Dark_Shikari> wait. ppc? [18:31:22] <Dark_Shikari> we don't use yasm for ppc. [18:31:31] <mru> err osx [18:31:33] <Dark_Shikari> lol [18:31:43] <mru> look what you've done to me [18:31:46] <mru> I can't think anymore [18:31:48] <peloverde> wtf it's inside an "elif enabled x86; then" [18:32:01] <peloverde> oh intel/osx? [18:32:06] <Dark_Shikari> yeah, it's intel [18:32:09] <Dark_Shikari> he just didn't install it [18:32:14] <mru> I know [18:32:14] <Dark_Shikari> btw, we should have some tests without yasm as well [18:32:16] <Dark_Shikari> just in case [18:32:32] <BBB> mru just added no-sse tests no? [18:32:40] <mru> yes [18:32:50] <BBB> should be easy to add 1-2 more [18:32:56] <Dark_Shikari> oh yeah, and mru, both 2) and 3) let us add inline MMX asm. [18:32:57] <mru> there are plenty of machines running only the C code [18:33:08] <Dark_Shikari> which is an extra benefit. [18:33:18] <Dark_Shikari> mru: I meant if non-yasm was broken, but yasm worked [18:34:26] <BBB> oh my... [18:34:35] <BBB> this vp3 code is a little annoying to translate [18:34:54] <Dark_Shikari> "inline asm" "annoying" [18:34:55] <BBB> "movdqa address, xmm7" /* xmm7 = address */ \ [18:34:55] <Dark_Shikari> well what a surprise [18:35:03] <BBB> it goes on like that for 20 lines in a row [18:35:11] <BBB> I'm trying to keep all comments identical [18:35:30] <Dark_Shikari> why? if they're shit, improve them [18:35:32] <mru> imo feel free to drop idiot comments [18:35:37] <Dark_Shikari> or remove [18:35:39] <Dark_Shikari> what mru said [18:35:48] <Dark_Shikari> "x += 1; //add one to x" [18:36:23] <j-b> Dark_Shikari: what --cpu= flag do you recommend to compile FFmpeg for x86/Win32 platform? [18:36:26] <mru> x++; // like x += 1 // add one [18:36:33] <Dark_Shikari> j-b: I use i686 personally [18:36:39] <mru> j-b: depends on the cpu of course [18:36:41] <Dark_Shikari> since anything above that is useless and possibly dangerous [18:36:48] <Dark_Shikari> *cough* autovectorization [18:36:51] <j-b> Dark_Shikari: I do too. But I might be wrong. [18:36:55] <peloverde> j-b: pentium2 is probably good for generic [18:36:59] <mru> Dark_Shikari: autovec is disabled [18:37:07] <Dark_Shikari> mru: we turned that off for x86? [18:37:11] <j-b> mru: this is for the main VLC win32 build. So, normal people on this stupid OS. [18:37:14] <mru> we turned it off for gcc [18:37:17] <Dark_Shikari> ah k [18:37:24] <mru> it broke everywhere [18:37:24] <j-b> peloverde: ok. some --march too? [18:37:26] <peloverde> What is the minimum win32 version you require? [18:37:33] <j-b> peloverde: Win2k [18:37:41] <j-b> peloverde: and XP for next major [18:37:51] <j-b> peloverde: we follow Microsoft support. [18:38:24] <peloverde> XP seems to require pentium 233 [18:38:36] <peloverde> but cmov is good and stuff [18:38:58] <j-b> peloverde: we do not care about anything under pentium2 [18:39:07] <Dark_Shikari> so mru, which of the 4 options do you prefer [18:39:57] <peloverde> j-b: cool, we are trying to sort out the cpu stuff at the moment, but you don't care if MMX support is hard coded instead of detected? [18:40:15] <Dark_Shikari> peloverde: that's what the distro people confirmed was fine [18:40:18] <Dark_Shikari> hardcoding of mmx specifically [18:40:23] <Dark_Shikari> iirc. [18:40:42] <j-b> peloverde: we deactivate autodetection and do it ourselves :D [18:41:43] <peloverde> Dark_Shikari: If people think hard coding of MMX specifically is OK... i'm ok with it as long as things run on the chips they are configured for.... i.e. --cpu=i686 should require an explicit enable/disable mmx [18:42:20] <peloverde> Really it should disable-mmx if it can't auto detect it but apparently i686 is codeword for generic [18:42:41] <Dark_Shikari> also, we need a default --cpu [18:42:51] <Dark_Shikari> I think --cpu=pentium2 should be the default. [18:42:58] <peloverde> I agree [18:43:09] <Dark_Shikari> meaning the default is an actual cpu. [18:43:19] <Dark_Shikari> as opposed to some nebulous default [18:43:43] <peloverde> also I don't think --disable-mmx should be explicitly required for i386 or i486 [18:43:47] <mru> I had a patch for that somewhere [18:43:54] <mru> sensible default cpu [18:44:04] <Dark_Shikari> peloverde: I think yes it should [18:44:12] <Dark_Shikari> here's why [18:44:18] <Dark_Shikari> 1) i686 doesn't support mmx [18:44:22] <Dark_Shikari> 2) neither does i386 or i486 [18:44:29] <Dark_Shikari> 3) thus, to be consistent, they should all act the same way [18:44:39] <Dark_Shikari> 4) whether we like it or not, huge numbers of users use i686 for "generic with mmx and cmov" [18:44:49] <mru> i486 disables cmov [18:44:51] <Dark_Shikari> 5) therefore, if we break i386/486's mmx, we must break i686's [18:45:00] <Dark_Shikari> mru: cmov didn't used to be runtime detected =p [18:45:11] <Dark_Shikari> also, currently, cmov is off by default [18:45:12] <mru> #5 is fucked up logic [18:45:14] <Dark_Shikari> because default cpu == generic [18:45:21] <Dark_Shikari> mru: consistency is important imo [18:45:24] <peloverde> But the reason for this is because i686 used to mean generic+CMOV [18:45:35] <Dark_Shikari> if we disable mmx on some cpus that don't support it, we should disable it on all [18:45:36] <peloverde> i486 always meant hard disable mmx [18:45:56] <peloverde> i486 never autodetected mmx [18:46:06] <Dark_Shikari> wait [18:46:10] <Dark_Shikari> then what was the default --cpu? [18:46:18] <mru> compiler default [18:46:24] <mru> with mmx [18:46:28] <Dark_Shikari> ok, so you're saying that before any of these changes [18:46:29] <Dark_Shikari> i386: no mmx [18:46:31] <Dark_Shikari> i486: mmx [18:46:32] <Dark_Shikari> er, [18:46:36] <Dark_Shikari> i486: no mmx [18:46:38] <Dark_Shikari> i686: mmx [18:46:40] <Dark_Shikari> right? [18:46:41] <mru> yes [18:46:50] <Dark_Shikari> ok, then let's keep it that way even if it's wrong. [18:46:58] <mru> also pentium disables mmx [18:46:59] <Dark_Shikari> But actually it does kind of make sense [18:47:02] <mru> and i586 [18:47:10] <Dark_Shikari> some i686 cpus support mmx [18:47:14] <Dark_Shikari> no i486s do [18:47:17] <Dark_Shikari> but, well, some pentiums do... [18:47:27] <mru> there's pentium-mmx for that [18:48:01] <Dark_Shikari> are there any distros out there compiling ffmpeg with --cpu=i586? [18:48:05] <Dark_Shikari> I would be totally shocked if there aren't [18:48:39] <Dark_Shikari> because as you can tell by my reaction, it's not obvious that --cpu=i586 disables mmx [18:48:44] <Dark_Shikari> especially since --cpu=i686 doesn't! [18:48:59] <Dark_Shikari> i.e. the user isn't told. [18:49:18] <Dark_Shikari> IMO the "requiring --disable-mmx for a cpu without mmx" is a good enough way to do it. [18:49:25] <Dark_Shikari> not perfect, sure, but it wakes people up [18:51:40] <peloverde> Back in the day mandrake targetted i586 [18:52:03] <peloverde> I remember because GStreamer Hat was building everything 386 [18:54:47] <Yuvi> pretty sure red hat does i586 [18:57:01] <janneg> not a problem since red hat/fedora will never have ffmpeg [18:57:06] <janneg> ;) [19:01:02] <Dark_Shikari> peloverde: huh? [19:01:08] <Dark_Shikari> I'm confused [19:01:09] <Dark_Shikari> C#? why [19:01:34] <peloverde> "a tool to make it more difficult for users to stab themselves in the face" [19:01:39] <Dark_Shikari> huh? [19:01:49] <Dark_Shikari> You are as aware as anyone else that users WILL accidentally disable asm [19:01:51] <Dark_Shikari> and unless you tell them [19:01:55] <Dark_Shikari> they will then complain about it going slow [19:01:58] <Dark_Shikari> as per what BBB said [19:02:02] <Dark_Shikari> we CANNOT silently disable mmx. [19:02:48] <peloverde> I'm aware, but I don't see it as an issue [19:03:19] <BBB> guys, STOP FUCKING AROUND :-p [19:03:30] <Dark_Shikari> peloverde: well, I repeat myself [19:03:32] <BBB> my god I can barely keep up with marking my inbox emails as read without actually reading them [19:03:35] <Dark_Shikari> I will revert any patch that silently disables mmx [19:03:43] <Dark_Shikari> in any situations where it wasn't before [19:04:01] <BBB> mru: intptr_t ok with you? [19:04:07] <BBB> mru: I'll work on a patch later on rgarding that [19:04:21] <BBB> I hate all these if (64bit) movsxd r%d, r%dd statements [19:04:23] <mru> BBB: intptr_t is defined to be at least as wide as a pointer [19:04:30] <mru> it's wrong to use for general arithmetic [19:04:36] <BBB> hm... :( [19:04:40] <BBB> got anything better? [19:04:45] <BBB> I'm tempted to just use void * [19:04:50] <mru> buy a ppc [19:05:00] <mru> void *? [19:05:01] <mru> wtf [19:05:06] <BBB> it was a joke [19:05:09] <BBB> now calm down :-p [19:05:28] <mru> not until you guys put down the pitchforks [19:05:30] <mru> and put out the fire [19:05:36] <peloverde> What about intptrdiff_t [19:05:40] <peloverde> it is a pointer difference [19:06:07] <peloverde> A value meant to be added to a pointer is by definition a pointer difference [19:06:14] <mru> that's ptrdiff_t [19:06:23] <mru> and no it's not [19:06:28] <mru> ptr1-ptr2 is a pointer difference [19:06:35] <mru> ptr+number is not [19:06:55] <peloverde> ptr+number is not [19:06:58] <peloverde> number is [19:07:02] <BBB> I think he means that number could be defined as ptr1-ptr2 [19:07:06] <BBB> ptrdiff_t isn't a bad idea [19:07:08] <peloverde> exactly [19:07:19] <mru> but that's not what the number is [19:07:23] <BBB> if ptr1+number is a valid number, then that's ptr2, and thus number=ptr2-ptr1 [19:07:23] <mru> it's just a number [19:07:26] <BBB> thus ptrdiff_t [19:07:42] <BBB> but anyway, yeah, let's bury the pitchforks for a sec [19:07:57] <mru> are there any posix interfaces with similar semantics? [19:08:04] <BBB> that's what I'm wondering [19:08:10] <BBB> I know nothing about posix [19:08:22] <BBB> I know long>=int>=short>=char [19:08:26] <BBB> that's about all I know [19:09:57] <mru> someone still has to sign extend the thing [19:10:08] <BBB> caller would do that [19:10:10] <BBB> instead of callee [19:10:16] <BBB> that's why I want it part of the interface [19:10:39] <BBB> if we make it machine native size, then that shouldn't cost any effort on the caller side [19:12:07] <mru> it still comes from somewhere [19:12:22] <BBB> right, but that's usually a struct in memory [19:12:23] <mru> also, mips and ppc don't have that problem [19:12:34] <BBB> we can leave it as-is, not abig issue [19:12:37] <peloverde> The caller can resize it when shoving it on the stack or into the appropriate register [19:12:43] <BBB> I just hate the random movsxds in my code here ;) [19:12:58] <mru> so you want to hide the ugly parts [19:13:14] <mru> you'd better pray the compiler doesn't fuck it up too [19:13:37] <peloverde> The cglobal interface could be extended? [19:13:39] <mru> also, making it wider might use more stack space [19:14:01] <peloverde> Is using an extra 4 bytes of stack space in an inner loop that bad? [19:14:12] <mru> it might be [19:16:24] <CIA-11> ffmpeg: mru * r24951 /trunk/configure: configure: improve error message for missing yasm [19:18:08] <mru> oh, and it's quite common to have 64-bit long with 32-bit pointers on ppc64 and mips64 [19:18:32] <peloverde> what's why we don't use long [19:18:44] <andoma> mru: i've been working with such archs as well... [19:19:14] <mru> peloverde: but what size would your magic type be? [19:19:27] <mru> a register is 64 bits, so that would be one logical answer [19:19:35] <mru> but that would be wasteful [19:19:53] <peloverde> I'd say 64-bits then [19:20:07] <mru> but that's wrong [19:20:18] <peloverde> I disagree [19:20:19] <mru> or at the very least wasteful [19:20:21] <peloverde> by the way what was the rationale for C's retarded type system [19:20:32] <mru> a plethora of existing hardware [19:20:36] <peloverde> meh I'm an american, I live to be wasteful [19:23:03] <BBB> Dark_Shikari: how do I create a define that does nothing in yasm? [19:23:10] <BBB> %define ADD(x) /* nothing */ [19:23:14] <BBB> yasm doesn't like empty defines [19:23:29] <BBB> %define ADD(x) paddw x, [pw_8] works fine though [19:23:58] <peloverde> Is there a way we can work integer promotion into the cglobal interface? [19:24:08] <peloverde> or is that too messy [19:24:49] <BBB> sign extension? [19:24:53] <BBB> I don't think that'd work... [19:25:57] <peloverde> We are potentially pulling arguments from the stack. Why copy them twice. [19:26:05] <mru> why don't you just make a macro that does it and call said macro with the relevant args at the start of the functionn? [19:26:31] <BBB> peloverde: well, cglobal doesn't really know which arguments are truncated and which aren't [19:26:37] <peloverde> i know [19:26:42] <peloverde> it would praobably be a mess [19:26:45] <peloverde> sigh [19:27:02] <mru> is load+sext as two insns really any slower than doing it in one? [19:27:07] <mru> it's two uops either way [19:43:46] <BBB> mru: really my only purpose here is int stride [19:43:59] <BBB> I think we could use ptrdiff_t stride [19:44:04] <BBB> but I won't push it if you don't like it [19:44:30] <mru> it's wrong [19:44:57] <peloverde> it is a pointer difference [19:48:16] <peloverde> char* some_plane, char* some_planed_plus_stride = some_plane + STRIDE; ptrdiff_t stride = some_planed_plus_stride - some_plane; [19:51:02] <CIA-11> ffmpeg: mru * r24952 /trunk/configure: configure: write config.fate file as early as possible [19:51:03] <mru> what's so dreadful about sign extending one value yourself? [19:51:16] <mru> or two for the functions that take two such params [19:56:14] <BBB> mru: nothing much [19:56:20] <BBB> mru: so I'll leave it for now [20:04:43] <mru> hmm, strange compiler bug [20:04:59] <mru> armcc 4.1 miscompiles two back-to-back bytestream_get_byte() calls [20:10:52] <BBB> error: (CAT_XDEFINE:1) `%xdefine' expects a macro identifier [20:10:53] <BBB> wtf? [20:15:24] <pengvado> BBB: "%define ADD(x)" worksforme [20:15:46] <BBB> pengvado: the whole thing doesn't work for me [20:15:57] <BBB> can I pastebin a whole .asm file and you tell me why it gives me compiler errors? [20:16:02] <pengvado> yes [20:16:50] <BBB> http://pastebin.com/YewF0t23 [20:16:54] <BBB> errors at the bottom [20:16:57] <BBB> so you have line numbers [20:30:29] <pengvado> BBB: typo on line 513, should be capitalized [20:53:11] <BBB> pengvado: holy shit, thanks [21:22:14] <BBB> patch posted \o/ another 2 files moved to yasm [21:22:27] * BBB looks @ h264 doomsday moment approaching [21:22:40] <Yuvi> BBB: you should do a %macro SIGN_EXTEND 1 for the movsxd, that'd at least get rid of 2/3 lines in each function [21:22:50] <astrange> there's going to be a census? [21:23:35] <BBB> Yuvi: is fine with me also [21:23:40] <BBB> oh yeah [21:23:47] <BBB> does anyone know calling convention on x86-32? [21:23:56] <BBB> there's a ?? in my patch and I don't know what it does on x86-32 [21:24:40] <Yuvi> for yasm (atm) params are always on the stack [21:24:55] <BBB> if I call a function also from within yasm? [21:25:01] <Dark_Shikari> within yasm, you can do whatever you want [21:25:05] <Dark_Shikari> literally [21:25:36] <BBB> Dark_Shikari: can you fill in the "??" in my patch just posted? [21:25:41] <BBB> kthnx!!112 [21:25:57] <Yuvi> hm [21:26:00] <pengvado> we have a macro movsxdifnidn [21:26:12] <BBB> that's useful [21:26:17] <BBB> is it in x86util.asm? [21:26:20] <pengvado> yes [21:26:22] <BBB> awesome [21:26:25] <BBB> I'll use that [21:26:40] <Yuvi> you can't do a tail call to a C function on 32-bit unless it has the same number or fewer arguments [21:26:54] <BBB> Yuvi: same number of args here [21:26:58] <BBB> I did a jmp [21:27:09] <BBB> but the args have different order [21:27:20] <astrange> if clang supports __attribute__((fastcall)) we could switch dsp to that on x86-32 [21:27:29] <astrange> i'm not sure it would really save much [21:27:36] <BBB> probably not [21:27:41] <BBB> we barely do any function calls inside simd [21:28:08] <pengvado> the main point would be to save time when calling simd in the first place [21:28:45] <Yuvi> BBB: something like [21:28:45] <Yuvi> mov r0m r2 [21:28:46] <Yuvi> mov r1m r0 [21:28:46] <Yuvi> mov r2m r1 [21:29:08] <BBB> and then jmp? [21:29:12] <Yuvi> yeah [21:29:15] <BBB> awesome [21:29:18] <jenk> man i thought i knew assembly but i srsly dont know any of the operands or instructions you guys mention in here [21:29:19] <BBB> so I don't need the fourth arg [21:29:27] <jenk> movsxdifnidn ????? wtf [21:29:36] <astrange> they're macros in x86util [21:29:37] <BBB> that's a macro, not a instr [21:29:40] <Dark_Shikari> jenk: movsxd if not identical [21:29:41] <jenk> i get that its a macro [21:29:48] <jenk> but i dont even know what it would be a macro for [21:29:49] <Dark_Shikari> that is, if the two arguments are the same [21:29:50] <Dark_Shikari> do nothing [21:29:50] <pengvado> we pretty much wrote our own assembly syntax [21:29:53] <Dark_Shikari> otherwise, do it [21:30:01] <jenk> ic [21:30:08] <jenk> i dont even know what movsxd is [21:30:12] <jenk> i know mov! [21:30:13] <jenk> lol [21:30:19] <Dark_Shikari> mov sign-extend double [21:30:28] <Dark_Shikari> 32bit -> 64bit, with sign extend [21:30:29] <jenk> is that a FP inst? [21:30:34] <Dark_Shikari> doubleword [21:30:36] <Dark_Shikari> i.e. 32-bit int [21:30:39] <jenk> oh that kind of double [21:30:58] <Yuvi> BBB: oh, make sure to pop any clobbered regs [21:31:07] <Yuvi> before the jmp [21:31:08] <BBB> O [21:31:08] <BBB> , [21:31:10] <BBB> oops [21:31:12] <pengvado> doubleword. which is really half of a word. [21:31:13] <BBB> I'm not using any, I think [21:31:29] <jenk> i learned all kinds of useless x86, like setting up ring0 and using the built-in multitasking [21:31:35] <jenk> and virtual memory [21:31:50] <jenk> i basically leanred how to make DOS [21:32:09] <iive> dos doesn't mess with ring0, it is realmode. [21:32:35] <BBB> Yuvi: ok, patch updated, I'm using only 3 regs on 32 and 4 on 64, so I don't think I have to pop any, or do I? [21:32:48] <Yuvi> nope [21:33:16] <jenk> but DOS does use the built-in "OS" features of the x86 [21:33:20] <jenk> and nothing else does [21:33:52] <BBB> Yuvi: excellent, thanks for the help! [21:33:57] <jenk> i wonder if there's a way to abuse them for performance [21:34:15] <jenk> like using the virtual memory exceptions as a nifty in-hardware hash table or something [21:36:37] <pengvado> aren't exceptions, like, really slow? [21:36:51] <jenk> hardware faults to be precise [21:37:01] <jenk> i dunno [21:37:05] <jenk> are they [21:41:39] <mru> hw exceptions are always slow [21:42:09] <mru> they flush all kinds of state and switch to kernel mode [21:42:34] <mru> which then has to save context, do stuff, restore context, and switch back to user mode [21:42:48] <mru> count hundreds of cycles at the minimum [21:43:45] <mru> many modern cpus have more efficient ways of doing a system call [21:44:10] <mru> they can be made faster since it's really just like a normal function call except it switches to kernel mode [21:49:06] <jenk> not int 0x80? [21:49:31] <mru> that's oldskool [21:49:40] <jenk> it is? [21:49:46] <mmu_man> call gates, ... [21:49:48] <jenk> what do you do now [21:49:53] <mru> sysenter [21:50:07] <mru> http://www.intel.com/software/products/documentation/vlin/mergedprojects/an… [21:50:09] <jenk> i will check that out [21:50:14] <mru> what a lovely url [21:50:21] <astrange> there's also new stuff for fast virtualization [21:50:40] <Yuvi> mergedprojects x3 [21:50:59] <mmu_man> it's a big merge [21:51:30] <jenk> it looks like it acts just like int 0x80? it jumps to an address specified by the OS [21:51:37] <jenk> except you have to manually save regs [21:51:58] <jenk> i will keep reading though [21:51:58] <mru> which can be a huge win [21:52:06] <mru> if you're not actually going to modify most of them [21:52:30] <jenk> ah [21:52:44] <mmu_man> saves the cost of fetching/decoding all the movs [21:53:51] <mmu_man> hmm or just moving them for fast paths [21:54:39] <jenk> man my asm is so rusty [21:54:52] <jenk> im guessing MIPS is still just "syscall" [21:55:06] <mru> I think so [21:55:45] <mru> some systems also do clever things that completely avoid an actual context switch for some syscalls [21:56:13] <mru> linux/ppc has a special page that processes can map read-only [21:56:24] <mru> reading the right place on that page gives the current time [21:56:36] <mru> so gettimeofday() doesn't need a full syscall [21:56:51] <mru> some apps call that a _lot_ [21:57:10] <mru> mostly stupid ones of course [21:57:13] <mru> like firefox [21:58:46] <jenk> linux does that with VDSO doesn't it? [21:59:05] <mmu_man> linux-gate.so [21:59:32] <mmu_man> Haiku also has a "comm page" for those like system_time() or optimized memcpy [21:59:59] <mmu_man> mru well depends, at least on BeOS system_time() which is equivalent is meant to be cheap [22:00:08] <mmu_man> and used [22:00:22] <mru> the apps are still stupid [22:00:30] <mru> how quickly do they expect the time to change? [22:00:36] <mru> and why the fuck do they care? [22:01:16] <mmu_man> how else would they get those cpu-sucking JavaScript newstickers work smoothly ? :) [22:01:27] <mmu_man> (while it can use no cpu if correctly written but eh) [22:01:36] <mru> set a timer for the actual time you want to wake up? [22:02:20] <jenk> so sysenter transitions to CPL=0, pushes relevant registers, switches to kernel stack etc... [22:02:26] <jenk> how is this different from what int 0x80 does? [22:02:31] <mru> mmu_man: btw, how's ffmpeg/beos doing these days? [22:02:34] <mru> jenk: I don't know [22:02:39] <mru> but it's supposed to be faster [22:02:40] <jenk> hrm [22:02:45] <jenk> i am looking at http://articles.manugarg.com/systemcallinlinux2_6.html [22:02:50] <mmu_man> still have a local patch here [22:03:24] <mmu_man> still need to check a haiku build but current nightlies are unstable [22:03:48] <jenk> do you guys mind if i bug you with random x86 questions or should i go somewhere else [22:04:21] <mmu_man> jenk you might find better answers on #osdev maybe [22:04:53] <jenk> thx [22:23:21] <CIA-11> ffmpeg: mru * r24953 /trunk/configure: [22:23:21] <CIA-11> ffmpeg: configure: move config.fate creation after OS section [22:23:21] <CIA-11> ffmpeg: The OS label can be changed, and we want this to be reflected. [22:59:30] * peloverde can't wait for git, it will be so much easier to not deal with these messes [22:59:54] <restrex> hi guys... I found this patch http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-October/077506.html will it make ffmpeg create cbr mpeg-2 transport streams? which version of ffmpeg should i download to apply it? thanks [23:00:28] <peloverde> "--- libavformat/mpegtsenc.c (revision 20231)" may be a clue [23:00:46] <mru> kinda old... [23:01:13] <restrex> i know, but how do I get it? [23:01:21] <restrex> svn? [23:01:34] <restrex> or are there tarballs for that revision? [23:02:49] <restrex> like svn co -r 20231 svn://svn.mplayerhq.hu/ffmpeg/trunk ? [23:03:24] <restrex> ok, it's going through thanks [23:07:05] <peloverde> do builds that don't use x87 need emms at all? [23:10:09] <astrange> yes, the client might use it [23:10:44] <peloverde> suppose the cpu doesn't have x87 support? [23:11:16] <peloverde> x87 was originally optional, could it be remove again some day [23:11:29] <astrange> nothing in x86 can ever be removed (except 3dnow) [23:11:44] <astrange> but if x87 doesn't exist then emms is unnecessary, yes [23:13:25] <peloverde> why not? [23:13:33] <peloverde> you just said s3now can be removed [23:13:36] <peloverde> *3dnow [23:13:37] <astrange> windows apps will break [23:13:42] <peloverde> so what [23:13:57] <peloverde> those apps were told they should runtime detect these features [23:14:26] <astrange> if it doesn't run windows xp, it's just as good as another ISA and might get replaced by one [23:14:40] <peloverde> and why is 3dnow an exception to those [23:15:15] <peloverde> I use plenty of apps that don't run on windows xp, doesn't make my cpu any less useful [23:15:23] <Dark_Shikari> why can't 3dnow be removed [23:15:25] <Dark_Shikari> er, can [23:15:35] <astrange> 3dnow didn't exist on intel, so there was a real requirement to detect it [23:15:53] <Dark_Shikari> sse4 doesn't exist on amd... so... [23:16:07] <astrange> i think the same goes for it [23:20:02] <peloverde> But there are plenty of CPUs still in use that dont support for instance SSSE3

1 0

IRC log for 2010-08-24
by irc＠mansr.com 25 Aug '10

25 Aug '10

[00:47:36] <CIA-11> ffmpeg: ramiro * r24894 /trunk/ffmpeg.c: indent [02:11:05] <swatiardeshna> hi [02:11:26] <swatiardeshna> how to install ffmpeg for iphone [02:11:39] <BBB> please see topic [02:12:01] <BBB> "Questions about using FFmpeg or developing with the libav* libraries should be asked in irc://irc.freenode.net/#ffmpeg." [03:16:48] <xxthink> is the audio stream is mp2 layer-2 [03:16:53] <xxthink> if the audio stream is mp2 layer-2 [03:17:47] <xxthink> the difference of the pts and dts between two successive audio frame should be the same [03:17:51] <xxthink> is it right? [04:11:57] <saintdev> kshishkov: ping [04:31:52] <kshishkov> saintdev: what? [04:33:09] <saintdev> kshishkov: pm [05:07:55] <saintdev> well except for decimating anything above scalefactor 39, which as far as i can tell is intentional. i think long blocks are working [05:08:54] <saintdev> so, on to short blocks [05:11:07] <saintdev> oh, except for perceptual entropy. [05:14:55] <saintdev> not sure yet how good it is, but it works :P [05:52:31] <_av500_> xxthink: yes, samples per frame are constant [06:00:55] <pJok> god morgon kshishkov [07:28:21] <funman> any reason why AVCodec->encode() doesn't take a const void* for the input samples? [07:35:12] <Tjoppen> funman: which function do you mean? [07:35:47] <kshishkov> funman: instead of what? [07:35:57] <funman> void *data [07:36:12] <funman> Tjoppen: int (*encode)(AVCodecContext *, uint8_t *buf, int buf_size, void *data); [07:37:22] <kshishkov> yes, const qualifier won't hurt, feel free to send a patch [07:37:30] <funman> well i see that mpeg video encoder for example modify the picture [07:37:46] <kshishkov> oops [07:37:59] <kshishkov> then you know the awnser ;) [07:38:06] <funman> perhaps that's a bug though [07:39:16] <Tjoppen> I ran into a case where I thought the same, but the void* could be used as an opaque pointer to some non-const state [07:39:38] <Tjoppen> not that exact function though. audio resampler IIRC [07:42:46] <Tjoppen> well, load_input_picture() in mpegvideo_enc.c modifies display_picture_number [07:45:25] <funman> r3833 -> s/pic/pic_arg/ is a typo maybe [07:49:09] <kshishkov> that could be needed for picture reordering [07:50:12] <funman> if some reordering must be done, i'd expect it to affect the output pictures only [07:51:17] <kshishkov> ask the author, is anybody is able to make out something from that, he's the only person [07:51:37] <funman> i should've asked about ->encode() in my reply [07:52:19] <funman> const polishing isn't very exciting anyway [07:52:37] <funman> much more adrenaline when playing with lego stuff! [07:52:56] <saintdev> lego \o/ [08:38:50] <CIA-11> ffmpeg: stefano * r24895 /trunk/libavfilter/avfilter.c: (log message trimmed) [08:38:50] <CIA-11> ffmpeg: Make avfilter_start_frame() invoke avfilter_get_video_buffer() on the [08:38:50] <CIA-11> ffmpeg: link rather than avfilter_default_get_video_buffer(). [08:38:50] <CIA-11> ffmpeg: This is required as the buffer requested may be greater than the [08:38:50] <CIA-11> ffmpeg: buffer allocated locally by avfilter_default_get_video_buffer(), for [08:38:51] <CIA-11> ffmpeg: example if in filterchain there is a pad filter (like in "fifo,pad"). [08:38:52] <CIA-11> ffmpeg: In that case the pad filter will try to write beyond the data of the [08:38:52] <CIA-11> ffmpeg: stefano * r24896 /trunk/ (5 files in 2 dirs): Add fifo filter. [12:02:47] <kierank> where's a good place to visit in sweden? [12:03:15] <mru> stockholm [12:03:35] <thresh> border line when leaving it [12:03:36] * thresh hides [12:04:49] <thresh> mru: what does 'Hättan' mean? [12:04:56] <thresh> (as in trollhättan) [12:05:54] <mru> the hat [12:06:00] <mru> so it's Troll Hat [12:06:59] <thresh> awesome [12:09:49] <kierank> hmm stockholm looks nice [12:10:27] <spaam> kierank: norrland is nice :) [12:10:31] <av500> doesnt it make people have a "syndrome"? [12:10:49] <kshishkov> mru: it actually can mean "The Magic(ian) Hat", can't it? [12:11:13] <mru> magician is trollkarl [12:11:16] <kshishkov> spaam: I should check that [12:11:39] <mru> which is derived from the verb "trolla" [12:11:46] <mru> meaning "to perform magic" [12:11:54] <mru> thus called because trolls do it [12:12:04] <kierank> spaam: what is norrland? [12:12:12] <spaam> kierank: the north part of sweden :) [12:12:26] <av500> and south part does not exist :) [12:12:26] <spaam> like the half of the country :) [12:12:34] <kshishkov> mru: you should remind that to people often [12:12:51] <kierank> spaam: can i crash with you ;) [12:12:51] <kshishkov> av500: you can ask imaginary pJok about it [12:13:13] <kshishkov> spaam: and remember, it's only half of pre-1809 Norrland [12:13:35] <spaam> kierank: i live in the south part of sweden =/ [12:13:43] <kierank> maybe i should try airbnb [12:14:30] <mru> kierank: merbzt should have a spare room if superdump has moved out [12:15:01] <superdump> as of last weekend, the room is probably occupied again [12:15:07] <superdump> but speak to merbanan :) [12:15:36] <mru> oh [12:15:58] <mru> superdump: so you have moved out? [12:16:09] <superdump> yup [12:16:17] <mru> where do you live now? [12:16:30] <superdump> with my g/f [12:16:53] <mru> and where's that? just curious... [12:17:19] <superdump> enskede gård [12:17:36] <kshishkov> weren't you living there anyway? [12:17:39] <superdump> just south of globen [12:18:05] <superdump> well, it was more that i was staying with her than actually living here [12:18:51] <superdump> though when i was 'living with ben' i spent basically all my time here so there wasn't much point [12:24:38] * kshishkov should book an hotel [12:27:26] <spaam> kshishkov: going to .se ? :) [12:27:34] <kshishkov> spaam: javisst [12:27:48] <kierank> kshishkov: when are you going? [12:27:56] <kshishkov> kierank: this weekend [12:28:22] <spaam> kshishkov: stockholm eller ? [12:28:29] <thresh> на истоrическую rодину? [12:29:35] <kshishkov> thresh: нет, просто на родину. А почему ви спrашиваете? [12:29:46] <thresh> kshishkov: таки завидуем. [12:30:13] <kshishkov> spaam: stockholm ock ! I usually try to visit several places though Stockholm usually takes lion share of time [12:30:41] <mru> "och", not "ock" [12:31:42] <kshishkov> mru: thanks, I'll try to remember it for longer time [12:32:14] <mru> but it's "också" just to be confusing [12:32:31] <kshishkov> yes [12:32:40] <kshishkov> still better than Danish "og" [12:33:19] <mru> pronounced "öuugh" [12:33:31] <mru> like most danish words [12:34:12] * kshishkov finds Danish to be less pleasant sounding than other Nordic languages [12:36:00] <kshishkov> and I must admit that Norwegian language seems to have better writing system than Swedish [12:36:24] <mru> not really [12:36:40] <mru> they write kk instead of ck [12:37:05] <mru> otherwise it's mostly the same [12:37:40] <pJok> god sorensen squeeze is useless [12:37:46] <kshishkov> look at words ending with "-tion" [12:37:49] <spaam> finnish is harder to understand then dansih ;S [12:38:00] <mru> finnish spelling is highly consistent [12:38:13] <mru> kshishkov: .no spells those -sjon [12:38:17] <kshishkov> yes, otherwise it would be real hell [12:38:26] * pJok prods kshishkov to make ffmpeg encode VP6 [12:38:29] <kshishkov> mru: and it sounds like that too [12:38:49] <mru> in swedish, -tion and -sjon sound the same [12:39:03] <pJok> danish is horrible [12:39:15] <kshishkov> pJok: no thanks, I'm against it [12:39:37] <mru> obligatory: http://www.youtube.com/watch?v=s-mOy8VUEBk [12:39:59] <kshishkov> mru: yes, but Norwegian writting seems to be a bit closer to pronunciation [12:40:00] <pJok> kshishkov, squeeze does not believe in 23.976 as framerate and its mp3 encoder does not believe in 64kbit stereo [12:40:30] <av500> pJok: so why use it? [12:40:32] <kshishkov> pJok: well, depends on bitrate for audio [12:40:43] <mru> av500: why use danish? [12:40:50] <av500> that too [12:40:58] <mru> what is the bitrate of danish? [12:41:13] <av500> that sorenson sqeal [12:41:17] <av500> +u [12:41:19] <pJok> av500, i just got specs on something i need to deliver and they say they want flv vp6 with framerate 23.976 or 29.97 with 64kbit stereo mp3 audio [12:41:29] <pJok> why i have no idea... [12:41:43] <kierank> pJok: encode in squeeze and remux [12:42:01] <kshishkov> don't forget to resample audio to 8kHz [12:42:06] <av500> cat /dev/random > vp6_23.976_mp3_64k.flv [12:42:28] <pJok> kierank, that was my first plan... but if squeeze doesn't support decimals in framerate, it doesn't matter :P [12:42:38] <av500> encode at 23976 fps [12:42:45] <av500> then slow down 100x [12:42:57] <kierank> encode it 24fps [12:43:00] <kierank> then slow it down [12:43:01] <pJok> or i could just take a hammer and tell those who wants those specs to shove it... [12:43:11] <av500> use shovel [12:43:13] <pJok> but its typical with my job [12:43:20] <pJok> i get specs 5 min before i have to deliver something [12:43:28] <pJok> and im just the IT guy... [12:43:33] <av500> at least you get specs! [12:43:43] <kshishkov> pJok: at least you can be proud of your mountains. [12:43:46] <av500> I get told, I am already late before I start [12:43:46] <pJok> av500, it would be easier if i didn't get specs... [12:43:58] <mru> pJok: why don't you show them what kind of power the IT guy can wield? [12:45:03] <pJok> mru, i hate trying to convience people who think they know that what they see is different from what i see... already had a battle with a broadcast company about the specs they gave me... but at least they dont complain about the files i send them, even though they are out of spec according to what they gave me [12:45:38] <pJok> mru, that i already did... im leaving two hours early today for a job interview at another company :P [12:45:47] <mru> :-) [12:46:06] <pJok> they don't know yet though [12:46:15] <pJok> and till i've signed a contract, they wont know either [12:46:32] <kshishkov> I imagine that Lego block carver may be more respectable and better paid profession [12:47:04] <av500> dont forget lego block painter [12:47:16] <av500> or lego adpcm encoder [12:48:09] <mru> I can haz deblocking filter for lego? [12:48:28] <kshishkov> of course! [12:48:45] <pJok> mru, http://www.youtube.com/watch?v=4qsWFFuYZYI [12:48:46] <kshishkov> ask any digital placeboist [12:50:17] <mru> pJok: nice [12:51:38] <pJok> ah well, time to call it a day and get to that interview [12:51:56] <pJok> then fix what ever encoder that will do what i need with VP6 later [12:51:59] <kshishkov> lycka till [12:53:04] <mru> kshishkov: http://www.youtube.com/watch?v=hWTFG3J1CP8 [12:57:26] <kshishkov> mru: hmm [12:58:31] <thresh> awesome [13:00:47] <spaam> kshishkov: do you own a .su domain ? :) [13:02:53] <kshishkov> spaam: I don't want to own any domains [13:03:29] <av500> in .ua, domains own you.... [13:03:38] <spaam> haha [13:04:00] <thresh> .su is stupidly expensive [13:04:20] <av500> wouldnt that be .se? [13:04:42] <thresh> two jokes in a minute, nicely done! [13:04:59] <mru> if you want your own TLD, what's cheaper, the registration fee for a custom one, or buying a pacific island? [13:05:05] <kshishkov> he's our biggest joker after all [13:05:25] <kshishkov> buying an island of course! [13:05:30] <mru> or buying an army to invade an island [13:05:38] <kshishkov> good place to run your tracker as well [13:15:14] <av500> kshishkov: what good is a tracker that sits on an island that has 1 fiber if lucky [13:15:31] <kshishkov> av500: or 1 sat [13:15:35] <av500> yep [13:15:48] <mru> av500: choose the island carefully: http://www.cablemap.info/ [13:17:00] <av500> ok, not cyprus [13:17:48] <thresh> huh, ibiza got no internets? [13:18:21] <mru> probably only smaller cables [13:19:14] <kshishkov> bootlaces [13:19:31] <mru> besides, people there are too drunk to be on the internets anyway [13:19:37] <thresh> indeed [13:20:55] <av500> ok, so guam [13:21:00] <thresh> sumatra looks nice as well [13:21:03] <av500> will be hard to take by force though... [13:24:03] <kshishkov> guam is harder [13:24:14] <kshishkov> if they still have that US military base there [13:24:30] <thresh> maybe if I tell Japan I'll give them Kuril islands back, they will attack US? [13:24:31] <mru> unless you use said base to take it over [13:25:31] <kshishkov> thresh: they can only self-defence themselves ;) so unlikely. But thanks for the islands [13:25:57] <thresh> kshishkov: choose whatever you like [13:39:36] <av500> how do I create a many frames video from one PNG? [13:41:24] <Tjoppen> something like ffmpeg -r 0.1 -i frame.png -r 25 output.avi ? [13:41:50] <mru> what a nasty way [13:42:01] <Tjoppen> I rarely use the CLI, so.. :p [13:43:20] <CIA-11> ffmpeg: mru * r24897 /trunk/libavformat/asfcrypt.c: [13:43:20] <CIA-11> ffmpeg: asfcrypt: fix unaligned accesses with armcc [13:43:20] <CIA-11> ffmpeg: Compilers may assume a pointer has natural alignment, even if it was [13:43:20] <CIA-11> ffmpeg: assigned from a pointer type with weaker alignment requirements. It [13:43:20] <CIA-11> ffmpeg: is thus not safe to assign a possibly unaligned value to a pointer, [13:43:21] <CIA-11> ffmpeg: regardless of how it is subsequently dereferenced. [13:51:59] <merbzt> how do I memcpy a struct with pointers in them and still abide alignment and other stuff ? [13:53:33] <mru> what do you mean? [13:54:50] <av500> Tjoppen: does not create several frames [13:55:27] <Tjoppen> -loop-input (or whatever it's called)? [13:55:29] <Tjoppen> and -t [13:55:55] <av500> thx [13:56:01] <kshishkov> merbzt: just memcopy [13:56:59] <merbzt> kshishkov: are pointers allowed to be on random addresses on all platforms ? [13:57:18] <kshishkov> nope [13:57:21] <mru> merbzt: what are you trying to do? [13:57:40] <astrange> pointers themselves are aligned to pointer size, their values are aligned to something else [13:57:41] <kshishkov> mebzt: but compiler should know that and allocate structure object aligned [13:57:43] <astrange> or not [13:58:11] <merbzt> typedef struct { [13:58:11] <merbzt> char* name; [13:58:11] <merbzt> void* value; [13:58:11] <merbzt> int type; [13:58:11] <merbzt> } nvt; [13:58:27] <merbzt> I have lots of structs with that [13:58:30] <mru> yes, so? [13:59:02] <merbzt> I wanna copy them a populate the copy's with data [13:59:38] <mru> you sound like an indian student doing his homework [13:59:49] <merbzt> yeah I know :) [14:00:00] <kshishkov> if you use nvt a, b; a = b; (or memcpy(&a, &b, sizeof(a))) it should work without any side effects [14:00:39] <merbzt> I need to malloc a and b [14:01:15] <av500> malloc outputs at least 8 byte aligned, no? [14:01:20] <merbzt> or that was my original plan [14:01:28] <kshishkov> av500: not on DOS, I think [14:01:36] <mru> malloc returns memory suitably aligned for any machine type [14:01:53] <kshishkov> merbzt: go ahead and don't worry unless you hit a VAX [14:01:57] <merbzt> :) [14:02:08] <av500> kshishkov: VAX runs DOS? [14:02:43] <kshishkov> av500: nope, it was too advanced for that [14:03:28] <CIA-11> ffmpeg: bindhammer * r24898 /trunk/ (5 files in 2 dirs): [14:03:28] <CIA-11> ffmpeg: fixed some return values and deprecated CODEC_TYPE_VIDEO. [14:03:28] <CIA-11> ffmpeg: dithering (faster) along a linear gradient now. [14:03:49] <merbzt> mru: that's what I thought also, but as always I'm not 100% sure [14:04:10] <mru> the C spec would have told you the answer [14:04:56] <merbzt> it just did [14:05:19] <merbzt> mr C spec [14:08:47] * kshishkov wonders why there're no attempts on FFcc yet [14:17:48] <kierank> imagine the bikeshedding for FFcc [14:26:05] <kshishkov> kierank: that would be enough bikesheds for whole Denmark, Netherlands and China combined [14:26:07] <BBB> wbs: I intend to review your g222 patch later today, poke me if I forget [14:37:53] <twice11> merbzt: nvt *a, *b; a = malloc(sizeof a); b=malloc(sizeof b); /* init a */; *b=* [14:37:59] <twice11> *b=*a; [14:38:02] <twice11> will work. [14:38:06] <twice11> everywhere. [14:38:16] <kshishkov> sizeof(*a) though [14:40:17] <twice11> kshishkov: Well spotted. [14:56:30] <BBB> hi spyfeng [14:56:37] <BBB> how's starcraft2 coming along [14:56:52] <wbs> BBB: oh, thanks :-) I'd guess michael wants to have a say about it, too, since he was reviewing it last time around, but he seems a bit busy lately [14:57:14] <BBB> he complained he has like 150 unanswered (reviewable) emails lying around [14:57:24] <wbs> yeah, I saw that [14:57:26] <BBB> poor guy, avfilter and so on are terribly complex and take ages [14:57:36] <wbs> yeah [14:57:46] <BBB> I'll help with codec review where relevant ;) [14:58:19] <mru> he's not improving his situation by writing code so convoluted that nobody else will go near it [14:59:34] <BBB> that problem will not solve itself other than us helping to fix it, I'm affraid [14:59:42] <kshishkov> mru: you can start easy with reviewing swscaler first ;) [14:59:44] <BBB> his mind might be wired so weirdly that he thinks the code makes sense [14:59:45] <BBB> or so [15:00:14] <mru> he refuses any such help [15:00:30] <mru> didn't you seem him denying any problems with libswscale yesterday? [15:00:48] <BBB> he'll accept patches that improve it even if there is no "problem" [15:01:19] <mru> swscale is one of those things that can't be improved incrementally [15:01:26] <mru> there's nothing sound to base a patch on [15:02:30] <BBB> that's a little funny :) [15:02:37] <kshishkov> well, some parts are not that bad. For example, I was able to figure out how YUV2RGB works [15:02:48] <BBB> I heard that very exact same sentence with s/swscale/ffmpeg/ about 5 years ago from fellow gstreamer developers [15:02:59] <mru> kshishkov: what kind of mind-altering drugs did you take when doing that? [15:03:24] <mru> BBB: it is true for large parts of it [15:03:28] <mru> e.g. mpegvideo* [15:04:30] <kshishkov> mru: none, I shun drugs. Digging through heaps of code with questionable quality helps though. [15:06:54] <kshishkov> I'd say that main tangled mess is hidden in swscale_template.h and swscale.c [15:07:04] <kshishkov> I'm afraid to touch them [15:07:10] <mru> what else is there to libswscale? [15:07:23] <mru> those two files are like 90% of it [15:09:42] <CIA-11> ffmpeg: mru * r24899 /trunk/libavformat/utils.c: avformat: free decryption key in av_close_input_stream() [15:10:37] <kshishkov> only a half actually [15:10:54] <kshishkov> rgb2rgb stuff is heavy too [15:13:05] <CIA-11> ffmpeg: stefano * r24900 /trunk/libavfilter/ (avfilter.c avfilter.h internal.h): Implement ff_get_ref_perms_string() and use it for tracing. [15:22:19] <CIA-11> ffmpeg: bindhammer * r24901 /trunk/libavcodec/ (a64colors.h a64enc.h a64tables.h a64multienc.c): added interlacing option and compression option for colorram (lut) [15:41:50] <CIA-11> ffmpeg: mru * r24902 /trunk/libavcodec/msmpeg4.c: [15:41:50] <CIA-11> ffmpeg: msmpeg4v1: fix undefined behaviour in msmpeg4_decode_picture_header() [15:41:50] <CIA-11> ffmpeg: Because the order of evaluation of subexpressions is undefined, two [15:41:50] <CIA-11> ffmpeg: get_bits() calls may not be part of the same expression. In this [15:41:50] <CIA-11> ffmpeg: specific case, using get_bits_long() is simpler. [15:41:51] <CIA-11> ffmpeg: This fixes msmpeg4v1 decoding with armcc. [15:42:55] <mru> there, that should give us two more green on fate [15:45:04] <superdump> merbanan: can you check the ffmpeg-soc moderation list to see if marcelo's mail(s) got blocked please? [15:45:22] <peloverde> mru: there are other places where that maltrick is used [15:45:47] <mru> do you have a good way to find them? [15:46:44] <peloverde> grep get_bits.*get_bits is not perfect but it's somewhere to start [15:49:02] <CIA-11> ffmpeg: stefano * r24903 /trunk/ffmpeg.c: [15:49:03] <CIA-11> ffmpeg: Make configure_filters() return a meaningful error code rather than [15:49:03] <CIA-11> ffmpeg: always -1. [15:49:03] <CIA-11> ffmpeg: stefano * r24904 /trunk/ffmpeg.c: [15:49:03] <CIA-11> ffmpeg: Cosmetics: rename out_video_filter to output_video_filter, for [15:49:03] <CIA-11> ffmpeg: consistency with input_video_filter. [15:49:04] <CIA-11> ffmpeg: stefano * r24905 /trunk/ffmpeg.c: Factorize opt_new_{audio,video,subtitle} definitions. [15:49:31] <peloverde> I can go through and fix the ones I found [15:50:14] <kierank> 15 years since: http://www.youtube.com/watch?v=5VPFKnBYOSI [15:50:49] <kshishkov> never forget, never forgive [15:50:52] <peloverde> I remember buying that on launch day [15:51:08] <kierank> I remember watching the weezer video [15:51:10] <kierank> and playing hover [15:51:56] * kshishkov got his first computer in '97 [15:52:32] <mru> peloverde: if you don't mind [15:53:13] <_skal_paris_> BBB: http://pastebin.org/760168 [15:54:35] <Dark_Shikari> _skal_: why [15:56:25] <BBB> is that correct? [15:56:52] <Dark_Shikari> he's just inlining get_sint [15:56:57] <Dark_Shikari> which I don't get [15:57:26] <_skal_> The spec^Wlibvpx says that, if the first bit is zero, you shouldn't touch the value. Not reset it to 0. [15:57:59] <kshishkov> _skal_: we know that VP8 spec == libvpx [15:58:21] <Dark_Shikari> _skal_: shouldn't get_sint be changed then? [15:58:34] <_skal_> Dark: i tried that, but it's cumbersome [15:58:49] <Dark_Shikari> Er... [15:58:51] <Dark_Shikari> why do only those change? [15:58:54] <Dark_Shikari> what about the segment info? [15:58:55] <_skal_> you have to pass 'int8_t* value' pointer [15:58:57] <BBB> as per kshishkov [15:59:01] <BBB> please check against libvpx [15:59:09] <_skal_> and i realized it was only meaningful in 2 places [15:59:14] <Dark_Shikari> and what about quants [15:59:18] <_skal_> the other two, the default value *is* 0 [15:59:19] <BBB> and provide a sample that shows the bug [15:59:25] <BBB> otherwise we can't put it in the regtest [15:59:31] <_skal_> quant = 0 for default too [15:59:48] <Dark_Shikari> _skal_: then do it like this [15:59:56] <Dark_Shikari> int x = getsint(); [15:59:57] <Dark_Shikari> if(x) [15:59:59] <_skal_> BBB: i've pinged the relevant people to have them generate a proper test-vector [16:00:03] <Dark_Shikari> ref[i] = x [16:00:10] <_skal_> Dark: no [16:00:21] <_skal_> Dark: because you *can* code zero with a leading non-zero bit [16:00:27] <Dark_Shikari> huh? [16:00:27] <_skal_> yeah, i know i know [16:00:32] <_skal_> sub-optimal [16:00:36] <Dark_Shikari> no no, you CAN, but does libvpx? [16:00:42] <Dark_Shikari> if it doesn't, we don't care [16:00:49] <_skal_> some encoder can [16:00:57] <Dark_Shikari> No, it can't [16:01:00] <Dark_Shikari> libvpx is the spec [16:01:05] <_skal_> for decoding [16:01:17] <Dark_Shikari> and? its behavior for invalid bitstreams does not have to be replicated [16:01:33] <Dark_Shikari> we don't replicate its behavior for invalid EOBs either [16:01:50] <_skal_> another encoder can code zero using: 1 + 0000000 for get_sint(.., 6) [16:01:56] <Dark_Shikari> That should be invalid [16:01:58] <_skal_> or 1 + 0000000 for that matter [16:02:03] <_skal_> or 0 simply, too [16:02:03] <Dark_Shikari> libvpx doesn't do it, so fix the spec to say so [16:02:23] <Dark_Shikari> If libvpx does not do X, and X is allowed by the decoder, you can define X to be invalid without breaking any existing software. [16:02:45] <Dark_Shikari> a good example is that bug with reference frame swapping. [16:02:47] <_skal_> Dark: libvpx *do* X [16:02:58] <Dark_Shikari> _skal_: libvpx writes "1 + 000000"? [16:03:03] <_skal_> libvpx does: if (get_bit()) { do something } else { do nothing } [16:03:08] <Dark_Shikari> NO, I meant the encoder. [16:03:11] <Dark_Shikari> Again, libvpx does NOT WRITE that [16:03:19] <_skal_> we do: if (get_bit()) { do_something } else { do something } [16:03:26] <Dark_Shikari> that is reading code, not writing code [16:03:29] <Dark_Shikari> stop being intentionally thick [16:03:31] <Dark_Shikari> the encoder does not do X [16:03:38] <Dark_Shikari> therefore, X can be declared invalid without breaking anything [16:03:49] <_skal_> come on, libvpx is not the only encoder [16:03:53] <Dark_Shikari> Yes it is [16:03:57] <_skal_> no it isn't [16:04:04] <Dark_Shikari> Now, in a month or two, this might change [16:04:09] <Dark_Shikari> when we remove libvpx from vlc and ffmpeg [16:04:20] <Dark_Shikari> but for now, it's the only one [16:04:31] <BBB> Dark_Shikari: so... the last argument to cglobal in yasm, for mmx functions [16:04:36] <BBB> does it do anything? [16:04:52] <Dark_Shikari> BBB: I think so. [16:04:59] <Dark_Shikari> I think it still does the same thing [16:05:03] <BBB> ok [16:05:03] <Dark_Shikari> so you have to either not set it, or set it to 0 [16:05:14] <Dark_Shikari> reason: you can have INIT_MMX but still explicitly use some xmmregs. [16:05:30] <BBB> right... [16:05:52] <BBB> <=8 it does nothing right? [16:06:02] <pengvado> <=6 [16:06:12] <_skal_> Dark: so, i'll have to supply an official test bitstream for you to change your mind? [16:06:27] <_skal_> something that libvpx decodes but not ffvp8? [16:06:34] <Dark_Shikari> No [16:06:39] <pengvado> test bitsrreams don't count either, except insofar as they'd be evidence for the existence of an encoder that does it [16:07:10] <Dark_Shikari> _skal_: we are at a point where there are still no encoders that do certain stupid things [16:07:18] <Dark_Shikari> therefore, we can safely declare those things to be wrong [16:07:30] <_skal_> Dark: why 'stupid' [16:07:31] <_skal_> ? [16:07:33] <Dark_Shikari> You apparently want to squander this chance [16:07:33] <_skal_> i don't get it [16:08:03] <_skal_> the algo is: if leading bit = 0, leave the value untouched, else update it with the following 6 bits + sign [16:08:03] <Dark_Shikari> In the case of residual coding, you agreed with me. [16:08:08] <_skal_> where is that stupid? [16:08:26] <Dark_Shikari> because it adds pointless redundancy to the bitstream [16:08:33] <_skal_> ffvp8 does: if leading is 0, reset to 0, else read 6 bits + sign [16:08:41] <Dark_Shikari> yes, so change ffvp8 to do [16:08:50] <_skal_> that was my patch, mind you [16:08:59] <Dark_Shikari> oh, actually, setting to zero is valid [16:09:07] <Dark_Shikari> ok, in that case, patch accepted [16:09:07] <_skal_> sometimes, but not always [16:09:09] <Dark_Shikari> wait [16:09:11] <Dark_Shikari> why not always? [16:09:20] <_skal_> some default values *are* 0 [16:09:28] <Dark_Shikari> what do you mean by default? [16:09:29] <_skal_> and set just before callign get_sint() [16:09:29] <Dark_Shikari> you said [16:09:36] <Dark_Shikari> you just said that it leaves the existing one at zero [16:09:40] <Dark_Shikari> er, it leaves the existing one [16:09:42] <Dark_Shikari> if zero is set [16:09:46] <Dark_Shikari> by definition then, there isn't a "default" [16:09:49] <_skal_> let me find the exact line [16:10:06] <Dark_Shikari> now I'm confused [16:10:20] <Dark_Shikari> you're giving me contradictory information about the coding method for these syntax elements. [16:11:20] <Dark_Shikari> if 10000000 is a value that cannot be represented any other way, patch accepted [16:11:25] <Dark_Shikari> (a valid value) [16:11:34] <BBB> I might need some thinking help [16:11:35] <CIA-11> ffmpeg: alexc * r24906 /trunk/libavcodec/ (qdm2.c mjpegdec.c): [16:11:35] <CIA-11> ffmpeg: Fix undefined expressions that use multiple calls to get_bits(). [16:11:35] <CIA-11> ffmpeg: Because the order of evaluation of subexpressions is undefined, two [16:11:35] <CIA-11> ffmpeg: get_bits() calls may not be part of the same expression. [16:11:35] <CIA-11> ffmpeg: See also r24902. [16:11:41] <Dark_Shikari> BBB: writing the rac? [16:11:44] <BBB> that bug on win64 with test sample 3 and 7 [16:11:52] <BBB> no that's waiting for me to fix vp8 on win64 [16:12:00] <BBB> the bug is caused by two functions in vp8 simd [16:12:07] <BBB> if I disable either one half the bug goes awy [16:12:13] <BBB> disabling both makes it go away 100% [16:12:21] <BBB> the buggy functions are ... bilin4/16_mmxext [16:12:26] <BBB> I don't understand how that's possible [16:12:39] <_skal_> Dark: this 1000000 was an unfortunate digression of mine [16:12:42] <BBB> how do mm registers screw up a double? [16:13:04] <Dark_Shikari> someone didn't run emms? [16:13:16] <BBB> what is emms? [16:13:29] <BBB> you wrote this asm, not me :-p [16:14:35] <Dark_Shikari> why are you talking about doubles? [16:14:43] <Dark_Shikari> where does vp8 use doubles? [16:14:57] <peloverde> http://www.intel.com/software/products/compilers/clin/docs/ug_cpp/comm1010.… [16:15:16] <mru> avcodec_decode_video2() does emms_c() [16:16:20] <_skal_> Dark: back to topic: for delta_q's the default value is 0. So calling get_sint() is ok. For segmentation.base_quant[] and filter_level[] the default is also 0, and libvpx does a memset(..,0,...) before doing the get_sint(). We don't, but rely on get_sint() to return 0 when leading bit is 0. Last use of get_sint() is for lf_delta's, but this one was erroneous because there's no default in this case, but we just have to leave the values unto [16:16:23] <_skal_> pfff.... that was long [16:16:34] <_skal_> need a coffee [16:16:55] <Dark_Shikari> patch ok as long as there is a commenbt explaining why we're not using sint [16:17:01] <_skal_> k [16:21:45] <BBB> Dark_Shikari: a double check in ffmpeg.c is screwed up by these two functions in vp8 [16:21:51] <BBB> if I disable these two, the bug goes away [16:21:58] <BBB> disable one of them, the bug goes half-away [16:22:11] <BBB> disable anything else, all other simd, the bug is still there [16:22:32] <BBB> I'm wondering how a mmxext function could screw up a double [16:22:50] <Dark_Shikari> because emms isn't being called afterwards [16:22:52] <Dark_Shikari> because the stack was corrupted [16:24:57] <BBB> hm... that's possible I guess [16:25:05] * BBB goes check stack writing variables [16:26:55] <Dark_Shikari> BBB: try cutting out parts of the function until it works [16:26:59] <Dark_Shikari> i.e. let it generate invalid output [16:27:05] <Dark_Shikari> but cut out parts until the double check succeeds [16:27:13] <BBB> I think I found it [16:27:17] <BBB> this is rather depressing [16:28:16] * mru also found something depressing [16:28:23] <mru> avfilter this time [16:29:21] <Dark_Shikari> BBB: what was it? [16:29:29] <Dark_Shikari> I want to know what stupid shit I did [16:31:46] <kshishkov> mru: next thing you find even more depressing should be audio resampler then [16:32:38] <mru> there's a function doing a huge malloc with no way of reporting an error [16:32:45] <mru> and of course the malloc isn't checked [16:32:59] <mru> error checking in lavfi is abysmal [16:33:03] <mru> and that's being polite [16:33:04] <BBB> Dark_Shikari: it was me forgetting to svn update and tracing the same bug I already fixed yesterday (sub r4 instead of sub r4d for an int height) [16:33:14] <BBB> the real bug is still there, I'm re-doing the same shit now [16:33:17] * BBB hits himself [16:33:23] <twice11> audio resampler? Let's go straight into lavseq then... [16:34:35] <BBB> this one appears in sse2 code, it seems... well at least it's a new bug then [16:38:43] <peloverde> Is there a way to turn fate "inside out" and look at it per test instead of per-machine? [16:39:14] <mru> not yet at least [16:42:28] <BBB> ah got it, finally [16:52:32] <mru> BBB: well? [16:52:37] <BBB> committed [16:52:49] <BBB> 24908 should have working VP8 on Win64 [16:52:55] <BBB> let's see if fate agrees [16:53:01] <BBB> I can look at the others later or so [16:53:11] <CIA-11> ffmpeg: mru * r24907 /trunk/configure: configure: fix typo in test deps [16:53:12] <CIA-11> ffmpeg: rbultje * r24908 /trunk/libavcodec/x86/vp8dsp.asm: [16:53:12] <CIA-11> ffmpeg: Clobber xmm registers in simple loopfilter. Should fix the last two VP8-related [16:53:12] <CIA-11> ffmpeg: fate failures on Win64. [16:53:31] <mru> that's a bad commit message [16:53:40] <mru> the registers were being clobbered all along [16:53:47] <mru> you just weren't telling anyone [16:54:16] <mru> this reminds me of people who believe "assert" to be synonymous with "fail" [16:54:38] <BBB> uh [16:54:39] <BBB> right [16:54:43] <BBB> "mark for clobber" [16:54:45] <BBB> let me fix that [16:55:36] <BBB> fixed [16:56:03] <BBB> anyway [16:56:14] <BBB> I can probably look at other win64-related bugs as long as it's in yasm-code [16:56:23] <peloverde> all this win64 work makes me look forward to VLC for win64 [16:56:26] <BBB> I will not touch inline asm with a 20-foot pole [16:56:54] <mru> inline asm is where most of the problems are [16:57:00] <mru> missing clobber marks mostly [16:57:08] <BBB> dontcarewontfix [16:57:20] <BBB> I can rewrite it into yasm but apparently michael doesn't like that or so [16:57:24] <mru> rewrite in yasm is the proper solution [16:57:26] <BBB> or was the rewrite bad? [16:57:29] <BBB> (eli's) [16:57:50] <mru> the one today? [16:58:12] <mru> that added a function call [16:58:17] <BBB> oh [16:58:21] <mru> making it 2 cycles slowr in theory? [16:58:23] <mru> -? [16:58:28] <mru> +e [16:58:29] <BBB> so if I "manually" inline it by embedding the function inside it's ok? [16:58:40] <mru> uh? [16:59:27] <BBB> int func(a, b, c){func2(a, b, c, d, e);} eli rewrote func2, if I rewrite func with func2 inlined in it, it's ok? [16:59:45] <mru> no, there was no func2 before [17:00:04] * BBB will actually have to read the patch [17:03:41] <BBB> how do I mark a register as clobeered in inline asm? [17:03:45] <BBB> vp5/6 bug is easy [17:03:55] <BBB> once I know how to fix it ;) [17:03:58] <mru> what is the bug? [17:04:05] <peloverde> list it on the third colon [17:04:06] <BBB> doesn't mark xmm6/7 as clobbered [17:04:20] <mru> almost all of those bugs are easy in the same way [17:04:31] <BBB> good, let's mark them and fix it [17:04:33] <mru> the problem is when you get to the amd64-only xmm regs [17:04:47] <BBB> you mean xmm8-15? [17:04:51] <mru> I guess [17:04:57] <BBB> this one only uses xmm6/7 [17:04:59] <BBB> so this is easy [17:05:08] <BBB> peloverde: how? got an example for me to peek at? [17:05:09] <mru> then do it [17:05:26] <mru> asm ("code" : outputs : inputs : clobbers); [17:05:41] <mru> clobbers is a comma-separated list of strings [17:05:44] <mru> each string one reg [17:06:15] <BBB> "%xmm6", "%xmm7"? [17:06:23] <BBB> let's try [17:06:34] <peloverde> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/x86/idct_sse2_xvid.c;h=… [17:08:01] <BBB> what do I do if the same reg is used in two subsequent asm("..") calls? [17:08:19] <BBB> won't it push/pop before/after each, thus the value not being preserved in the second? [17:08:40] <peloverde> you aren't supposed to preserve register values across multiple asm calls [17:08:47] <peloverde> that's why I redid the imdct [17:08:50] <peloverde> in yasm [17:09:16] * BBB kills whoever wrote this pos [17:09:24] <BBB> ok, I'll rewrite it, it's not very long [17:09:28] <BBB> in fact it'll be smaller :-p [17:16:31] <BBB> VP6DSPContext good idea also? [17:16:39] <BBB> would remove more crap from dsputil [17:16:46] <BBB> crap_that_should_not_be_there [17:16:49] <mru> one thing at a time [17:16:57] <BBB> separate patches of course [17:17:00] <BBB> but is it a good idea? [17:17:08] <BBB> I mean, dude, I'm volunteering ;) [17:17:22] <mru> which function? [17:17:24] <BBB> it's just one function though [17:17:27] <BBB> vp6_filter_diag4 [17:17:34] <BBB> used only in vp6.c [17:17:35] <mru> if nothing else uses it, go for it [17:17:38] <BBB> k [17:18:04] <mru> put it in vp56dspcontext [17:18:19] <mru> no need for yet another one [17:18:26] <BBB> ah, ok [17:47:57] <CIA-11> ffmpeg: mru * r24909 /trunk/libavcodec/ (15 files in 4 dirs): Remove global mm_flags variable [17:48:52] <Dark_Shikari> \o/ [17:48:55] <Dark_Shikari> wait. what about emms? [17:49:03] <Dark_Shikari> what'd you do to solve that? [17:49:05] <mru> compile-time static [17:49:13] <peloverde> so much for all my compiled object code [17:49:21] <mru> huh? [17:50:22] <mru> I see no reason to carry around special support for the 3 non-mmx machines still in existance [17:50:45] <peloverde> dsputil .h just changed, means almost everything gets rebuilt... it was more of a joke than a complaint [17:50:46] <Dark_Shikari> inb4 distros supporting i386 complain [17:50:59] <mru> peloverde: oh, I see [17:51:21] * mru loves poking sticks in debian's eyes [17:51:42] <peloverde> poor siretart [17:51:57] <mru> didn't he say he was ok with this? [17:52:39] <peloverde> then I'm curious as to what his plan is [17:52:45] <kurosu> *famous last words* [17:53:17] <Dark_Shikari> peloverde: I don't think they support i386, at least not on ubuntu [17:53:35] <peloverde> what about debian? [17:54:00] <mru> good luck running ffmpeg on a 386 [17:54:59] <peloverde> I don't see why you couldn't run it on a pentium-sans-mmx [17:55:12] <mru> then you build with --disable-mmx [17:56:11] <J_Darnley> When you're done encoding with that, DNF will be oldskool [17:57:48] <CIA-11> ffmpeg: janne * r24910 /trunk/configure: configure: enable fast_cmov for 'atom' [18:06:53] <BBB> I wonder if HD H264 plays above or below 1fps on a pre-MMX x86 [18:07:01] <BBB> or VP8, for that matter :-p [18:07:18] <Dark_Shikari> you may have cache issues [18:07:26] <mru> I guess <1fps [18:07:29] <Dark_Shikari> though memory-cpu communication was faster back then [18:07:34] <Dark_Shikari> (relative to clock speed) [18:07:35] <mru> those machines were insanely slow [18:08:02] <kshishkov> what about your avr? [18:08:16] <peloverde> You know people always brink up how slow 1080p H.264 would play on those things but we watched low res divx videos just fine [18:08:36] <Dark_Shikari> no you didn't [18:08:47] <Dark_Shikari> back in the P1 days, you needed a PCI acceleration card for mpeg-2 [18:08:47] <ohsix> not without mmx anyways :D [18:08:53] <Dark_Shikari> remember those? [18:08:57] <BBB> haha [18:08:57] <mru> not on pre-mmx pentium [18:08:58] <mru> no way [18:09:02] <BBB> i had one of those [18:09:23] <BBB> there was even a linux driver [18:09:26] <BBB> DXR2 or DXR3 or so [18:09:34] <Dark_Shikari> in 1994? ;) [18:09:48] <BBB> later 90s [18:09:52] <BBB> but still 90s [18:10:19] <BBB> (the card, not the linux driver :-p) [18:11:36] <kshishkov> thank you all, you make me feel young [18:13:08] <peloverde> 352x288 MP43 at 25 fps + mp3 stereo 22050 Hz [18:14:14] <peloverde> After all these years it still looks pretty good [18:18:31] <kshishkov> VideoCDs FTW! [19:10:18] <peloverde> saintdev: I ran aacx under massif and don't see any leaks, my 285 frame file uses 40 MB [19:10:38] <saintdev> peloverde: oh i don't think there are any leaks [19:10:59] <saintdev> was just loading a 7minute file... [19:11:17] <peloverde> ok [19:11:46] <saintdev> just happened to notice my mem usage skyrocket [19:14:53] <siretart> peloverde: sorry, WHAT happened?! [19:15:47] <peloverde> siretart: emms() is now called if AV_MMX is present (i.e. it is no longer runtime detected) [19:15:57] <peloverde> s/AV_MMX/HAVE_MMX/ [19:16:20] <siretart> peloverde: does this have any effect on existing binaries? [19:16:49] <peloverde> binaries built from this point forward with MMX will not run on pre-MMX machines [19:16:50] <mru> no, only on ones compiled after the change [19:17:02] <mru> I'd love the ability to retroactively change compiled binaries [19:17:27] <siretart> oh, that's just an SHLIBS bump then IIUC, that's really no problem [19:18:05] <siretart> oh, does that mean that FFmpeg officially dropped support for non-MMX machines on x86? [19:18:22] <peloverde> does debian no longer support PPro? [19:18:23] <mru> no [19:18:32] <mru> --disable-mmx still works [19:18:43] <peloverde> yes but you can't build one binary for both [19:19:21] <siretart> again, that's also no problem, I have to compile several flavors anyways and let ld-linux.so pickup the best one based on hwcaps detection [19:19:39] <siretart> don't know what other distros are doing, though. [19:19:39] <peloverde> ok [19:19:56] <siretart> but make sure that this change is documented properly [19:20:06] <siretart> it will be important for the next release notes [19:20:19] <siretart> pretty please :-) [19:22:39] <siretart> hm. but that means that I really need to compile the base flavor with --disable-mmx [19:26:41] <Dark_Shikari> siretart: does debian support pre-i586? [19:26:44] <Dark_Shikari> I didn't think it did [19:27:10] <peloverde> PPro is i686 without MMX [19:27:11] <mru> debian supports clay tablets [19:27:27] <mru> in fact, they build it on an abacus [19:27:34] <mru> that's why all the packages are so old [20:09:41] <lu_zero> hyc: ping [20:12:46] <BBB> vp6 should work on win64 too now [20:12:52] <BBB> let's see if it really does (totally untested) [20:13:00] <BBB> now I wonder why fate-vp5 fails on fate [20:13:04] <BBB> er, win64 [20:26:54] <lu_zero> win64 is actually getting used by people? [20:27:10] <lu_zero> and more important mingw64 and wine are working? [20:31:18] <Compn> ____ is actually used by people ? [20:31:25] <Compn> and more important ____ and ____ are working? [20:31:36] <Compn> insert any odd os/compiler combo here ^ [20:31:59] <mru> soon beos will be the only one not on fate... [20:32:32] <Compn> http://i.imgur.com/I9sYr.jpg [20:32:34] * mru has both tru64 and irix machines standing around unusued... [20:44:33] * lu_zero could setup a kvm with haiku inside [20:44:59] * mru wouldn't bother [20:45:23] <mru> as far as we know, there is only one user of haiku anyway [20:46:10] <lu_zero> nah [20:46:14] <lu_zero> there is plenty [20:46:49] <lu_zero> haiku is getting functional and there are many people who aren't developing it [20:49:34] <thresh> poor souls [20:49:53] <CIA-11> ffmpeg: vitor * r24911 /trunk/tests/ (ref/fate/txd-pal8 ref/fate/txd-16bpp fate2.mak): Renderware TeXture Dictionary FATE test [20:54:02] <pJok> mru, that went fairly well... [20:54:18] <mru> the interview? [20:54:28] <pJok> yeah [20:54:45] <pJok> next step is a phone interview [20:55:08] <mru> what? you met them in person first, then phone interview? [20:55:48] <pJok> no, it was a recruitment company interview [20:55:53] <mru> ah [20:56:10] <pJok> just to sift out any unwanted applications [20:57:00] <pJok> but i think it went well, so the phone interview will hopefully be equally good [20:57:26] <pJok> since the person hirering is in london whilist the job is still in copenhagen [21:10:40] <lu_zero> o_O [21:25:00] <kierank> hehe using vlc at the chilean mine [21:47:49] <mru> saste: vf_scale crashes badly if avfilter_get_video_buffer() fails [21:48:01] <mru> and there's no way to error out of that function [21:48:03] <Dark_Shikari> mru: fun pdf of the day [21:48:05] <Dark_Shikari> http://www.intel.com/Assets/en_US/PDF/specupdate/323338.pdf [21:48:15] <Dark_Shikari> start on page 18 [21:48:50] <Dark_Shikari> some of these errata are amazing, as in, I'm shocked that the actions necessary to trigger the bug are even _valid_ [21:49:25] <Dark_Shikari> e.g. AAY7 is about how if you use FXSAVE (store float registers) on an address at the top of memory with less than 512 bits left as is necessary to store it [21:49:33] <Dark_Shikari> it'll only partially save the results, and won't wrap around to the low memory [21:57:42] <mru> processor errata are always obscure [21:58:40] <Dark_Shikari> some of them less so than others [21:58:56] <mru> the non-obscure ones are the scary ones [21:59:06] <Dark_Shikari> Yeah [21:59:18] <Dark_Shikari> Is that even standard btw? [21:59:24] <Dark_Shikari> to have a write of 4 bytes to 0xffffffff [21:59:30] <Dark_Shikari> intend to wrap around to 0x00000003 ? [21:59:41] <mru> on some CPUs, sure [21:59:43] <Dark_Shikari> i.e. is that by-design in most processors? [21:59:59] <mru> some don't support unaligned accesses, so they don't have to choose [22:00:12] <Dark_Shikari> true [22:01:57] <Dark_Shikari> heh, there are even some livelocks in those erratum [22:02:38] <twnqx> well, it's the reason for the good old a20 gate.. [22:02:59] <twnqx> (the wraparound on x86) [22:03:11] <Dark_Shikari> ? [22:03:31] <twnqx> remember the 286, and real mode? :P [22:03:40] <twnqx> with segment:offset addressing? [22:04:11] <Dark_Shikari> >_> [22:04:42] <twnqx> segments where always 64kbyte in size, but overlapping... and you had 20 address bits, so you could "use" a segment that would go from just below 1MB to the first few kB [22:05:08] <twnqx> to emulate that, 386+ had the gate a20 that would turn off the 20th adress line off until requested by software. [22:05:16] <twnqx> and it haunts us until today... [22:06:30] <mru> Dark_Shikari: on ARM any memory access that crosses the top of the address space is unpredictable [22:08:55] <Dark_Shikari> interesting [22:09:33] <mru> overflow in an address calculation is defined the obvious way [22:09:49] <Dark_Shikari> valid wraparound? [22:10:02] <mru> unsigned wraparound as you'd expect [22:10:22] <Dark_Shikari> yeah [22:10:37] <mru> accessing both sides with a single instruction isn't possible [22:10:56] <mru> be it an unaligned (half-) word access or a multiword access [22:12:48] <roxfan> http://www.win.tue.nl/~aeb/linux/kbd/A20.html [22:37:58] <BBB> ok what shall I port next? [22:38:38] <Dark_Shikari> port? [22:38:50] <saintdev> x264 -> vp8 [22:38:54] <Dark_Shikari> yes [22:38:54] <Dark_Shikari> that [22:38:59] <Dark_Shikari> get on with it, stop slacking =p [22:39:02] <Dark_Shikari> and ask for help if you need it [22:39:04] <Dark_Shikari> I'm not doing enough work [22:39:25] <BBB> ok, ok [22:39:36] <BBB> I have really been looking hard at understanding the boolcoder [22:39:44] <BBB> maybe I need a book [22:39:54] <Dark_Shikari> understanding? there's not much to understand [22:39:55] <BBB> it's purpose is to compress... but I don't see how it works [22:39:56] <Dark_Shikari> it's just like x264's [22:40:05] <Dark_Shikari> do I need to re-explain arithmetic coding? [22:40:08] <BBB> and x264's is totally clear and understandable to me :-p [22:40:13] <BBB> yes [22:40:42] <Dark_Shikari> I will explain via induction [22:41:00] <Dark_Shikari> I will explain the inductive step first [22:41:16] <Dark_Shikari> At the start of the inductive step, we have the following data: [22:41:32] <Dark_Shikari> 1) "low". This is a value from 0.0 to 1.0. (in reality, it's fixed point) [22:41:53] <Dark_Shikari> 2) "high". This is a value larger than low, and still <= 1.0. [22:42:08] <Dark_Shikari> 3) In some coders, "high" doesn't exist, and instead "range" is stored (the difference between low and high). [22:42:19] <Dark_Shikari> These two values together represent a range of values. [22:42:22] <Dark_Shikari> So, for example [22:42:24] <Dark_Shikari> 0.4 - 0.9 [22:42:30] <Dark_Shikari> That would be a low of 0.4, high of 0.9, range of 0.5. [22:42:31] <Dark_Shikari> Got it? [22:42:35] <BBB> yes [22:42:56] <Dark_Shikari> What we are doing is writing an infinite-precision fraction. [22:43:05] <Dark_Shikari> Suppose our range was in fact 0.6 - 0.9. [22:43:14] <Dark_Shikari> This means that we KNOW the next bit of our fraction is a 1. [22:43:16] <Dark_Shikari> Do you see why? [22:43:48] <BBB> uhm... no [22:43:56] <Dark_Shikari> Because we know that our fraction is larger than 0.5. [22:43:59] <Dark_Shikari> Therefore, the next bit must be 1. [22:44:09] <Dark_Shikari> Our fraction is somewhere between 0.6 and 0.9 (our range). [22:44:11] <BBB> oh, range, not high [22:44:12] <BBB> yes [22:44:16] <Dark_Shikari> Therefore, we know that we can "write out" a 1. [22:44:27] <Dark_Shikari> Writing out a 1 turns 0.6-0.9 into 0.2-0.8. [22:44:28] <Dark_Shikari> Do you see why? [22:45:29] <BBB> the 0.2 might be 0.6-low [22:45:35] <BBB> but I don't really get it [22:45:35] <Dark_Shikari> no, think about it [22:45:38] <Dark_Shikari> we are rescaling it [22:45:50] <Dark_Shikari> by writing out a 1, we are "magnifying" 0.5-1.0 into 0.0-1.0 [22:45:56] <Dark_Shikari> i.e. 0.5-1.0 becomes the new 0.0-1.0 [22:45:57] <Dark_Shikari> thus, [22:46:01] <Dark_Shikari> 0.6-0.9 becomes 0.2-0.8 [22:46:06] <Dark_Shikari> This is called renormalization [22:46:19] <Dark_Shikari> This codifies the number 1 rule of an arithmetic coder: [22:46:26] <Dark_Shikari> The range must cross 0.5. [22:46:37] <Dark_Shikari> When it does not, you write out bits until it does. [22:46:52] <Dark_Shikari> If high < 0.5, you write out a 0 and renormalize. [22:46:56] <Dark_Shikari> if low > 0.5, you write out a 1 and renormalize. [22:47:05] <Dark_Shikari> this is repeated until high > 0.5 > low. [22:47:20] <Dark_Shikari> what parts of this do you not understand? [22:47:26] <BBB> I think I get this [22:47:30] <Dark_Shikari> OK, now the second part [22:47:37] <Dark_Shikari> how does the range even happen in the first place [22:47:44] <Dark_Shikari> well, suppose we start our range at 0.0 - 1.0 (a nice initialization point) [22:47:55] <Dark_Shikari> now, suppose we are writing a bit with probability 30% [22:48:00] <Dark_Shikari> i.e. 30% chance it's 1, 70% chance it's 0 [22:48:14] <Dark_Shikari> "prob" in vp8 is a fix8 representation of this probability. [22:48:57] <Dark_Shikari> If the bit is a 0, our range becomes 0.0 - 0.7. [22:49:02] <Dark_Shikari> If the bit is a 1, our range becomes 0.7 - 1.0. [22:49:14] <Dark_Shikari> In other words, we split the range: one side of the range is "if the bit is a 0", the other side is "if the bit is a 1". [22:49:47] <Dark_Shikari> Notice how if the bit is a 0, no bit is immediately written to the output bitstream! [22:49:54] <Dark_Shikari> in this case, a bit of "0" cost us *LESS* than one bit. [22:50:07] <Dark_Shikari> and a bit of "1" cost us *MORE* than one bit, due to it taking up more than half of the range. [22:50:18] <Dark_Shikari> So, suppose our bit is in fact a 1. [22:50:20] <Dark_Shikari> 0.7 - 1.0 [22:50:22] <Dark_Shikari> This doesn't cross 0.5. [22:50:25] <Dark_Shikari> So we renormalize. [22:50:40] <Dark_Shikari> We write out the bit "1" and get a range of 0.4-1.0. [22:50:46] <Dark_Shikari> Now it crosses 0.5. [22:51:01] <Dark_Shikari> Now, suppose our next bit has probability 50%, and we write a "0" [22:51:08] <Dark_Shikari> "0" range: 0.4 - 0.7 [22:51:12] <Dark_Shikari> "1" range: 0.7 - 1.0 [22:51:26] <Dark_Shikari> so now our range is now 0.4 - 0.7 [22:51:36] <Dark_Shikari> But this time, it still crosses 0.5, so we don't renormalize, and we don't write anything to the bitstream. [22:51:53] <Dark_Shikari> Note the distinction between input bits (which are assigned probabilities) and output bits (which are written due to renormalization). [22:51:58] <Dark_Shikari> what don't you get so far? [22:52:21] <BBB> I think I get it [22:52:26] <Dark_Shikari> Now, some other things to note... [22:52:33] <Dark_Shikari> this is the GENERIC description of an arithcoder [22:52:37] <Dark_Shikari> all range coders and arithcoders work this way. [22:52:45] <Dark_Shikari> Some take shortcuts for speed, in terms of precision or whatnot. [22:52:51] <Dark_Shikari> Others may use lookup tables instead of multiplies for calculations. [22:53:00] <Dark_Shikari> Some are adaptive, and update their probabilities based on bits written. [22:53:16] <Dark_Shikari> Next, most good implementations of arithcoders work based on bytes, not bits, as you saw in the vp56 one. [22:53:48] <Dark_Shikari> In such an implementation, a renormalization becomes that branchless function in vp56.h [22:53:53] <Dark_Shikari> instead of being a while() loop [22:53:56] <Dark_Shikari> as I described above [22:53:59] <Dark_Shikari> e.g. renorm until it crosses 0.5 [22:54:48] <Dark_Shikari> By the way, a simple example of how bit costs work out [22:54:51] <BBB> so how does the writing work then? do we wait until 8 bit-probabilities have been written? or is it just a bitstream writer as before, but output is only written once every 8 output bits? [22:55:01] <Dark_Shikari> no, you just write a bit at a time [22:55:08] <Dark_Shikari> Or you can have a cache, etc [22:55:13] <BBB> ok, so writing is the same [22:55:16] <Dark_Shikari> in x264, we use a bytestream implementation I described above [22:55:21] <Dark_Shikari> well, mentioned, not described [22:55:24] <Dark_Shikari> Let me guide you through x264's. [22:55:36] <Dark_Shikari> x264's is slightly munged for performance reasons, but it's largely the same. [22:55:50] <Dark_Shikari> open common/cabac.c and turn to line 819 [22:55:52] <Dark_Shikari> and tell me when you're ready [22:56:11] <BBB> done [22:56:20] <Dark_Shikari> line 834 [22:56:27] <Dark_Shikari> range_lps is how much to adjust the range [22:56:32] <Dark_Shikari> e.g. in the case of 0.0 - 1.0 [22:56:36] <Dark_Shikari> and 30% probability [22:56:52] <Dark_Shikari> our range_lps would be 0.3 [22:57:08] <Dark_Shikari> e.g. if the bit is 0, we -= range_lps to get 0.0 - 0.7 [22:57:16] <Dark_Shikari> and if the bit is 1, we = range_lps to get 0.7 - 1.0 [22:57:24] <Dark_Shikari> since "range" is the distance between the two [22:57:28] <Dark_Shikari> (low is also set accordingly) [22:57:40] <Dark_Shikari> cabac_range_lps is a lookup table: h264 uses a LUT that's slightly approximate in order to avoid the multiply. [22:58:01] <Dark_Shikari> The i_state>>1 and &1 bits are just a reorganization we made to the state table for speed reasons. Ignore them. [22:58:02] <BBB> slightly approximate means...? [22:58:10] <Dark_Shikari> It's quantized [22:58:14] <Dark_Shikari> note the low [] of the table [22:58:18] <Dark_Shikari> it's [num states][4] [22:58:27] <Dark_Shikari> range_lps, in theory, should be different for every input range value. [22:58:38] <Dark_Shikari> But here it's quantized so there's only 4 possible values. [22:58:45] <Dark_Shikari> NB: "state" is the probability. [22:59:05] <Dark_Shikari> line 841: we update the probability based on the transition table and bit (whether it's 0 or 1). [22:59:06] <saste> mru: why are you saying that? are you actually having crashes in vf_scale.c? [22:59:09] <Dark_Shikari> line 842: call renorm. [22:59:27] <saste> mru: or is it just an API issue? [22:59:27] <Dark_Shikari> line 821: calculate how much to renorm. The number that results from this LUT is _equivalent_ to the number of times a bit-based implementation would need to renorm. [22:59:35] <Dark_Shikari> so if this is "3", we need to renorm 3 times. [22:59:45] <Dark_Shikari> The <<, <<, and + perform the renorm step. [22:59:55] <Dark_Shikari> finally, putbyte is run if we have at least one byte to write out. [23:00:07] <Dark_Shikari> any issues so far? [23:00:22] <BBB> Ill have to re-read this tonight but makes sense so far [23:00:32] <Dark_Shikari> ok, now to explain putbyte [23:00:34] <Dark_Shikari> this is a little bit tricky [23:00:46] <Dark_Shikari> NB: queue is offset by 8, same as in vp56 [23:00:50] <Dark_Shikari> in order to make the if() faster [23:00:53] <Dark_Shikari> i.e. "0" is really 8 [23:00:56] <Dark_Shikari> and "-8" is really 0 [23:01:08] <Dark_Shikari> line 789: if we have a byte to write out... [23:01:23] <Dark_Shikari> line 791: get the data to write out (the high bits of "low") [23:01:43] <Dark_Shikari> 792: mask off the bits we're writing out, since, well, we're writing them out, so they should go away. [23:01:50] <Dark_Shikari> 793: update queue (number of bits queued) [23:01:58] <Dark_Shikari> 795: Here is the tricky part. [23:02:17] <Dark_Shikari> It's quite possible to keep writing bits, and writing bits, until your range looks like ths: [23:02:20] <Dark_Shikari> *this: [23:02:22] <Dark_Shikari> 0.49 - 0.51 [23:02:25] <Dark_Shikari> And keep writing and writing. [23:02:28] <Dark_Shikari> 0.49999-0.500001 [23:02:38] <Dark_Shikari> and so forth. [23:02:43] <Dark_Shikari> Since it crosses 0.5, we can't renorm. [23:03:04] <mru> saste: yes, it crashed there [23:03:07] <Dark_Shikari> This is handled by bytes_outstanding. [23:03:16] <Dark_Shikari> If we are in that situation, as defined by out&0xff == 0xff [23:03:21] <Dark_Shikari> it increments bytes outstanding instead. [23:03:32] <mru> saste: simulate an allocation failure and see for yourself [23:03:33] <Dark_Shikari> And later, when it's time to actually write, it can handle that. [23:03:44] <Dark_Shikari> got it so far? [23:04:02] <mru> fixing it seems to involve changing the entire damn api [23:04:39] <BBB> no... so why do you need i_bytes_oustanding? [23:05:25] <Dark_Shikari> because we can accumulate an arbitrary number of bytes in that situation [23:05:42] <saintdev> you get 'stuck' in a place where low and high are just on either side of 0.5 [23:05:43] <Dark_Shikari> pengvado can probably explain it better [23:05:53] <Dark_Shikari> so basically, the thing is [23:06:06] <BBB> so you mean "it's not actually writing bits to the output", so a reader wouldn't know what to do with it? [23:06:16] <Dark_Shikari> BBB: it will write them when it comes time to write something [23:06:19] <Dark_Shikari> e.g. they're "queued" bytes [23:06:27] <Dark_Shikari> Then, as you can see in 807 [23:06:32] <Dark_Shikari> if it comes time to write a byte that isn't 0xff [23:06:39] <Dark_Shikari> it will write out all the queued bytes. [23:07:01] <Dark_Shikari> pengvado can explain this better. [23:07:05] <Dark_Shikari> afk [23:08:06] <BBB> will need to re-read it, but I think I sort of get it [23:08:15] <BBB> I'll re-read vpx boolcoder also [23:08:19] <BBB> maybe now it'll make sense [23:11:01] <BBB> do we really need libavsequencer versioning symbols etc.? [23:11:15] <mru> imo we don't need it at all [23:11:21] <BBB> I'm not gonna bring it up again but it seems silly for something that we all agree probably should be in lavc for the time being, if anywhere at all [23:11:28] <mru> certainly not without a _thorough_ review [23:11:30] <BBB> it should NOT have a public API, esp. not now [23:11:46] <mru> it shouldn't be in svn now [23:11:56] <BBB> I think they're gonna commit it ;) [23:12:05] <mru> can we stop them? [23:12:10] <mru> well, I can... [23:12:26] <BBB> saste: can you hold off committing lavseq until we've seen the actual real patches? [23:13:23] <mru> gah, he ran away [23:19:57] <BBB> thanks for the email [23:19:59] <BBB> gonna go home [23:20:01] * BBB bbl

1 0

IRC log for 2010-08-23
by irc＠mansr.com 24 Aug '10

24 Aug '10

[00:30:08] <BBB> how do I create win64 binaries? </stupid question probably> [00:35:42] <Dark_Shikari> with mingw64 [02:42:12] <CIA-11> ffmpeg: rbultje * r24871 /trunk/libavcodec/x86/vp8dsp.asm: Fix segfaults in VP8 SIMD code on Win64 (and FATE/win64 failures). [02:55:21] <lu_zero> BBB: what was the issue? [02:55:43] <BBB> using a native-size register instead of a 32-bit size register [02:55:47] <BBB> it's always something trivial [02:56:19] <BBB> the problem is that a function prototype of (uint8_t *dst, int stride, uint8_t *src, int src_stride, int h); doesn't guarantee 0-padding of the int arguments [02:56:27] <BBB> so on the stack, the upper 32bits may be crap [02:56:44] <BBB> dec <reg> then takes the crap into account [02:56:46] <lu_zero> O_o? [02:58:43] * lu_zero doesn't understand the solution [02:58:58] <BBB> r4=native size [02:59:10] <BBB> r4d makes it zero-pad the upper 32 bit and read only the lower 32 bits [02:59:32] <BBB> so dec 1+(1<<32) is zero [02:59:40] <lu_zero> ... [02:59:42] <BBB> dec r4 becomes 1<<32 then [02:59:45] <BBB> dec r4d becomes 0 [02:59:56] <BBB> because it ignores the higher 32 bits [03:00:33] <lu_zero> astrange: may I troll about that as well =) ? [03:00:41] <lu_zero> wonderful [03:01:05] <BBB> lol :) [03:01:11] <BBB> 32 vs. 64 bits is tricky [03:01:15] <BBB> most of these issues are trivial [03:01:27] <BBB> it's like programming a shell script that works on both linux and windows [03:01:34] <BBB> or a source file that compiles on both msvc++ and gcc [03:01:37] <BBB> it's not difficult [03:01:39] <BBB> it's tricky [03:01:42] <lu_zero> Dark_Shikari: where is the magic pixie dust (TM) accounting for it? =P [03:01:45] <BBB> there's twenty ways to do it in valid C [03:01:49] <BBB> there's 10 accepted by gcc [03:01:54] <BBB> another 5 by msvc++ [03:01:59] <BBB> and only 2 accepted by both [03:02:05] <BBB> same here [03:02:18] <BBB> making the argument type long instead of int would also work, I think [03:02:32] <lu_zero> BBB: that's fun because of the small troll-oriented discussion about inline asm vs full asm vs intrinsics [03:02:35] <BBB> then the argument type is native-size instead of 32bits sizs [03:02:47] <BBB> I know, I read you guys trolling :-p [03:03:02] <lu_zero> yawn [03:03:08] <lu_zero> and it's already morning =_= [03:03:15] * BBB goes to bed in a little [03:03:21] <BBB> I was about to say, shouldn't you be asleep now? [03:03:27] <BBB> you're in inverted timemode [03:03:44] <lu_zero> I overslept a bit so I woke up early [03:04:35] * lu_zero wonders if he should troll mesa as well... [03:04:46] <BBB> yes ye syes [03:04:48] <BBB> trolling is fun [03:05:03] <lu_zero> it's fun when you got a large chunk of C code replaced with a larger chunk of c++ code [03:05:17] <lu_zero> and, wonder, not even es2gears works [03:05:35] <lu_zero> (that to keep the C++ is always broken myth alive) [03:06:15] <lu_zero> (in that case the glgs compiler) [03:10:13] <BBB> I think the inline asm vs intrinsics vs yasm flamewar was better [03:10:18] <BBB> please keep trolling on that one [03:10:22] <BBB> it gave me a good laugh :-p [03:11:06] * BBB sleep now [03:11:09] <BBB> see you tomorrow :) [04:11:02] <xxthink> Questions on the audio frame size calculation in ffmpeg [04:11:13] <xxthink> frame_size = (frame_size * 144000) / sample_rate; [04:12:09] <xxthink> this is the calculation method in ff_mpegaudio_decode_header [04:12:26] <xxthink> what does 144000 stands for? [04:12:43] <xxthink> is the sample size of an audio frame is 144? [04:25:43] <_av500_> no [04:27:36] <_av500_> 1152s/frame * 1000/8 [04:28:22] <_av500_> /8 because you go from bytes to bits/s [04:28:40] <xxthink> thank u!!! [04:30:18] <xxthink> but this should be the average frame size [04:33:03] <xxthink> is it right? [04:38:17] <_av500_> framesize for a givem bitrate [04:38:36] <_av500_> in layer 3 it is average [04:38:49] <_av500_> as bitrate can change per frame [04:38:54] <_av500_> and there is bit bucket as well [04:46:39] <CIA-11> ffmpeg: reimar * r24872 /trunk/tests/ (ref/fate/truemotion1-15 ref/fate/truemotion1-24 fate.mak): Add truemotion1 tests. [05:00:11] <lu_zero> god morgon [05:03:24] <_av500_> gm [05:38:07] <saintdev> interesting, the lame psymodel 0s the scalefactors greater than 39 [05:38:28] <Dark_Shikari> higher --> lower quality? [05:38:52] <Dark_Shikari> i.e. any band with too high a scalefactor gets zeroed? [05:39:39] <saintdev> Dark_Shikari: high scalefactors apply to higher frequencies [05:40:16] <Dark_Shikari> so it's a lowpass [05:40:30] <saintdev> in effect, yes [05:42:01] <saintd3v> so what frequency does that translate to... [05:42:09] <Dark_Shikari> it's a dynamic lowpass [05:42:15] <Dark_Shikari> which everyone constantly says not to do [05:42:36] <Dark_Shikari> theory: it's intended that this lowpass NOT lowpass any further than the preprocessing lowpass did. [05:42:59] <Dark_Shikari> and instead it's intended to get rid of any stray HFs that ended up in because of the imperfectness of the DCT [05:43:12] <Dark_Shikari> e.g. since a "lowpass in the DCT" doesn't match the concept of a "proper lowpass" [05:43:17] <saintd3v> afaik lame doesn't do any preprocessing, but i've never looked into that [05:43:26] <Dark_Shikari> o.0 [05:43:31] <Dark_Shikari> what about the frequency cutoff then? [05:43:33] <Dark_Shikari> I know it has one [05:43:58] <saintd3v> yeah, guess i'll have to look into that [05:51:15] <saintd3v> wholly possible i've gotten something wrong, also [05:51:44] <saintd3v> i'be been over everything a couple of times, and can't find any reason it would be wrong [05:55:47] <kshishkov> saintd3v: even I remember phrase "applying polyphase filter ..." appearing when running LAME [05:57:58] <saintdev> kshishkov: wouldn't that be the filter that is part of the transform process, along with the mdct? [05:59:34] <pJok> god morgon, kshishkov [06:00:27] <thresh> хмутро [06:02:32] <pJok> twolame/toolame has psymodels afair [06:02:40] <pJok> but those are for layer II audio [06:03:20] <saintdev> i wonder how good they were? [06:03:28] * saintdev adds them to the list to look into [06:04:07] <pJok> i dont know how good they are, i just noticed when i had to actually get something to make better layer II audio than ffmpeg could spit out ;) [06:04:19] <pJok> better as in predict peak levels [06:04:25] <kshishkov> saintdev: Gabriel once told me LAME filters out high frequencies before transform [06:05:31] <saintdev> understandable [06:05:31] <pJok> though, the patch i have for ffmpeg to actually deliver on predictable peak levels is very ugly [06:05:47] <saintdev> pJok: use the psymodel! [06:06:27] <pJok> afair, the patch i have use the input audio level and lowers the output to the input level [06:06:39] <pJok> uses* [06:07:05] <pJok> works a treat, before that patch, i could never deliver a perfect peak for the tv stations, after that patch, its spot on every time [07:21:14] <KotH> morge [07:37:45] <kshishkov> s/morge/god morgon/ [07:38:19] <av500> s/god morgon/guten morgen/ [07:38:42] <av500> kshishkov: btw, I live in part of city called Eberstadt :) [07:40:21] <pJok> av500, servus! [07:44:26] * kshishkov looks at http://de.wikipedia.org/wiki/Darmstadt-Eberstadt#Pers.C3.B6nlichkeiten , sees no Vladimir [07:44:47] <av500> kshishkov: its wikipedia, edit it.... [07:45:21] <av500> ukranian IP will seem less supicious.... [07:45:23] <av500> +s [07:45:43] <av500> I can add you to Karlsruhe.... [07:47:53] <kshishkov> no, thanks. I prefer to leave as few traces as possible [07:48:50] <av500> in german wikipedia, its easy, it will have deleted itself completely in a few years due to non-relevance [08:03:01] <KotH> kshishkov: that's why you're in a publicly logged irc channel? [08:03:03] <KotH> hoi DonDiego [08:03:11] <KotH> DonDiego: back in good old germany? [08:05:29] <DonDiego> only until tomorrow.. [08:05:57] <KotH> and then? back on the road again? [08:17:05] <siretart> morning [08:17:30] <kshishkov> KotH: well, at least I've never publicly disclosed my address [08:17:50] <kshishkov> or phone number [08:18:04] <KotH> well.. i had to [08:18:27] <KotH> but then, people are still unable to find it anyways, although it's infront of their eyes [08:19:39] <kshishkov> yes, majority of people are idiots or try hard to become one [09:51:39] <atmos4> hi [09:52:28] <atmos4> I'm looking for a quick hack to get ffmpeg to skip every second input frame on the demuxer level, because I have a proprietary security video, that stores multiple camera frames interleaved as h264-es [09:52:41] <atmos4> so the decoder uses the wrong frames for reference [09:52:53] <atmos4> any idea where I should look to hack this? [11:07:00] <DonDiego> atmos4: hi, long time no see... [11:07:24] <atmos4> hi Diego :-) [11:31:45] <mru> am I the only one who finds these "insightful" blog posts titled "Why $foo" annoying? [11:31:59] <_av500_> for which $foo? [11:32:06] <janneg> all [11:32:08] <mru> one I just came across: Why Americans cannot enjoy holidays [11:32:12] <_av500_> ah [11:32:57] <kshishkov> mru: you're not alone. But I just ignore such blogs wholesale [11:33:06] <mru> I ignore them too [11:33:09] <atmos4> just as useful as the 100 best/most awesome $something posts [11:33:11] <mru> but I see the titles in various lists [11:33:18] * elenril goes to write "why cannot mru enjoy insightful blagposts" [11:35:11] * kshishkov refreains from pointing out to elenril that nobody here is likely to read his blog, including elenril himself [11:35:34] <mru> maybe if he wrote a trope about it [11:36:16] <elenril> kshishkov: that wouldn't be a nice thing to say [11:36:24] <elenril> it's good you didn't [11:36:29] <kshishkov> of course [11:37:01] <_av500_> elenril: just write about trains and boars and he will read it!!! [11:37:05] * kshishkov refrains from adding "especially if tvtropes is your blog" [11:37:43] <kshishkov> _av500_: Czech locos were the best Soviet ones. [11:37:59] <elenril> btw are there any tools for editing DLL relocation tables? [11:38:04] <atmos4> The 100 most awesome photos of boars and trains [11:38:12] * elenril inb4 dd [11:38:13] <kshishkov> _av500_: and in Beograde you had Tatra trams [11:38:37] <kshishkov> atmos4: for the latter, it's all in www.jarnvag.net [11:38:42] <kierank> elenril: lordpe or whatever it's called [11:38:58] * atmos4 wonders why find . -size 893 doesn't work, or find disagrees about filesize with ls =) [11:39:21] <kshishkov> atmos4: it may be in blocks, man find [11:39:33] <mru> try 893b [11:39:36] <atmos4> yea, but 1024 doesn't work either [11:39:48] <kshishkov> block size may be 4k [11:39:49] <atmos4> b is no allowed [11:39:51] <elenril> kierank: thanks, will try [11:39:56] <atmos4> if no char ia appended it's bytes [11:39:56] <mru> block size is probably 512b [11:40:02] <atmos4> yea it is [11:40:27] <mru> my man page says 512-byte blocks w/o suffix [11:40:32] <mru> c for bytes [11:40:39] <atmos4> oh =) [11:40:43] <atmos4> yea -size 2 works =) [11:40:49] <mru> and b for blocks [11:41:28] * kshishkov enjoys looking at http://www.jarnvag.net/images/bild/lokguide/Rc61370Malmo2005.jpg [11:43:13] <KotH> kshishkov: what's special about it? [11:43:38] <kshishkov> KotH: sentimental value. It's one of the best Swedish locomotives after all [11:45:35] <kshishkov> also I'd like to add that Nattåg was the only train where I could sleep with comfort [11:45:49] * KotH wonders whether there is a swedish equivalent of a weaboo [11:46:16] <elenril> lol [11:46:32] <kshishkov> KotH, not all of us are Turks loving Japan, you know [11:47:24] <CIA-11> ffmpeg: bindhammer * r24873 /trunk/libavcodec/ (a64enc.h a64tables.h a64multienc.c): Initial version of the a64 (multicolor charset) codec [11:47:26] <CIA-11> ffmpeg: vitor * r24874 /trunk/tests/ (ref/fate/wmv8-drm fate2.mak): Add FATE test for WMV8 DRM [11:48:03] * kshishkov waits for ref/fate/mp4-itunes-drm test [11:48:38] <CIA-11> ffmpeg: bindhammer * r24875 /trunk/libavformat/a64.c: Corresponding muxer for the a64 codec [11:48:42] <KotH> kshishkov: yes, some of us are swedophile ukranians living in germany ;) [11:48:45] <_av500_> kshishkov: well, i guess i could mentor a M$ DRM gsoc :) [11:49:27] * mru curses sigma designs [11:49:39] <CIA-11> ffmpeg: bindhammer * r24876 /trunk/doc/general.texi: documentation added for the a64 codec [11:49:47] <kshishkov> mru: ask skal for better sigma-oriented curses [11:49:49] <KotH> mru: with a double barel? [11:49:57] <mru> KotH: I'd love to [11:50:40] <mru> latest kernel I can get is 2.6.22.19 [11:50:47] <_av500_> so? [11:50:55] <_av500_> its good one :) [11:51:13] <mru> ethernet driver is flaky at 1Gbps [11:51:22] <mru> must insert 100Mbps switch [11:51:33] <mru> then nfs over tcp is broken [11:51:49] <mru> and the chip overheats easily [11:51:52] <CIA-11> ffmpeg: bindhammer * r24877 /trunk/libavcodec/avcodec.h: added codec-ids for the a64 codec [11:53:00] <mru> and there's still something wrong that I haven't figured out [11:53:28] <CIA-11> ffmpeg: bindhammer * r24878 /trunk/ (4 files in 2 dirs): enabling codec and muxer by registering it in allcodec.c and allformat.c and adding files to the build-system [11:53:29] <kshishkov> besides the fact such product exists at all? [11:54:10] <mru> it's randomly failing tests [11:54:17] <CIA-11> ffmpeg: lucabe * r24879 /trunk/libavformat/rtpdec.c: Do not use the server SSRC as client SSRC in the RTP demuxer [11:54:43] <kshishkov> mru: sorry, are you talking about Sigma Designs porduct or SheevaPlug? [11:54:51] <mru> sigma now [11:54:58] <mru> I managed to stabilise the sheeva [11:55:27] <mru> my stripping it down and placing it by a fan [11:55:44] <mru> I propped it up behind the atx psu that's powering it [11:55:51] <mru> airflow there is rather cool [11:55:53] <KotH> lol [11:56:11] <KotH> what's the point in having a fan-less thing that needs constant airflow of a fan? [11:56:43] <mru> the sigma board has no fan either [11:56:47] <mru> but it has two fan headers [11:56:49] <mru> telling... [11:56:57] <mru> but not enough power for more than one fan [11:57:44] <kshishkov> KotH: what was the name of your box with HDD and wifi card not fitting inside? [11:58:15] <mru> KotH: now imagine the sheeva boxed up in a plastic case with scarcely a hole together with an overheating psu [11:59:12] <mru> in defence of the gdium, at least it remains stable even though it's close to melting [12:01:49] <KotH> kshishkov: soekris net5501 [12:02:12] <KotH> kshishkov: and they got a nice mail from me, saying that their design is utter BS [12:02:20] <KotH> kshishkov: though, for some reason, i didnt get a reply yet [12:02:43] <kshishkov> I wonder why [12:05:39] <KotH> interestingly, pcengines was quite interested in my complaints about the net5501 :) [12:17:56] <CIA-11> ffmpeg: vitor * r24880 /trunk/ (Makefile tests/fate/mp3.mak): MP3 float decoder FATE tests [12:26:32] <peloverde> oh no 3DNow! has been deprecated! [12:27:11] <lu_zero> how so? [12:27:36] <peloverde> http://blogs.amd.com/developer/2010/08/18/3dnow-deprecated/ [12:28:18] <CIA-11> ffmpeg: vitor * r24881 /trunk/tests/fate/mp3.mak: fix fate breakage, 10l to me (too much copy and pasting) [12:33:43] <lu_zero> fun [12:37:09] <kshishkov> who cares (and whose name is not Diego)? [12:37:33] <mru> why would the diegos care? [12:38:00] <peloverde> I care, which other vector instruction set requires you to shout its name [12:38:36] <peloverde> maybe intel can add an "!" to SSSSSSE12 [12:40:39] <merbzt1> so my geode wont get any more support from amd ? [12:40:44] <merbzt1> boho [12:40:57] <merbzt1> I'll cry me a river [12:41:01] * mru has two of those [12:41:05] <mru> geodes [12:41:06] <mru> not rivers [12:41:48] * mru worked on them together with merbzt1's boss [12:42:25] <merbzt1> Ic [12:42:36] <twnqx> peloverde: they should add "SCHEI" in front. [12:44:49] <peloverde> Can someone explain LIBAVCODEC_VERSION_MICRO to me? it seems to reset inconsistently [12:45:11] <mru> what makes you believe there _is_ an explanation? [12:46:31] <kshishkov> merbzt1: you have a suspicious IP. [12:46:55] <kshishkov> mru: one Diego is known to have outdated AMD chip [12:47:03] <kshishkov> mru: and caring for it [12:47:28] <mru> they're not going to remove the instructions from existing chips [12:47:32] <janneg> kshishkov: amd is not going to remove 3dnow! from old chips [12:47:51] <kshishkov> peloverde: any change that significantly changes codec behaviour should bump micro, bumping mini or macro resets it [12:47:56] <twnqx> btw, could someone apply the bitrate sanity checking patch, please? [12:48:09] <mru> twnqx: you're doing it wrong [12:48:17] <kshishkov> janneg: stupid people, haven't thought about kill switch [12:48:25] <mru> you need to badger for a _review_ before you can bitch about having it applied [12:48:27] <peloverde> kshishkov: then why do minor bumps not reset it half the time? [12:48:28] <twnqx> mru: mailing list was last pinged last week [12:48:33] <kshishkov> peloverde: though people often forget about it so it's rarely bumped [12:48:42] <janneg> that would be even scarier than the planned and canceled in flights avition firmware for the dreamliner [12:48:57] <peloverde> Can we add a hook to make it suck less? [12:49:18] <mru> add a hook to the dreamliner? [12:49:32] <mru> to stop it falling out of the sky? [12:49:33] <kshishkov> peloverde: hook can't decide whether it's important or not [12:49:59] <kshishkov> mru: that can be achieved with M$ Windows, plane will just randomly hang mid-air [12:50:07] <peloverde> it bothers me quite a bit but not for any particularly good reason [12:50:10] <janneg> http://news.infracritical.com/pipermail/scadasec/2010-August/001701.html [12:50:11] <twnqx> kshishkov: hook can reset micro if minor is bumped? [12:50:22] <merbzt1> kshishkov: what's the problem with my IP ? [12:51:29] <kshishkov> merbzt1: it belongs to a company that tried to hire me (though too late :( [12:52:07] <kshishkov> twnqx: well, it depends whether that hook is alowed to modify SVN repo in that way [12:52:37] <mru> I will not have anything automatically change the repo [12:53:24] <merbzt1> kshishkov: well they did hire me [12:53:26] <kshishkov> it may send nag mail to cvslog [12:53:32] <lu_zero> I'd rather have a river [12:53:40] <lu_zero> (belated) [12:54:01] <kshishkov> merbzt1: I'd rather work in Solna than in Karlsruhe too [12:54:04] <peloverde> I'm not saying use a hook to rewrite the commit, i'm saying use it to reject the commit [12:54:14] <mru> solna is a boring suburb [12:54:30] <kshishkov> merbzt1: though it's not bad here despite not being Sweden [12:54:47] <mru> sweden isn't nearly as great as you seem to believe [12:55:10] <kshishkov> it's not great but it seems to fit me best [12:55:31] <atmos4> anyone here knows the h.264 decoder and elementary stream demuxer code? [12:56:32] <atmos4> I'd like to get ffmpeg to skip every other frame without feeding it to the decoder, because I have a h264 es stream that contain two video streams interleaved [12:57:50] <merbzt1> atmos4: maybe look at the parser and see if that makes any sense [13:01:54] <atmos4> yea, but which demuxer handles elementary streams? [13:06:36] <atmos4> hmm, probably raw.c [13:09:13] <peloverde> why did aac turn red on freebsd/clang? [13:09:31] <mru> peloverde: typo by vitor [13:09:34] <mru> already fixed [13:09:38] <peloverde> ahh [13:20:42] <CIA-11> ffmpeg: bindhammer * r24882 /trunk/libavcodec/avcodec.h: removed an unnecessary blank line [13:24:35] <CIA-11> ffmpeg: bindhammer * r24883 /trunk/Changelog: Adding of a64-codec: there were changes to be documented in changelog [14:05:43] <atmos4> KotH: btw. got the video to decode, if not quite correct by hacking the h264.c source [14:06:13] <atmos4> ref frame handling is not quite correct, so thre are distortions on camera switch [14:47:56] <CIA-11> ffmpeg: vitor * r24884 /trunk/ (ffmpeg.c tests/fate/mp3.mak): [14:47:57] <CIA-11> ffmpeg: Make "-fs ss" mean "make output file of size equals or less than ss" [14:47:57] <CIA-11> ffmpeg: instead of current "make output file of size less than ss". [14:47:57] <CIA-11> ffmpeg: Also use it to make MP3 tests more readable (using -fs xxx where xxx is [14:47:57] <CIA-11> ffmpeg: the requested output size, not something slightly lower). [14:50:06] <peloverde> reddit logic: "did anybody write any code that uses 3DNow?" / "I would hope not, specially since AMD came out with the K10 which has a 128-bit FPU" [15:01:22] <atmos4> :-) [15:01:37] <atmos4> they did however abandon 3dnow in the new chips [15:01:56] <atmos4> which doesn't really matter because they aslo support sse [15:01:57] * kshishkov would rather apply Russian traditional weapon on AMD, Intel and x86[_64] in general [15:02:10] <atmos4> :-) [15:04:08] <atmos4> Dark_Shikari: are you around? [15:04:52] <twnqx> tzar bomba? [15:06:05] <Dark_Shikari> yes [15:06:40] <thresh> kshishkov: ice cold weather? [15:06:55] <thresh> or kalashnikov [15:07:06] <_av500_> wooden club? [15:07:31] <thresh> nano-wooden nano-club, then. [15:08:41] <mru> shovel [15:09:01] <_av500_> right [15:09:16] <atmos4> Dark_Shikari: could you take a look at a video? [15:09:46] <atmos4> I've got a h264-es stream form a security cam that doesn't decode correctly, and KoTH told me to ask you about it [15:10:15] <atmos4> the es stream probably contains two different videstreams interleaved, but I'm not sure about it [15:10:59] <Dark_Shikari> o.0 [15:11:42] <atmos4> with a hack in h264.c I got it to partially decode, it seems two camera views are decoded while the other two only decode the i-frames [15:11:50] <Dark_Shikari> MVC? [15:12:16] <atmos4> without the hack I only got grey garbadge with the occasional i-frame which are decoded correctly [15:13:14] <atmos4> the videos were created by alogics dvr, but I couldn't find any playback sw [15:13:54] <atmos4> for each video there is a filename.avd which contains video data and a .avh which contains metadata [15:14:15] <kshishkov> thresh: вообще-то у вас главный по этому вопросу Нанотолий Чубайс, не правда ли? [15:14:21] <atmos4> Dark_Shikari: should I send you a small clip? [15:15:12] <thresh> kshishkov: он самый. [15:15:19] <Dark_Shikari> if you want, but if it's some weird MVC shit I doubt there's much I can do [15:16:02] <atmos4> the hack I used to get it to somewhat decode was in h264.c after the error "Frame num gap" I let it always return -1 [15:16:13] <kshishkov> thresh: рыжий-рыжий, конопатый, убил дедушку... чем? [15:16:51] <thresh> kshishkov: нанолопатой, в духе времени. [15:17:17] <kshishkov> thresh: вот-вот [15:18:02] <atmos4> Dark_Shikari: ok sending by dcc or should I upload? [15:20:45] <Dark_Shikari> upload [15:28:07] <atmos4> ok, sent you a msg with the link [15:29:27] <atmos4> Dark_Shikari: isn't MVC only used for 3D Video? [15:29:38] <Dark_Shikari> no [15:29:44] <Dark_Shikari> MVC can be used for any situation where you have multiple view [15:29:47] <Dark_Shikari> like multiple cameras [15:30:01] <atmos4> yea the video containt 4 cameras [15:31:55] <Dark_Shikari> looks like it's just interleaved and you need to deinterleave it before playback [15:32:00] <Dark_Shikari> nothing to do with the h264 stream, and not ffmpeg's job [15:32:42] <CIA-11> ffmpeg: benoit * r24885 /trunk/libavutil/common.h: Add missing parentheses to AV_NE macro. [15:33:49] <atmos4> Dark_Shikari: so it's 2 streams interleaved so it'S like A1,B1,A2,B2 in the stream? [15:35:23] <Dark_Shikari> I have no idea [15:35:27] <Dark_Shikari> It might be AAAABBBB... [15:36:17] <atmos4> I had the idea of skipping every other frame in the demuxer before feeding video to the codec [15:36:34] <atmos4> but I couldn't quite figure out where in the code to do that [15:37:52] <_av500_> atmos4: why not read the spec and drop the right frames? [15:38:03] <mru> :effort: [15:38:04] <atmos4> which spec? =) [15:38:13] <_av500_> mru: right [15:39:00] <atmos4> _av500_: you mean the h.264 specs? [15:39:46] <CIA-11> ffmpeg: mru * r24886 /trunk/libavformat/asfcrypt.c: asfcrypt: fix unaligned read in ff_asfcrypt_dec() [15:40:07] <_av500_> atmos4: err, yes [15:40:15] <atmos4> I don't have a spec for the .avd/.avh fileformat used by the cam, it's prorietary [15:41:15] <atmos4> I tried serching for the frame header 00 00 01 00, but no luck [15:41:29] <mru> that's not a frame header [15:41:38] <atmos4> well pciture header [15:41:42] <mru> not that either [15:41:53] <atmos4> then what'S the sequence for frame header? =) [15:42:03] <mru> why don't you read the spec and find out? [15:42:09] <_av500_> :effort: [15:42:16] <atmos4> well if you can point me to which of the 10 or so pdfs =) [15:42:23] <mru> the h264 one of course [15:42:25] <mru> there is only one [15:42:46] <atmos4> hmm KoTH send me a bund of pdfs for h.264 [15:43:02] <mru> why did you get them from KotH and not from the ITU? [15:43:20] <atmos4> because itu probably want's money for it [15:43:27] <mru> they don't [15:43:45] <atmos4> hmm thought the final h.264 spec wasn't public [15:44:44] <mru> http://www.itu.int/rec/T-REC-H.264-201003-I [15:45:08] <atmos4> thx [15:45:21] <BBB> Dark_Shikari: don't you have win64? [15:45:26] <Dark_Shikari> no [15:45:29] <Dark_Shikari> well yes but I don't have mingw [15:45:36] <Dark_Shikari> cygwin is win32 only [15:45:44] <BBB> can you install mingw and go fix the remaining 2 win64 issues in vp8's asm? [15:45:53] <BBB> it's probably somewhere subtle in the bilin code [15:46:00] <BBB> 1 bilin test passes, 2 fail [15:46:49] <atmos4> before I find what IO'm looking for in that PDF I'm quicker understanding the source [15:47:23] <BBB> it doesn't output all frames for test vector 3 and 7 [15:47:27] <BBB> I have no idea why [15:47:38] <BBB> ramiro said it worked with --disable-asm [15:49:20] <Dark_Shikari> I dunno [15:49:22] <Dark_Shikari> you should be able to do it [15:50:01] <BBB> right, because I have very convenient access to a win64 box and you don't [15:52:16] <CIA-11> ffmpeg: alexc * r24887 /trunk/libavcodec/x86/ (fft_3dn2.c fft_sse.c): [15:52:16] <CIA-11> ffmpeg: imdct/x86: Use "s->mdct_size" instead of "1 << s->mdct_bits". [15:52:16] <CIA-11> ffmpeg: It generates smaller cleaner code. [15:52:47] <peloverde> I have a win64 box but I wouldn't know where to start looking [15:53:28] <peloverde> Also in my experience mingw toolchains have been burdensome to install [15:55:49] <peloverde> Is there any case where 3DNow!™ is useful on x86-64? [15:56:05] <mru> probably not [15:56:21] <mru> sse2 is a superset iirc [15:56:36] <mru> at least in terms of functionality [15:56:37] <peloverde> I was thinking maybe we should disable it by default for x86_64, no need to carry around extra garbage object code [16:00:25] <Dark_Shikari> no, 3dnow is useless [16:00:35] <Dark_Shikari> peloverde: then you might as well disable all functions that are slower on amd64 cpus [16:00:42] <Dark_Shikari> in many (but not all) cases, that includes mmx versions [16:00:55] <peloverde> I was thinking *_c functions are still useful for debugging [16:01:44] <Dark_Shikari> yes those should be kept obviously [16:02:07] <BBB> I mentioned this yesterday already [16:02:25] <BBB> all mmx/mmx2 versions should be disabled for x86-64 if >=sse2 are available [16:02:37] <BBB> should=could I guess [16:02:41] <BBB> it'd save some space [16:08:14] <peloverde> Why do I get a "warning: section flags ignored on section redeclaration" on a line that doesn't declare a section at all [16:09:10] <twice11> Maybe because gcc adds the default section to it. [16:09:31] <peloverde> it's a yasm file [16:09:43] <BBB> peloverde: dsputil_yasm.asm? [16:09:57] <peloverde> libavcodec/x86/fft_mmx.asm [16:10:05] <BBB> section .text align=16 [16:10:44] <peloverde> I'm getting it on line 47... "endstruc" [16:11:19] <BBB> oh [16:11:22] <BBB> I get it on line 31 [16:11:24] <BBB> which is that line [16:23:42] <atmos4> hmm, if someone could point me at the right section of the h.264 itu spec where it desfribes the frame structure I'd be glad [16:24:50] <Dark_Shikari> wow. this is worse than I thought [16:24:56] <Dark_Shikari> someone in #ffmpeg is complaining about ffmpeg encoding being slow [16:25:04] <Dark_Shikari> so I went and tested 1080i ffmpeg mpeg-2 against x264 1080i [16:25:11] <Dark_Shikari> ffmpeg: 22fps [16:25:13] <Dark_Shikari> x264: 60fps [16:25:26] <mru> comparable params? [16:25:36] <Dark_Shikari> default settings in ffmpeg (well, with ildct/ilme) [16:25:42] <atmos4> hmm I encoded qcif msmpeg4v2 today at 2000 fps [16:25:47] <Dark_Shikari> --interlaced --preset ultrafast and similar vbv settings in x264 [16:25:55] <Dark_Shikari> only difference is ffmpeg probably has hpel on [16:25:57] <atmos4> from qcif h264 [16:26:01] <Dark_Shikari> but I don't think you can turn that off on cli [16:26:16] <Dark_Shikari> oh. ffmpeg has b-frames on, lemme turn that off [16:26:27] <Dark_Shikari> with b-frames off it's 34 [16:26:30] <Dark_Shikari> still way slower. [16:27:16] <atmos4> probably x264 is better optimized for multicore encoding [16:27:23] <Dark_Shikari> that is part of it [16:27:26] <mru> x264 has faster ME [16:27:29] <Dark_Shikari> also, -g 1 speeds up ffmpeg by over a factor of 2 [16:27:34] <Dark_Shikari> here's what's weird about that [16:27:37] <Dark_Shikari> -me_method zero DOESNT [16:27:43] <mru> wtf [16:27:55] <Dark_Shikari> -me_method zero has near zero speed effect [16:28:00] <Dark_Shikari> -g 1 gives me >80fps [16:28:15] <Dark_Shikari> This suggests to me that something is weird. [16:28:32] <mru> that doesn't only suggest, that _is_ weird [16:29:01] <Dark_Shikari> x264 with keyint 1: 88fps, ffmpeg with keyint 1: 86fps [16:29:08] <Dark_Shikari> mru: well, with -g 1, you can omit idct [16:29:20] <mru> true [16:29:26] <Dark_Shikari> and omit all reference frame handling [16:29:36] <Dark_Shikari> which x264 _cant_ [16:29:48] <mru> but _does_ ffmpeg? [16:29:57] <Dark_Shikari> I would assume so, because ffmpeg has a jpeg encoder/etc [16:30:02] <Dark_Shikari> and michael wouldn't let that optimization bit get away [16:30:11] <Dark_Shikari> but let me check [16:30:31] <Dark_Shikari> I think this is why encoding is separated into encode and decode functions [16:30:34] <Dark_Shikari> the latter of which does the idct [16:30:36] <Dark_Shikari> so it doesn't have to be called [16:30:40] <mru> michael often misses things [16:30:44] <mru> and then refuses to add them later [16:31:13] <Dark_Shikari> the architecture design strongly suggests this method though [16:31:23] <Dark_Shikari> like, this is the only reason to build it like that [16:32:22] <Dark_Shikari> yup [16:32:23] <Dark_Shikari> if ((s->flags&CODEC_FLAG_PSNR) || !(s->encoding && (s->intra_only || s->pict_type==FF_B_TYPE) && s->avctx->mb_decision != FF_MB_DECISION_RD)) { [16:32:29] <mru> ick [16:33:15] <Dark_Shikari> so yeah, it avoids that entire decoding step if gopsize is 1 [16:33:55] <Dark_Shikari> I'm just rather surprised at how slow ffmpeg is. I wonder if it's worse with interlacing, as this is 1080i [16:42:19] <CIA-11> ffmpeg: vitor * r24888 /trunk/tests/fate2.mak: BinkAudio FATE tests [17:27:28] <mru> 700 fate tests... [17:28:09] <pJok> in non-mike tempo [17:28:14] <mru> time for another test with the damn sigma chip [17:28:22] <mru> this time using a usb-ethernet adaptor [17:31:09] <mru> thankfully I have one that's supported by the ancient kernel [17:31:27] <kierank> mru: popcorn hour? [17:31:30] <mru> yes [17:32:01] <mru> the onchip ethernet seems incredibly unstable [17:33:13] <mru> don't know if silicon or driver is to blame [17:34:19] <kierank> i assume it's impossible to access the h.264 decoding hardware? [17:34:57] <CIA-11> ffmpeg: mru * r24889 /trunk/tests/fate-run.sh: fate: set LC_ALL=C to avoid locale interference [17:43:42] <mru> kierank: impossible is a strong word [17:47:18] <mru> since root access is easily obtained, and the sigma modules are there, reverse engineering it is certainly possible [17:47:32] <mru> I have no intention of doing it myself though [17:52:44] * saintdev lols at the asm bikeshed [18:41:17] <mru> hah, now all tests pass on the sigma (except the broken swscale one) [18:43:37] <kshishkov> isn't it proper MIPS chip anyway (i.e. better than Chinese)? [18:44:11] <mru> it's a 74kf [18:44:14] <Dark_Shikari> heh, interesting description from an nvidia guy [18:44:19] <Dark_Shikari> the "managerial chain reaction" [18:44:23] <mru> lol [18:45:01] <Dark_Shikari> " [18:45:01] <Dark_Shikari> Sorry for the delay, your proposition set off a chain reaction with our managers and their decisions. [18:45:04] <Dark_Shikari> Let me reply to you when they make their mind." [18:46:44] <saintdev> this to do with our talk a while ago? [18:46:51] <Dark_Shikari> no [18:47:15] <saintdev> something at work then? [18:47:18] <Dark_Shikari> yes [18:47:32] <saintdev> ic [19:04:04] <merbanan> saintdev: did you post the window selection patches ? [19:04:14] <saintdev> merbanan: yes [19:05:39] <saintdev> merbanan: http://thread.gmane.org/gmane.comp.video.ffmpeg.devel/115869 [19:14:20] <merbanan> look at that [19:14:55] <merbanan> an ok before I had the time to finish looking through the code [19:17:20] <saintdev> alex already had it, he just had other stuff he was working on before he reviewed it [19:20:01] <elenril> does that mean aacenc will suck even less? [19:20:22] <saintdev> yes [19:20:30] <elenril> \o/ [19:21:14] <saintdev> aacenc: now with 1% less suck [19:21:44] <saintdev> ...well, not quite yet... [19:22:40] <saintdev> still have to wait for alex to commit it. [19:23:56] <merbanan> it looked ok, with the exception of psy_lame_window, friggin harry potter shit [19:23:57] <peloverde> my MUA can't handle inline patches :( [19:25:18] <saintdev> merbanan: wait till you see analysis o.O [19:25:35] <saintdev> peloverde: want me to pastebin them? [19:26:06] <peloverde> Actually, it looks like the raw view will git apply [19:27:48] <peloverde> fuck, I had shit in my svn tree [19:27:51] * peloverde hates svn [19:28:15] <CIA-11> ffmpeg: alexc * r24890 /trunk/libavcodec/ (fft.h aacpsy.c): [19:28:16] <CIA-11> ffmpeg: aacenc: Rename Psy3gpp* structs to AacPsy* [19:28:16] <CIA-11> ffmpeg: This allows cleaner implementation of other psymodels using the existing [19:28:16] <CIA-11> ffmpeg: structs. It also will make it easier to interchange individual parts of [19:28:16] <CIA-11> ffmpeg: the psymodel to create hybrid models. [19:28:16] <CIA-11> ffmpeg: Patch by: Nathan Caldwell <saintdev(a)gmail.com> [19:28:17] <mru> in soviet russia svn hates you [19:29:14] <saintdev> \o/ [19:29:31] <saintdev> erm fft.h [19:30:31] <peloverde> see my above comment [19:30:36] <saintdev> yeah [19:30:37] <merbanan> saintdev: expect a flood of spam, alex forgot to obfuscate the email [19:30:42] <peloverde> now I have to figure out how to revert this shit [19:31:06] <saintdev> merbanan: heh [19:31:09] <peloverde> merbanan: I'm agianst e-mail obsfucation, addresses are public in the archive [19:31:26] <saintdev> peloverde: every little bit helps... [19:31:27] <merbanan> peloverde: why, it's just one line [19:31:32] <saintdev> if there [19:31:34] <saintdev> gah [19:31:44] <merbanan> just reply to the commit [19:31:51] <BBB> the comment? [19:31:57] <BBB> oh come on, leave it, just change the log msg [19:32:03] <BBB> it's not like it breaks anything [19:32:06] <saintdev> if there's one less bot that gets your email, that's several hundred less spams [19:32:31] * mru doesn't notice a few hundred spams this way or that [19:32:56] <mru> my filters discard thousands a day [19:33:16] <peloverde> all the guides seem to use svn merge but that seems to fuck up all the svn:properties [19:33:40] <mru> what are you trying to do? [19:33:48] <peloverde> roll back that last commit [19:33:52] <mru> why? [19:34:03] <peloverde> because I had some changes in fft.h in my svn repo [19:34:13] <mru> just undo the fft.h changes [19:34:25] <DonDiego> mru: btw, i'm favor of dropping support for running make in subdirs [19:34:32] <mru> DonDiego: I know that [19:34:54] <DonDiego> well, start being in favor of that as well then [19:35:08] <DonDiego> i'll start lobbying when i come back from holidays.. [19:35:10] <mru> I don't consider it highly important to break it [19:35:19] <DonDiego> it's broken already [19:35:27] <DonDiego> and it complicates the build system [19:35:39] <DonDiego> not worth it at all [19:36:53] <CIA-11> ffmpeg: alexc * r24891 /trunk/libavcodec/fft.h: Revert unintended changes to fft.h from r24890. [19:37:03] <mru> DonDiego: well, then there's no hurry to fix it [19:37:18] <peloverde> someone else can commit the other patch, using svn to deal with my own stuff is enough of a pain in the ass [19:37:32] <saintdev> lol [19:37:47] <mru> DonDiego: and the "complication" you think is there is a matter of 3 lines [19:37:55] <mru> if that [19:38:09] <DonDiego> i disagree [19:38:15] * peloverde wishes he could just use git without all the git-svn bullshit [19:38:20] <DonDiego> if we drop support for make in subdirs [19:38:21] <mru> you can't disagree about facts [19:38:35] <DonDiego> there is no more need for the subdir.mak/common.mak split [19:38:38] <saintdev> git-svn isn't that bad. [19:38:50] <mru> DonDiego: and why is that split bothering you so? [19:38:53] <mru> it works [19:38:53] <saintdev> much better than just using svn ;) [19:39:05] <DonDiego> it's needlessly complicated [19:39:06] <peloverde> dcommit is fucked, bisect is fucked, pulling from someone else is fucked [19:39:19] <mru> DonDiego: it's two files where you want one [19:39:23] <mru> hardly "more complicated" [19:39:32] <DonDiego> as i said, needless complication [19:39:39] <DonDiego> i never know where to look for what [19:39:52] <mru> that only means you don't know how it works [19:40:06] <mru> would you bundle all of libav* into one C file too? [19:40:09] <DonDiego> it means that understanding it is harder than necessary [19:40:16] <mru> to make it easier to know which file to check [19:40:41] <mru> running make in subdirs is a very tiny part of it [19:40:42] <DonDiego> the split is only for make in subdirs, it's for no other sane reason [19:40:50] <merbanan> saintdev: can you email me the diff ? [19:41:01] <DonDiego> so the split is arbitrary [19:41:04] <mru> no [19:41:11] <mru> the split is necessary [19:41:12] <DonDiego> the splitting of files in lavc is not [19:41:25] <DonDiego> necessary because of the subdirs thing [19:41:26] <mru> the subdir.mak rules must not be applied to the top dir [19:41:51] <mru> then you'd get a library instead of an ffmpeg executable [19:42:11] <DonDiego> as i said, it's designed with subdir make in mind [19:42:15] <mru> no [19:42:19] <DonDiego> and it can be done simpler [19:42:29] <mru> maybe a little [19:42:45] <mru> but not for the reasons you seem to think [19:43:04] <saintdev> merbanan: done [19:43:23] <DonDiego> we shall see when i'm back [19:43:30] <DonDiego> i'll pack my bag now.. [19:43:31] <mru> you shall not touch it [19:44:16] <DonDiego> last i checked, you hadn't rooted my computers yet, so i'll program all i want :) [19:44:19] * merbanan thinks that mru needs a hug [19:44:27] <mru> DonDiego: you will not commit anything [19:44:33] <DonDiego> i'm not threatening to commit anything [19:44:37] <mru> good [19:44:48] <mru> and you will not do it without a threat either [19:45:14] <DonDiego> i'm not planning to commit anything in a haste [19:45:31] <mru> haste or not, you will not touch the makefiles [19:45:40] <mru> not until I'm confident you understand them [19:45:52] <DonDiego> this obviously needs some investigation [19:46:15] <mru> it works, what else do you want? [19:47:39] <DonDiego> make in subdirs is broken, deps do not work because they list the subdir [19:47:55] <mru> so don't build in subdirs dammit [19:47:57] <DonDiego> and i want it simpler and easier to understand [19:48:00] <mru> you didn't want to do that anyway [19:48:18] <DonDiego> i don't want a broken feature in there [19:48:33] <mru> if it doesn't work, the feature is by definition not there [19:48:46] <DonDiego> much less if it drags along complexity [19:48:55] <DonDiego> it breaks silently! [19:49:01] <mru> I can't make it physically impossible to run make in a subdir [19:49:13] <DonDiego> you can type 'make' but it does not run as reliably as in the top dir! [19:49:33] <mru> well, that's what I call unsupported [19:49:37] <mru> just the way you wanted it [19:49:40] <DonDiego> pffff [19:49:48] <mru> or what would you have? set fire to the computer? [19:49:52] <DonDiego> this is evil [19:49:53] <mru> that'll teach 'em [19:50:34] <DonDiego> anyway, this discussion is pointless - i'll see how much i can simplify it, then we can talk again [19:52:09] * lu_zero wonders if the "feature" is fixable [19:55:48] <merbanan> saintdev: I think the mail got stuck in the spam filter [19:56:49] <peloverde> where are your svn gods now? [19:56:57] <mru> why don't you help me fix swscale instead? [19:57:38] <peloverde> svn:externals, that's why [19:57:46] * mru curses [20:00:59] <CIA-11> ffmpeg: alexc * r24892 /trunk/libavcodec/aacpsy.c: (log message trimmed) [20:00:59] <CIA-11> ffmpeg: acenc: LAME-inspired window decision [20:00:59] <CIA-11> ffmpeg: This performs quite a bit better than the current 3GPP-inspired window decision [20:00:59] <CIA-11> ffmpeg: on all the samples I have tested. On the castanets.wav sample it performs very [20:00:59] <CIA-11> ffmpeg: similar to iTunes window selection, and seems to perform better than Nero. [20:01:00] <CIA-11> ffmpeg: On fatboy.wav, it seems to perform at least as good as iTunes, if not better. [20:01:01] <CIA-11> ffmpeg: Nero performs horribly on this sample. [20:01:04] <janneg> peloverde: http://www.mplayerhq.hu/DOCS/tech/svn-howto.txt section 9. the copy method [20:01:26] <saintdev> hmm, pastebin.org seems down, that would explain the wgetpaste hang :/ [20:01:54] <peloverde> applied it myself [20:01:55] <saintdev> anyway besides the point now [20:02:10] <saintdev> \o/ [20:02:14] <janneg> peloverde: yeah missed the commit [20:02:22] * mru stabs libswscale with a rusty fork [20:02:40] <peloverde> saintdev: if you could keep lines in commit messages to 80 cols it saves whomever else the trouble of reformatting [20:02:58] <saintdev> libswscale stabs mru back with an even rustier appendage [20:03:08] <saintdev> peloverde: ok [20:03:17] <mru> saintdev: yes, that's libswscale [20:04:19] <peloverde> Does this look like appropriate usage of libswscale? http://pastebin.com/FkkrXRjU [20:05:00] <peloverde> because it is significantly slower than the chrome scaler which makes me think i'm doing something terribly wrong [20:05:12] <mru> it's c++ [20:05:13] <mru> ught [20:05:17] <mru> I can't read that [20:05:24] <mru> worse that lsws itself [20:05:26] <Dark_Shikari> peloverde: slower than the chrome scaler isn't very surprising [20:05:32] <Dark_Shikari> iirc chrome scaler is multithreaded [20:05:42] <Dark_Shikari> also, it uses sse [20:05:51] <Dark_Shikari> are you just doing yuv2rgb? [20:05:54] <Dark_Shikari> or actual scaling? [20:06:01] <Dark_Shikari> Also, did you enable the asm flags? [20:06:17] <Dark_Shikari> Also, the context creation shouldn't be in the benchmark [20:06:18] <Dark_Shikari> that takes time [20:06:25] <peloverde> both scaling and yuv2rgb [20:06:53] <peloverde> maybe that's why I put it before "TimeTicks start = TimeTicks::HighResNow();" [20:07:09] <DonDiego> wasn't ramiro supposed to work more on refactoring libswscale? [20:07:36] <mru> I can hardly blame him for not doing it [20:08:12] <Dark_Shikari> peloverde: is your asm enabled? [20:08:16] <Dark_Shikari> I don't see the flags being set [20:08:32] <peloverde> I have to set flags? [20:08:46] <Dark_Shikari> yes..... hurrr [20:08:51] <Dark_Shikari> cpuflags are 0 by default [20:08:52] <Dark_Shikari> (off) [20:09:13] <peloverde> Shouldn't it just check what I have when I init the context? [20:09:24] <peloverde> this API seems retarded [20:09:32] <Dark_Shikari> IT IS [20:09:41] <mru> it's libswscale, _everything_ about it is retarded [20:12:44] <saintdev> mru: LMAO [20:13:01] <Dark_Shikari> it's no laughing matter [20:13:04] <mru> did I say something funny? [20:14:49] <peloverde> fascinating: http://pastebin.ca/1923584 [20:15:15] <peloverde> bilinear seems marginally faster than bilinear fast [20:15:22] <Dark_Shikari> that seems unlikely [20:15:24] <Dark_Shikari> fast bilinear is JIT'd [20:16:08] <Dark_Shikari> it looks to me like they're the same speed, i.e. they're the same code [20:16:20] <Dark_Shikari> this could mean that fast bilinear isn't working correctly, and it's falling back to bilinear [20:16:23] <Dark_Shikari> OR [20:16:33] <Dark_Shikari> that bilinear is an alias to fast bilinear [20:17:26] <peloverde> updated: http://pastebin.ca/1923590 [20:18:34] <peloverde> funfact: a debug build of skia running under valgrind is 3 seconds per frame [20:22:09] <peloverde> Is SSE not useful for scaling or is it missing for some other reason? [20:22:21] <Dark_Shikari> because swscale hasn't been updated since 2000 [20:22:30] * peloverde facepalm [20:22:31] <mru> it's missing because nobody is able to code for lsws [20:22:57] <peloverde> And I thought aacenc was an embarrassment [20:24:14] <janneg> Dark_Shikari: cpuflags matter only with --enable-runtime-cpudetect [20:24:29] <peloverde> Also I thought kshishkov just rewrote the x86 optimizations recently [20:24:29] <Dark_Shikari> janneg: then why is peloverde getting a difference? [20:24:40] <Dark_Shikari> peloverde: the infrastructure is still horribly broken [20:24:46] <Dark_Shikari> and that doesn't mean we have sse [20:25:20] <peloverde> so realistically what can we do about it? [20:25:53] <mru> write a new lib that beats it in ever possible way [20:25:59] <mru> every [20:26:22] <Dark_Shikari> with neon [20:26:48] <mru> it will have to be faster on every x86 chip ever made [20:26:54] <Dark_Shikari> lol [20:26:57] <Dark_Shikari> even the via c3! [20:27:11] <mru> s/ever made/michael knows of/ [20:27:52] * peloverde headdesk [20:28:23] <BBB> lol :) [20:28:35] <BBB> poor guy [20:28:41] * BBB pets peloverde on the back [20:28:45] <Dark_Shikari> so BBB, how's that vp8 encoder [20:29:08] <BBB> I'm going through the rac writing functions in libvpx right now [20:35:45] <saintdev> merbanan: finally got a failure message back. guess i typed the email wrong :P [21:01:22] <DonDiego> saste: why are the libavfilter #includes ifdeffed? [21:01:39] <DonDiego> they look harmless, so the #ifdefs are unnecessary.. [21:02:36] <mru> DonDiego: are you bored? [21:02:50] <DonDiego> why? [21:03:02] <mru> you seem to be looking for trivial nits to kick up a fuss over [21:03:22] <DonDiego> no, i was about to apply the usleep in ffplay.c patch [21:03:36] <DonDiego> and when i opened ffplay.c i noticed the pointless ifdeffery [21:03:40] <mru> ah [21:03:43] <mru> so typical [21:03:59] <DonDiego> what? fixing one thing and noticing another? [21:04:11] <mru> yes [21:06:47] <mru> there, one swscale bug taken care of [21:07:05] <mru> assuming it's not too pretty of course [21:07:25] <DonDiego> you could fix more :) [21:07:36] <DonDiego> flaming will not get you anywhere.. [21:07:44] <mru> this one gets fate back in the green [21:08:22] <mru> not flaming will also not achieve anything [21:08:24] <mru> apparently [21:13:21] <janneg> cmov on atom is slow, right? [21:13:26] <CIA-11> ffmpeg: diego * r24893 /trunk/ffplay.c: [21:13:26] <CIA-11> ffmpeg: Add _XOPEN_SOURCE definition for usleep(). [21:13:26] <CIA-11> ffmpeg: patch by Dave Yeo, daveryeo telus net [21:13:55] <mru> janneg: probably varies between isotopes [21:14:10] <DonDiego> janneg: what is the status of your latm patch? [21:16:30] <janneg> DonDiego: still trying to avoid working on mpeg-ts integration. I have to do it soon though since I've removed libfaad with latm from mythtv [21:17:08] <DonDiego> latm in mpeg-ts? [21:20:54] <janneg> latm is an audio multiplex format, the demuxer for it is finished but that doesn't help to get the audio data from the mpeg-ts demuxer to the aac decoder [21:31:31] <janneg> not as fast as core2 but much fast than everything P4 based [21:45:43] * janneg kicks CIA-11 [21:45:44] <CIA-11> ow [21:46:21] <janneg> ah it's missing libswscale patches [21:50:35] <saste> DonDiego: libavfilter is not supposed to be mandatory for both ffmpeg, and ffplay.c [21:51:01] <saste> DonDiego: as for the ifdeffery... they are not necessary [21:51:28] <saste> but maybe who added those was concerned with making the ff* code appears like an external app [21:55:38] <BBB> lol @ fate because it doesn't show the swscale revision number :-o [21:59:22] <janneg> BBB: the other question is if the fate machines will pick up the libswscale change if noboby commits to ffmpeg [21:59:52] <BBB> good point [22:06:21] <CIA-11> libswscale: mru * r32010 /trunk/libswscale/swscale.c: swscale: remove unused macro parameter in BGR2UV template [22:06:22] <CIA-11> libswscale: mru * r32011 /trunk/libswscale/ (swscale_template.c swscale.c): swscale: fix unaligned accesses in (RGB|BGR)32_1 to YUV conversion

1 0

IRC log for 2010-08-22
by irc＠mansr.com 23 Aug '10

23 Aug '10

[08:31:46] <xxthink> Is VDPAU open source? [08:34:59] <thresh> libvdpau is [08:39:36] <xxthink> I download it from http://cgit.freedesktop.org/~aplattner/libvdpau [08:39:46] <xxthink> but I can't find the GPU source [08:40:37] <xxthink> is this the right place to download? [08:41:30] <thresh> GPU source ? [08:41:54] <xxthink> the decoding source for GPU [08:42:19] <xxthink> for example, the mpeg-2 decoding source for GPU [08:43:38] <xxthink> the decoder seems in the NVIDA driver [08:43:48] <thresh> yes, you need proprietary driver [08:43:56] <thresh> libvdpau is just an interface [08:44:01] <xxthink> yes [08:44:07] <xxthink> I c [08:44:32] <xxthink> but the driver is not open source :) [08:46:38] <thresh> of course it is not [11:53:41] <mru> morning [11:53:53] <CIA-93> ffmpeg: mru * r24866 /trunk/tests/fate.sh: fate: allow specifying relative path to config file in fate.sh [12:04:01] <CIA-93> ffmpeg: mru * r24867 /trunk/configure: mmsh depends on http [13:42:40] <deets> hi all. I know this is the wrong channel for questions about using libav*. However, I'm the only one there currently. So I wonder if it would be ok to ask user questions here as well. [13:42:55] <deets> there being "#libav-user" of course. [13:44:28] <kierank> libav-user is a mailing list, not an irc channel [13:45:32] <deets> argl. [13:45:33] <deets> sorry [13:45:45] <deets> I'll switch to the ffmpeg channel [14:25:48] <CIA-93> ffmpeg: mru * r24868 /trunk/ (Makefile tests/fate2.mak): fate: remove pointless fate/fate2 separation [14:40:49] <CIA-93> ffmpeg: alexc * r24869 /trunk/libavcodec/x86/ (fft_mmx.asm fft_sse.c): [14:40:49] <CIA-93> ffmpeg: Convert ff_imdct_half_sse() to yasm. [14:40:49] <CIA-93> ffmpeg: This is to avoid split asm sections that attempt to preserve some [14:40:49] <CIA-93> ffmpeg: registers between sections. [15:08:41] <mru> peloverde: look at that, imdct works on suncc now [15:11:00] <peloverde> hmm? The only sun config rebuilt so far seems to be gcc3/sunos [15:12:28] <peloverde> nevermind [15:12:34] <peloverde> I'm reading fate wrong [15:17:49] <peloverde> x86_64-w64-mingw32-gcc-4.4 is the machine I really care about at the moment [15:21:02] <CIA-93> ffmpeg: mru * r24870 /trunk/tests/fate.sh: fate: remove unused variable in fate.sh [15:48:25] <peloverde> vorbis and aac now pass on win64 [15:48:58] <peloverde> http://fate.mansr.com/x86_64-w64-mingw32-gcc-4.4 [15:53:58] <mru> peloverde: it's fate.ffmpeg.org now [15:54:10] <mru> though it points at the same thing [15:54:47] <peloverde> I've never been one to buy into fancy rebrands [15:56:23] <mru> just saying [15:56:30] <mru> fate.ffmpeg.org is the official name [15:56:37] <mru> the other one could go away at any time [15:56:54] <mru> or turn into goatse [15:56:57] <mru> you have been warned [15:57:01] <peloverde> sometimes I still go to mike's fate out of habit [18:47:15] <BBB> mru: can you give me a ssh account on the win64 box? [18:47:50] <BBB> or any way in which I could debug [18:48:24] <kierank> you could use virtualbox [18:48:31] <kierank> and one of those windows 7 images microsoft provides [18:48:41] <kierank> not sure if they do win64 though [18:53:37] <mru> BBB: no, it's not mine [18:54:31] <BBB> whose is it? [18:54:41] <BBB> ramiro? [18:54:45] <mru> probably [18:55:04] <mru> yes [19:31:48] <Dark_Shikari> mru: could you try modifying fate to try to track down causes of errors a bit more? [19:31:52] <Dark_Shikari> like passing different asm flags or whatever? [19:31:57] <Dark_Shikari> that might be useful [19:32:18] <mru> no modification necessary, just more configs [19:33:10] <Dark_Shikari> well I mean localize it a bit more [19:33:16] <Dark_Shikari> to make it easier to view [19:33:24] <Dark_Shikari> actually that could be done with gccs too [19:33:33] <Dark_Shikari> the point is, we could click on a system and get a grid of what fails and what doesn't [19:33:41] <Dark_Shikari> e.g. "this works with no asm, mmx, mmx2, but not sse2" [19:33:47] <Dark_Shikari> without having to check a ton of different "systems" [19:34:16] <mru> I see what you mean [19:34:34] <mru> but it's hard to present results of ~700 tests concisely [19:34:38] <Dark_Shikari> I mean, it would be great to have checkasm for ffmpeg [19:34:47] <mru> patches welcome [19:34:48] <Dark_Shikari> but I doubt that will happen soon =p [19:46:08] <BBB> I think for that you don't need more configs [19:46:12] <BBB> just settable cpu flags [19:46:15] <BBB> ffmpeg used to have that [19:46:35] <Dark_Shikari> yeah, what I'd do for that is as follows [19:46:37] <BBB> e.g. disabling certain flags for mm_support, as in masking them out [19:46:43] <Dark_Shikari> run each test with many combinations of cflags [19:46:45] <Dark_Shikari> then add a grid to the test panel [19:47:02] <BBB> right, that'd be great [19:47:15] <Dark_Shikari> not as good as checkasm, but something [19:47:18] <BBB> assuming cflags is my "ffmpeg maskfield", not compiler CFLAGS :-p [19:47:18] <mru> different cflags => different configs [19:47:33] <BBB> I mean runtime variable [19:47:44] <BBB> being able to hardcode mm_support() [19:47:53] <Dark_Shikari> mru: cpuflags != cflags [19:47:59] <mru> he said cflags [19:48:04] <Dark_Shikari> 05:46 <@BBB> just settable cpu flags [19:48:06] <mru> no, you did [19:48:10] <Dark_Shikari> er, yeah [19:48:13] <Dark_Shikari> that was a typo [19:48:13] <BBB> I think he meant cpuflags [19:48:22] <mru> makes sense [19:48:23] <BBB> anyway, great idea, would be very helpful and nice to have [19:48:29] <Dark_Shikari> mm_support is retarded anyways [19:48:32] <BBB> not super-urgent, but super-cool :) [19:48:34] <Dark_Shikari> I mean seriously [19:48:36] <Dark_Shikari> GLOBAL VARIABLES [19:48:38] <Dark_Shikari> >_> [19:48:41] <BBB> haha :-p [19:48:41] <mru> yes, very [19:48:50] <Dark_Shikari> And of course, the best part [19:48:53] <Dark_Shikari> is that despite it being global [19:48:55] <mru> and that global is only used in one fucking place [19:48:56] <Dark_Shikari> we treat it as a local var [19:48:58] <mru> emms() [19:49:02] <BBB> given that win64 works w/o asm [19:49:19] <Dark_Shikari> mru: emms should be inlined imo [19:49:24] <mru> it is [19:49:27] <BBB> I'll try with different variations of cpuflags [19:49:30] <Dark_Shikari> I mean, inline inlined [19:49:30] <BBB> to see which breaks [19:49:31] <Dark_Shikari> no check [19:49:36] <mru> if (mm_support & MMX) asm("emms") [19:49:38] <Dark_Shikari> i.e. "fuck 486 users" [19:49:47] <mru> I suggested that a while back [19:49:54] <mru> didn't get quite the buyin I'd hoped for [19:49:55] <BBB> 486 doesn't exist anymore [19:49:55] <Dark_Shikari> we do that in x264 [19:50:11] <BBB> mru: I wasn't aware you wanted our approval :-p I'm all for it [19:50:18] <BBB> under HAVE_MMX if you want [19:50:18] <Dark_Shikari> I wasn't aware you _needed_ approval, just do it [19:50:20] <Dark_Shikari> =p [19:50:24] <BBB> right [19:50:56] <Dark_Shikari> IMO, if you want to do that, you need to make emms take an argument [19:51:00] <Dark_Shikari> e.g. a context [19:51:08] <Dark_Shikari> er, "that" == "what is currently done" [19:51:09] <mru> why? [19:51:15] <Dark_Shikari> to avoid a global [19:51:16] <mru> oh [19:51:21] <mru> but there's no need for that [19:51:25] <Dark_Shikari> Yes, I agree, it shouldn't be that way [19:55:40] <iive> the problem is not that you fuck 486... you also fuck all cpu up to the one I have. [19:55:52] <mru> fuck you then [19:57:58] <funman> fympeg [20:00:56] <iive> the correct solution is to allow inlineing of the asm routines when building for specific cpu, and keep the old generic way when you build generic one. [20:01:32] <mru> in your world [20:04:12] <iive> well, I'm eager to see real solution that doesn't involve fucking around. [20:04:42] <mru> --disable-mmx if you don't have it [20:04:43] <mru> job done [20:10:04] <BBB> iive: most distros already do it this way [20:10:16] <BBB> debian (ubuntu), mandriva [20:10:46] <BBB> in the real world (apple) this is standard anyways [20:11:22] <BBB> (and that's b/c they are 64-bits already, so they get away with it, but still) [20:11:37] <mru> apple real... rotfl [20:11:47] <BBB> bigger market share than all linux combined... [20:11:59] <mru> by that token windows would be the most real [20:12:02] <BBB> Dark_Shikari has suggested multiple times to disable all pre-sse2 functions for functions where >=sse2 are available and when building for x86_64 [20:12:10] <BBB> windows is more real [20:12:17] <BBB> but its dev environment sucks :-p [20:12:42] <funman> but it runs delphi! [20:12:43] <peloverde> I would wager more videos get processed by FFmpeg on linux at places like youtube and vimeo than an all apple systems combined [20:13:29] <BBB> peloverde: "ffmpeg" is what? [20:13:43] <BBB> I tend to think of "ffmpeg" as things like VLC, Chrome etc. [20:13:54] <BBB> I certainly don't use "./ffmpeg" much myself [20:14:34] <peloverde> even then I think it's the case [20:14:45] <funman> ./ffmpeg is nice imo [20:14:45] <peloverde> most youtube video is consumbed by flash on windows [20:15:01] * pJok uses ./ffmpeg a lot [20:19:14] <iive> BBB: my distro still builds against i486. Indeed it uses -mcpu=i686. [20:19:59] <BBB> well of course it does, otherwise it wouldn't run on your cpu if I understand correctly :-p [20:20:19] <BBB> so by mere logic, you wouldn't use "your distribution" if it didn't build that way, because it wouldn't run on your cpu [20:20:41] <iive> BBB: my cpu is not THAT old. [20:20:42] * BBB wonders why configure hangs on win64 [20:20:58] <mru> BBB: does it hang or just take insanely long time? [20:21:12] <BBB> I wouldn't be able to tell the difference really [20:21:21] <BBB> is there a debug mode? [20:21:23] <BBB> ./configure -d? [20:21:27] <BBB> so it tells me what it's doing [20:22:10] <iive> bash -x ./configure [20:23:52] <mru> wtf @ h263dec.c:556 [20:25:50] <BBB> uh [20:25:55] <BBB> it was indeed not hanging :-p [20:25:57] <BBB> that's kinda funny [20:26:04] <BBB> ok gotta run now [22:00:39] <kierank> What is this code trying to acheive on a signed value? http://pastebin.org/733592 [22:02:59] <roxfan> it toggles ebx high bits [22:03:11] <roxfan> hard to say what for without seeing the rest [22:04:37] <kierank> I know it does that. It's part of gain adaptive quantisation [22:04:48] <kierank> the rest of the code multiplies by the inverse gain element [22:11:01] <twice11> kierank: Could that code possible be used for sign-extension of a value already determined to be negative? ebx would be the number of "missing" bits. [22:11:16] <twice11> i.e. EBX=3 for a 29 bit value. [22:11:47] <kierank> that sounds correct [22:12:00] <kierank> and makes sense considering the context [22:15:13] <mru> where does the code come from? [22:16:17] <kierank> dolby e's gaq decoder [23:38:49] <BBB> has anyone ever noticed that windows, or maybe this is cygwin, is really quite slow? [23:40:19] <Dark_Shikari> cygwin is very slow [23:40:22] <Dark_Shikari> configure takes about 5 minutes [23:40:25] <Dark_Shikari> this is because fork() is slow on windows [23:40:52] <Compn> cygwin is ungodly slow [23:53:30] <BBB> can't someone fix windows? [23:53:39] <BBB> I mean, even my mac is 10x faster than this wincrapbox [23:53:45] <BBB> excusez-le-mot [23:54:33] <lu_zero> BBB: fix how? [23:55:00] <lu_zero> windows is an apparently nifty idea implemented in a not so good way [23:55:12] <lu_zero> the idea is bad and so is the rest =P [23:55:50] * lu_zero tries tmux now

1 0

IRC log for 2010-08-21
by irc＠mansr.com 22 Aug '10

22 Aug '10

[00:48:38] <Compn> hahaha [00:48:53] * Compn finds h264-in-ogg-in-avi [00:49:04] <Compn> http://web.archive.org/web/20070924195347/www.leadcodecs.com/Download/H264/… [00:50:29] <Compn> where are my ogg buddies at ? [00:58:12] <Compn> oh good, there are real avi versions too [00:58:41] * Compn was afraid he was going to have to find some strange ogg program to demux ogg-in-avi [01:00:02] <saintd3v> Compn: rofl [01:10:32] <xxthink> http://www.pastebin.org/641127 [01:11:15] <xxthink> what does the line 4 in the pastebin mean ? this is some code from the handle_packet of ffmpeg [01:12:37] <xxthink> because *p is the data type according to iso 138183-1 [01:13:12] <xxthink> if the data type is the PES packet, *p is the 1st byte of the start code of the PES packet [02:08:25] <peloverde> Chrome managed to link without exploding my system, life is good [02:43:33] <Compn> its probably a trap [04:44:03] <peloverde> mind boggling http://forum.doom9.org/showthread.php?t=156287 [04:46:34] <Dark_Shikari> peloverde: he banned everyone who disagreed with him [04:47:25] <drv> the thruth is out there [04:47:56] <peloverde> I feel like I outgrew doom9 fiveish years ago [04:50:01] <peloverde> But that whole thread seems full of stupid [04:50:31] <peloverde> vaguely reminds me of the GNOMEies pimping Fluendo shit... only worse [04:54:37] <peloverde> I think the real way to stick it to them is to make lavc fast [05:04:19] <Yuvi> heh, it looks like openbsd backported the aes instructions for binutils [05:04:22] <Yuvi> but not ssse3 [05:04:33] <Dark_Shikari> lol [05:11:39] <peloverde> another reason to avoid gas? [05:11:59] <Dark_Shikari> more like another reason to avoid bsd [05:13:08] <peloverde> At least win64 has enough users to be worth bending over backwards for [05:15:04] <Dark_Shikari> now this is funny [05:15:12] <Dark_Shikari> x264 was crashing in deblocking despite me messing with trellis stuff [05:15:14] <Dark_Shikari> it made no sense... [05:15:20] <Dark_Shikari> and then I realized I had an array overflow on a function pointer array [05:15:27] <Dark_Shikari> guess what function was immediately after the level-run coder... [05:15:30] <Dark_Shikari> deblocking. [07:41:37] <superdump> morning [07:41:44] <kshishkov> morrow [07:42:12] <elenril> dobré ráno [07:42:17] <superdump> mru: i don't suppose marcelo sent an AMR-WB patch to -devel that got moderated because the attachment was too large did it? [07:53:52] <saintdev> i have sound in long blocks \o/ [07:58:24] <saintdev> on that note, i think it was bedtime an hour ago :P [08:08:43] <mru> superdump: nope [08:19:23] <superdump> ok [08:19:29] <superdump> thanks for checking [08:19:31] <superdump> have fun :) [08:52:36] <mru> let's see if the mips machine is happier with a cpu fan and no gdium on top of it [09:00:07] <_av500_> it was a mips dual core stack before? [09:00:22] <mru> yeah [09:00:41] <mru> now the gdium is perched at an angle on top of the mac [09:01:00] * mru needs a better server room [09:01:03] <_av500_> post fate pics [09:01:44] <mru> I also strapped an nvidia chipset fan to the sigma cpu [09:01:47] * _av500_ has a well heated server room, but no servers... [09:02:42] <_av500_> my sheeva cpu has a piece of thermo rubber on top, wonder what that is good for... [09:04:14] <iive> keep it warm ? [09:05:28] <mru> my sheevaplug is no longer a plug [10:54:45] <mru> damn, still overheating [10:55:10] <mru> maybe if I add a case fan too [10:55:18] <mru> there are mounting holes... [10:58:35] * pJok hands mru the liquid nitrogen [11:23:49] <ods15> can someone explain to me what the "+" means in git fetch and push? I've read the description in the man page about 5 times and i still don't get it... [11:47:55] <pengvado> ods15: what is there to explain? what a forced update is? how one could fail? [11:48:31] <ods15> pengvado, figured it out, i didn't understand it simply meant "force" [11:48:41] <ods15> the man page keeps saying "non fast forward update" [11:48:53] <ods15> (i'm possibly out of date...) [11:49:23] <ods15> pengvado, what does ffmpeg use? git-svn? [11:50:54] <lu_zero> git-svn right now [11:51:04] <CIA-93> ffmpeg: reimar * r24857 /trunk/MAINTAINERS: Add myself as maintainer for the PGS subtitle decoder. [11:51:09] <pengvado> you mean what does it use on the server side to generate a git mirror of the svn repo? [11:52:09] <lu_zero> each svn commit get converted [11:52:11] <ods15> git push works? [11:52:20] <lu_zero> right now no [11:52:38] <ods15> and you can't really have git branches? [11:52:50] <lu_zero> You canno push them [11:52:53] <CIA-93> ffmpeg: reimar * r24858 /trunk/libavcodec/pgssubdec.c: Export the presentation video dimensions as avctx->width/avctx->height. [11:53:30] <lu_zero> aas dev [11:53:44] <ods15> what do you mean "right now no"? is there intention to drop the svn? [11:56:52] <ods15> pengvado, so, currently, on every svn commit, the git repo does "git svn fetch"? and so everyone can use the git clone for read only? [11:57:24] <ods15> sounds uncomftable for committing... do you use "git svn dcommit" for pushing? [11:58:47] <lu_zero> brb [12:00:23] <pengvado> I cloned mru's git repo before there was an official ffmpeg git mirror, and I never switched [12:01:33] <pengvado> I do all my development in git, but commit to svn, not git-svn. [12:01:51] <ods15> so you constantly copy patches? [12:02:05] <pengvado> (on the rare occasion that I actually commit to ffmpeg, which I haven't done many times since switching to git) [12:02:59] <ods15> umm.. does someone else commit for you? or do you just maintain your own branch on git for others to use? or do you just not do anything anymore like me? :) [12:03:12] <ods15> (or am i missing a 4th option?) [12:05:35] <pengvado> my major project (ffv2) is in a private branch. other than that, I have 7 commits this year, plus 4 patches that are mostly mine but were committed by other people. [12:06:32] <ods15> so, do people clone from you? or is it completely private? [12:07:23] <pengvado> I occasionally upload a copy of my repo to my server, but the copy I actually develop on isn't publically clonable. [12:08:51] <pengvado> nnedi might count as another project using that model, since I plan to eventaully include it in swscale but it wasn't started as even part of the ffmpeg sourcetree, and so far is just in my git repo. [12:12:48] <DonDiego> pengvado: i only found nnedi on doom9, are you user tritical there? [12:13:43] <ods15> hya DonDiego [12:14:56] <pengvado> I am referring to that same nnedi, but I'm not tritical [12:15:00] <pengvado> http://forum.doom9.org/showthread.php?p=1427793#post1427793 [12:16:53] <DonDiego> ods15: don't kung-fu me with those "hya" shouts... [12:18:06] <ods15> hya! [12:20:57] * DonDiego steps aside and dodges the incoming ods15 .. [12:34:02] <lu_zero> ^^? [15:19:44] <CIA-93> ffmpeg: stefano * r24859 /trunk/libavcore/imgutils.c: Cosmetics: if( -> if (. [15:19:46] <CIA-93> ffmpeg: stefano * r24860 /trunk/libavcodec/imgconvert.c: Cosmetics: remove useless (). [16:34:34] * peloverde hates how every browser feels the need to invent its own build system [16:34:58] * kshishkov hates building browsers anyway [16:35:17] <kshishkov> once I tried building mozilla and ran out of free disk space [16:37:41] <peloverde> since the chromium scaler appears to suck and libswscale is now LGPL everywhere, I was looking at replacing their scaler [16:38:35] <kshishkov> sorry for creating such conditions [16:39:14] <merbanan> kshishkov: did you get the package yet ? [16:39:30] <kshishkov> merbanan: yes, on Wednesday, thank [16:39:31] <kshishkov> s [16:39:35] <merbanan> yey [16:39:45] <merbanan> did the cheese survive ? [16:39:51] <kshishkov> merbanan: though it's not enough for me :) So I'm going in person to get more [16:39:59] <merbanan> hehe [16:40:00] <kshishkov> yes, slightly deformed but overall fine [16:40:48] <kshishkov> so any interested parties have time till Friday to leave Sweden [16:41:22] <merbanan> when and where are you going ? [16:42:15] <kshishkov> next Friday evening, ~22:00, Arlanda [16:42:32] <merbanan> how long are you going to stay ? [16:42:37] <kshishkov> two weeks [16:43:01] <merbanan> ok ok, then we will have time to meet [16:43:11] * kshishkov would prefer a lifetime though it's a bit unrealistic [16:45:26] <kshishkov> merbanan: yes, I hoped so [17:08:41] * kierank blames mru for the sky digibox packing up ;) [17:38:55] <mru> kierank: I never worked on the Sky boxes [17:39:02] <mru> in fact, I actively avoided them [17:44:02] <kierank> that won't stop me from blaming you for it's failure ;) [17:48:38] <ods15> mru, do you still commit to ffmpeg? do you use git svn dcommit? [17:48:53] <mru> yes and yes [17:49:08] <mru> nobody in their right mind still uses plain svn [17:49:28] <ods15> i'm doing a slow migration of svn to git at work [17:49:51] <ods15> heh, i still used svn until just about a month ago, and really, it wasn't that bad :) but i admit i enjoy git [17:50:14] <mru> svn wasn't that bad once upon a time [17:50:22] <mru> just like cvs wasn't that bad when it was new [17:50:24] <mru> and rcs before it [17:50:58] <ods15> never used rcs [17:51:09] <peloverde> Now that the gsoc deadline has passed, can we switch? [17:51:11] <ods15> and i'm amazed how little i remember about my short time with cvs [17:51:33] <mru> peloverde: gsoc was never a concern for me [17:51:40] <ods15> i remember it wasn't compressed by default, and you needed to pass "diff -u"... [17:54:11] <ods15> mru, any general tips for the current slow migration i intend at work? most people will continue using svn, some will switch to git,main repo still svn [17:54:48] <peloverde> mru: It was michael's concern, he said he was ok switching after soc was done [17:55:06] <ods15> how do people use git-svn on the git clone from ffmpeg? they need all of the .git/svn/ [17:55:50] <peloverde> ods15: That is why I want to switch "for realz" [17:56:29] <peloverde> You can't even rebuild the .svn info because it was a file:/// checkout [17:57:00] <ods15> actually, git-svn kind of scares me - i saw non dtermenistic results from it! [17:57:14] <mru> git-svn is ok [17:57:22] <ods15> i have no idea why, and i even still have the old logs to prove it, 2 identical "git svn clones" gave me different results [17:57:54] <ods15> it just randomly skipped commits, about 1 in a 1000 [17:57:56] <peloverde> git svn is ok as long as you don't have to collaborate with anyone besides the central repo [17:59:24] <peloverde> in regard to the soc issue see https://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-June/090534.html [18:00:12] <peloverde> also using this as an chance to merge libswscale would be awesome too [18:00:24] <peloverde> swscale always fucks up my git-bisect [18:00:58] <ods15> why is the https on lists.mplayerhq.hu messed up... (gives firefox warning) [18:01:48] <peloverde> It's not signed by a recognized CA [18:02:23] <ods15> wasn't michael the one who advocated git in the first place? i vaguely recall [19:05:43] <CIA-93> ffmpeg: rbultje * r24861 /trunk/ (5 files in 3 dirs): [19:05:43] <CIA-93> ffmpeg: MMSH support, the most popular and widely used of all MMS variants. Written by [19:05:43] <CIA-93> ffmpeg: Zhentan Feng <spyfeng gmail com> as part of Google's Summer of Code program. [19:08:57] <Compn> huh [19:09:06] <Compn> that one took a while :D [19:12:20] <elenril> \o/? [19:12:24] <merbanan> still awesome [19:13:43] <ods15> why are vla's being removed? [19:14:50] <funman> i assume fixed length arrays are simpler to allocate, and detecting stack overflows is easier too [19:21:15] <Kovensky> ods15: I know mru classes them as "spawn of the devil" but I never asked the specifics :> [19:22:22] <kierank> because if the array length is stupidly large for some reason you get a crash whereas with malloc you just error out [19:22:37] <mru> and even if it works they are slower [19:27:33] <iive> why are they slower? [19:27:59] <mru> with gcc you lose a register [19:28:51] <mru> multi-dimentional VLAs variable in anything but the outermost dimension require slower addressing [19:32:03] <iive> even when other dimentions are fixed in size (and multiple of 2)? [19:32:28] <iive> do you lose register if you use alloca instead? [19:33:02] <mru> imagine char foo[2][x] [19:33:14] <mru> now calculate &foo[1][2] [19:33:39] <mru> &foo[1][0] is of course foo+x [19:33:53] <mru> so &foo[y][0] is foo+x*y [19:33:59] <mru> yes, multiplication [19:34:26] <mru> alloca is just as evil btw [19:34:41] <mru> it's almost exactly the same thing under a different name [19:38:25] <CIA-93> ffmpeg: reimar * r24862 /trunk/libavcodec/truemotion1.c: [19:38:25] <CIA-93> ffmpeg: Do not swap red and blue when decoding truemotion [19:38:25] <CIA-93> ffmpeg: on big-endian. [19:39:50] <funman> the GNU89 name? [19:40:21] <mru> alloca is non-standard but widely supported [19:40:50] <mru> memory from alloca remains allocated until the containing function returns [19:41:02] <mru> VLAs are released when they go out of scope [19:41:29] <CIA-93> ffmpeg: reimar * r24863 /trunk/libavcodec/truemotion1.c: [19:41:29] <CIA-93> ffmpeg: Since the 24 bit format is decoded to endian-dependant [19:41:29] <CIA-93> ffmpeg: BGR32 and not BGR24, do not swap red and blue on big-endian [19:41:29] <CIA-93> ffmpeg: for this format as well. [19:42:08] <iive> so if vla is not used in the function anymore it is released? [19:43:33] <Kovensky> no, it's released when it goes out of scope :) [19:43:40] <Kovensky> as in you can't possibly use it anymore [19:45:36] <mru> I suppose the compiler might release whenever it can prove it won't be used again [19:46:02] <mru> the important difference is if used in a loop, alloca() accumulates, VLA doesn't [19:46:15] <mru> but more importantly, neither should be used, ever [19:46:39] <ods15> <@mru> VLAs are released when they go out of scope - i'm not 100% sure about that [19:46:47] <mru> I am [19:47:20] <ods15> i vaguely remember looking at the assembly and seeing that gcc prepares some things in the begginning of the function in accordance to how many vla's are inside it [19:47:27] <ods15> ok, you're sure then [19:47:37] <mru> I didn't say they had no effect outside their scope [19:47:52] <ods15> anyway, besides performance and possible crash, anything else bad about vla i should know? [19:48:00] <mru> gcc sets up a frame pointer and such at the start of the function if there's a vla anywhere in it [19:48:03] <ods15> (in what universe is vla slower than malloc?...) [19:48:28] <mru> slower than fixed-size array [19:48:38] <ods15> that's obvious [19:48:39] <mru> and there is never a legitimate reason for using them [19:48:53] <ods15> i differ on that opinion [19:49:12] <mru> if you can prove the maximum size is acceptable for stack, use a statically-sized array of that size [19:49:20] <mru> if you can't, you must use malloc anyway [19:49:39] <ods15> anyway, i'll totally grant those 2 disadvantages, perf and safety (stack overflows truely are bad(tm)), i'm just wondering if there are other disdavantages i should be aware [19:50:09] <mru> do you care about pre-c99 compilers? [19:50:27] <ods15> not at work for sure [19:50:43] <ods15> in general, barely.. iirc even 2.95 supports them [19:50:50] <mru> btw, some compilers implement VLAs by calling malloc [19:50:59] <ods15> (some older gcc's, 3.*, have issues with sizeof of vla..) [19:51:32] <CIA-93> ffmpeg: reimar * r24864 /trunk/libavcodec/truemotion1.c: [19:51:32] <CIA-93> ffmpeg: The 24-bit ydt also should not depend on endianness, [19:51:32] <CIA-93> ffmpeg: since all of it ends up in a single 32-bit pixel. [19:51:32] <CIA-93> ffmpeg: This seems likely to be wrong though, since it is different [19:51:32] <CIA-93> ffmpeg: from the 15 and 16 bit modes and might explain the half-width [19:51:32] <CIA-93> ffmpeg: issue for 24 bit truemotion. [19:53:16] <ods15> that's interesting.. which? not gcc i expect [19:53:28] <mru> no, not gcc [19:54:57] <ods15> we have a bit of an odd rule at work, no malloc at runtime... i rarely need vla's, but i usually preffer them over some random MAX define [19:55:12] <peloverde> hmm... sws is 12% faster than the chrome scaler [19:55:49] <ods15> peloverde, which scaler does firefox use? libporn or whatever it use, is just for decoding? [19:56:08] <peloverde> ods15: I don't do firefox [19:56:41] <peloverde> chrome internals are hideous enough for mew [19:57:03] <ods15> chrome took me hours to compile.. [19:57:21] <peloverde> chrome is very memory intensive to compile [19:57:49] <peloverde> since i upgraded to 6GB it builds fairly quickly [19:58:24] <mru> no malloc is a perfectly normal rule in a realtime system [19:59:06] <ods15> mru, ok, didn't realize it was common [20:01:02] <peloverde> I tend to prefer a no-malloc rule [20:01:07] <mru> it's very hard to make any guarantees about malloc [20:01:14] <mru> simpler to just not use it [20:01:56] <mru> a pool allocator can be acceptable [20:02:02] <mru> if you can prove you never run out [20:04:11] <ods15> yeah, we constantly use pools, and it's then not a matter of proving, just a matter of setting maximums... [20:11:39] <Kovensky> <@peloverde> chrome is very memory intensive to compile <-- and to run [20:11:46] <Kovensky> even firefox uses less ram than it :/ [20:11:53] <peloverde> RAM is cheap [20:11:59] <Kovensky> DDR400 isn't [20:14:56] <mru> who uses ddr400? [20:14:58] <Compn> i have some laptop ram, but i dont know if it will work with michaels' laptop [20:15:53] <Compn> that ram with the LEDs are strange man [20:16:05] <Compn> green/red leds to tell you if your memory is good/bad haha [20:17:36] <ismail> I am not even sure over-expensive macbook pros have DDR400 [20:18:39] <J_Darnley> mru: people with athlon64's, etc [20:19:00] <mru> who uses athlon64? [20:19:12] * J_Darnley raises his hand [20:19:21] <Kovensky> mru: every computer in here but the craptop (ddr2) and the new one (ddr3) use ddr400 [20:19:27] <Kovensky> and they have semprons [20:31:25] <BBB> I hope I can sort-of push zhentan to finish mmsu at least, even though soc is over... [20:31:51] <cartman> how many projects successfully done ? [20:31:58] <BBB> all 7 [20:32:08] <BBB> not all are completely finished, but most are functional at least [20:32:13] <BBB> i.e. on the roads to being submitted to svn [20:32:23] <peloverde> wow [20:32:40] <BBB> I think amrwb is the most widely anticipated [20:32:47] <cartman> indeed :) [20:33:01] <BBB> it's functional, being reviewed now, then will go to -devel for inclusion [20:33:12] <BBB> form what I understand at least [20:33:27] <BBB> then we can remove opencore and will have completely LGPLv2.1-compatible amr decoding stack [20:33:44] <mru> I don't like the mod player [20:33:54] <BBB> code, or person? [20:33:56] <mru> both [20:34:01] <BBB> I knew you'd say that [20:34:05] <mru> I get the feeling he's trying dump a crapton of old code into ffmpeg [20:34:25] <mru> without proper design or code review [20:34:27] <cartman> \o/ [20:34:29] <BBB> that's why I'm trying to stop stefano from committing it so "we can work on it in svn" [20:34:38] <BBB> and I'm pushing for patches for review [20:34:48] <BBB> not "here's a patch for lavseq versioning" [20:34:52] <mru> yeah [20:35:11] <BBB> but rather "here's all patches, here's what they are required for, here's what they do and let's review what parts are really neessary for a function such as mod file playback" [20:35:18] <cartman> wmv3 encoder done too? [20:35:22] <BBB> but most people don't quite get that, and of course it's a lot of work... [20:35:24] <BBB> cartman: ? [20:35:38] <cartman> looking at http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010 [20:35:42] <cartman> guess thats outdated [20:35:52] <BBB> right [20:35:59] <BBB> not all of those were accepted ;) [20:36:01] <BBB> they were ideas [20:36:09] <cartman> uhm ok :) [20:36:14] <kierank> dolby e is near completion too [20:36:20] <kierank> just need to fix some more bugs [20:36:34] <BBB> http://socghop.appspot.com/gsoc/org/home/google/gsoc2010/ffmpeg [20:37:14] <cartman> G.723.1 Decoder/Encoder is nice too [20:37:20] <BBB> kierank: is it helpful if I go thorugh the code as it is now for a basic review? [20:37:22] <cartman> LGPL ftw! [20:37:33] <BBB> he finished the encoder also [20:37:36] <BBB> that's really awesome [20:37:49] <BBB> I hope he keeps contributing, he's quite smart, and we can use more such encoders, if they're good [20:37:59] <kierank> BBB: not with the current patch you have because it's changed a lot [20:38:06] <BBB> ok... [20:39:00] <cartman> if all the decoding bits are LGPL that would be quite a win :) [20:40:02] <BBB> I'm quite sure all is lgpl :) [20:40:13] <cartman> amr was missing :) [20:41:01] <BBB> so many things are still missing [20:41:12] <BBB> that's work ;) [20:41:40] <cartman> many? whats missing except amr? [20:41:50] <BBB> dolby-e :-p [20:42:06] <cartman> uhm [20:42:10] <cartman> ok :P [20:42:17] <BBB> wmv3 (not vc1), vp6 several frame types, wmv2 some weird frame type [20:42:23] <BBB> vp7 [20:42:35] <BBB> is that enough, or do you want more? [20:42:46] <BBB> wma lossless, realaudio lossless [20:42:51] <cartman> BBB: beats me [20:44:32] <iive> BBB: wmv2 is complete [20:44:44] <BBB> oh [20:45:55] <ods15> wtf is this... http://www.openpkg.org/product/packages/?package=libnut [20:46:03] <ods15> "Vendor Oded Shimon et al." [20:46:27] <cartman> you are such a vendor ods15 [20:46:35] <ods15> lol [20:48:30] <BBB> iive: I thought one frame type was not implemented? [20:49:46] <cartman> BBB: yeah thats fixed long time ago [20:49:51] <cartman> by anonymous the mad coder [20:49:59] <cartman> I love anonymous [20:51:28] <BBB> well the others are still standing :-p [20:51:58] <cartman> yeah anonymous is slacking [20:52:05] <pJok> i know what is missing...! [20:52:15] <pJok> 8bit RLE! [20:52:23] <pJok> (encoder) [20:58:17] <CIA-93> ffmpeg: vitor * r24865 /trunk/tests/ (ref/fate/ansi fate2.mak): Add FATE test for ANSI/ASCII animation and TTY demuxer [20:59:54] <BBB> ascii video codec [20:59:57] <BBB> that's what we need [21:01:08] <cartman> yeah ascii pr0n perverts [21:01:57] <BBB> well at least modern shells give you color ascii pr0n [21:07:31] <peloverde> Expression Screen Codec, ProRes, Apple Intermediate [21:14:41] <peloverde> Is there a description of SWS_FAST_BILINEAR vs SWS_BILINEAR anywhere? [21:18:43] <Kovensky> fast is probably faster than the non-fast one, unless it's like the FAST_MODE code, then the non-fast one is faster [21:24:30] <peloverde> Is there a quality difference? [21:24:44] <peloverde> Is there any documentation? [21:25:27] <peloverde> Who allowed swscale to become part of FFmpeg without appropriate documentation? [21:26:04] <peloverde> I thought people were just complaining about "dump[ing] a crapton of old code into ffmpeg" [21:32:56] <BBB> peloverde: ask user questions on ffmpeg-user :-p </waiting to be kickban'ed> [21:33:25] <BBB> I thought swscale was pretty ok'ishly documented btw? [21:35:48] <peloverde> The quality flags seem to have no documentation unless I'm looking in the wrong place [21:39:00] <peloverde> hmmm... I had done a debug build my mistake, chromium bilinear seems much faster than SWS_FAST_BILINEAR unless I'm still doing something wrong [21:40:05] <peloverde> There is this but it's pre-pure-LGPL swscale: http://www.bluishcoder.co.nz/2010/02/19/comparing-colour-space-conversion-l… [21:50:43] <BBB> does chromium use our code? [21:50:50] <peloverde> not at the moment [21:50:57] <BBB> what's their license? [21:51:07] <peloverde> Something BSD-ish [21:51:12] <BBB> take it [21:53:16] <Kovensky> isn't libswscale a pile of stuff nobody ever wants to look at [21:53:50] <kierank> get google to pay for lgpl [21:54:07] <peloverde> swscale is lgpl [21:56:17] <kierank> is all the asm lgpl now too? [21:56:41] <peloverde> This whole thing is screwy i'm, getting valgrind errors not just in swscale but in their scaler too, and for their scaler I'm using their unmodified test code [21:56:46] <peloverde> kierank: yes [21:57:11] <kierank> oh, didn't know that [22:04:16] <BBB> if the asm is lgpl and google's bsd chromium code is still twice as afst [23:08:19] <kierank> anybody going to this: http://www.foms-workshop.org/foms2010OVC/ [23:09:36] <mmu_man> over the ocean for me [23:11:24] <kierank> we should have a proper one in europe [23:12:00] <kierank> with blackjack and... [23:13:22] <kierank> that one looks like the real xiphcon

1 0

IRC log for 2010-08-20
by irc＠mansr.com 21 Aug '10

21 Aug '10

[05:04:52] <thresh> moroning [05:16:56] <saintdev> is there a FHT anywhere in ffmpeg? [05:24:35] <saintdev> ahh. the FHT is just an all-real analog of the FFT [05:25:37] <saintdev> I wonder if I can just use the MDCT coefficients for this, like vorbis does? [05:26:26] <saintdev> question the second, do we have access to an all-real FFT? [05:28:29] <kshishkov> we have RDFT [05:28:46] <kshishkov> it's used for Bink audio, FFplay and somewhere else [05:28:57] <saintdev> Real-DFT, I take it? [05:32:07] <saintdev> I wonder if that would be close enough. Guess I should try using MDCT coeffs first. [07:28:56] <astrange> http://gmailblog.blogspot.com/2010/08/use-linux-now-you-can-video-chat-too.… [07:33:45] <kshishkov> okay, what codecs are there? [07:35:53] <astrange> i was hoping someone else would say [07:36:16] <av500> bink? [07:36:40] * kshishkov sends plushy Jar-Jar Binks to av500 [07:36:54] * av500 uses them for target practice [07:37:08] <kshishkov> astrange: strings on main decoder say something [07:37:14] <kshishkov> hmm, Lmi H.264 encoder [07:37:40] <av500> what is a .deb anyway? [07:38:10] <kshishkov> g.711, PCM, isac/isaclc, iLBC, G.722, GSm, Speex, [07:38:28] <kshishkov> av500: installation package for Debian/Ubuntu. Tar xzf should unpack it [07:38:57] <kshishkov> and H.263 [07:39:35] <kshishkov> H.264 SVC? hmmm [07:40:45] <thresh> tar wouldnt unpack it [07:40:52] * kshishkov makes av500 wear T-shirt "I liked Wesley character from TNG!" while he's not watching [07:40:59] <thresh> or would it? [07:41:06] <av500> ar -x [07:41:12] <thresh> i always that it is ar+cpio [07:41:13] <thresh> yeah [07:41:18] <thresh> +thought [07:41:28] <kshishkov> whatever, it's standard archive anyway [07:41:33] <kshishkov> (unlike RPM) [07:41:48] <thresh> ORLY [07:42:04] <av500> great, rpm vs deb war!!! [07:42:15] <kshishkov> thresh: ÐŽÐ°, ÐŸÑÐ»Ñ [07:42:38] * kshishkov is long time Fedora user [07:43:12] <kshishkov> personally I don't care about package format much, be it .deb, .rpm or .tgz [07:43:33] <thresh> rpm2cpio ftw [07:43:50] <kshishkov> I know [07:44:12] * kshishkov preferred Midnight Commander to browse them all anyway [07:44:23] * av500 found "Hello, world!" in libnpgtpo3dautoplugin.so, prepared to sue google [07:46:24] <kshishkov> av500: use Word 2000 to write letter, Clippy will be happy to assist you [07:47:02] <av500> hmm, word2000 is 1994 versions after word6? [07:47:15] <av500> it must have improved a lot then... [07:47:17] <kshishkov> nope [07:48:14] <kshishkov> they got word6, then word 95-97, then word 2000, then 16-bit overflow so they settled with XP [08:15:52] <superdump> kshishkov: i tried some trocadero from an OKQ8 yesterday [08:16:03] <superdump> it was a bit too fizzy straight out of the bottle [08:16:09] <superdump> but the flavour was quite refreshing [08:24:24] <kshishkov> superdump: you haven't tried Julmust/PÃ¥skmust then [08:24:44] <superdump> must? [08:24:48] <superdump> what's that? [08:24:58] <mru> a drink [08:24:59] <mru> or two [08:25:03] <kshishkov> http://en.wikipedia.org/wiki/Julmust [08:26:38] <superdump> yeah [08:26:45] <av500> malzbier? [08:26:50] <superdump> lol @ coca cola AB [08:26:59] <superdump> just to produce coca cola julmust [08:27:06] <superdump> because it impacts on their sales so much [08:27:23] * superdump makes a note to check the brand of the julmust before buying [08:27:38] <superdump> i'm not a big fan of carbonated soft drinks though [08:27:42] <kshishkov> that article says it went out of production anyway [08:27:42] <superdump> i prefer still stuff [08:27:55] * kshishkov hates still water after visiting Denmark [08:28:35] <av500> kshishkov: dont drink the sea water! [08:29:40] <kshishkov> av500: I don't. [09:45:31] <av500> my pogoplug compatible runs ffmpeg :) [09:48:54] <mru> my sheeva is back in action [09:48:59] <mru> free of its shell [09:51:49] * mru finds a horrible design bug in swscale [09:51:52] <mru> s/a/another/ [09:53:24] <kshishkov> is that bug called "swscale"? [09:54:18] <kshishkov> well, it's originated from borrowed libmpeg2dec code in MPlayer so it's all hacks [09:54:42] <kshishkov> too bad that an effort to rewrite it failed [10:12:50] <mru> seriously though, this needs to be fixed [10:15:58] <av500> mru: http://ffmpeg.pastebin.com/yQj7E5EG [10:16:30] <mru> yes? [12:19:32] <lu_zero> mru: rewritten how? [12:21:19] <av500> in c++... [12:22:44] <lu_zero> av500: in haskell you mean [12:24:00] <av500> pascel? [12:25:45] <lu_zero> pascal? [12:25:51] <lu_zero> erlang! [12:25:59] <lu_zero> let's rewrite all in erlang! [12:34:09] <kshishkov> lu_zero: may I remind you where Erlang was developed and it makes sense for FFmpeg? [12:34:46] <KotH> let's do it in scheme [12:35:10] <kshishkov> ELisp is more popular [12:37:28] <thresh> this what google gave me for 'people who code on erlang': http://1.bp.blogspot.com/_bXDgUoT7V7o/Sk4AeAT0K7I/AAAAAAAAANA/5lDV0iMS_V8/s… [12:37:49] <thresh> i could never be as awesome as erlang programmers :( [12:37:51] <av500> new coders on the block? [12:37:58] <kshishkov> yep, looks better than people who code in PHP [12:38:08] <kshishkov> err, s/people/monkeys/ [12:39:51] <Tjoppen> I've wondered why swscale isn't built to be able to cobble together transforms on its own. it seems rather "mechanical" atm [12:41:03] <KotH> thresh: i remember when people were walkin dressed like that on the streets :) [12:41:05] <cartman> thresh: lol [12:41:27] <thresh> KotH: I do too. Last year. [12:41:32] <KotH> lol [12:41:44] <KotH> did you fall in a space-time virtex? [12:42:06] <thresh> yes, isnt it the translation of Russia in european languages? [12:43:14] <thresh> seriously, jackets like red one are hugely popular here [12:43:27] <thresh> among other 'I AM A RACER' like ones [12:46:26] <kshishkov> ÐŒÐ°Ð»ÐžÐœÐŸÐ²ÑÐµ Ð¿ÐžÐŽÐ¶Ð°ÐºÐž, Ð·ÐŸÐ»ÐŸÑÑÐµ ÑÐµÐ¿Ðž [12:47:40] <thresh> kshishkov: ÑÑÐŸ Ð¿ÐŸÐ·Ð°Ð¿ÑÐŸÑÐ»ÑÐ¹ Ð³ÐŸÐŽ :) [12:48:11] <kshishkov> thresh: Ð° Ñ ÐºÐŸÐœÐºÑÐµÑÐœÑÑ Ð¿Ð°ÑÐ°ÐœÐŸÐ² ÐŸÐœÐŸ Ð²ÑÐµÐ³ÐŽÐ° Ð² ÐŒÐŸÐŽÐµ, ÑÐµÐ°Ð»ÑÐœÐ°! [13:00:54] <mru> lu_zero: I said fixed, not (necessarily) rewritten [13:01:16] <kshishkov> sometimes it's the only appropriate fix [13:01:19] <mru> right now there's code doing one unaligned load per pixel [13:01:24] <mru> obviously a bad idea [13:04:28] <mru> KotH: space-time virtex? some new all-powerful fpga? [13:04:29] <kshishkov> hmm, is that why that one test fails on many systems making FATE more yellow than it should be? [13:04:34] <mru> yes [13:05:14] <kshishkov> mru: probably in his case it was "vortex" typo. Or could be an abbreviation for "virtual technology" [13:05:15] <KotH> mru: juup.. all powered by an improbability field [13:14:54] <lu_zero> KotH: I want one! [13:24:39] <KotH> lu_zero: they're available, quite cheaply, at CERN :) [13:25:01] <av500> so, ask mru sister for some [13:25:36] <kshishkov> av500: I thought you're going to ask her for pet llama offspring for your kids [13:25:52] <mru> different sister [13:26:36] <lu_zero> mru: you don't have other siblings? [13:26:38] * KotH doesnt think that non-plush lamas are a good gift for kids [13:26:43] <av500> kshishkov: I would love to see pet llama offspring going through the CERN black hole [13:27:01] <av500> I guess it will take the whole family to pull that off [13:28:10] <lu_zero> av500: just to have a quantum roast llama? [13:28:46] <av500> lu_zero: yes, goes well with the pumpkin soup [13:29:14] <lu_zero> uhmm [13:29:20] <lu_zero> pumpkin soup [13:29:20] <KotH> is today no-ffmail day or something? [13:29:21] <lu_zero> yum [13:29:30] * lu_zero is 1/2 ill [13:29:44] * KotH got worried when he had a look at todays mail stats [13:29:51] <lu_zero> and my crazy partners want to go camping in the mountains [13:30:01] <lu_zero> =E [13:30:14] <KotH> lu_zero: do i know them? :) [13:30:49] <lu_zero> I doubt [13:30:58] <KotH> do they know me? [13:31:00] <av500> crazy mountain folks [13:31:05] <av500> they should [13:31:15] <av500> you are from montain country too [13:31:36] <lu_zero> one is Puria and you might know him [13:31:38] * KotH will be in the mountains this evening [13:31:43] <kshishkov> av500: don't say that to somebody with nickname abbreviated from "Kurd of the Helvetia" [13:31:49] <KotH> to translate japanese <-> swiss german [13:31:58] * thresh will be in mountains next year, if lucky [13:32:05] <KotH> thresh: you'll be in .ch? [13:32:09] <lu_zero> the other is Alessandro Molina [13:32:21] <thresh> KotH: no idea, probably not (too expensive) [13:32:37] * kshishkov was in Basle around a month ago [13:32:42] <lu_zero> 15:31 < KotH> to translate japanese <-> swiss german [13:32:45] <lu_zero> eh? [13:32:53] <KotH> lu_zero: the name allesandro molina rings a bell, but i cannot tell from where i might know him [13:32:54] <thresh> Bulgaria, France, Switzerland are sure guesses for next year... have to decide on two other vacation dates still [13:33:14] <KotH> lu_zero: you know, people hire other people to translate between different languages [13:33:29] * KotH got once hired to translate turkish <-> japanese at a wedding in zürich [13:33:37] <lu_zero> is the mix sounding strange [13:33:51] <KotH> strange people attract strange mixtures [13:33:52] <av500> KotH: also during wedding night? [13:34:03] <av500> sounds fun [13:34:07] <KotH> av500: there was no night left after the party :-) [13:34:21] <lu_zero> eheheh [13:34:33] <KotH> i think, it was 5am, when i finaly left [13:34:47] <lu_zero> KotH: japanese people drinking turkish alcool? [13:35:25] <kshishkov> lu_zero: yes, the best turkish alcohol blessed by imam [13:35:55] <lu_zero> kshishkov: alcohol is part of the turkish tradition... [13:36:04] <KotH> lu_zero: juup [13:36:10] <kshishkov> lu_zero: go tell that to Russians [13:36:38] <av500> that anis flavored stuff is more like an anti alcohol treatment to me [13:37:20] <thresh> kshishkov: alcohol is not a tradition here [13:37:25] <thresh> it's more of a everyday drink [13:37:28] <lu_zero> kshishkov: those are nearly edible fuel [13:38:19] <kshishkov> thresh: well, what about drunken fight on wedding? [13:38:52] <lu_zero> O_o? [13:41:44] <KotH> av500: did you do the mistake and drink raki pure? [13:41:59] <av500> instead of? [13:42:07] <av500> raki on the rocks? [13:42:15] <thresh> kshishkov: I will attend wedding tomorrow, so will check on this one! [13:42:18] <kshishkov> av500: ask iive about Gabrovo style of raki [13:42:35] <thresh> rakia owns [13:42:52] * thresh still has two bottles in a bar [13:43:19] * kshishkov points out that Ukraine owns more - there is no word "vodka" in Ukrainian [13:43:47] <thresh> so Ukrainians not only steal gas from us, you steal words too! [13:45:18] <kshishkov> thresh: no, it's other languages stole your word, Ukrainian simply doesn't have it (maybe it was stolen by Russians?) [13:48:05] <lu_zero> kshishkov: what's the traditional drink then? [13:48:23] <thresh> russian blood [13:49:14] <kshishkov> horilka [13:50:35] <kshishkov> lu_zero: and Russian traditional drink is "anything that burns" [13:50:46] <thresh> true [13:55:13] <lu_zero> ah... [14:08:00] <KotH> av500: raki is diluded 1:3 and drunk with a cup of yoghurt to cool the burn :) [14:08:19] <KotH> av500: only the die hard alcoholics drink it pure [14:11:50] <av500> ah, so thats why you buy so much yoghurt... [14:15:50] <KotH> nah.. that's for ayran :) [14:20:44] <CIA-93> ffmpeg: stefano * r24842 /trunk/libavfilter/avfilter.h: [14:20:44] <CIA-93> ffmpeg: Cosmetics: add an empty newline between the function description and [14:20:44] <CIA-93> ffmpeg: the list of @params. [14:20:44] <CIA-93> ffmpeg: Improve consistency and possibly enhance readability. [14:22:55] <lu_zero> ayran is wonderful [14:23:03] <lu_zero> (with some mint leaves) [14:24:29] <cartman> lu_zero: thats yummy indeed [14:26:38] <KotH> salut Rathann|BlackHole [14:27:48] <Rathann|work> salut KotH [14:28:52] <kierank> black holes have internet? [14:29:04] <av500> at cern, yes [14:29:08] <av500> they invented it [14:29:26] <Rathann|work> and the increased gravity makes it go faster, too [14:29:31] <av500> al gore came out of one and brought it with him afaik [14:42:10] <CIA-93> ffmpeg: stefano * r24843 /trunk/libavfilter/avfilter.c: [14:42:10] <CIA-93> ffmpeg: Only print the pointer to the first plane in ff_dprintf_picref(). [14:42:10] <CIA-93> ffmpeg: To display the other planes is usually not useful and add noise to the [14:42:10] <CIA-93> ffmpeg: output. [14:42:10] <CIA-93> ffmpeg: stefano * r24844 /trunk/libavfilter/avfilter.c: Make ff_dprintf_picref() print video properties only if available. [14:42:12] <CIA-93> ffmpeg: stefano * r24845 /trunk/libavfilter/avfilter.c: [14:42:12] <CIA-93> ffmpeg: Extend ff_dprintf_picref() to make it print video interlaced and [14:42:12] <CIA-93> ffmpeg: top_field_first information. [15:11:54] <BBB> punpcklbw 1(%1), %%mm0 \n\t <- what does that 1(%1) mean? [15:12:28] <mru> %1 is the second operand to the asm block [15:12:37] <Dark_Shikari> 1(%1) means [%1+1] [15:12:43] <BBB> ah [15:12:47] <BBB> inline asm is weird [15:12:52] <Dark_Shikari> duhr [15:12:53] <mru> different syntax [15:12:56] <peloverde> x86 is weird [15:13:03] <mru> neither is more weird than the other really [15:13:08] <Dark_Shikari> I don't think x86 is at fault for gcc inlining sucking [15:16:51] <CIA-93> ffmpeg: stefano * r24846 /trunk/libavfilter/ (avfilter.c internal.h): [15:16:51] <CIA-93> ffmpeg: Rename ff_dprintf_picref() to ff_dprintf_ref(). [15:16:51] <CIA-93> ffmpeg: The function is going to be used to represent also audio data. [15:16:51] <CIA-93> ffmpeg: stefano * r24847 /trunk/libavfilter/avfilter.c: [15:16:51] <CIA-93> ffmpeg: Make ff_dprintf_ref() print the information related to the referenced [15:16:51] <CIA-93> ffmpeg: AVFilterBuffer. [15:16:52] <CIA-93> ffmpeg: stefano * r24848 /trunk/libavfilter/avfilter.c: Cosmetics: merge two lines in ff_dprintf_ref(). [15:16:52] <CIA-93> ffmpeg: stefano * r24849 /trunk/libavfilter/avfilter.c: Make ff_dprintf_ref() print audio related information if available. [15:19:41] <roozhou> is it possible to put label to put label in offset? e.g. label1(%1) [15:49:04] <CIA-93> libswscale: ramiro * r31984 /trunk/libswscale/utils.c: [15:49:04] <CIA-93> libswscale: fix anonymous memory mapping for NetBSD [15:49:04] <CIA-93> libswscale: mmap() with MAP_ANONYMOUS requires the file descriptor to be -1 in NetBSD. [15:49:04] <CIA-93> libswscale: Linux just ignores this parameter. [15:49:04] <CIA-93> libswscale: Patch by Grant Carver <grantc at cat dot co dot za> [16:35:31] <CIA-93> ffmpeg: stefano * r24850 /trunk/libavcore/imgutils.h: Add missing period in av_fill_image_max_pixstep() doxy. [16:47:53] * mru enables unaligned access trapping on all his fate systems [16:48:04] <mru> maybe this will get someone's attention [16:48:14] <kshishkov> including x86? [16:48:25] <mru> of course not [16:48:44] <mru> only unaligned that can't be done in hw [16:48:50] <kshishkov> well, it helped a bit with RV40 IIRC [16:49:11] <mru> or put differently, I'm disabling unaligned fixup in kernel [16:49:31] <kshishkov> that sounds more correct [16:50:40] <mru> so soon there'll be lots and lots of yellow [16:51:04] <Dark_Shikari> can you modify it so we can tell the difference between a failure and a crash? [16:51:08] <Dark_Shikari> e.g. invalid output vs crash [16:51:12] <Dark_Shikari> that would be rather nice [16:51:30] <mru> open the details [16:51:41] <mru> either the full report or click the arrow at the end of the line [16:51:56] <mru> it says things like BUS or SEGV when it crashes [16:52:31] <Dark_Shikari> Yeah, but it would be nice to sort [16:52:37] <Dark_Shikari> i.e. to see which ones are crashes BEFORE clickong on each one [16:52:48] <Dark_Shikari> so we don't have to manually search [16:52:49] <av500> rss feed? [16:52:52] <Dark_Shikari> I mean color coding [16:52:59] <Dark_Shikari> say, yellow test ---> invalid output [16:53:01] <Dark_Shikari> red ---> crash [16:53:02] <mru> I don't understand what you want [16:53:08] <Dark_Shikari> invalid output == yellow [16:53:10] <Dark_Shikari> SIGX --> red [16:53:11] <av500> mru: colours [16:53:13] <mru> you mean if _any_ test crashes -> red [16:53:14] <mru> ? [16:53:16] <Dark_Shikari> no [16:53:19] <Dark_Shikari> I mean in the LIST of failed tests [16:53:36] <Dark_Shikari> Oh, it already has that. [16:53:36] <kshishkov> colour-code return value for each test [16:53:38] <CIA-93> ffmpeg: stefano * r24851 /trunk/ (6 files in 2 dirs): [16:53:38] <CIA-93> ffmpeg: Rename av_fill_image_max_pixstep() to av_fill_image_max_pixsteps(). [16:53:38] <CIA-93> ffmpeg: The plural form is preferred as it is more consistent with the other functions: [16:53:38] <CIA-93> ffmpeg: av_fill_image_linesizes() [16:53:38] <CIA-93> ffmpeg: av_fill_image_pointers() [16:53:38] <CIA-93> ffmpeg: and looks semantically more correct as it fills an array of elements. [16:53:43] <Dark_Shikari> It's just not color coded [16:53:45] <Dark_Shikari> I missed the column [16:53:46] <mru> yes [16:53:59] <Dark_Shikari> looks good then [16:56:32] <CIA-93> ffmpeg: stefano * r24852 /trunk/doc/APIchanges: Add APIchanges for av_fill_image_max_pixstep() rename of r24851. [17:03:09] <mru> meanwhile, anyone care to take a quick look at the swscale issue? [17:03:23] <mru> warning: your head will spin and your eyes will bleed [17:03:53] * kshishkov values his eyes too much [17:04:05] <mru> try having the code read to you [17:05:35] <mru> maybe I should get evil and fire up the old sgi/irix machine [17:05:54] <kshishkov> please do [17:06:26] <mru> dual 200MHz R10k [17:06:59] <mru> or maybe install tru64 on the other alpha [17:25:22] <av500> --enable-gpl --enable-libfaac --enable-libfaad [17:25:27] <av500> does that work? [17:26:03] <Dark_Shikari> no, you need nonfree [17:26:26] <av500> well, seagate did not think so [17:26:49] <av500> and -formats says both faad and faac present [17:26:59] <Dark_Shikari> old version of ffmpeg [17:27:02] <Dark_Shikari> prior to the nonfree requirement [17:27:04] <av500> 0.5 [17:30:20] <peloverde> Just because it wasn't blocked by configure doesn't make it legit [17:30:36] <av500> thats what i think [17:32:51] <av500> the supported codec list on that seagate dockstar aka pogoplug is impressive [17:33:13] <peloverde> that said, when 0.5 was released people thought it was legit, so it's easy to claim ignorance [17:33:52] * peloverde blames menno since it's exactly the same as the issue lame used to have and surely he was aware of that [17:36:34] <kshishkov> av500: anything not supported by FFmpeg? [17:38:24] <Dark_Shikari> mru: which systems are unaligned trapping enabled on? [17:38:31] <av500> kshishkov: ? [17:38:38] <kshishkov> alpha and probably mips [17:38:43] <Dark_Shikari> not ppc? [17:39:02] <Dark_Shikari> lavfi-pixfmts_scale_le failed with a sigbus, hah [17:39:13] <kshishkov> av500: you said pogoplug codec list was impressive, so I ask if it will impress me [17:39:20] <av500> no [17:39:57] <av500> it will impress people in expensive suits... [17:46:27] <peloverde> It looks like they are using r15625 [17:47:11] <kshishkov> av500: BTW, are you hinting we should sue them before anybody else does? [17:47:27] <av500> yeah, get the little money they have [17:48:40] <kshishkov> well, you can get payment in their harddrives [17:48:57] <kshishkov> so we can get 10TB incoming filedump [17:49:44] <av500> kshishkov: so, it will just fill up quickly, regardless of the size.... [17:50:03] <kshishkov> it will, but it will save us some time [17:50:16] <av500> nah, ppl will just upload larger files [17:50:26] <kshishkov> just forbid uploading MPEG streams or anime [17:50:29] <av500> like full 4k 3D greenray rips [17:50:46] <av500> with the smell track [17:51:21] <kshishkov> that will be fun to debug [18:20:20] <mru> Dark_Shikari: alpha, mips, and armv5 have full trapping [18:20:40] <mru> and mips64 of course [18:20:57] <kshishkov> and Chinese MIPS [18:21:12] <mru> yeah, calling it mips64 is actually incorrect [18:21:16] <mru> but it's close enough [18:21:40] <kshishkov> there's official MIPS64 anyway [18:21:44] <mru> yes [18:21:49] <mru> it differs slightly [18:22:12] <mru> there's mips64 v2 (or r2) as well [18:22:19] <kshishkov> nobody cares about it, MIPS-III seems to be good enough for majority [18:22:30] <mru> it has some very nice additions [18:22:44] <mru> like mul with register destination [18:22:51] <mru> lets you do more than one mul ever 5 cycles [18:26:51] <mru> curious that dv fails with gcc 4.4 on alpha [18:26:56] <mru> that's worth looking into [18:27:17] <kshishkov> it would be more curious if it failed with suncc on solaris [18:29:37] <CIA-93> ffmpeg: fenrir * r24853 /trunk/libavcodec/mpegvideo.c: (log message trimmed) [18:29:38] <CIA-93> ffmpeg: Fixed mpeg12 top field first flag value with field picture encoding. [18:29:38] <CIA-93> ffmpeg: The relevent extract of the iso 13818-2 about the value of the syntaxical [18:29:38] <CIA-93> ffmpeg: element top_field_first of the Picture Coding Extension is: [18:29:38] <CIA-93> ffmpeg: "top_field_first -- The meaning of this element depends upon picture_structure, [18:29:38] <CIA-93> ffmpeg: progressive_sequence and repeat_first_field. [18:29:38] <CIA-93> ffmpeg: [...] [19:39:48] <BBB> I think I'm gonna give up on this mc setting, I can't get it faster than original code no matter what I try :( [19:40:26] <Dark_Shikari> BBB: that's what I thought [19:40:27] <BBB> Dark_Shikari: how much faster was your coreavc0D/ 1D/2D MC compared to always-2D? [19:40:34] <Dark_Shikari> a good bit [19:40:42] <Dark_Shikari> here's how it worked [19:40:45] <BBB> so why can't I get it faster? [19:40:49] <Dark_Shikari> if(!mx) {do 1D} [19:40:52] <Dark_Shikari> if(!my) {do 1D} [19:40:57] <Dark_Shikari> in the !mx, it check if(!my) at the start. [19:41:18] <BBB> right, so that's what we do for width=8 already [19:41:23] <BBB> but not for width=4/width=2 [19:41:28] <BBB> probably because the gain is too small [19:42:02] <BBB> so that was all in one function, is what you're saying? [19:42:09] <Dark_Shikari> I'm not sure about width4 [19:42:10] <BBB> (ather than having several smaller functions for each case) [19:42:26] <BBB> I can test, that's not the problem [19:42:41] <BBB> I'm just wondering if I'm using the wrong approach or if my result makes sense [19:43:01] <BBB> and clearly having many small functions is slower than having a few bigger functions [19:43:09] <BBB> as per my measurements [19:50:36] <CIA-93> ffmpeg: mru * r24854 /trunk/libavcodec/dv.c: dv: fix alignment of scratch buffer [19:52:39] * mru decides against waiting for dv maintainer review [19:53:33] <kshishkov> "DV maintainer drunk"? [19:53:51] <mru> he hasn't been heard from in a long time [19:54:18] <kshishkov> year-long binges are not that rare in RUssia yet I agree with you [19:56:56] <mru> he didn't live in russia last time I saw him [19:57:11] <kshishkov> I know [19:57:37] <kshishkov> but who knows where he is now and what he does, his company is nonexistent [19:57:40] <mru> what's worse, he was at the time going for a full month without drinking due to losing a bet [20:09:08] <Compn> hmm [20:09:17] <Compn> wasnt there a patch posted to implement some 10bit codec ? [20:09:19] * Compn cant find it [20:11:58] <kierank> r10k you mean [20:12:20] <Compn> yes, thats it [20:12:32] * Compn kept searching for v210 ; [20:13:05] <pJok> 10bit is out soon anyways [20:13:23] <pJok> i heard 16bit float will be the new thing... [20:29:53] <BBB> Dark_Shikari: no, it's slower also :( [20:30:11] <BBB> either that or my asm skills are very crappy [20:30:28] <mru> or both [20:32:56] <BBB> quite possibly [22:50:24] <saintd3v> peloverde: did you see the patches i sent to the ML? [22:50:31] <peloverde> yes [23:06:02] <saintd3v> ok, cool. i know you said it would be a little before you could review them. just wanted to make sure you didn't miss them. [23:09:46] <Dark_Shikari> 08:34 < blight_> i thought av_resample functions would do resampling without changing pitch...? [23:09:49] <Dark_Shikari> ] [23:09:49] <Dark_Shikari> 09:06 < PovAddict> blight_: unfortunately I think you need to call av_wishful_thinking() first for that to work [23:17:42] <CIA-93> ffmpeg: stefano * r24855 /trunk/doc/filters.texi: Add AUDIO FILTERS section. [23:17:43] <CIA-93> ffmpeg: stefano * r24856 /trunk/ (5 files in 2 dirs): [23:17:43] <CIA-93> ffmpeg: Add null audio filter. [23:17:43] <CIA-93> ffmpeg: Patch by S.N. Hemanth Meenakshisundaram -af smeenaks,ucsd,edu.

1 0