[FFmpeg-devel-irc] IRC log for 2010-08-30

[irc at mansr.com]

[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-Server?from=rss <--- 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.html.csp
[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.html#i386-and-x86_002d64-Options
[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/W98NT42KMeXP/EN-US/6channel.exe
[15:52:03] <Compn> http://download.microsoft.com/download/6/b/1/6b17045c-6ce8-4dc4-a3b5-2717b8711fc8/8Channel.exe
[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.aspx#link6
[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/FFmpeg.cpp#794
[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 at 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 at 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-conformance/referencesWav/al17_44.wav