[FFmpeg-devel-irc] IRC log for 2010-04-22

[irc at mansr.com]

[01:30:46] <hyc> hmm. http://ingenient.com/resources/video_codecs/MP4145-DEC-Datasheet-2009.03.18-v1.4.pdf
[01:31:07] <hyc> they only spec up to 352x480 for H.264MP decode on OMAP3
[01:31:29] <hyc> kind of an oddball resolution
[01:32:37] <Compn> widescreen ?
[01:32:51] <hyc> 352x480 is tallscreen :P
[01:32:58] <Compn> oh yeah :P
[01:33:32] <Compn> well horizontal is where its at, so they half ntsc dvd into that and anamorph it
[01:34:41] <hyc> sounds about right
[02:24:36] <ramiro> win64 builds are behaving oddly on av_find_stream_info(). it has code that uses double, and also calls decoders, which themselves use optimized code that use xmm registers and don't tell that to gcc. so after_try_decode_frame, the values that av_find_stream_info() had set up in some xmm registers are now bogus.
[02:25:07] <ramiro> could someone please sum up why that is bad on win64 again and how to fix it?
[02:28:12] <astrange> quick fix: write an asm wrapper around codec->decode() that saves and restores all the xmm registers
[02:28:32] <astrange> un-quick fix: every dsputil function needs to mention the xmm registers it uses in the asm clobber list
[02:34:29] <ramiro> astrange: for the quick fix, if any function inside codec->decode() uses doubles, it will screw up the same, right?
[02:35:42] <astrange> hmm possibly yes
[02:39:33] <Dark_Shikari> better fix: move everything to yasm
[02:41:04] <ramiro> Dark_Shikari: hm, why would that be a better fix?
[02:42:41] <Dark_Shikari> because yasm macros automatically handle win64 xmm clobbers
[02:42:47] <Dark_Shikari> without having to compile with -msse2
[02:45:04] <ramiro> if I remove -msse2 will that stop gcc from using the xmm registers for doubles?
[02:45:13] <ramiro> or use -mno-see2 or whatever
[02:45:15] <astrange> -msse not sse2, surely
[02:45:30] <astrange> if you disable it then it would ignore clobbers for it and not bother saving them, i guess
[02:45:37] <astrange> but it makes no sense to disable sse on x86-64
[03:29:20] <Compn> how much would it cost to have mplayer.c reviewed and cleaned up by a professional ? can ffmpeg foundation pay for this ? :P
[03:34:35] <Dark_Shikari> lol
[03:34:52] <Dark_Shikari> since when are we not professionals?
[03:35:01] <Compn> since when are you reviewing mplayer.c ?
[03:35:19] <Dark_Shikari> lol
[03:35:27] <Dark_Shikari> "we" includes you
[03:35:30] <Dark_Shikari> why aren't you reviewing it?
[03:35:32] <Compn> gasp
[03:35:49] <Compn> i'm actually looking at it right now
[03:36:33] <Compn> i'd like to use my super copy/paste skills, but i dont know what this static / extern char stuff is
[03:37:27] <Dark_Shikari> what's hard about static
[03:37:56] <Compn> probably nothing, i just havent read any programming books
[03:38:23] <Dark_Shikari> neither have I, not since grade school
[03:38:52] <Dark_Shikari> I don't understand, why would there be useful information about using C engraved on dead trees?
[03:39:04] <Compn> gotta start somewhere
[03:39:12] <Compn> guess i'll try wikipedia
[03:42:01] <Compn> no one took the wikipedia troll? ;\
[03:42:03] * Compn sleeps
[03:43:03] <Yuvi> hey, if you can learn how to program from reading wikipedia, I'll send you my hat
[03:43:25] <Compn> is it a nice hat ?
[03:43:43] <Yuvi> standard ballcap
[03:43:50] <Dark_Shikari> bah, that sucks
[03:43:53] <Dark_Shikari> I need a nice hat
[05:17:49] <_av500_> _/\
[05:19:31] <elenril> ~^~
[05:36:52] <KotH> grüezi
[05:51:59] <Dark_Shikari> how do I make gcc generate preprocessed source?
[05:52:08] <astrange> -E
[05:52:11] <Dark_Shikari> I have both gcc 4.4.3 and 4.6 segfaulting on the same code
[05:52:14] <astrange> it's like in the manual and stuff
[05:52:15] <Dark_Shikari> Which is pretty impressive
[05:52:27] <Dark_Shikari> If I submit a bug, should I submit it on 4.6 or 4.4.3?
[05:53:14] <astrange> 4.6 but stick both versions in the title
[05:53:17] <Dark_Shikari> ok
[05:58:13] <Dark_Shikari> their bug tracker doesn't seem to have a place in the submission form to put preproc'd source/
[05:58:55] <astrange> you can attach stuff in replies
[05:59:25] <Dark_Shikari> ok
[06:05:54] <DimStar> Good morning guys: anybody remembers the discussion we had yesterday about libswscale and the weird, empty function? It does not work with the #ifdef around the function block.See buildlog extract at http://www.pastebin.org/166998
[06:15:08] <DimStar> An updated patch, that changes the if (HAVE_7REGS) to #ifdef HAVE_7REGS can be found at: http://www.pastebin.org/167000 (fully untested... don't even know yet if it builds.. will let you know later)
[06:16:35] <Yuvi> DimStar: why are you changing HAVE_7REGS from always being defined?
[06:17:38] <DimStar> Yuvi: If it wuold always be defined I would not run into issues when building (like no-return-in-nonvoid function in _template.c... there was a lengthy discussion yesterday evening about this.
[06:17:59] <DimStar> I'm not changing the value of HAVE_7REGS by myself at any place.
[06:19:36] <DimStar> Yuvi: the two functions at the bottom of the patch: RENAME(yuva420_rgb32) for example... in some builds I see them 'empty', as the #ifdef is inside the {} block.
[06:19:38] <Yuvi> oh, you're moving the checks around to avoid warnings?
[06:19:48] <Yuvi> check #if HAVE_7REGS not #ifdef
[06:20:17] <DimStar> Yuvi: on openSUSE, we have code checks that abort a build on that specific warning (in this case it's arguably a false positive, in most cases it is not)
[06:20:43] <DimStar> Yuvi: yes, you're right about #if vs #ifdef... my bad.
[06:22:24] <DimStar> http://www.pastebin.org/167005 would be the result then
[06:28:58] <DimStar> I'll be back this evening...
[07:28:54] <wbs> who's got access to upload.ffmpeg.org and can move samples to samples.mplayerhq.hu?
[07:29:29] <KotH> o/
[07:29:31] <KotH> which ones?
[07:34:14] <wbs> KotH: I uploaded some to /amrnb-dtx-
[07:34:21] <av500> KotH: I uploaded an asf with chapters like a mo ago, would be nice to have it in samples
[07:34:24] <wbs> nodata yesterday
[07:34:54] <KotH> wbs: destination directory?
[07:35:05] <wbs> A-codecs/amr
[07:35:56] <KotH> av500: files? dest?
[07:36:08] <wbs> KotH: chmod the directory, too ;P
[07:36:12] <av500> something _with_shapters.asf...
[07:36:27] <KotH> wbs: done :)
[07:36:34] <KotH> wbs: ok like this?
[07:36:40] <KotH> wbs: or shal i rename anything?
[07:37:03] <wbs> I think this is ok, thanks!
[07:37:15] <KotH> av500: dest?
[07:37:32] <av500> asf_with_chapters.wmv
[07:37:50] <av500> asf-wmv I guess
[07:39:58] * KotH hates fucking "everything on the internet is for free" fags
[07:40:23] <av500> it is not?
[07:40:35] <KotH> recent exchange on webmaster at mphq
[07:40:56] <ohsix> the cost of duplicating information is indeed low
[07:40:58] <KotH> A: i cannot access samples.mphq anymore, can you help me?
[07:41:03] <KotH> US: what's your ip
[07:41:06] <KotH> A: <ip>
[07:41:20] <KotH> US: we banned you because of rules violation
[07:41:26] <KotH> A: please restore my access
[07:41:53] <ohsix> do you have a torrent for that stuff?
[07:42:06] <KotH> no word of appology, nothing
[07:42:25] <KotH> ohsix: for >40G of files that only a few are interesting to most people?
[07:42:27] <av500> he said "please"
[07:42:47] <av500> ohsix: i dount that torrent would live long
[07:42:51] <ohsix> heh, maybe he didn't know or connect up what he did to a violation
[07:43:01] <KotH> ohsix: go to samples.mphq
[07:43:05] <KotH> ohsix: what do you see there?
[07:43:22] <ohsix> torrents are always good
[07:43:37] <KotH> ohsix: feel free to create a torrent
[07:43:57] <KotH> ohsix: i'd give you also the permission to download all samples with max speed for this
[07:43:59] <ohsix> i'd have to get the files to create the metadata
[07:45:45] <av500> KotH: how about BOLD and RED for the relevent sentence?
[07:46:29] <ohsix> or ratelimit it at the source; contact for fast access
[07:48:37] <KotH> ohsix: you mean rate limit all access to samples to a total sum of 10kB/s ?
[07:48:55] <KotH> 'cause everything else would not work
[07:49:57] <ohsix> 50kbs, like on the info blurb; if people wanted to use multiple connections and get around it then they're jerks (though nginx or whatever could restrict that too)
[07:49:59] <KotH> av500: wer lesen kann ist klar im vorteil... und wer nicht, wird halt geblockt
[07:50:19] <av500> KotH: oder so :)
[07:50:21] <KotH> ohsix: limiting to 50kB/s per person would not help
[07:50:37] <KotH> ohsix: we have half china and russia wanting to download the samples
[07:51:00] <KotH> ohsix: that'd be a few hundert to a few thousand concurent downloads
[07:51:10] <KotH> -> way too much traffic
[07:52:17] * av500 wonders what they want them for
[07:52:22] <ohsix> heh, are the people who would mirror willing to join the torrent?
[07:52:46] <KotH> av500: i have no clue
[07:52:47] <ohsix> or order dvds for samples
[07:53:10] <KotH> av500: especially considering that more than half of the files are so obscure i even dont know what they are good for
[07:53:17] <av500> right
[07:53:41] <av500> thx for the move
[07:53:48] <KotH> ohsix: we cannot sell dvds.. if we do we would be liable for copyright violation and would have to pay compensation
[07:54:17] <av500> sell DVDs with crypted data, leak the key :)
[07:54:40] <KotH> ohsix: for most of the files, we do not have the right to distribute them. as long as we do not get any money from it, we're somewhat safe
[07:54:41] <ohsix> then dont; do what the mame people do and offer for the price of media, shipping and "good will"
[07:54:56] <KotH> ohsix: that's already enough
[07:55:18] <ohsix> its also not you; its the people who are willing to do it but ar eotherwise unaffiliated
[07:55:24] <KotH> ohsix: as soon as you touch money, you're a for-profit-entity
[07:55:36] <av500> ohsix: I would not try to test that
[07:56:20] <KotH> ohsix: the only legaly possible solution is to distribute over the inet for free
[07:56:29] <ohsix> thats an interesting thing to say considering how people feel about patents in here :>
[07:56:38] <KotH> well.. it's still not legal, but at least you are not liable for compensation
[07:56:48] <KotH> patents != copyright
[07:57:04] <KotH> these are two completely different things
[07:57:10] <KotH> (although mixed way too often)
[08:02:41] <ohsix> i was only speaking to the effort to get and stay into a grey area and defend it; unaffiliated people could start sending dvds and you wouldn't be liable
[08:04:15] <ohsix> you wouldn't have a problem demonstrating the intent of the archive
[08:06:55] <ohsix> and moreover you cant be held to the intent of any party that would do otherwise
[08:42:13] <lu_zero> mru: you around?
[08:42:47] <wbs> bcoudurier: thanks for the review, will address the comments soon :-)
[08:42:57] <lu_zero> good morning
[08:43:02] * lu_zero yawn
[08:43:02] <lu_zero> s
[08:43:33] <av500> t
[08:43:49] <lu_zero> hi av500 =P
[08:45:41] <wbs> bcoudurier: even if you wanted the muxer-related changes merged, I guess it's ok to keep the generic stuff from Yuvi's qt chapters as a separate patch, since I guess that will be applied quite soon anyway
[08:48:35] <Dark_Shikari> mru: awesome!  the official t-shirt of ffmpeg-devel
[08:48:36] <Dark_Shikari> http://www.despair.com/timeforaction.html
[08:54:53] <av500> Dark_Shikari: we could never agree on the color of such a shirt!
[08:55:26] <lu_zero> av500: black and white is fine if you can't pick a color, don't =P
[08:56:19] <CIA-7> ffmpeg: cehoyos * r22940 /trunk/ (ffplay.c ffmpeg.c):
[08:56:19] <CIA-7> ffmpeg: Fix compilation error of ffmpeg and ffplay with --disable-avdevice.
[08:56:19] <CIA-7> ffmpeg: Patch by Cyril Russo, stage D nexvision A laposte net
[08:58:21] <CIA-7> ffmpeg: cehoyos * r22941 /trunk/libavformat/riff.c:
[08:58:21] <CIA-7> ffmpeg: Support VP6F in Matroska.
[08:58:21] <CIA-7> ffmpeg: Patch by Christian Schmidt, schmidt digadd de
[09:05:28] <CIA-7> ffmpeg: thardin * r22942 /trunk/libavformat/flic.c: Made FLIC demuxer capable of handling the videos from "X-COM: Terror from the Deep".
[09:07:07] <Tjoppen> there, finally.
[09:11:19] <bilboed-pi> erf, vp6f riff code is ... FLV4 ? wtf :)
[09:11:32] <Dark_Shikari> why not
[09:11:43] <bilboed-pi> why not .. you know... VP6F ? :)
[09:11:51] <Yuvi> I think mplayer is to blame
[09:11:52] <Dark_Shikari> ask adobe
[09:12:07] <bilboed-pi> Dark_Shikari, ... is that *seriously* an official mapping ? :)
[09:12:11] <av500> adove puts VP6 in mkv?
[09:12:13] <Yuvi> and vp6f came after such files exist flash stores it upside down
[09:12:17] <Yuvi> exist since
[09:12:25] <bilboed-pi> I'd be more with Yuvi on this one
[09:13:13] <Yuvi> actually, maybe not
[09:13:21] <Yuvi> don't see it in codecs.conf
[09:15:52] <Yuvi> heh, wikipedia edit: 'There is no "h.264", only H.264'
[09:18:29] <Yuvi> now I think g-spot is to blame
[09:18:55] <av500> you found it?
[09:20:09] <Yuvi> either that or http://forum.doom9.org/showthread.php?t=113655
[09:20:48] <KotH> ohsix: you are free to do so
[09:20:52] <KotH> ohsix: i wont hold you back
[09:21:03] <KotH> ohsix: just let me know which ip you are comming from before you start a download :)
[09:24:02] <av500> KotH: please open 192.168.1.22 :)
[09:27:20] <KotH> it's open :)
[09:41:44] <CIA-7> ffmpeg: michael * r22943 /trunk/ffmpeg.c:
[09:41:44] <CIA-7> ffmpeg: Make sure ffmpeg chooses a supported samplerte if the encoder supports
[09:41:44] <CIA-7> ffmpeg: just some.
[09:42:33] <CIA-7> ffmpeg: michael * r22944 /trunk/libavcodec/ (libmp3lame.c mpegaudioenc.c): Set .supported_samplerates for mpeg audio encoders.
[09:48:11] <Tjoppen> ah, looks like michael noticed my suggestions yesterday
[09:49:28] <av500> next thing could be to add an avlog WARNING if the reqd rate does not match exatcly
[09:50:45] <Tjoppen> yep
[09:53:09] <KotH> ---
[09:53:11] <KotH> >> May I please request you to restore access to this collection.
[09:53:11] <KotH> > Yes, you may request it.
[09:53:12] <KotH> We would like to have access this collection. We hereby request you to unblock our IP and thereby enable us access the collection.
[09:53:15] <KotH> ---
[09:53:19] <KotH> .o0(stupidity prevails)
[09:54:25] <av500> hereby and thereby!
[09:55:31] <KotH> av500: $INDIAN_WORKING_FOR_BIG_OSCILLOSCOPE_MANUFACTURER
[09:58:04] <av500> gee, they play video on the scope
[09:58:23] * av500 looks at his nonvideo scope
[09:59:10] <bcoudurier> anyone familiar with dts here ?
[09:59:20] <av500> a tiny wee bit
[10:02:35] <bcoudurier> do you think you can set the frame size in the parser ? :)
[11:34:56] <BastyCDGS> hi 2 all
[11:44:13] <pJok> mornings BastyCDGS
[11:44:55] <mru> moroning
[11:44:55] <BastyCDGS> greetz pJok...i'm in office...a bit later here than yesterday
[11:45:02] <BastyCDGS> had to install git here too
[11:45:12] <BastyCDGS> and to transfer the ffmpeg stuff from home to here
[11:45:19] <BastyCDGS> but I'm ready to continue here as at home
[11:45:38] <BastyCDGS> mohoin mru & av500
[11:47:12] <BastyCDGS> yasm is installed here now too
[11:47:18] <BastyCDGS> test build was successful too
[11:47:28] <BastyCDGS> so it just can go on ;)
[11:51:23] <BastyCDGS> what's going on with you?
[12:04:28] <BastyCDGS> anything interesting ;)
[12:04:42] <BastyCDGS> ?
[12:04:57] <BastyCDGS> about that fg/bg colored messaging
[12:05:09] <BastyCDGS> it was stated that there's no way of determing the bg color
[12:05:14] <BastyCDGS> (high contrast algorithm)
[12:05:20] <BastyCDGS> so what we can do then?
[12:05:24] <mru> nothing
[12:05:51] <BastyCDGS> what's the problem with configure? if the params aren't passed the defaults are used
[12:06:29] <av500> it makes no sense
[12:06:32] <mru> it's useless bloat
[12:06:42] <av500> what mru said
[12:07:10] <BastyCDGS> so either use fixed fg/bg or drop the patch at all?
[12:07:17] <av500> just red
[12:07:20] <mru> I'd say drop the whole idea
[12:07:22] <BastyCDGS> or just use bold/italic
[12:07:26] <mru> it's impossible to do it cleanly
[12:07:29] <BastyCDGS> bold + blink = fatal
[12:07:32] <BastyCDGS> bold = err
[12:07:34] <BastyCDGS> italic = warn
[12:07:44] <mru> do not _ever_, under any circumstance, use blink
[12:07:49] <av500> what mru said
[12:08:03] <BastyCDGS> bold + italic = fatal? ;)
[12:08:07] <BastyCDGS> or bold + underline?
[12:08:19] <mru> most terminals can't do italic
[12:08:37] <BastyCDGS> underline isn't supported always, too?
[12:08:38] <hyc> I would swear that mru's last email came in bright red and blinking in my inbox :P
[12:09:15] <hyc> (responding to the configure options for color settings ... ;)
[12:09:19] <mru> if that's how you choose to configure your mail reader...
[12:09:43] <BastyCDGS> ;)
[12:10:08] <BastyCDGS> maybe then just bold for fatal + err
[12:10:16] <BastyCDGS> warn nothing
[12:10:32] <mru> people use the word fatal too lightly
[12:10:35] <mru> fatal means YOU DIE
[12:10:46] <hyc> I don't think warnings need any highlight
[12:10:58] <hyc> you can use bold or inverse
[12:11:02] <BastyCDGS> warn nothing sounds best to me then too...
[12:11:03] <hyc> for error
[12:11:31] <mru> this is all pointless
[12:11:43] <mru> people with a clue will read the error messages as they are
[12:11:52] <mru> people without one will ignore them even in red
[12:11:54] <BastyCDGS> I already stated yesterday I want it be off (default) anyways ;)
[12:11:56] <av500> mru: I would like errors in red
[12:12:08] <av500> but then I also like colorgcc
[12:12:13] <BastyCDGS> what about popping up 500 dialog boxes like in win on error :D
[12:12:14] <BastyCDGS> *gg*
[12:13:26] <mru> sure, I like colorgcc too
[12:13:29] <hyc> inverse, bold, bold+inverse
[12:13:54] <av500> red, bold
[12:13:55] <hyc> that's the pool of options I would consider most reliable
[12:14:08] <av500> red works on many backgrounds
[12:14:13] <av500> bold works on all
[12:14:29] <BastyCDGS> unless someone uses bold as default in a terminal hehe
[12:14:33] <mru> these idiots wouldn't see the error message if it were written in their own blood
[12:14:34] <BastyCDGS> but who does this
[12:14:34] <av500> his problem
[12:14:44] <av500> we are talkling std users
[12:14:55] <av500> the ones that mis error msgs
[12:14:58] <mru> my shell prompt is bold
[12:15:03] <mru> yellow
[12:15:04] <hyc> mine too
[12:15:12] <av500> you are all so bold!
[12:15:12] <mru> red if the last command exited with an error
[12:15:16] * BastyCDGS thinks how to build a device which writes the error message into their flesh...shall I post a patch? :D
[12:15:34] <hyc> I was just joking yesterday about "my background color is red" but still the point remains, using a fixed color is a bad idea
[12:15:41] <mru> turn up the power on the dvd drive's laser...
[12:16:02] <hyc> need an aiming mechanism :P
[12:16:04] <BastyCDGS> mru, neat idea...like I did a floppy music on m68k asm
[12:16:29] <hyc> mmm, we did floppy drive music back in the Apple II days
[12:16:30] <av500> can we have shades of red for lavc vs lavf vs lavu errors?
[12:16:44] <BastyCDGS> btw, does that work with CD/DVD drives, too? bring the laser to make music?
[12:16:55] <hyc> as Henry Ford said, any color you like, as long as it's black
[12:17:06] <mru> oh, and what about people reconfiguring the colours in their terminal?
[12:17:17] <mru> most terminals let you choose which actual colours to use
[12:17:20] <hyc> exactly
[12:17:27] <hyc> so again, bold and inverse are reliable
[12:17:33] <hyc> specific colors, not.
[12:17:52] <mru> inverse is ugly
[12:17:59] <hyc> errors are ugly
[12:18:02] <mru> people look away from ugly things
[12:18:05] <BastyCDGS> lol
[12:18:25] <hyc> if you want beautiful output, don't have errors :P
[12:19:38] <hyc> Why not just skip all this and put an extra blank line around error messages...
[12:19:45] <mru> the real problem is that the ffmpeg output is far too verbose by default
[12:19:53] <mru> error messages are masked by useless chatter
[12:21:39] <BastyCDGS> hyc: not a bad idea either, maybe also add some indentation?
[12:22:08] <FUautotools> People still won't see it
[12:22:10] <BastyCDGS> hey what about doing a sinus scroller for errors? *gg*
[12:22:11] <ohsix> and some ^V^G's
[12:22:29] <BastyCDGS> like in the good old intros ;)
[12:23:06] <hyc> too bad we can't use VT100 double-size character mode
[12:23:11] <mru> ugh
[12:23:12] <av500> btw, do we do this: http://utcc.utoronto.ca/~cks/space/blog/programming/HowToWriteToStderr
[12:23:32] <ohsix> does ffmpeg still use ncurses? sure you could
[12:23:51] <av500> ncurses for subtitles?
[12:23:52] <mru> oh, that's just someone who just discovered line buffering vs block buffering and thinks he's smart
[12:24:05] <mru> I'd rather not add an ncurses dependency
[12:24:32] <FUautotools> Perhaps I should drop the not-windows parts since you people can't agree on a standard terminal
[12:26:46] <BastyCDGS> hey
[12:26:48] <BastyCDGS> I have an idea
[12:26:56] <av500> cant we just start with error=red
[12:26:58] <BastyCDGS> what about defining the color via an environment variable
[12:27:02] <av500> and see how that works out
[12:27:09] <av500> BastyCDGS: it is foor n00bs
[12:27:12] <av500> not for us
[12:27:15] <BastyCDGS> if env = N/A = red
[12:27:18] <av500> ok
[12:27:23] <av500> and drop the env :)
[12:27:44] <FUautotools> Actually, I've got a better idea than colours...
[12:27:56] <BastyCDGS> FUautotools, then tell...
[12:28:02] <elenril> sounds?
[12:28:07] <FUautotools> prefix the messages with "Error: ", "Warning: ", etc
[12:28:18] <BastyCDGS> ERROR:
[12:28:27] <BastyCDGS> uppercase would be better...
[12:28:30] <av500> E_R_R_O_R_:
[12:28:38] <FUautotools> with \a\a\a
[12:29:10] <av500> $ banner error > stdout
[12:29:35] <hyc> gothic error
[12:29:42] <BastyCDGS> FUautotools: http://vanhu.free.fr/blog/public/guru-meditation.gif
[12:29:46] <BastyCDGS> what about this? ;)
[12:30:08] <FUautotools> Won't work on windows AFAICT
[12:30:14] <hyc> if audio output is still working, play some annoying alarm bell
[12:30:23] <BastyCDGS> was kidding ;)
[12:30:29] <BastyCDGS> \b
[12:30:34] <BastyCDGS> was bell
[12:30:41] <BastyCDGS> if i'm not wrong...
[12:30:45] <hyc> no, a wav file...
[12:31:15] <BastyCDGS> what \b does is OS dependent, on linux KDE/windows you can configure the OS either use pc speaker or a custom WAV
[12:31:40] <hyc> I wonder how many people use a VT52 or non-ansi terminal these days
[12:31:59] <KotH> in the us? quite a few
[12:32:04] <BastyCDGS> apart from this I'd be very careful about sound output
[12:32:14] <BastyCDGS> it's annoying when you're listening to music etc.
[12:32:20] <KotH> in the rest of the world: probably only very old legacy systems that nobody bothered to replace
[12:32:26] * BastyCDGS hates websites which output sound without asking
[12:32:53] <BastyCDGS> exception of course are sites like youtube where you expect that
[12:33:09] <FUautotools> Huh?  \b is a backspace \a is a bell
[12:33:10] <hyc> anyway... XBMC's logger prefixes all messages with the level
[12:33:22] <hyc> librtmp does that too
[12:33:22] <elenril> even sites like youtube shouldn't start playback automatically
[12:33:41] <av500> elenril: and lose half the audience?
[12:33:49] * elenril doesn't care =p
[12:34:19] <av500> hyc: I could like a 8 space prefix that is blank unless error:
[12:34:24] <av500> [       ] doing foo
[12:34:30] <av500> [ ERROR ] foo is on fire
[12:34:38] <hyc> yeah, that would work
[12:35:09] <av500> so it works even after |less etc
[12:35:09] <BastyCDGS> [ FATAL ] foo is slain
[12:35:16] <av500> or in log file
[12:35:19] <hyc> exactly
[12:35:28] <hyc> ANSI codes are .. messy ...
[12:35:33] <BastyCDGS> sounds great for me too...
[12:35:34] <ohsix> just dd' some urandom to the console
[12:36:02] <av500> ohsix: that what ffmpeg does by default, no? :)
[12:36:33] <hyc> oops. my /dev/urandom is a symlink to a file with 32768 0xff's
[12:36:47] <BastyCDGS> lol
[12:36:55] <mru> nine, nine, nine
[12:37:16] <BastyCDGS> hyc, then take /dev/random ;)
[12:38:36] <hyc> (it's a cheap trick, but effective when trying to break secure handshakes of unknown protocols...)
[12:38:50] <BastyCDGS> mru, just reading your ml comment unix default is nothing...that's right and we should follow that
[12:38:57] <hyc> it's also a bad thing to leave in place when you open an ssl session to your bank
[12:39:46] * BastyCDGS encrypts only with twice rot13 :D
[12:40:52] <BastyCDGS> best encryption algorithm is drink much alcohol, nobody can decrypt your spoken stuff anymore *gg*
[12:41:34] <av500> BastyCDGS: triple rot13 is more scure!
[12:41:48] <av500> like triple DES
[12:41:58] <hyc> av500: now you're just being paranoid
[12:42:49] <FUautotools> How about prefixes then: http://pastebin.org/167539
[12:43:06] <av500> yes, but not aligned
[12:43:21] <av500> i mean, can they be aligned
[12:43:43] <BastyCDGS> put the if else if stuff after the if loglevel return stuff
[12:44:12] <hyc> and leave a blank prefix by default "[       ]"
[12:44:19] <av500> yep
[12:44:32] <BastyCDGS> does anyone uses non-fixed width term fonts?
[12:44:42] <av500> yes, but we do not care for him
[12:44:46] <hyc> that would be their problem
[12:44:50] <BastyCDGS> we actually can't even
[12:44:51] <mru> they can go f*ck themselves
[12:44:58] <av500> they already do
[12:44:58] <mru> in fact, they've already done so
[12:45:02] <hyc> yep
[12:45:32] <av500> ok, so thats settled, not what color do we make the prefixes? :)
[12:45:36] <av500> now
[12:45:44] <hyc> mauve
[12:45:58] <mru> pale goldenrod yellow
[12:46:00] <av500> teal
[12:46:09] <BastyCDGS> I thought we left out the color stuff?
[12:46:22] <hyc> yeah
[12:46:28] <BastyCDGS> und just want [ $MSG ]
[12:46:45] <BastyCDGS> maybe [b][ FATAL ][/b] blablah
[12:46:51] <BastyCDGS> etc.
[12:46:56] <BastyCDGS> so that the [ ... ] is bold
[12:46:58] <mru> medium sea green
[12:47:03] <FUautotools> Even bold is bard to do
[12:47:03] <av500> off white
[12:47:05] <BastyCDGS> #336699
[12:47:06] <FUautotools> *hard
[12:47:13] <mru> blanched almond
[12:47:17] <hyc> as for the prefixes, I would just have an array of strings, indexed by [level>>3]
[12:47:18] <mru> rgb.txt is a hoot
[12:47:38] <hyc> too many if statements...
[12:47:53] <BastyCDGS> => switch case then
[12:48:02] <hyc> btw, try red text on blue background, for a nice 3-D effect
[12:48:08] <BastyCDGS> a table isn't bad too though
[12:48:22] <mru> hyc: mere thought makes my eyes hurt
[12:48:23] <FUautotools> Aligned with empty prefix: http://pastebin.org/167555
[12:48:40] <hyc> :P
[12:48:43] <mru> hyc: you know why that happens?
[12:48:50] <BastyCDGS> instead of if else if either table or switch/case
[12:48:53] <hyc> yep, cone alignment in your eyes
[12:49:03] <hyc> that's why red/blue 3-D glasses work
[12:49:07] <mru> no
[12:49:13] <FUautotools> A table will be big because FATAL != ERROR+1
[12:49:23] <BastyCDGS> so switch/case
[12:49:32] <mru> FUautotools: >>3
[12:49:37] <av500> FUautotools: now u could optimize away 2 spaces per line
[12:49:42] <BastyCDGS> but do it AFTER the if ( level > av_log_level ) return;
[12:50:04] <BastyCDGS> it doesn't make sense to go through a bunch if switches/if stats if you return anyway without output sth.
[12:50:06] <mru> hyc: red/blue glasses show a different image to the right/left eye
[12:50:08] <ohsix> hyc: on a crt right? electron beamz go through the shadow mask at different angles
[12:50:19] <mru> ohsix: that has nothing to do with it
[12:50:21] <mru> works on lcd too
[12:50:34] <hyc> mru: yes, but that's beside the point
[12:50:40] <mru> the lens in the eye has a different refractive index for red and blue light
[12:50:50] <mru> like just about any transparent thing
[12:51:00] <av500> unless it is APO corrected :)
[12:51:03] <mru> so red stuff gets focused at a different distance than blue stuff
[12:51:13] <hyc> ah yes, right.
[12:51:32] <hyc> it's physically impossible for the eye to be focused on both blue and red simultaneously
[12:51:34] <ohsix> hur; focus, that wasn't what i was talking about anyways
[12:51:44] <mru> equivalently, the lens needs to be set differently for red and blue stuff at the same distance be to focused on the retina
[12:51:57] <BastyCDGS> btw, switch/case also creates a table automatically if there's a lot of them
[12:52:06] <BastyCDGS> at least StormC did this on amiga
[12:52:08] <mru> so the red and blue are perceived as being at different distances
[12:52:15] <hyc> yep
[12:52:48] <hyc> BastyCDGS: most compilers turn switch/case into a jump table
[12:53:03] <hyc> but if you just use the right data structure you don't need a jump at all
[12:53:45] <BastyCDGS> don't do they this only if the stuff done in case differs...
[12:54:18] <BastyCDGS> i mean if you always have a single char * assignment there they could be smart enough to act on this
[12:54:41] <BastyCDGS> I remember once being surprised what stormc outputted when doing sth. tucomposer stuff
[12:54:57] <BastyCDGS> (standard out is normal jmp table, though)
[12:55:11] <av500> BastyCDGS: I doubt ffmpeg spends much time in outputting log messages, and if it does, we have much larger problems...
[12:55:35] <BastyCDGS> I think in this case it inlines internally the jump table function
[12:55:36] <hyc> IMO, relying on the compiler to be too smart is just a bad policy
[12:55:40] <CIA-7> ffmpeg: jai_menon * r22945 /trunk/libavformat/id3v2.c: Fix off-by-1 error in the tag parsing code.
[12:56:07] <hyc> write better source code, get better object code
[12:56:12] <BastyCDGS> btw, one question regarding patches
[12:56:32] <BastyCDGS> file structure
[12:56:38] <BastyCDGS> should I use:
[12:56:47] * mru recalls doubling speed of aac decoder without writing a single line of asm
[12:56:48] <BastyCDGS> ffmpeg-svn/foo/bar.c
[12:56:51] <BastyCDGS> trunk/foo/bar.c
[12:56:53] <BastyCDGS> ffmpeg/foo/bar.c
[12:57:03] <BastyCDGS> what's preferred here and takes the least work for you all?
[12:57:04] <BastyCDGS> just
[12:57:04] <mru> whatever git diff does
[12:57:06] <BastyCDGS> foo/bar.c?
[12:57:22] <BastyCDGS> ok
[12:57:43] <mru> something that works with patch -p0 or -p1 in the ffmpeg root
[12:57:45] <hyc> git? I've been using svn
[12:57:50] <hyc> is git the master now?
[12:57:58] <BastyCDGS> with svn diff the output differed depending on the dir I was calling the svn diff cmd
[12:58:05] <merbzt1> hyc: no
[12:58:22] <mru> nevermind the backend repo
[12:58:30] <mru> using git as frontend is still better
[12:58:37] <hyc> ah
[12:58:38] <merbzt1> indeed
[12:58:51] <BastyCDGS> ah so I don't have to take care about the directory from where I call git diff?
[12:59:03] <hyc> git always does the full path from repo base
[12:59:10] <BastyCDGS> great
[12:59:16] <BastyCDGS> then that issue is solved ;)
[12:59:34] <FUautotools> switch: http://pastebin.org/167578
[12:59:53] <jai> BastyCDGS: diff from the root dir
[13:00:03] <BastyCDGS> kk
[13:00:06] <hyc> FUautotools: ugh, declaration after code
[13:00:14] <hyc> I hate that aspect of C99
[13:00:15] <BastyCDGS> this would be foo/bar.c then in my example ;)
[13:00:16] <FUautotools> ffmpeg is c99
[13:00:36] <hyc> it takes me all the way back to BASIC
[13:00:41] <FUautotools> I can move that 2 lines up if nessecary
[13:00:51] <BastyCDGS> the empty char * doesn't harm at the beginning regarding of perfomance
[13:01:09] <hyc> right, there's no reason not to move the decl up
[13:01:37] <hyc> and as av500 said, drop two spaces from each prefix
[13:01:49] <hyc> WARNING will have no spaces, but no biggie
[13:01:51] <FUautotools> [TEXT] then?
[13:01:59] <av500> yes
[13:02:10] <hyc> [ FATAL ]   [WaRNING]
[13:02:11] <BastyCDGS> which log level is [TEXT] then? SCNR
[13:02:24] <ohsix> shell to figlet
[13:02:40] <ohsix> or banner
[13:02:52] * KotH paints the bikeshed blue
[13:02:59] <av500> KotH: teal!
[13:03:05] <hyc> banner is a bit extravagant, but I still like gothic
[13:03:20] <ohsix> make it go to a printer like it's supposed to, too
[13:03:36] <FUautotools> Somebody fix the shed so I don't have to paint it.
[13:03:46] <KotH> av500: too late, it's already painted
[13:03:57] <av500> [ERROR] is about fixing the user
[13:04:21] <FUautotools> True, but people say ffmpeg is too verbose
[13:04:29] <ohsix> play a melody on tty0
[13:04:38] <av500> well, now they have a nice way to regex it away
[13:04:42] <hyc> http://pastebin.org/167587
[13:05:23] <av500> grep -v "[      ]"
[13:05:34] <mru> 2>/dev/null
[13:05:40] * mru does that a lot
[13:05:51] <mru> and | md5sum
[13:06:03] <av500> mru must have a huge /dev/null
[13:06:11] <mru> watching it in code and all that
[13:06:12] <hyc> hmmm, what do you need sum of stdout for?
[13:06:21] <mru> -f rawvideo -
[13:06:23] <av500> regression
[13:06:27] <hyc> ah
[13:06:53] <av500> or mru can see the matrix in md5 sums
[13:07:00] <hyc> cool
[13:08:36] <FUautotools> no c99, fewer spaces: http://pastebin.org/167598
[13:09:38] <av500> FUautotools: since the log masg start with [ anyway, we could drop the [] anyway, no?
[13:10:16] <av500> bikeshed, I know
[13:10:20] <mru> or combine it all
[13:10:24] <FUautotools> If you want it in with the [codec @ hex] thing...
[13:10:34] <av500> ack
[13:10:51] <DonDiego> FUautotools: you have a peculiar nick..
[13:10:54] <FUautotools> do you want an empty prefix then?
[13:11:05] <FUautotools> DonDiego: yes I do
[13:11:13] <mru> [ERROR thing @ hex]
[13:11:16] <hyc> ugh. now that I'm actually reading log.c, what's with this gratuitous use of strlen(). bleah.
[13:11:26] <hyc> careful, you guys are losing your pretty regex
[13:11:58] <mru> ^\[[[:space:]]*ERROR
[13:13:04] <FUautotools> Do you still want an empty prefix?
[13:13:10] <av500> sure, for aling
[13:13:12] <av500> gn
[13:15:43] <hyc> unrelated to FUautotools' patch, please get rid of strlens. http://pastebin.org/167609
[13:15:47] <BastyCDGS> btw, I just removed the IFF_ANIM1-8/J stuff from my latest patch
[13:16:02] <BastyCDGS> since you commented that you can't change the codec ID while decoding anymore
[13:16:10] <BastyCDGS> but exactly this is needed
[13:18:42] <hyc> oops, off by one http://pastebin.org/167614
[13:19:12] <merbzt1> BastyCDGS: then you need to merge the codecs
[13:19:17] <merbzt1> codecid's
[13:19:54] <merbzt1> it is then not a separet codec but a frame coding mode
[13:20:03] <FUautotools> http://pastebin.org/167617
[13:21:29] <hyc> FUautotools - looks like you've got it. of course, I'm not an actual team member here
[13:22:20] <BBB> BastyCDGS: I agree with merbzt1, you probably want to preceed the AVPacket's data with the coding mode byte or something along those lines, and then handle that byte in the actual decoder
[13:22:30] <BBB> BastyCDGS: but I ddn't look carefully at the patch yet, hope to do that today
[13:32:16] <BastyCDGS> key
[13:32:17] <BastyCDGS> okey
[13:35:01] <BastyCDGS> preceeding a single byte to AVPacket is probably a bad idea...
[13:35:14] <BastyCDGS> it will odd-byte align the actual data
[13:35:26] <BastyCDGS> which might be a huge perfomance impact
[13:35:32] <BastyCDGS> if it's either read (D)WORD wise
[13:36:00] <BastyCDGS> so I'll allocate an int or sth like that
[13:36:23] <BastyCDGS> AVPacket->data I meant
[13:36:55] <BBB> that's fine also, I guess
[13:36:56] <wbs> I don't think you should read such data with operations that require aligned access, on some architectures it's just plain slower, on some it's not permitted at all, and afaik there's no alignment requirement for AVPacket->data
[13:37:00] <BastyCDGS> btw, merging of the codecs just done ;)
[13:37:09] <BBB> merging codecs = good :)
[13:37:31] <wbs> that is, doing unaligned accesses are not permitted, unless you wrap it in something like AV_RB32() etc
[13:39:31] <mru> correct, packet data is not required to be aligned
[13:39:40] <BastyCDGS> is that even necessary?
[13:39:47] <BastyCDGS> isn't there anything like avpkt->flags?
[13:39:48] <mru> most compressed data has no internal alignment anyway
[13:39:56] <BastyCDGS> where you just have 32 bits to set or sth.?
[13:40:19] <wbs> there's no point in speculating in whether reading stuff one way or another is faster/slower since you can't rely on its alignment
[13:41:25] <BastyCDGS> int   flags;
[13:41:34] <BastyCDGS> AVPacket
[13:41:53] <BastyCDGS> can I use these for setting the compression type?
[13:42:18] <BastyCDGS> or are they used internally?
[13:42:30] <BastyCDGS> header file doesn't document it
[13:42:36] <mru> you can only use whatever is in the header
[13:42:50] <BastyCDGS> this IS in the header
[13:42:51] <mru> the decoder must not rely on your demuxer being used
[13:43:20] <mru> so you can only set flags defined in the public header
[13:43:56] <mru> AV_PKT_FLAG_KEY is the only one currently defined
[13:44:50] <BastyCDGS> what about this?
[13:44:50] <BastyCDGS> void  *priv;
[13:45:01] <mru> decoder must not touch that
[13:46:07] <BastyCDGS> int   stream_index;
[13:46:18] <BastyCDGS> is this the frame?
[13:46:23] <BastyCDGS> currently playing?
[13:46:45] <wbs> no, it's the index of the AVStream within the AVFormatContext that the packet belongs to
[13:47:36] <BastyCDGS> sounds useful for something else though ;)
[13:48:19] <BastyCDGS> AVCodecContext->sub_id;
[13:48:31] <BastyCDGS> Some codecs need additional format info. It is stored here.
[13:48:40] <BastyCDGS> sounds like I can put the compression type there...
[13:50:52] <lu_zero> wbs: I started putting some stats facility in feng, could you give me your opinion? What you'd like to see there (that's missing) ?
[13:51:36] <wbs> lu_zero: is the current stuff available somewhere? (don't see it in git on lscube)
[13:51:55] <wbs> lu_zero: generally, the number of current viewers of each stream, perhaps the total bandwidth used
[13:52:29] <wbs> preferrably remote accessible through some http api or something similar, but other access may be usable too
[13:54:54] <wbs> lu_zero: btw, if you were experiencing weird slowdowns when watching rtsp streams with ffplay for testing different timestamps mechanisms... I found out that it's the ffplay framedrop code that may get triggered by those streams sometimes
[13:55:05] <wbs> if running with -noframedrop, the streams run just fine
[13:55:37] <wbs> (haven't gathered enough on it to create either a patch or a bug report, though..)
[14:01:45] <lu_zero> wbs: uhm you are right
[14:02:17] <lu_zero> wbs there is a statistics branch
[14:02:54] <wbs> ah, there it is, missed it :-)
[14:03:27] <lu_zero> http://cgit.lscube.org/cgit.cgi/feng/log/?h=statistics
[14:03:47] <lu_zero> it provides a json if you request /stats through http
[14:03:52] <pentanol> hi mru, we talk about disasm dumps avcodec lib when it glitched on arm compiled with uClib here it's... http://rapidshare.com/files/378827339/libavcodec.a.asm.tar.bz2.html there dumps libs which's compiled with optimisation and not. http://codepad.org/Jb6cL5VX
[14:04:04] <wbs> that's probably a quite neat and simple interface, I'll have a look in a few days
[14:05:02] <lu_zero> I'll add the bandwidth calculation soon (since that's missing
[14:05:21] <KotH> omg.. using rapidshare for file exchange...
[14:05:34] <KotH> pentanol: we are no warez and pr0n guys
[14:05:58] <Kovensky> KotH: rly?
[14:06:04] <BastyCDGS> hehe
[14:06:06] <KotH> ya rly
[14:06:37] <Kovensky> I have heard of at least one pr0n sample what helped fix a codec ;)
[14:07:25] <BastyCDGS> tell...which codec?
[14:07:25] <KotH> Kovensky: but, do you have a rapidshare pro account? :)
[14:07:46] <av500> BastyCDGS: libaa
[14:07:46] <KotH> Kovensky: if you dont, rapidshare is just a PITA
[14:08:03] <BastyCDGS> and why the sample helped in that ;)
[14:08:04] <BastyCDGS> ?
[14:08:10] <BastyCDGS> what was the bug?
[14:09:30] <pentanol> KotH c'mon ;) I wan't post here link to my servers:)
[14:10:05] <Kovensky> KotH: oh, ofc, rapidshare is useless :P
[14:10:14] <Kovensky> pentanol: mediafire
[14:12:22] <BastyCDGS> btw, shall I provide a patch which adds EHB support to the original codec?
[14:12:26] <BastyCDGS> IFF
[14:12:44] <BastyCDGS> (requires parsing the CAMG chunk)
[14:13:14] <BastyCDGS> and dump an error message if the IFF-ILBM is HAM6/HAM8?
[14:13:26] <BastyCDGS> the original code silently let it by
[14:14:49] <BastyCDGS> neither EHB nor HAM are IFF-ANIM specific
[14:15:06] <BastyCDGS> I could add it to the 100% iff-compliance.patch if desired
[14:15:51] <BBB> no no, small patches are easier
[14:16:00] <BBB> and that patch was reviewed, you should revise it :)
[14:16:28] <BBB> for codec-id, just transmit the whole header along with the frame if that makes it easier
[14:20:10] <BastyCDGS> I already adressed the issues of that patch, just didn't re-submit it yet
[14:21:09] <BastyCDGS> so I would simply add the CAMG stuff in there (it really fits in there, since EHB is part if IFF-ILBM compliance) ;)
[14:21:33] <BastyCDGS> it's ~ 10 lines more
[14:24:01] <BBB> you're trying to prevent having to use git/quilt
[14:24:05] <BBB> that's not a good idea :)
[14:24:15] <BBB> it's painful to start, but it's easier in the long run
[14:24:28] <BBB> but for this time just submit the patch as-is, just expect people to tell you you should split it ;)
[14:25:00] <BastyCDGS> no I'm tryping to make the IFF-ANIM patch at the end really only dealing with IFF-ANIM itself ;)
[14:25:06] <BastyCDGS> EHB is not part of this
[14:26:01] <BBB> I know, but that doesn't mean anything else is part of a second patch
[14:26:06] <BBB> it means you'll have 3 patch
[14:26:06] <BBB> e
[14:26:07] <BBB> s
[14:26:20] <BBB> didn't you see I committed like 8 patches yesterday?
[14:26:24] <BBB> they all touched similar code
[14:26:28] <BBB> but each did something else
[14:26:30] <BBB> do it's 8 patches
[14:26:32] <BBB> not 2, or 4
[14:26:35] <BBB> or 1 :)
[14:29:19] <lu_zero> uhmm
[14:32:10] <BBB> hi lu_zero
[14:32:19] <BBB> will you work on the website for the foundation?
[14:35:00] <lu_zero> BBB: if nobody else is up to
[14:35:32] <BBB> that's quite evident
[14:36:23] <BastyCDGS> what should the website done with?
[14:36:31] <BastyCDGS> I can assist with PHP/MySQL experience
[14:36:34] <BBB> html, just basic html
[14:36:36] <BastyCDGS> HTML too
[14:36:41] <BBB> help would be good
[14:37:18] <BastyCDGS> and of course with testing various browsers...
[14:37:44] <jai> pure html shouldnt be a problem
[14:37:48] <BastyCDGS> konqueror (KDE 3/4), firefox 3/3.6, IE 5.5/6.0/8.0 if that's enough...
[14:37:49] <BBB> website should be like http://www.mozilla.org/foundation/
[14:37:54] <BBB> simple, straightforward, and pretty
[14:37:55] <jai> just stay away from CSS3
[14:38:00] <lu_zero> why?
[14:38:05] * lu_zero is all for css3
[14:38:13] * BastyCDGS adds lynx to testing list
[14:38:13] <mru> BBB: you call _that_ pretty????!?!?
[14:38:21] <jai> lu_zero: because of ie
[14:38:21] <BBB> mru: better than ffmpeg.org
[14:38:28] <jai> unless you dont care about ie compatibility
[14:38:35] <mru> I strongly disagree
[14:38:35] * lu_zero doesn't
[14:39:07] <lu_zero> anyway
[14:39:24] <jai> also, wouldnt you need some artwork to work with?
[14:40:07] <BastyCDGS> only if we won't make it text-only ;)
[14:40:31] <BBB> you guys provide artwork
[14:40:32] <BBB> :)
[14:40:45] <BBB> this is actual work, yes
[14:40:51] <BBB> it's not a 10-minute hack
[14:41:12] <jai> of course :)
[14:41:32] <lu_zero> I could check if the people that usually makes design for me would be up for this task
[14:41:53] <BBB> excellent
[14:41:57] <lu_zero> and how much they would like to be paid or not
[14:42:18] <BBB> we can consider paying a little, but it's mostly not-for-profit
[14:42:38] <jai> minimal is good -> http://www.sinatrarb.com/ as an example
[14:44:07] <lu_zero> uhmm
[14:44:30] * lu_zero calls
[14:47:54] * KotH calls the men in white
[14:50:06] <BastyCDGS> lu if you need help don't hesistate to ask me on specific stuff
[14:50:53] <lu_zero> ok, hopefully by sunday I'll have some estimates
[14:51:42] <BastyCDGS> uhm who did wrote this?
[14:51:44] <BastyCDGS> length = -value + 1;
[14:51:54] <BastyCDGS> should be: length = ~value;
[14:52:09] <lu_zero> BastyCDGS: the website will be probably pure xhtml+css2/3
[14:52:23] <wbs> the former is much more readable, depending on context of course
[14:52:34] <BastyCDGS> RLE decoding
[14:52:39] <wbs> if it isn't critical for performance
[14:53:20] <BastyCDGS> it's the original IFF byterun1 decoder
[14:53:24] <BastyCDGS> and it's in a loop
[14:53:43] <BastyCDGS> will just provide a patch for this line...
[14:54:57] <lu_zero> benchmark it as wel
[14:54:58] <lu_zero> l
[14:55:17] <BastyCDGS> not eax
[14:55:23] <BastyCDGS> shall be faster than
[14:55:25] <BastyCDGS> neg eax
[14:55:26] <BastyCDGS> inc eax
[14:55:49] <BastyCDGS> it even stalls the pipeline
[14:55:56] <lu_zero> BastyCDGS: keep in mind x86 _isn't_ the whole world
[14:56:20] <lu_zero> and gcc might do the change by itself =P
[14:56:31] <BastyCDGS> is there REALLY any CPU out there which has NEG but not NOT
[14:56:38] <av500> not not not?
[14:56:53] <lu_zero> BastyCDGS: I hope all have both =P
[14:56:55] <BBB> these are still small changes
[14:56:58] <BBB> they're good
[14:57:03] <BBB> but how's the anim decoding going? :)
[14:57:27] <BastyCDGS> I was stumbling around this when I was fixing the EHB support (I found something still missing)
[14:57:40] <BBB> ok... :)
[14:57:42] <BastyCDGS> that might also be a cause that the image is garbaged in IFF-ANIM
[14:58:30] <BBB> I guess that depends on the frametype... :)
[14:59:41] <BastyCDGS> the first image is either raw IFF-ILBM or RLE
[14:59:59] <BastyCDGS> but the thing is that in my IFF-ANIM it's a EHB
[15:00:26] <BastyCDGS> just was considering that...
[15:03:35] <BastyCDGS> just doing a test build
[15:03:49] <BastyCDGS> to be on the safe side ;)
[15:05:17] <BastyCDGS> btw, optimized similar stuff also
[15:05:35] <BastyCDGS> removed a mul in a loop by replacing it with an appreciate add
[15:28:37] <mru> hmm, -x+1 != ~x
[15:29:23] <BastyCDGS> just noticed that while testing an LBM with it ;)
[15:29:30] <BastyCDGS> was the other way around
[15:29:57] <BastyCDGS> -x-1 = ~x
[15:30:49] <BastyCDGS> anyway then I just apply the mul-out-of-loop-replace-with-add-patch
[15:32:39] <BastyCDGS> replaced also some * and / by << and >>
[15:32:51] <BastyCDGS> yes I know the compiler does it but when I do this in RIFF...
[15:39:11] <BastyCDGS> btw, while doing this I had a really great idea of EHB support making it as simple as adding just 4-5 lines in total
[15:39:19] <BastyCDGS> and also without that change in iff.h
[15:39:33] <BastyCDGS> in fact there are 2 possibilities in doing that
[15:39:54] <BastyCDGS> one smart and one fast (but a little bit more error prone)
[15:40:28] <BastyCDGS> the more error prone differs in that it doesn't have to read the CAMG chunk
[15:40:46] <BastyCDGS> it just checks if the length if CMAP is either EHB or normal compatible solely it's length
[15:41:03] <BastyCDGS> the smart one would also read CAMG and do the EHB check only if the normal length doesn't fit
[15:41:07] <BastyCDGS> which one you would prefer?
[15:41:15] <BastyCDGS> (we'll need CAMG later anyway for HAM support)
[17:31:56] <DimStar> Good evening everybody. Just wanted to let you all know that my latest patch for libswscale built completely and the post build check did no longer fail... would be great if the patch could be reviewed and, if considered useful, applied to trunk.
[17:34:54] <jai> send it to the ml
[17:36:23] <merbanan> mmm food
[17:37:37] <DimStar> jai: yacks :) I need to subsribe there again :)
[17:37:56] <DimStar> it's typically a 'too high volume' for a  non active follower...
[17:38:05] <DimStar> but I'll do it :)
[17:38:18] <mru> you can subscribe and turn off delivery
[17:38:25] <av500> DimStar: your mailer will hapilly file it away in a dedicated folder
[17:38:44] <DimStar> av500: you met my mailer already? :)
[17:39:02] <av500> yes, use a stronger password next time
[17:39:10] * drv plays the "see if lkml can catch up with gmail size limit increases" game
[17:40:15] <mru> I suspect google detect list mail and only store one copy per subscriber
[17:40:46] <drv> well, it counts toward my account limit anyway
[17:41:17] <mru> how evil of them
[17:41:39] <av500> mru: per subscriber?
[17:42:09] <mru> eh, scratch that bit
[17:42:24] <mru> and _not_ store one copy per subscriber
[17:42:30] <av500> gg could subscribe all mls and offer that as a service in gmail
[17:49:03] <DimStar> ok.. mail should be flying by...
[18:02:34] <mru> too much ifdef
[18:59:37] <CIA-7> ffmpeg: michael * r22946 /trunk/libavutil/log.c:
[18:59:37] <CIA-7> ffmpeg: Coloring the log with ANSI.
[18:59:37] <CIA-7> ffmpeg: Ive checked this on black and white background and found no problem in terms
[18:59:37] <CIA-7> ffmpeg: of readability.
[18:59:37] <CIA-7> ffmpeg: flames welcome.
[19:00:18] <Dark_Shikari> \o/
[19:00:22] <Dark_Shikari> I love you michael
[19:00:27] <mru> I HATE YOU MICHAEL
[19:00:33] <BBB> lol :)
[19:00:48] <dgt84> heh
[19:00:52] <BBB> I mean, FLAMEWAR!!!11
[19:01:50] <_av500_> gee, too late to get popcorn
[19:02:06] <mru> seriously, I ought to take away his commit rights for a while
[19:02:19] <Dark_Shikari> lol
[19:02:27] <Dark_Shikari> COMMIT RIGHTS WAR1!11
[19:02:43] <DimStar> commit rights? Can I has it? :)
[19:03:19] <jai> sure, give us a meeeellion dollarz
[19:04:42] <BBB> that little?
[19:04:43] <mru> I feel like strangling someone
[19:05:10] <j-b> would some people need some Blu-Ray drives ?
[19:05:17] * mru already has
[19:05:23] <mru> don't know why
[19:08:01] <_av500_> j-b: gimme
[19:08:23] <_av500_> i can pick it up in paris
[19:08:30] <_av500_> :)
[19:09:16] <j-b> _av500_: would you improve lavc ?
[19:09:35] <_av500_> err
[19:10:38] <jai> hmm, i get a bunch of colored text all over the place
[19:11:02] <jai> makes me want to bump up MAX_READ_SIZE
[19:11:42] <BBB> j-b: how's libbluray going?
[19:11:59] <j-b> BBB: not that bad, but I am still fighting the legal fight
[19:12:09] <j-b> BBB: and we have one GSoC student to work on it
[19:13:00] <wbs> lu_zero: btw, feng seems to require libnetembryo >= 0.1.2 at the moment, even if the latest release is 0.1.1.. is there any concrete requirement for this? it seems to build just fine with 0.1.1 for me, when I modded configure
[19:13:08] <_av500_> j-b: there are ppl more in need than me to give the drive too :)
[19:14:25] <lillo55> hi all experts
[19:14:29] <j-b> BBB: in fact the issue is that I don't understand a shit of the last "arrêt de la cour d'état" on DADVSI
[19:15:25] <_av500_> j-b: quoi?
[19:15:34] <lillo55> somebody can help me about VP6 playback on wii mplayerce?
[19:16:15] <mru> some people like it obscure...
[19:16:21] <j-b> _av500_: http://juriscom.net/jpt/visu.php?ID=1087
[19:17:00] <lillo55> nobody?
[19:17:12] <j-b> lillo55: wrong channel :)
[19:17:31] <FFmpeg|BBB> j-b: huh? legal fight?
[19:17:31] <FFmpeg|BBB> wtf?
[19:18:04] <FFmpeg|BBB> (sorry for nick, it's gsoc time)
[19:18:36] <merbanan> FFmpeg|BBB: what channel is it ?
[19:18:50] <FFmpeg|BBB> #gsoc-dedup
[19:18:50] <lillo55> but mplayerce use libavcodec
[19:18:56] <FFmpeg|BBB> we're not affected
[19:19:23] <lillo55> a part of FFmpeg...
[19:19:59] <j-b> FFmpeg|BBB: mainly: "Is distributing the source for a meant to break a DRM, legal or not?"
[19:20:13] <FFmpeg|BBB> .. in france
[19:20:16] <FFmpeg|BBB> but is that a legal fight?
[19:20:20] <FFmpeg|BBB> I didn't know you were in court
[19:20:25] <j-b> oh, not yet :)
[19:20:30] <Dark_Shikari> lol
[19:20:32] <FFmpeg|BBB> so who cares?
[19:20:36] <FFmpeg|BBB> give me libbluray :)
[19:20:53] <FFmpeg|BBB> maybe I should do that next
[19:20:57] <FFmpeg|BBB> can you send me the bluray drive?
[19:21:00] <FFmpeg|BBB> :-p
[19:21:00] <j-b> FFmpeg|BBB: I do care. And I can give you a tarball whenever you want
[19:21:08] <FFmpeg|BBB> we'll see who sues me first
[19:21:15] <FFmpeg|BBB> actually, before you do, let me talk to sflc and see if that's ok
[19:21:37] <FFmpeg|BBB> I might be in trouble here for contributing to source even if I don't personally distribute it... then again, a commit is a distribution also
[19:21:48] <j-b> but, in fact, France has a stupid law where they made a mistake and should allow us to distribute binaries+keys
[19:23:37] <wbs> lu_zero: the json stats look quite ok, but gives e.g. clients: 3 even if there is only one client watching
[19:26:10] <merbanan> BBB: so all gsoc is fine and dandy ?
[19:26:58] <_av500_> all students quali-fried?
[19:28:40] <merbanan> yupp, really fried
[19:52:13] <BBB> merbanan: yes, I think so
[19:57:42] <_av500_> \\\ooo/// color errors
[19:57:59] * _av500_ forced his netbook to compile ffmpeg
[20:04:50] <mru> poor netbook
[20:05:28] <_av500_> it survived
[20:05:42] <_av500_> it even started to play ffserver
[20:05:58] <_av500_> thought it was mp3
[20:06:06] <_av500_> we have no elf probe?
[20:06:12] <_av500_> or antiprobe
[20:09:12] <jai> BastyCDGS: i'd really suggest spending time working on a new decoder instead of these "optimizations" :)
[20:09:16] <BBB> BastyCDGS: mru simply wants you to look at disassembly before and after your patch
[20:09:33] <BBB> and yes, this decoder is obscure enough for us to not care too much about optimizations
[20:09:53] <jai> the maintainer might consider readability more important
[20:10:06] <BBB> if amiga can decode it, then surely even the best-fucked-up arm processor can decode this crap on cell phones nowadays
[20:10:11] <BBB> unoptimized
[20:10:46] <jai> as far as all those anim packing modes, we care about supporting as many
[20:10:52] <jai> as possible
[20:12:00] <BastyCDGS> amiga decodes this by hardware mostly
[20:12:18] <BBB> oh, btw, AV_LOG_ is a log level set per message
[20:12:23] <BBB> so AV_LOG_SILENT wouldn't make much sense
[20:12:27] <BBB> it'd mean "never print me"
[20:12:40] <BBB> you're wondering about what the default log level would be, which is the -v option to ffplay/ffmpeg
[20:12:46] <_av500_> BBB: it is printed in transparent with latest patch
[20:13:45] <jai> also, i'll reiterate my opinion, the compiler should be able to convert those into shifts by itself
[20:13:49] <BastyCDGS> jai, you're right...but doing this had a nice side effect
[20:14:02] <BBB> jai: / != >>
[20:14:09] <jai> BastyCDGS: which is?
[20:14:10] <BastyCDGS> for me, I found a much better way to handle EHB stuff than current patch
[20:14:13] <BBB> jai: -9/2 is not the same as -9>>1
[20:14:26] <jai> BBB: i know, i meant the unsigned ones
[20:14:36] <BastyCDGS> yes but I were optimizing signed stuff also ;)
[20:14:53] <BastyCDGS> number of bpp can't be neg for example
[20:14:55] <BastyCDGS> so it's safe
[20:15:27] <BBB> we should make such vars unsigned
[20:15:28] <BBB> anyway
[20:15:29] <BastyCDGS> btw, I did a git clone now
[20:15:30] <BBB> ...
[20:15:46] <jai> make it unsigned then :)
[20:15:49] <jai> yeah
[20:15:49] * BastyCDGS likes the git output in that
[20:15:50] <BBB> BastyCDGS: focus on the decoder... these formats are obscure enough for us to not bother too much with performance
[20:16:11] <BBB> performance is more important for formats such as h264
[20:16:13] <BastyCDGS> much better than SVN: A         blabla.c
[20:16:15] <BastyCDGS> etc.
[20:17:56] <BastyCDGS> just read your comments on my newest patch
[20:18:19] <BastyCDGS> about that optimizer stuff, you're right it runs the same code...but not 100%
[20:18:44] <BastyCDGS> there is somewhere a thing like an if checking if it's a /
[20:18:49] <mru> no
[20:18:51] <mru> there's not
[20:19:28] <BastyCDGS> there has to be, otherwise the compiler wouldn't know at all that a division is requested, right?
[20:20:01] <mru> there's of course the frontend parser
[20:20:22] <mru> which feeds an internal-representation tree to the optimiser
[20:20:38] <mru> the optimiser consists of several passes
[20:20:57] <BastyCDGS> that's new in GCC 4 yes, but old GCC 2 was different on this...or do you mean sth. different than the vectorize-tree?
[20:21:13] <mru> high-level passes do things like CSE, loop permutations, DCE
[20:21:41] <mru> the overall design of gcc hasn't changed since gcc2
[20:22:05] <mru> I don't know why they put 'tree' in the name of a few new flags
[20:23:07] <mru> after the high-level optimisations RTL optimisations are performed
[20:23:10] <BastyCDGS> btw, concerning readability...generally you're right, but we're dealing here with bit-planes
[20:23:18] <BastyCDGS> so shifting is more "natural" here...
[20:23:23] <mru> these are low-level transformations on pseudo-instruction level
[20:23:26] <osaft> tree->binary-search-tree->log(n)->fast->gcc==fast ;-)
[20:23:29] <BastyCDGS> amiga uses bit-planar mode not chunky
[20:24:05] <BastyCDGS> and so does IFF-ILBM ;)
[20:24:13] <mru> finally the pseudo-instructions are turned into assembler
[20:24:25] <mru> this is where / can turn into >> and vice versa
[20:25:36] <mru> for each RTL insn it looks for an equivalent sequence where each step has a direct asm representation
[20:25:39] <BastyCDGS> I just personally think that code dealing with bits should use bit like instructions (even in C src)
[20:25:55] <BastyCDGS> and << & >> fall into this category...
[20:26:00] <mru> but these are numbers
[20:26:05] <mru> not bitfields
[20:26:22] <bcoudurier> hi guys
[20:26:54] <Dark_Shikari> hi bcoudurier's onjoin script
[20:27:29] <BastyCDGS> I didn't mean the data type bitfields
[20:27:29] <BBB> mru: he's right that in this case, / is not turned into >> because all these numbers are signed
[20:27:36] <BBB> mru: which is a bug, they should be unsigned
[20:27:38] <mru> maybe we should fix that then
[20:27:49] <mru> fix the cause, not the symptom
[20:27:52] <BBB> but I agree generally these aren't worthy optimizations
[20:28:34] <BBB> loren wrote the fft asm right? now that's optimizations
[20:28:35] <BastyCDGS> simply switching some stuff to uint can also cause perfomance lecks because you have then do sign extensions etc.
[20:28:38] <BBB> I mean, wtf :)
[20:28:57] <BastyCDGS> but I'll look at this and convert the stuff to unsigned too if that causes no side effects
[20:29:05] <BBB> BastyCDGS: they're low-level... think higher-level :)
[20:29:34] <wbs> generally, premature optimization is the root of all evil, as they say
[20:29:40] <BBB> I'll tell you that the fft code in ssewhatever is about 10x faster than the original. you'll never, EVER accomplish a 10x speedup with micro-optiizations
[20:29:43] <jai> yes, as i said earlier, make them unsigned
[20:29:58] <wbs> first implement whatever you're supposed to implement, then we can start looking at tweakings later
[20:30:02] <jai> that's acceptable
[20:30:03] <Dark_Shikari> BBB: but the best way to make something 10% faster is to make it 0.1% faster 100 times.
[20:30:12] <Dark_Shikari> Of course, that's stupid for a new codec
[20:30:21] <Dark_Shikari> that has huge speedups you could get even ignoring micro-ops.
[20:30:22] <Dark_Shikari> *opts
[20:30:28] <BBB> Dark_Shikari: no, file decoding got 10x faster
[20:30:36] <mru> Dark_Shikari: not if a simple restructuring makes it 5x faster
[20:30:45] <Dark_Shikari> mru: that was my point
[20:30:51] <BBB> Dark_Shikari: just by enabling yasm fft
[20:30:51] <Dark_Shikari> for a new codec that approach is dumb
[20:30:54] <BBB> I was like "wtf"
[20:31:06] <mru> Dark_Shikari: for old ones too
[20:31:15] <Dark_Shikari> mru: "new" means "hasn't been optimized by sane people yet" ;)
[20:31:20] <mru> ah
[20:31:33] <superdump> immature in terms of development
[20:32:23] <BastyCDGS> please also don't forget I have to study this code carefully right now though (since I'm new to ffmpeg devel)
[20:32:32] <BBB> that's fair
[20:32:35] <BastyCDGS> so when scrolling around it I just done it on the fly ;)
[20:32:53] <mru> try to break that habit
[20:33:03] <BBB> yeah, it distracts
[20:33:07] <wbs> you don't need to modify _all_ code you see
[20:33:19] <wbs> every modification has to go through peer review anyway, keep it to the ones that are worthwhile
[20:33:20] <BBB> you'll find so much of ffmpeg you could optimize with no general effect at all...
[20:33:30] <BBB> focus on these parts that matter
[20:33:40] <BastyCDGS> well I would suggest for now, that we finish that discussion for now (either you accept the patch or not) and go on
[20:33:51] <BastyCDGS> i have some questions about git right now, which are more important
[20:33:57] <BBB> ask :)
[20:34:12] <BastyCDGS> I have now a clean git repository
[20:34:14] <BBB> also, for "performance optimizations", eep our rules in mind: we need timer info from before and after the patch
[20:34:48] <BastyCDGS> one question is...
[20:35:08] <BastyCDGS> makes it a difference to git, if I edit files in the base repo or apply a patch which would do the same?
[20:35:24] <CIA-7> ffmpeg: bcoudurier * r22947 /trunk/libavformat/mpegts.c:
[20:35:24] <CIA-7> ffmpeg: Disable LATM AAC in mpegts, this is not supported and produce too many
[20:35:24] <CIA-7> ffmpeg: bug reports. Also warn the user about it.
[20:35:30] <BBB> read doc/optimization.txt
[20:35:32] <BBB> while you're at it
[20:35:36] <BBB> it's a good read, though a tad old
[20:38:18] <Dark_Shikari> if you like micro-optimizations, x264 always welcomes those ;)
[20:38:30] <Dark_Shikari> though most of x264 has already been micro-optimized with a fine-toothed comb
[20:38:40] <Dark_Shikari> (and we still reject microopts that make things much uglier for little benefit)
[20:38:55] <BastyCDGS> I'll explain why I do this stuff like replace / 2 by >> 1 etc. that means where my behaviour for this originates
[20:39:18] <mru> old compilers?
[20:39:19] <BastyCDGS> this is because almost all C compilers I used during amiga days didn't do this stuff
[20:39:21] <Dark_Shikari> well every systems programmer has that instinct
[20:39:40] <mru> compilers are much better now
[20:40:04] <mru> if you want to optimise stuff, you should always start with oprofile
[20:40:13] <Dark_Shikari> well, int / 2 is still not just one instruction
[20:40:18] <Dark_Shikari> unless the compiler can prove the value is always positive
[20:40:21] <Dark_Shikari> e.g. as in a loop index
[20:40:27] <mru> or by being unsigned
[20:40:28] <CIA-7> ffmpeg: michael * r22948 /trunk/libavutil/log.c:
[20:40:28] <CIA-7> ffmpeg: Disable ANSI color code until we figured out how to detect ANSI support in
[20:40:28] <CIA-7> ffmpeg: the used terminal.
[20:40:33] <Dark_Shikari> I say int
[20:40:34] <Dark_Shikari> not uint
[20:40:45] <BastyCDGS> another point to mention out
[20:40:50] <mru> which is why using unsigned variables is often good
[20:40:54] <mru> often but not always
[20:40:56] <BastyCDGS> the following will fail for example on m68k:
[20:40:57] <Dark_Shikari> uints have their own problems as local vars
[20:41:00] <Dark_Shikari> multiplies are slower
[20:41:00] <BastyCDGS> 16777216 / 4
[20:41:07] <mru> Dark_Shikari: depends on cpu
[20:41:10] <Dark_Shikari> oh x86, at least
[20:41:11] <Dark_Shikari> *on
[20:41:12] <BastyCDGS> for both signed/unsigned
[20:41:34] <mru> if you only care about the low half of the result it doesn't matter
[20:41:40] <BastyCDGS> if and only if 4 is short
[20:41:41] <Dark_Shikari> yeah, but just tell the compiler that
[20:41:52] <mru> int x = y * z;
[20:41:59] <mru> there, don't care about high 32 bits
[20:41:59] <BastyCDGS> the reason is that the 68000 just had a 32/16 bit division
[20:42:13] <Dark_Shikari> mru: you sure the compiler is smart enough?
[20:42:20] <BastyCDGS> if the result is larger than 32k - 1 (signed) or 64k - 1 (unsigned) it doesn't put any result at all
[20:42:21] <mru> many modern CPUs don't have integer division at all
[20:42:25] <mru> Dark_Shikari: sure
[20:42:38] <BastyCDGS> it just sets the overflow bit in that case
[20:42:55] <mru> Dark_Shikari: gcc is much too stupid to use 16-bit mul when it could though
[20:43:13] <BastyCDGS> but 16777216 >> 2 does NOT fail
[20:43:19] <mru> arm has both signed and unsigned long mul
[20:43:37] <Yuvi> mru: it does sometimes, but it's regressed significantly since 4.2
[20:43:42] <BastyCDGS> an m68k compiler will therefore consider 16M / 4.w different than 16M >> 2
[20:43:52] <mru> Yuvi: there's a reason for the MUL16 macro
[20:43:52] <Dark_Shikari> mru: yup, you're right
[20:44:05] <Dark_Shikari> it uses imul instead of mul
[20:44:13] <Dark_Shikari> for a func that takes uint32_t x2 and multiplies to uint32_t output
[20:44:46] <BastyCDGS> and I think there are similar caveats for other CPUs than m68k too...
[20:45:01] <mru> try not to think of m68k
[20:45:12] <mru> x86 and arm are the important ones today
[20:45:33] <Dark_Shikari> wow.
[20:45:36] <Dark_Shikari> gcc 3.4 optimizes this correctly
[20:45:37] <Dark_Shikari> uint32_t func( uint32_t x, uint32_t y )
[20:45:38] <Dark_Shikari> {     return ((uint64_t)x * y) >> 32; }
[20:45:42] <mru> wow
[20:45:43] <BastyCDGS> m68k is just ONE example I know where such strange stuff can happen, there probably plenty of others
[20:45:54] <Dark_Shikari> the function is four instructions:
[20:45:56] <Dark_Shikari> load y off stack
[20:46:00] <Dark_Shikari> mul [x]
[20:46:03] <Dark_Shikari> mov eax, edx
[20:46:03] <BastyCDGS> gcc even uses rotation instruction
[20:46:03] <Dark_Shikari> ret
[20:46:16] <Dark_Shikari> it's literally impossible to use fewer instructions
[20:46:20] <BastyCDGS> when you do (x << 5) | (x >> 3) and x is unsigned short
[20:46:42] <Dark_Shikari> mru: it also works if I do, say >> 31
[20:46:44] <Dark_Shikari> still only 4 instructions
[20:46:49] <Dark_Shikari> move off stack, mul, shrd, ret
[20:46:54] <Dark_Shikari> I'm surprised
[20:47:32] <Dark_Shikari> it is pretty nice how x86 can do arbitrary 32x32->32 with any shift in two instructions.
[20:47:33] <mru> apparently it fits nicely into gcc's rtl
[20:47:47] <mru> anything that's hard to express in rtl falls apart easily
[20:47:51] <Dark_Shikari> heh
[20:48:09] <mru> have you looked at that stuff ever?
[20:48:09] <BastyCDGS> btw, regarding that unsigned vs. signed stuff, when I look now on this, should I replace >> 1 etc. with / 2 again then?
[20:49:06] <Dark_Shikari> btw mru , my latest annoyance is that attribute ((pure)) doesn't work with function pointers
[20:49:10] <Dark_Shikari> but attribute ((const)) does
[20:49:11] <Dark_Shikari> for no apparent reason
[20:49:42] <mru> we need a new compiler
[20:49:59] <Dark_Shikari> well, we need a compiler that we can give more information
[20:50:09] <Dark_Shikari> mru: see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43827
[20:50:28] <Dark_Shikari> it seems rather hard to tell gcc "this dsp function pointer doesn't fuck with things, don't reload every value from memory after calling it"
[20:50:52] <mru> s/intrinsic/attribute/
[20:51:12] <Dark_Shikari> aren't attributes a type of intrinsic?
[20:51:39] <mru> intrinsics are the function-like things we're not supposed to use
[20:51:45] <Dark_Shikari> lol
[20:52:03] <_av500_> why does looking at bugzilla feel like looking at a 747 cockpit?
[20:52:20] <Dark_Shikari> gcc devs do seem to be getting better though
[20:52:25] <Dark_Shikari> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43845 reported this the other day
[20:52:25] <mru> I'm sure a 747 is easier to fly
[20:52:38] <Dark_Shikari> simple test case created, patch made, and committed in like a day or less
[20:52:49] <Dark_Shikari> makes ffmpeg bugtracker look like a river of molasses during the winter
[20:53:19] <mru> I've fixed ffmpeg bugs in less than an hour
[20:53:27] <Dark_Shikari> sure, but most random segfaults don't get fixed in a day
[20:53:30] <Dark_Shikari> on the tracker
[20:53:44] <mru> one reason is poor quality of bug reports
[20:54:34] <Dark_Shikari> look at how awful my bug report was.   no simple reduced test case, just a massive mess of a file
[20:54:49] <mru> didn't read the details
[21:05:39] <BastyCDGS> ehm, someone read my question above?
[21:05:47] <BastyCDGS> also the one regarding git?
[21:07:47] <Dark_Shikari> bah.  gcc, die.
[21:07:49] <Dark_Shikari> sub    [esp+0x21c],eax
[21:07:49] <Dark_Shikari> sub    [esp+0x220],edx
[21:07:49] <Dark_Shikari> mov    ebx,[esp+0x21c]
[21:07:49] <Dark_Shikari> mov    esi,[esp+0x220]
[21:08:52] <mru> does it need the values in memory later?
[21:09:29] <Dark_Shikari> no, but if it isn't keeping them on the stack I guess it does need to store them again
[21:09:33] <Dark_Shikari> that is one way to do it...
[21:09:41] <Dark_Shikari> actually I wonder how x86 handles that sort of code idiom
[21:09:46] <Dark_Shikari> er, *is keeping them on the stack
[21:09:48] <Dark_Shikari> instead of in registers
[21:10:23] <mru> it might need the registers for something else in between
[21:10:42] <Dark_Shikari> that actually makes sense, the original idea
[21:10:48] <Dark_Shikari> that it needs to store them so that later it can clobber those registers
[21:10:48] <mru> but load/sub/store should of course be faster than load/sub/store/load
[21:11:23] <Dark_Shikari> hmm, actually, gcc uses this idiom a LOT
[21:11:41] <mru> it's less code
[21:11:42] <Dark_Shikari> add to loop index in memory, load it, compare to max value
[21:11:48] <mru> if you don't care about scheduling it looks better
[21:11:51] <Dark_Shikari> this eliminates the store
[21:12:04] <Dark_Shikari> I suspect load-store forwarding eliminates most of the overhead
[21:13:13] <Dark_Shikari> I'm not sure why it uses "add" instead of "inc" though
[21:13:22] <Dark_Shikari> (no it doesn't use the flags)
[21:18:31] <j-b> __gb__: did you see VDADecoder ? Do you want a mac?
[21:20:37] <CIA-7> ffmpeg: mru * r22949 /trunk/libavcodec/arm/rdft_neon.S:
[21:20:37] <CIA-7> ffmpeg: ARM: fix build for darwin/iphone
[21:20:37] <CIA-7> ffmpeg: References to external symbols in asm code need prefixes.
[21:21:27] <astrange> i've seen vdadecoder but don't have a supported gpu
[21:23:43] <BBB> does that work on the iphone?
[21:24:14] <BBB> BastyCDGS: yes, revert these changes for now
[21:24:24] <BBB> BastyCDGS: learn to use git so you can keep them as a private patch
[21:24:28] <mru> BBB: I doubt it
[21:24:32] <BBB> BastyCDGS: as for git, I have no idea, ask others :)
[21:24:39] <BBB> mru: :(
[21:24:45] <BBB> that's like the coolest use case
[21:24:49] <mru> they seem to keep iphone and macos just different enough to really annoy people
[21:25:02] <BBB> but I guess it fits with the "you should use quicktime" principle
[21:25:29] <_av500_> does new iphone rulez allow .S at all :)
[21:25:46] <_av500_> it was c, c++ and obj-c only...
[21:25:52] <Dark_Shikari> _av500_: worse
[21:25:53] <astrange> iphone doesn't have quicktime or low-level decode of any form
[21:25:57] <Dark_Shikari> the language it's "originally written in"
[21:26:00] <Dark_Shikari> or actually
[21:26:04] <Dark_Shikari> I think it was originally conceived in
[21:26:12] <mru> _av500_: the code was originally written in C
[21:26:15] <Dark_Shikari> which means that they are making a judgement on the nature of human conciousness
[21:26:16] <astrange> its only video playback api is hw accelerated though
[21:26:16] <mru> I translated it to asm
[21:26:37] <_av500_> mru: pah, i bet you started with a flash mockup
[21:26:39] <astrange> and you can figure out the privateframework prototypes by looking at VideoDecodeAcceleration if you want
[21:26:57] <mru> _av500_: yeah, I spent a week taking out all the ifdefs
[21:27:20] <_av500_> mru: anyway, u are tainted as you saw fl src
[21:27:44] <_av500_> you can never put your stuff in app store
[21:27:53] <_av500_> no that you want to...
[21:28:46] <mru> Dark_Shikari: did you see the ifdef-fest I posted earlier?
[21:31:04] <Dark_Shikari> ? link
[21:31:08] <mru> http://pastie.org/928309
[21:31:31] <Dark_Shikari> what is this from
[21:31:34] <mru> there's another 700k lines where that came from
[21:31:41] <mru> flashlite
[21:31:54] <Dark_Shikari> er, are you supposed to be posting that code? =p
[21:31:58] <mru> no
[21:32:11] <Dark_Shikari> teeeechnically the channel is logged, etc
[21:32:36] <_av500_> mru: you should post pngs
[21:32:52] <_av500_> in comic sans
[21:35:34] <BastyCDGS> mru, another thing I could mention...that's why I did smaller stuff today, don't forget my normal work days started today
[21:36:25] <BastyCDGS> tomorrow I have special preparation lessons for exam
[21:37:02] <BastyCDGS> but at weekend I will concencrate on decoding stuff ;)
[21:37:56] <BastyCDGS> I'm pretty tired right now, so I'ld be glad when you answer the git questions, so I can really use git then
[21:38:08] <BastyCDGS> so patching problems are solved finally ;)
[21:40:11] <FUautotools> What kind of gibberish was committed for "colour messages"?
[21:41:27] <FUautotools> no wonder people bitched (other than breaking)
[21:41:52] <pentanol> hi, I'm back, http://www.mediafire.com/?gwdimv3nmdv there diasm for optimized and not avcodec for arm uClib
[21:44:30] <CIA-7> ffmpeg: jbr * r22950 /trunk/libavcodec/ac3dec.c:
[21:44:30] <CIA-7> ffmpeg: ac3dec: return smaller of buf_size and frame_size instead of always returning
[21:44:30] <CIA-7> ffmpeg: frame_size.
[21:47:37] <pentanol> mru you there?
[21:48:11] <BastyCDGS> he seems to be busy doing some coding stuff probably
[21:48:19] <BastyCDGS> or reviewing patches who knows ;)
[21:48:46] <mru> if it's about that arm problem, please try to create a minimal test case that fails
[21:50:34] <pentanol> test case?
[21:51:56] <BastyCDGS> btw, another nice optimization manual on x86 asm and C as well as C++
[21:51:58] <BastyCDGS> http://www.agner.org/optimize/#manual_cpp
[21:52:09] <BastyCDGS> just in case you didn't knew the page yet
[21:56:55] <pentanol> just guessing, is that might be crashed in lrink, that's  from math lib
[22:08:52] <pentanol> what means test case? in crached when I start ffmpeg; here ... avcodec_opts[i]= avcodec_alloc_context2(i);
[22:09:41] <BastyCDGS> ok, I'll say good night for now and have you nice dreams
[22:09:41] <mru> I mean a small stanalone piece of code that exhibits the error
[22:10:09] <BastyCDGS> mru, if you want to answer my questions, either write me a mail or next time here
[22:10:41] <BastyCDGS> I hope to get here tomorrow evening at least
[22:17:28] <BBB> BastyCDGS: also search google for git-questions, not all of us are git-experts
[22:17:33] <BBB> at least I'm not :)
[22:18:12] <BastyCDGS> it's just that I don't want fiddle hours around with git just to get in my patches I already did
[22:18:22] <BastyCDGS> thus not running in the same problem as I had with SVN ;)
[22:19:06] <BastyCDGS> who's the best person here to ask stuff regarding git?
[22:19:57] <mru> just ask
[22:20:02] <Dark_Shikari> don't ask to ask
[22:20:02] <mru> if anyone knows they'll answer
[22:21:52] <BastyCDGS> okey
[22:22:03] <BastyCDGS> so sleep well then...;)
[22:22:25] <BastyCDGS> I'd better off now, otherwise I risk falling on the keyboard
[22:22:36] <BastyCDGS> so just don't wonder if you suddenly read: fhsdfiuhsdsu :D
[22:22:50] <mru> is that a new sssse5 instruction?
[22:23:18] <pentanol> mru http://codepad.org/Jb6cL5VX
[22:23:20] <BastyCDGS> no that's AMD 4dnow!
[22:23:24] <BastyCDGS> ;)
[22:23:52] <mru> pentanol: that doesn't look minimal or standalone
[22:24:08] <BastyCDGS> *wavesgoodbye*
[22:24:21] <pentanol> with optimisation it said av_set_number2 done, and not optimisation it said few times o_0  %i \n" ,ret)
[22:24:37] <pentanol> ok
[22:24:53] <mru> standalone means it contains a main() function so it can be compiled and run
[22:25:06] <mru> minimal means if anything is removed from it, it doesn't show what it's supposed to
[22:33:13] <pentanol> yes I got it;) http://codepad.org/lJ0hJjLY
[22:33:47] <mru> that's not what I meant
[22:34:24] <mru> find the function that fails, copy that out and trim it down until only the failing part remains
[22:36:24] <pentanol> here can be dependencies, then it's time...
[22:36:45] <mru> time that I don't have
[22:36:50] <mru> want your problem solved or not?
[22:37:37] <pentanol> that been affirmation
[22:37:51] <pentanol> I will post it...
[22:37:54] <pentanol> I mean;)
[23:09:43] <Yuvi> mru: http://pastie.org/930680 <- does gcc save d8/d9 for you?
[23:11:54] <Yuvi> nm, forgot -mfloat-abi
[23:14:04] <Yuvi> heh, gcc doesn't handle q clobbers as expected
[23:16:26] <mru> known bug
[23:16:31] <mru> don't use inline asm with neon
[23:16:37] <mru> it's a recipe for disaster
[23:18:06] <Yuvi> so I shouldn't report it?
[23:18:21] <mru> I'm surprised nobody has
[23:18:27] <mru> it's been known for years
[23:18:40] <mru> I assumed it was just one of those things they ignore
[23:18:41] <Yuvi> well http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43860
[23:19:25] <mru> am I the only one who thinks the title is misplaced in that page?
[23:19:27] <Yuvi> I think it's mainly because they convert d and q registers to single s clobbers
[23:20:25] <Yuvi> only noticed because I"m trying to fix clang+neon inline asm
[23:22:57] <Yuvi> by single s clobbers, I mean d8 -> s16 only, it doesn't explictly mark s17
[23:24:48] <mru> and then save/restore the containing d reg?
[23:25:14] <Yuvi> I think so
[23:25:19] <Yuvi> apparently someone reported it last month
[23:25:24] <Yuvi> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43440
[23:30:52] <mru> and as usual they refuse to fix the easy case because there'd still be a rare complicated case left