[FFmpeg-devel-irc] IRC log for 2010-09-16

[irc at mansr.com]

[01:44:03] <BBB> \o/ hadamard_mmx/mmx2 work... now on to the easier ones (sse2/ssse3)
[01:44:08] <BBB> and then win64 fate is fixed finally
[01:45:35] <Dark_Shikari> And then you can come do xvp8.
[01:46:11] <BBB> yes :-p
[01:46:20] <BBB> dude, isn't it cool that win64 will finally work?
[01:46:27] <BBB> you of all people should care
[01:46:31] <BBB> you run that crap
[01:46:49] <Dark_Shikari> no, I run 32-bit apps on my win64
[01:46:49] <Dark_Shikari> lol
[01:46:58] <Dark_Shikari> because 64-bit avisynth is broken
[01:47:00] <BBB> now you can run 64-bit ffmpeg :-p
[01:48:03] <Dark_Shikari> it still can't read from 32-bit avisynth
[01:48:56] <Dark_Shikari> but yeah, win64 working is good
[01:48:59] <Dark_Shikari> now ramiro can re-add it!
[01:49:04] <Dark_Shikari> and actually, this means x264 win64 is fixed
[01:49:13] <Dark_Shikari> woohoo =p
[01:53:12] <astrange> does win64 have something like IOSurface?
[01:53:42] <astrange> which is an easy way of mapping pixel buffers/opengl textures between processes
[01:54:05] <Dark_Shikari> that'd still require a complete api rewrite
[01:54:20] <glYoda> astrange no
[01:54:39] <glYoda> (at least concerning the GL API)
[01:54:39] <astrange> start a 32-bit helper process for each plugin you want to load and talk between them
[01:54:56] <astrange> probably doable no matter how poor the ipc is and how much you need to hack up the host avisynth
[02:00:24] <Dark_Shikari> it's doable, for sure, but it'd be horribly bitchy
[02:00:29] <Dark_Shikari> you might as well just do avs2yuv
[02:15:52] <BBB> patch posted
[02:16:04] <BBB> I'll commit tomorrow or so
[02:16:06] * BBB sleep
[02:17:15] <BBB> Dark_Shikari: isn't ASB1_MMX a mmx2 variant?
[02:17:24] <BBB> I'll commit a mmx-only ABS1_MMX also
[02:19:00] <BBB> (see PABSW_MMX and MMX2)
[06:29:59] <ohsix> wat http://hothardware.com/image_popup.aspx?image=big_idf-2010-keynote-53.jpg&articleid=1561&t=a
[06:31:46] <av500> intel added cupboard acceleration?
[06:31:47] <superdump> ohsix: what is that trying to show?
[06:32:24] <superdump> unless it's 'you can only render this with one but this with the other'
[06:32:37] <superdump> the carpet and wallpaper is different too
[06:32:39] <ohsix> how awesome it is; your guess is as good as mine, intel does a lot of crap like that
[06:38:57] <cartman> av500: damn you
[06:43:06] <superdump> ohhh, i know
[06:43:15] <superdump> ohsix: i bet they're videos
[06:43:22] <superdump> or real-time renders
[06:43:34] <superdump> so you can see the frame rate difference
[06:43:43] <superdump> and yet, the second one can have more stuff in it too
[06:45:27] <av500> cartman: damn you too
[06:45:40] <cartman> av500: I had a question for you last night :(
[06:45:47] <av500> i had a need for sleep
[06:45:54] <av500> but i figured you'd be back
[06:45:57] <cartman> av500: right
[06:46:02] <cartman> I was asleep :P
[06:46:27] <cartman> av500: question is how good http://www.archos.com/products/ta/archos_101it/index.html?country=tr&lang=en ?
[06:46:45] <av500> i hope it is good
[06:46:55] <cartman> av500: me too, but is it 2.1?
[06:47:53] * cartman notes that his company has a great interest in Android tablets too
[06:50:43] <superdump> cartman: you mean android 2.1?
[06:50:48] <cartman> superdump: yeah
[06:50:48] <superdump> on the tech specs page it says 2.2
[06:50:55] <cartman> oh
[06:50:57] <cartman> thanks :)
[06:51:27] <cartman> av500: onether question, are you gonna release a tablet with 3.0 sooner or later? :P
[06:51:33] * cartman sets av500 -v
[06:53:25] <av500> cartman: its 2.1 atm and will be 2.2 soon
[06:53:40] <cartman> 3.0 not in horizon yet I guess
[06:53:44] <av500> cartman: lend me your crystal ball and i will answer all questions about >2.2
[06:53:51] <av500> or ninja into google HQ
[06:53:53] <cartman> yup ok
[06:53:57] <cartman> guessed so
[06:54:05] <cartman> av500: how good is the touch screen? :)
[06:54:34] <av500> it reacts on touches
[06:54:43] <av500> pretty amazing, uh?
[06:59:27] <thresh> that is different from what we have now
[07:00:18] <lu_zero> av500: just touches or stylus input is working as well?
[07:01:02] <cartman> lu_zero: can't be
[07:01:08] <cartman> there is no hybrid system
[07:01:14] <cartman> either capacitive or resistive
[07:01:53] <lu_zero> uhm
[07:02:04] <wbs> cartman: unless you use a sausage stylus! ;P
[07:02:07] <cartman> stylus systems are resistive
[07:02:15] <cartman> yeah sausage works for capacitive :D
[07:02:23] <mru> only resistive respond to stylus
[07:02:32] <mru> they can be used with finger too
[07:02:42] <cartman> not fun to use with finger
[07:02:45] <cartman> need to use nails
[07:02:47] <mru> but are usually less accurate than capacitive with fingers
[07:02:56] <Dark_Shikari> touch screens are never fun to use with fingers
[07:03:03] <Dark_Shikari> unless you like hilarious inaccuracy and unresponsiveness
[07:03:09] <cartman> Dark_Shikari: unless you are writing capactive is good
[07:03:22] <Dark_Shikari> I've never found a capacitive touch screen that wasn't horrible
[07:03:33] <cartman> big icons to save the day
[07:03:41] <Dark_Shikari> I never really liked styluses either, but at least when you tried to do X, they would do X.
[07:04:12] * thresh likes stylus on his palm t5
[07:04:16] <thresh> s/likes/liked/
[07:04:24] <cartman> there are actually some hybrid systems in development
[07:04:33] <cartman> when a special pen touches they become resistive
[07:04:41] <cartman> and capacitve otherwise
[07:04:53] <av500> you can buy "fat" pens that work on capacitive
[07:04:56] <Dark_Shikari> so in other words, after I smudge the screen to hell
[07:05:01] <Dark_Shikari> *then* I can decide to use my finger.
[07:05:03] <cartman> :D
[07:05:08] <Dark_Shikari> er, to not use my finger
[07:05:17] <cartman> av500: stop being useless btw, I just asked you a simple q.
[07:05:45] <av500> cartman: actually, i cant say atm
[07:05:49] <thresh> back in 2004, T5 looked cool in metropolitan and attracted chicks.
[07:05:50] <cartman> av500: thats ok
[07:05:59] <cartman> thresh: works for iPad these days
[07:06:10] <cartman> is that a huge iPhone or what
[07:06:26] <thresh> cartman: you have to be gay to use that though :(
[07:06:40] <cartman> thresh: won't comment, my boss have one :P
[07:07:02] <mru> http://www.wulffmorgenthaler.com/default.aspx?id=86c5551c-48dc-4e20-a71e-a8f5d9e8badb
[07:07:36] <cartman> lol
[07:13:39] <cartman> http://dilbert.com/strips/comic/2010-09-16/
[07:20:21] <kshishkov> cartman: actually Dilbert strip from yesterday featured no dumb things said by PHB, only obvious ones
[07:21:01] <cartman> ;>
[07:27:03] <Dark_Shikari> from an email thread at my company regarding encoders
[07:27:04] <Dark_Shikari> "The quality was excellent on a LAN" is about as meaningful as saying
[07:27:05] <Dark_Shikari> that "this sports car goes really fast when it's falling off a cliff."
[07:27:31] <cartman> Dark_Shikari: good analogy
[07:28:19] <kshishkov> Dark_Shikari:
[07:28:31] <kshishkov> not very good analogy
[07:29:06] <kshishkov> it's rather "my sport car has no problems turning even on high speed in clear field"
[07:29:54] <Dark_Shikari> Yeah but that's not as funny.
[07:31:22] <kshishkov> "that's like killing fish in a barrel. From elephant gun. With two attempts"
[07:32:28] <cartman> <insert some funny analogy here />
[07:51:51] * mru wonders what the problem might be with threads on sparc/openbsd
[07:53:21] <kshishkov> very "special" implementation
[07:53:40] <kshishkov> but IIRC pthreads were based on Sun stuff
[07:54:50] <CIA-63> libswscale: ramiro * r32256 /trunk/libswscale/swscale-test.c: swscale-test: always use bilinear scaler to get output for SSD
[07:54:53] <CIA-63> libswscale: ramiro * r32257 /trunk/libswscale/swscale.c: swscale: factorize plane copying code out of 2 functions
[07:54:53] <CIA-63> libswscale: ramiro * r32258 /trunk/libswscale/swscale.c: swscale: remove useless temporary variable
[08:30:57] <CIA-63> ffmpeg: cehoyos * r25129 /trunk/libavcodec/libmp3lame.c: Remove useless comment.
[08:32:10] <pasteeater> has anyone mentioned that current doesn't configure correctly when --enable-libmp3lame?
[08:32:24] <mru> elaborate
[08:33:37] <mru> works for me
[08:33:45] <spaam> same here :)
[08:34:24] <pasteeater> http://pastebin.com/nUbyYriV
[08:34:48] <spaam> upgrade lame :)
[08:35:02] <pasteeater> yes. i just realized this after i pasted.
[08:35:25] <kshishkov> also it mentions different IRC channel
[08:35:56] <CIA-63> ffmpeg: stefano * r25130 /trunk/doc/filters.texi:
[08:35:56] <CIA-63> ffmpeg: Prefer "X" over ``X'', looks more readable and more consistent with
[08:35:56] <CIA-63> ffmpeg: the rest of FFmpeg docs.
[08:36:00] <pasteeater> well, if the current revision breaks something i usually report it here
[08:36:11] <mru> well, that's wrong
[08:36:11] <pasteeater> but i'll stay in #ffmpeg for now
[08:38:07] <CIA-63> ffmpeg: stefano * r25131 /trunk/doc/filters.texi: Fix grammar in the ocv_smooth filter documentation.
[08:48:20] <CIA-63> ffmpeg: stefano * r25132 /trunk/libavfilter/vf_libopencv.c: Fix copyright notice, make it more consistent with the rest of FFmpeg.
[08:48:22] <CIA-63> ffmpeg: stefano * r25133 /trunk/libavfilter/vf_libopencv.c: Use <> for system headers inclusion.
[08:48:22] <CIA-63> ffmpeg: stefano * r25134 /trunk/libavfilter/vf_libopencv.c: Cosmetics: fix weird align.
[08:52:00] <mru> hi DonDiego
[08:52:28] <DonDiego> moin
[09:21:15] <DonDiego> the evil typedeffer from italy has arrived
[09:21:17] <DonDiego> ;)
[09:22:11] <kshishkov> well, yesterday somebody posted a work of evil French typedeffer here on IRC
[09:22:26] <mru> that was me
[09:22:28] <DonDiego> *gasp*
[09:22:31] <mru> typedef void Void;
[09:23:23] <DonDiego> typedef int float;
[09:23:32] <av500> so mru is now an evil French typedeffer
[09:23:45] <mru> DonDiego: that's an error
[09:23:53] <mru> you can't redefine existing types
[09:24:06] <kshishkov> av500: mere poster of evil French typedeffer deeds
[09:24:16] <funman> if it's void, it doesn't exist?
[09:24:16] <kshishkov> use #define
[09:24:53] <mru> typedef void null;
[09:24:58] <mru> now it's both null and void
[09:25:07] <kshishkov> sounds a bit like Bible
[09:26:17] <funman> should we teach typedefionism in schools?
[09:26:46] <kshishkov> no, just provide eutanasy for people who abuse it
[10:31:29] <KotH> a wonderfull good morning everyone!
[10:31:33] <av500> +1
[10:31:41] <thresh> :(
[10:32:34] <andoma> \o/
[10:33:38] <kshishkov> KotH: too late
[10:33:54] <KotH> sorry dude, i just came in
[10:34:28] <andoma> KotH: http://apina.biz/34073.jpg
[10:34:35] <andoma> sfw
[10:35:03] <merbzt> http://oddlyspecific.com/2010/08/18/funny-signs-thats-what-he-said/
[10:35:14] <andoma> av500: wrong channel!
[10:36:13] <av500> wuz?
[10:36:32] <andoma> err
[10:36:39] <andoma> my irc-client screwed up
[10:37:33] <andoma> windoeswitching in irssi sometimes leaves some text from a previous window
[10:37:44] <kshishkov> andoma: have you started your morning like pictured in that ad?
[10:38:10] <andoma> kshishkov: not in a very long time
[10:41:32] <merbzt> 2 bottles now
[10:42:25] <andoma> :)
[11:18:16] <KotH> http://m.xkcd.com/793/
[11:18:29] <KotH> (not safe for phyisicists)
[11:19:05] <kshishkov> safer than nerd sniping
[12:00:56] <lu_zero> kshishkov: you use nerds as ammo?
[12:10:46] <elenril> http://xkcd.com/356/
[12:12:58] <BBB> hehe :)
[12:15:40] <pJok> http://ark.intel.com/ProductCollection.aspx?series=52490 x86 now with NEON, AltiVec and 3DNow! ?
[12:16:00] <lu_zero> O_o
[12:16:20] <Dark_Shikari> ? where does it say that
[12:16:38] <pJok> Dark_Shikari, it doesnt... it was the FPGA part that made me say that...
[12:16:47] <Dark_Shikari> what fpga?
[12:17:26] <pJok> http://www.slashgear.com/intel-stellarton-atom-e600fpga-promises-flexible-embedded-devices-14102251/
[12:18:04] <Dark_Shikari> I doubt the fpgas are synchronous enough to do instructions like that
[12:18:18] <pJok> i wouldn't know
[12:18:20] <twnqx> depends if the coupling allows you to attach instructions to the decoder
[12:18:25] <pJok> but it was just a silly thought
[12:18:33] <twnqx> xilinx' virtex 4-6 with embedded power pc core allow it...
[12:20:21] <pJok> i dont think anyone will be bothered optimizing ffmpeg for that processor though
[12:29:51] <jannau> DonDiego: I'm procrastinating on LATM
[12:31:59] * jannau declares DonDiego and saste as combined concurrent commit winners
[12:34:12] <jannau> mru: I think the postproc changes are the only chnages that modifies identical files in different places
[12:35:01] <mru> there have been some other moves
[12:35:03] <jannau> at least all remaining commits with identical timestamps are genuine
[12:35:10] <mru> maybe someone managed to fix them in svn
[12:36:19] * kshishkov uses a bit of necromancy
[12:36:27] <kshishkov> when do we officially switch to git?
[12:36:48] <_av500_> soon
[12:36:49] <_av500_> after gsoc
[12:37:40] <jannau> mru: I'll push my tree and publish the script later today
[12:38:12] <mru> push?
[12:39:19] <kshishkov> _av500_: what year gsoc?
[12:39:25] <mru> the last one
[12:39:48] <_av500_> the next one
[12:39:49] <mru> he said "after gsoc", not "after year xxxx gsoc"
[12:39:55] <jannau> mru: to git.jannau.net
[12:40:03] <Dark_Shikari> mru: 2020 is after 2010
[12:40:04] <_av500_> gsoc has not even started
[12:40:30] <jannau> maybe he ment after google stops gsoc
[12:40:37] <mru> !
[12:41:36] <kshishkov> maybe I should fork my own FFmpeg and not commit to it either
[12:43:18] * pJok forks kshishkovs FFmpeg and refuses to commit to it
[13:00:52] <DonDiego> jannau: stop procrastinating please :)
[13:02:48] <jannau> I have, but LATM is so annoying
[13:02:55] <jannau> +to
[13:03:54] <DonDiego> say
[13:04:16] <DonDiego> does anybody have some suggestions for a piece of nice code (possibly even in ffmpeg) to showcase?
[13:04:29] <mru> be more specific
[13:04:39] <kshishkov> "return 0;"
[13:04:52] <kshishkov> nice and optimistic
[13:05:17] <DonDiego> i need a piece of code for the biweekly code review session
[13:05:37] <mru> typedef void Void;
[13:05:46] <mru> with a comment in French
[13:06:09] <DonDiego> i'm open to serious replies
[13:06:38] <mru> what is your objective?
[13:06:56] * mru has some objectionable C here...
[13:07:06] <DonDiego> we have this biweekly meeting where we do code reviews at uni
[13:07:14] <kshishkov> libavcodec/rv40.c function rv40_loop_filter()
[13:07:18] <DonDiego> somebody asked to see some nice code for a change
[13:08:03] <DonDiego> kshishkov: no, that function is too simple
[13:08:03] <DonDiego> ;)
[13:08:26] <kshishkov> mru: objectionable C is a special language for Apple OS
[13:08:39] <Dark_Shikari> DonDiego: ah
[13:08:45] <Dark_Shikari> interesting
[13:09:26] <DonDiego> now if only i could locate some suitable piece of code..
[13:09:30] <kshishkov> DonDiego: take libavcodec/motion_est.c then
[13:09:33] <Dark_Shikari> LOL
[13:09:43] <mru> swscale.c
[13:09:52] * kshishkov likes build_vlc()
[13:10:02] <kshishkov> mru: swscale_template.h actually
[13:10:03] * elenril thinks obvious mru is obvious
[13:10:08] <mru> vp8.c isn't so bad
[13:10:18] <mru> aacdec is ok
[13:10:31] <Dark_Shikari> the main problem is that a lot of code I consider "good" is also heavily optimized
[13:10:36] <Dark_Shikari> and thus often not written in the most obvious fashion
[13:11:50] <kshishkov> DonDiego: libavcodec/bink.c read_dct_coeffs(), nice code (and I'd be grateful if somebody explains to me how it works)
[13:12:03] <Dark_Shikari> lol
[13:12:19] <kshishkov> Dark_Shikari: ok, you volunteered
[13:12:48] <Dark_Shikari> I mean, I can't think of any particularly "good" code in x264.  Nearly everything is either:
[13:12:51] <Dark_Shikari> a) decent
[13:12:58] <Dark_Shikari> b) optimized too heavily to use as a good example
[13:13:03] <Dark_Shikari> c) old code that hurts my eyes
[13:26:06] <DonDiego> both vp8.c and aacdec.c are a tad bit complex..
[13:26:52] <mru> so take one function
[13:39:35] <lu_zero> DonDiego: how simple it should be?
[13:40:12] <mru> av_clip_uint8()?
[13:43:06] <kshishkov> libavcodec/aura.c
[13:43:28] <mru> dsputil_mmx.c
[13:45:38] <jannau> http://git.jannau.net/git/FFmpeg.swscale/
[13:46:02] <lu_zero> uh
[13:46:07] <lu_zero> the merge?
[13:46:27] <jannau> yes
[13:46:42] * lu_zero hugs jannau 
[13:47:00] <lu_zero> what is preventing us to switch?
[13:47:09] <mru> my lack of time
[13:47:42] <lu_zero> uhmm
[13:47:51] <mru> jannau: how hard is it to update that with the latest commits?
[13:50:38] <jannau> not hard, it has to rewrite the libswscale repo to move it into a subdir, cherry pick the commits in right order and fix the committer_name|email|date
[13:51:04] <mru> I know what it does
[13:51:16] <mru> so you have to redo the whole thing to update it?
[13:51:59] <jannau> no, just I jsut have to redo the libswscale repo rewrite
[13:52:21] <mru> well, that _is_ the whole thing pretty much
[13:52:21] <jannau> then it's enough to pick the new commits
[13:52:28] <mru> yeah, true
[13:52:59] <lu_zero> jannau: simple cherry-pick won't do?
[13:53:14] <mru> lu_zero: it needs to be moved into the right directory
[13:53:21] <jannau> and the libswscale rewrite only needs to be done for libswscale commits obviously
[13:54:17] <kshishkov> and Sundays in Germany are ideal for such work
[13:55:10] <mru> I'd rather do this when I'm not stuck on a flaky shared wifi
[13:55:14] <jannau> the whole script needs currently 46mins. 25 minutes alone fix the committer_name|email|date after cherry-picking
[13:55:48] <lu_zero> I was sure that there was a way to tell git to consider an offset
[13:56:06] <mru> jannau: can you rewrite the commiters replacing glantau with bellard and tmmmm with melanson?
[13:56:12] <kshishkov> mru: it was rather stable on Gdium ;)
[13:56:40] <mru> kshishkov: the wifi itself is mostly stable
[13:56:45] <mru> the external line is not
[13:57:40] <jannau> mru: sure. for the final repo we should probably ask who wants to have his full name and email in the commits
[13:57:52] <kshishkov> mru: yes, I remember that now
[13:57:57] <mru> jannau: that would be nice
[13:58:27] <mru> even better if you could grep for 'patch by' and set the correct author
[14:18:24] <jannau> is al3x == alex? and Ramiro == ramiro?
[14:18:36] <DonDiego> yes
[14:18:37] <mru> ramiro is ramiro
[14:18:51] <DonDiego> you may wish to look at the ohloh.net page of ffmpeg
[14:19:08] <DonDiego> duplicate committer names are merged ther
[14:19:09] <DonDiego> e
[14:19:10] <mru> it's the ones with multiple committer names I'd mostly like to see merged
[14:19:30] <jannau> who is uid46427
[14:19:38] <mru> iirc michael has had more than one too
[14:19:44] <DonDiego> i already went to that trouble for ohloh.net, you don't need to duplicate it
[14:19:51] <jannau> yes, micheal michealni
[14:20:56] <DonDiego> uid46427?
[14:21:18] <jannau> DonDiego: http://www.ohloh.net/p/ffmpeg/contributors/19252190931446
[14:21:27] <lu_zero> btw
[14:21:42] <lu_zero> do you know if ffplay mixes well with libsdl 1.3?
[14:22:12] * lu_zero is going further with his android perversions and tried to make an ffplay working using libsdl1.3 ...
[14:22:29] <DonDiego> hrmpf
[14:22:34] <DonDiego> never noticed that one..
[14:24:40] <DonDiego> arpi?
[14:24:52] <DonDiego> do we have mailing list logs?
[14:25:30] <mru> the commits by that user say 'patch by michael niedermayer'
[14:25:38] <mru> so might as well credit him directly
[14:26:18] <DonDiego> yeah, i guess..
[14:26:29] <DonDiego> dunno if there was a ml back then..
[14:26:53] <mru> there was
[14:27:13] <DonDiego> so where are the archives?
[14:28:43] <DonDiego> i cannot find archives on sf.net anymore
[14:28:49] <jannau> r248 doesn't but it's simple enough to ignore
[14:29:36] <DonDiego> why not fix some commit messages while you're at it?
[14:29:49] <mru> DonDiego: only you are able to do that
[14:30:02] <mru> nobody else cares enough
[14:30:12] <mru> yes, bad messages are annoying
[14:30:45] <DonDiego> i'm just talking about obvious things, like cutting down the ones that are 10000000000 chars long in one line
[14:31:05] <mru> still a lot of work for little gain
[14:34:09] <jannau> DonDiego: if you prepare something that fixes messages automatically sure. something that gets the original message on stdin and returns to the fixed message to stdout
[14:34:35] <mru> mailto dondiego?
[14:36:27] <jannau> bad round trip time. how fast can dondiego reply 25k mails
[14:37:02] <mru> about as many days I guess
[14:37:08] <mru> if you're lucky
[14:37:31] <KotH> modulo spaam filter
[14:38:03] <spaam> return -ERR
[14:38:33] <mru> ESPAAM
[14:38:43] <spaam> much better
[14:38:49] <jannau> too bad, average commit count per day is around 7
[14:39:11] <CIA-63> libswscale: ramiro * r32265 /trunk/libswscale/swscale-test.c: swscale-test: cosmetic alignment
[14:41:29] <KotH> jannau: ETOOMANYCOMMITSPERDAYFORDIEGOTOHANDLE
[14:41:44] <mru> EERRORCODETOOLONG
[14:43:35] <thresh> for die, go to handle?
[14:44:47] <kshishkov> for(die); goto handle
[14:55:36] <merbzt> is the ffmpeg url code supposed to be slow as hell ?
[14:56:05] <wbs> merbzt: no
[15:00:57] <merbzt> :/
[15:01:08] <lu_zero> merbzt: what's the problem?
[15:01:12] <merbzt> right now I get 0 fps from a http source
[15:02:30] <lu_zero> if you wget the file and pipe it it works better?
[15:03:15] <merbzt> cant pipe it
[15:03:37] <j-b> who would be able to do a h264 422 decoder in lavc?
[15:04:07] <wbs> merbzt: what format is it?
[15:05:04] <merbzt> fragmented mp4
[15:05:14] <lu_zero> merbzt: url?
[15:05:41] <wbs> hmm.. do we support that? :-)
[15:05:52] <merbzt> ttp://sme.labs.ericsson.net/ahs/fifa-hvga/
[15:05:53] <lu_zero> wbs: I'm wondering
[15:06:04] <merbzt> wbs: we do, but not ahs
[15:06:10] <wbs> anyway, if it doesn't work through a pipe and if it does lots and lots of seeks, we'd probably be very slow
[15:06:40] <merbzt> I think I just need a profiling run to see what happens
[15:06:54] <kshishkov> j-b: our elite - michael, Dark_Shikari, pengvado
[15:07:04] <lu_zero> avf produced?
[15:07:26] <lu_zero> merbzt: streamcopy it
[15:07:35] <lu_zero> and play the copy
[15:08:26] <merbzt> hmm, I'll try local playback first
[15:10:16] <merbzt> worx perfectly
[15:11:17] <merbzt> must be lots of seeks then
[15:11:33] <merbzt> is there a way to buffer the complete file ?
[15:11:48] <merbzt> or as much as possible
[15:14:02] <lu_zero> merbzt: -vcopy -acopy something.sane isn't an option?
[15:14:17] <lu_zero> -vcodec copy -acodec copy
[15:15:08] <merbzt> well it works ok if the files are locally
[15:15:26] <kierank> merbzt: does your server support proper range requests
[15:15:55] <kierank> because iirc on mp4 lavf will read a bit, seek to the end to pick up stuff then continue from the beginning
[15:16:15] <merbzt> kierank: yes, but fragments are coded as a large chungk of video then audio
[15:17:11] <merbzt> I think all the seeks cause a constant flush of buffers
[15:23:42] <DonDiego> mru, jannau, so you decided that uid464345357 is michael? i'll update ohloh then..
[15:25:41] <mru> no, it's whoever applied some patches from michael
[15:25:46] <mru> before he got cvs write access
[15:26:03] <CIA-63> ffmpeg: mru * r25135 /trunk/configure: configure: detect Open64 compiler
[15:26:12] <jannau> DonDiego: yes. a single 2 lines changed commit has no patch by michael so it it should be safe to attribute the changes to micheal
[15:26:57] <DonDiego> mru: no, r245 is from michael for example, earlier than the revs from uid454lj54543
[15:28:21] <mru> hmm
[15:28:44] <mru> was that a swscale commit?
[15:28:59] <mru> he may have had mplayer access before ffmpeg
[15:31:32] <jannau> DonDiego: that's a postproc commit that won't exists in the git repo
[15:31:34] <DonDiego> no, the uid46435345 commits were all libavcodec
[15:31:43] <DonDiego> jannau: why not?
[15:33:26] <jannau> because it belongs to postproc/libswscale
[15:34:38] <DonDiego> will that not be in the git repo?
[15:37:37] <mru> it will be there under a different name
[15:38:45] <mru> DonDiego: libswscale and libpostproc used to be in the same directory
[15:38:59] <DonDiego> umm,no..
[15:39:01] <mru> at some point libpostproc was moved to libavcodec/libpostproc
[15:39:13] <DonDiego> libpostproc was below libavcodec
[15:39:16] <mru> and at some other time the swscale files were moved to libswcale/
[15:39:21] <mru> DonDiego: before that
[15:39:30] <mru> this is really ancient history
[15:39:36] <mru> before anyone had even heard of you
[15:39:41] <DonDiego> better compare with ancient tarballs
[15:39:56] <mru> tarballs were scarce then
[15:39:59] <DonDiego> i had to stitch part of that stuff together from thin air when creating the svn repo
[15:40:07] <mru> yes, I know
[15:40:16] <DonDiego> i recreated a bunch of renames for example
[15:40:40] <KotH> .o0(the joys of long running projects)
[15:41:06] <mru> not that it really matters
[15:41:14] <mru> nobody is ever going to build that old code
[15:41:45] <mru> and the quality of commits is so poor that looking at them doesn't help much
[15:41:53] <jannau> DonDiego: all changes to libavcodec/libpostproc are also identically in mplayer/postproc
[15:42:08] <lu_zero> btw libvo gl is going to be imported in ffmpeg anytime soon?
[15:42:21] <mru> lu_zero: I hope not
[15:42:28] <lu_zero> mru: why?
[15:42:33] <mru> mplayer code sucks
[15:42:37] <mru> look at swscale
[15:42:38] <jannau> lu_zero: not before the the git conversion
[15:42:39] <DonDiego> jannau: that's a bug in the repo then i'm afraid
[15:42:44] <mru> we're still struggling to clean it up
[15:42:56] <mru> DonDiego: it's a side-effect of moving cvs files around
[15:42:57] <lu_zero> mru: did, got scared, lost sanity, I have a t-shirt reminding me
[15:43:11] <DonDiego> mru: yes, nobody knows that better than myself :)
[15:43:36] <DonDiego> maybe it's easier to fix this stuff in an svn test repo
[15:43:37] <lu_zero> still something that provides a gl/gles vo
[15:43:41] <DonDiego> talk to you guys later..
[15:43:43] <DonDiego> bbl
[15:43:46] <lu_zero> might be _quite_ useful
[15:43:52] <mru> how could anything possibly be easier to fix in svn?
[15:43:54] <jannau> DonDiego: yes, I've fixed it by removing all changes to libavcodec/libpostproc before Fri Feb 14 21:27:25 2003 +0000 and doing a proper move in the git repo
[15:45:20] <jannau> there's no need to fix it in a svn repo since it's already fixed in the git repo
[15:45:56] <DonDiego> mru: geez, stop trolling already..
[15:46:16] <mru> DonDiego touchy as usual
[15:46:27] <KotH> DonDiego: how can a troll stop being a troll?
[16:11:22] <jannau> email sent to ffmpeg-dev
[16:18:44] <mru> jannau: there are 2690 commits with 'patch by' in the message
[16:21:39] <jannau> mru: there are also several with: (commited by michael / arpi was crazy enough to give me his password)
[16:22:13] <mru> uh oh
[16:22:25] <jannau> those should be fixed
[16:22:29] <mru> and some 'based on patch by'
[16:23:38] <jannau> 14 with (commit[ed]* by micheal
[16:24:24] <jannau> not clear if we should change the "based on patch by" ones
[16:25:51] <mru> no, leave those
[16:42:58] <mru> lu_zero: I added open64 to fate
[16:44:10] <mru> path64 is no longer the worst performer
[17:05:51] <kierank> I'm wondering what is the most laughable device I can get fate working on
[17:11:18] <mru> what do you have around?
[17:12:27] <kierank> pentium pro 180mhz box, some crappy mips router
[17:12:35] <kierank> can't think of anything else
[17:12:48] <mru> no point running on those
[17:12:59] <iive> kierank: you do have working ppro!!
[17:13:07] <iive> we desperately need this one.
[17:13:13] <kierank> iive: hasn't been booted for years but i think it works
[17:13:31] <mru> iive: just to have that one i686 w/o mmx?
[17:13:33] <kierank> also it sucks power like there's no tomorrow
[17:13:54] <BBB> power consumption is a good reason to _not_ run on it
[17:15:07] <iive> kierank: i doubt it takes more than 200W
[17:15:25] <mru> I have alpha/tru64 and mips/irix systems to get up and running...
[18:45:52] <DonDiego> BBB: that ppro consumes little power compared to modern cpus..
[19:11:41] <jannau> DonDiego: not in relation to the computing power
[19:13:05] <DonDiego> if the computing power is "enough", then yes ;-p
[19:21:55] <jannau> I doubt that, full CPU on ppro 180mhz is is roughly idle on a modern cpu
[19:22:30] <jannau> and modern cpu should have lower idle power consumption thansaid ppro
[20:18:54] <Dark_Shikari> woo, awesome, vp8 neon!
[20:19:41] <j0sh> awesome
[20:32:44] <BBB> Dark_Shikari: you should review it
[20:33:04] <Dark_Shikari> I can't review neon
[20:33:07] <mru> I'll do it
[20:33:11] <mru> it needs work
[20:36:02] <BBB> of course it does, that's why you review it and not me
[20:36:07] <BBB> my review would be "this looks cool"
[20:36:09] <BBB> or so
[20:36:22] <BBB> it'd be about as insightful as my reviewing mmx code before I could write mmx
[20:36:23] <BBB> :-p
[20:36:35] <mru> I mean the code needs changes
[20:36:59] <BBB> I understood
[20:37:06] <BBB> I'll patiently await your review
[20:37:12] <mru> I won't do it today
[20:37:22] <BBB> I understand that too ;) I'm not pushing
[20:37:40] <cartman> where is the patch btw?
[20:37:45] <mru> mailing list
[20:38:49] <cartman> tx