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

[irc at mansr.com]

[00:00:08] <peloverde> I told you
[00:00:09] <bcoudurier> then you started complaining about parsing, chain demuxing or whatever
[00:00:32] <bcoudurier> I'm trying to _fix_ things here
[00:00:36] <peloverde> (1024-64*frame_length_flag)/nominal_sample_rate
[00:00:45] <bcoudurier> and since these issues are _very long_ standing
[00:00:59] <bcoudurier> nobody can argue for the clean way anymore
[00:01:10] <bcoudurier> we need to make things working
[00:01:43] <peloverde> we've tried to make things work before and it never went anywhere
[00:01:50] <peloverde> making things work is a waste of time
[00:02:00] <bcoudurier> what ?
[00:02:01] <peloverde> I'd rather work on what's feasible in this disfunctional community
[00:02:09] <bcoudurier> here we go
[00:02:17] <bcoudurier> I don't believe you
[00:02:20] <peloverde> We've discussed these same issues dozens of times since i've been here
[00:02:27] <bcoudurier> I never seen any latm stuff working
[00:02:32] <bcoudurier> except samsung
[00:02:39] <peloverde> google the ML archives for "Paul Kendall"
[00:02:49] <bcoudurier> that doesn't work
[00:03:09] <peloverde> that was the LATM discussion
[00:03:10] <bcoudurier> besides, it's not you
[00:03:19] <peloverde> it went nowhere
[00:03:20] <bcoudurier> I don't care about the discussion personally
[00:03:26] <janneg> bcoudurier: Paul's patches are working for the streams he sees
[00:03:30] <bcoudurier> I want a patch that make it _work_
[00:03:34] <bcoudurier> not for mine
[00:03:45] <janneg> bcoudurier: and samsung uses one of his patches
[00:03:48] <peloverde> then write a patch that will make it work
[00:03:50] <bcoudurier> mplayer did patch faad
[00:03:53] <bcoudurier> it _works_
[00:04:00] <bcoudurier> there is nothing to discuss
[00:04:08] <peloverde> I thought you just said that it doesn't work
[00:04:17] <bcoudurier> faad works
[00:04:21] <bcoudurier> paul kendall stuff doesn't
[00:04:36] <bcoudurier> or am I confusing both ?
[00:04:46] <bcoudurier> paul kendal was bitstream filter stuff right ?
[00:04:57] <janneg> paul kendall's patches are using libfaad
[00:05:11] <peloverde> Look AAC signaling is super-fucked, the only way to handle things is to make soem assumptions and deocde some streams wrong
[00:05:11] <janneg> it was various stuff
[00:05:27] <bcoudurier> Re: [FFmpeg-devel] [PATCH] LATM Bitstream Filter & Parser
[00:05:30] <peloverde> or use MPEG-Surround
[00:05:31] <bcoudurier> ...
[00:05:39] <bcoudurier> how is that related to faad ?
[00:05:52] <janneg> the bitstream filter was not working that well iirc
[00:05:54] <peloverde> ‎I never said it was related to faad
[00:05:56] <bcoudurier> peloverde, it's fine if 5% are wronly decoded
[00:06:11] <bcoudurier> as long as it's less than faad we are gooc
[00:06:15] <janneg> but he has also a libfaad/latm decoder which seems to work
[00:06:26] <bcoudurier> ok
[00:06:33] <bcoudurier> patched faad for mplayer was the way to go
[00:06:41] <bcoudurier> it is IMHO the way to go for ffmpeg as well
[00:06:51] <bcoudurier> we will get most of the ts stuff decoded
[00:07:14] <bcoudurier> if you want chain demuxing, it's also perfectly fine with it
[00:07:17] <bcoudurier> but do it :()
[00:07:31] <bcoudurier> and I completely understand that AAC is fucked
[00:07:52] <janneg> no libfaad patches necessary, just wrapping around faad.
[00:07:55] <bcoudurier> but hell we should try to do the best with that we have
[00:08:15] <janneg> the only reason for using faad was missing heaac support in ffaac
[00:08:22] <bcoudurier> janneg, that's good enough it seems
[00:08:45] <peloverde> Then ask the maintainer to put it in the decoder
[00:09:32] <peloverde> we can deal with muxing later
[00:09:43] <janneg> paul promised to resubmit it with ffaac support as soon as PS is finished
[00:09:54] <peloverde> PS is done
[00:10:31] <janneg> nice, I must have missed it
[00:10:38] <peloverde> it's not merged
[00:10:45] <janneg> ah
[00:11:02] <bcoudurier> peloverde, aren't you the maintainer ? :>
[00:11:09] <bcoudurier> you should be
[00:11:16] <peloverde> MAINTAINERS says otherwise
[00:11:33] <bcoudurier> don't you want to be maintainer ?
[00:12:02] <peloverde> yeah I suppose
[00:12:48] <bcoudurier> then take over :)
[00:12:57] <bcoudurier> I'm sure superdump will be ok
[00:13:27] <bcoudurier> you deserve it after all the effort you put into it
[00:13:51] <peloverde> ok
[00:14:03] <peloverde> you or paul or whoever have my blessing to put LATM in the decoder, but patches still need to be reviewed on their individual merits
[00:17:39] <mru> a
[00:19:58] <janneg> peloverde: I've pinged paul, do you have a publich git tree or patch with PS?
[00:21:01] <peloverde> janneg, I can make a git tree for it Monday-ish
[00:23:32] <janneg> peloverde: thanks
[01:22:56] <saintd3v> peloverde: PS finished \o/
[01:46:44] <hyc> anyone here understand FLV format?
[01:47:14] <hyc> I'm seeing a live stream where the packet timestamps are much different from the stamps inside the FLV packets
[01:47:32] <hyc> e.g. DEBUG: type: 08, size: 373, pktTS: 99ms, TS: 99ms, bLiveStream: 1
[01:47:42] <Dark_Shikari> "packet timestamps"?
[01:47:45] <hyc> DEBUG: type: 16, size: 4845, pktTS: 100ms, TS: -512229559ms, bLiveStream: 1
[01:47:57] <Dark_Shikari> FLV only has one set of timestamps
[01:48:03] <hyc> those are two consecutive RTMP packets
[01:48:14] <Dark_Shikari> what is "TS"
[01:48:14] <hyc> a type 08 packet is an audio packet
[01:48:18] <Dark_Shikari> where is it stored?
[01:48:27] <hyc> a type 16 packet is FLV in RTMP
[01:48:40] <Dark_Shikari> what is TS
[01:48:55] <hyc> TS is the timestamp read from the packet data, vs the packet header
[01:49:21] <Dark_Shikari> meaning the timestamp in the FLV file itself?
[01:49:23] <hyc> comes from bytes 4-7 of the packet data
[01:49:25] <Dark_Shikari> Sounds like the muxer is retarded
[01:50:49] <hyc> yeah, could be
[01:51:06] <hyc> came from here http://stream-recorder.com/forum/rtmpdump-live-stream-problem-please-help-t6405.html
[01:51:16] <hyc> you can see it yourself if you're interested
[01:51:46] <hyc> the only reason I bothered to check is because he says the flash player plays it fine
[01:51:54] <Dark_Shikari> probably it ignores the FLV timestamps
[01:53:33] <hyc> hm, yeah. I'll see if I can force the stamps to a reasonable value
[02:28:24] <astrange> i feel bad for telling that filter guy to try merging his code into the most complicated parts of ffmpeg
[03:46:38] <bcoudurier> astrange why do you think it should be best in libswscale ?
[03:48:54] <astrange> swscale is much better at scaling and transforms than what he posted
[03:49:14] <astrange> but i don't know how to do rotation, so i don't know if it can be evaluated with a kernel
[04:00:25] <bcoudurier> ah ok
[04:27:22] <astrange> http://astrange.ithinksw.net/ffmpeg/VusionFullVuVideoPlayer-intel vp7 decoder in here somewhere, pity they remembered to strip it
[04:28:03] <Dark_Shikari> aw.
[04:29:01] <Dark_Shikari> what executable format is it?
[04:30:36] <astrange> macho i386
[04:30:47] <astrange> browser plugin
[04:31:11] <astrange> http://www1.vusion.com/showcase.php this should autodownload a windows plugin
[04:37:46] <thick_mcrunfast> Hey there! Just asked a question in #ffmpeg that should have been here; Essentially, I'm writing an mp4 carver in Python and I have been unsuccessful at finding any kind of documentation on the mdat atom
[04:37:57] <Dark_Shikari> astrange: doesn't even use ssse3 :/
[04:38:15] <Dark_Shikari> btw, big_mclargehuge here wants a copy of the ISO media spec
[04:38:23] <Dark_Shikari> er, I mean, blast_hardcheese
[04:38:24] <thick_mcrunfast> Dark_Shikari: ^^
[04:38:30] <Dark_Shikari> er, I mean roll_fizzlebeef
[04:38:53] <thick_mcrunfast> Dark_Shikari: blast_hardcheese is my main, this is my alt, big_mclargehuge is my second alt ;)
[04:39:04] <Yuvi> isom is free: http://standards.iso.org/ittf/PubliclyAvailableStandards/ c051533_ISO_IEC_14496-12_2008.zip
[04:40:12] <thick_mcrunfast> Yuvi: Looking over it now
[04:40:32] <thick_mcrunfast> Thanks for that link, all the stuff I found regarding the spec was like 70+ USD
[04:41:05] <Yuvi> part 14 isn't, but you don't really need that
[04:42:04] <Yuvi> also if you get an atom viewer it'll help more than reading the spec
[05:16:44] <thick_mcrunfast> Yuvi: Ah, good tip
[05:16:58] <thick_mcrunfast> I've written something that separates the atoms, but doesn't understand them
[05:17:37] <thick_mcrunfast> I've been going through implementing the spec, things have been becoming more and more clear as I go
[05:17:44] <thick_mcrunfast> which is very exciting
[05:17:47] <KotH> salut
[05:53:02] <av500> 'jour
[06:36:55] <CIA-7> ffmpeg: conrad * r22927 /trunk/libavformat/movenc.c: movenc: Write nero chapters
[06:36:56] <CIA-7> ffmpeg: conrad * r22928 /trunk/libavformat/ (isom.h mov.c): mov: Read QuickTime chapters
[06:38:21] <Tjoppen> regarding https://roundup.ffmpeg.org/issue1877 and https://roundup.ffmpeg.org/issue1695 (aac), if the fix ends up just capping the bitrate, then maybe the user should be able to figure out that the bitrate changed?
[06:39:20] <Tjoppen> unless I'm mistaken this happens in various cases, where values in AVCodecContext end up slightly modified. if so, then AVCodecContext::bitrate should as well
[06:45:01] <Dark_Shikari> well the way x264 does it is that it modifies the parameters in its own internal param struct
[06:45:11] <Dark_Shikari> and then has an API call to copy back the current set of parameters
[06:46:49] <Tjoppen> ok. I'll just suggest in my roundup thread that the modified bitrate should be left in the context and not hidden away
[06:47:19] <astrange> michael didn't like the idea of modifying the context when i tried it once
[06:47:25] <Tjoppen> that way I can detect the change and log it
[06:47:31] <astrange> i think that's why the mpegvideo encoder dies on invalid values rather than fixing htem
[06:47:45] <Tjoppen> the context gets modified by by a lot of encoders though
[06:48:06] <Tjoppen> I recall having problems with that, where I had to update my structs in turn
[06:48:12] <Dark_Shikari> astrange: ffmpeg should do what x264 does
[06:48:14] <Dark_Shikari> encoder_reconfig
[06:48:18] <Dark_Shikari> for modifying the context externally
[06:58:53] <tetsuo--> How likely is it that the ffmpeg team will accept patches that make ffmpeg compilable on visual studio?
[06:59:50] <av500> one liner will get in I guess
[07:00:19] <tetsuo--> yeah the patch would have to be simple and to the point
[07:00:33] <av500> is it?
[07:00:38] <tetsuo--> not currently
[07:01:46] <tetsuo--> i think its 20-50 lines spread over 2-10 files currently
[07:02:36] <tetsuo--> and i'm convinced some stuff is just plain hacks that need to be beautified into ifdef's
[07:02:58] <scaphilo> how do i tell ffmpeg to use h263? h263 is not a full encoder right? It works as a modification to mpeg4 when i understand that correctly. ---- Would -vcodec h263 correct?
[07:05:19] <tetsuo--> i have another question about a possible include, how about dxva specific changes to the h264, vc1 and mpeg2 decoders?
[07:05:37] <Tjoppen> tetsuo--: we had problems with AV_TIME_BASE_Q in MSVC, due to the syntax it's defined with
[07:06:26] <Tjoppen> our solution was to use a constant instead, in the places we needed it
[07:06:26] <tetsuo--> i guess we fixed it somehow
[07:07:17] <tetsuo--> i'm not to deep into the code as i am not a programmer myself, all i know is that we have been able to compile ffmpeg with msvc for years and i believe we can upstream those patches if/when they are sain
[07:07:48] <Dark_Shikari> tetsuo--: no way that will work
[07:07:52] <Dark_Shikari> Visual studio uses MSVC
[07:07:57] <Dark_Shikari> It might work if you use ICC instead
[07:08:00] <Dark_Shikari> but MSVC is not C99-compatible
[07:08:07] <tetsuo--> it works
[07:08:15] <Dark_Shikari> doubtful, ffmpeg is chock-full of C99 features
[07:08:18] <tetsuo--> but i cannot tell you how badly hacked it was to make it possible
[07:08:40] <tetsuo--> i know it is, and everyone keeps saying its impossible, and yet we do it every day since 2004
[07:08:40] <Tjoppen> tetsuo--: just diff?
[07:08:57] <Dark_Shikari> tetsuo--: Sure, you can do it, but it will be never accepted
[07:09:01] <Dark_Shikari> because accepted means banning c99
[07:09:06] <Tjoppen> apart from the problem of figuring out which version/revision you based it off of
[07:09:23] <tetsuo--> we update ffmpeg head every 2-4 months
[07:09:52] <tetsuo--> Dark_Shikari obviously, thats why i have asked some of the members of my team to extract the patches and look at their sainness
[07:10:02] <Dark_Shikari> why not just require ICC?
[07:10:04] <Dark_Shikari> problem solved
[07:10:11] <tetsuo--> for one its hella expencive
[07:10:26] <tetsuo--> and secondly it generates like 300 fatal errors
[07:10:48] <tetsuo--> we compile ffmpeg with gcc/mingw for release builds, no problem there
[07:10:56] <Yuvi> sainness?
[07:11:09] <Dark_Shikari> lol
[07:11:20] <tetsuo--> Yuvi: I clean patch that doesnt break any intended behaviour
[07:11:23] <astrange> Yuvi: are you making the mov muxer write qt and nero chapters at the same time?
[07:11:36] <Yuvi> astrange: yeah
[07:12:16] <astrange> well, i guess it doesn't take much space
[07:12:22] <tetsuo--> we only use msvc for debug builds, and since its been working flawlessly since 2004 i think there might be some stuff there that could be included in ffmpeg without reverting any of the c99 stuff etc...
[07:13:04] <tetsuo--> obviously if all the patch does is replace all the c99 lines with msvc compatible lines its pointless
[07:13:52] <Dark_Shikari> why doesn't icc work for debug builds?
[07:14:15] <tetsuo--> we get a lot of errors
[07:14:42] <Yuvi> btw, changing stuff like (AVRational){1, AV_TIME_BASE} won't be accepted (msvc can't handle that?)
[07:15:08] <tetsuo--> Yuvi the patch has to be acceptable on your terms ofcourse
[07:15:18] <Yuvi> just forwarning you :)
[07:16:52] <av500> tetsuo--: is that patch available somewhere to look at?
[07:16:54] <Tjoppen> could be useful for some people though, if you maintain the branch
[07:18:30] <tetsuo--> here is our patched source: http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/transform/MPCVideoDec/ffmpeg?rev=1773
[07:18:39] <tetsuo--> we dont have the patches seperated out yet
[07:18:57] <av500> tetsuo--: and thats against what SVN rev?
[07:19:05] <tetsuo--> let me see
[07:20:48] <tetsuo--> no rev in the commitlog
[07:20:49] <tetsuo--> 02/06/10 17:50:00 (2 months ago)
[07:21:19] <tetsuo--> could be off by 1-3 days
[07:22:35] <av500> hmm, the fact that you miss files like "configure" makes me think your patch will not be "small" :)
[07:23:21] <Tjoppen> not to mention libavformat and libavfilter
[07:23:42] <av500> why are e.g. LICENSE missing?
[07:24:29] <tetsuo--> we dont use the missing stuff
[07:24:44] <av500> you dont use a LICENCE?
[07:24:59] <tetsuo--> i have no idea about the missing licence
[07:25:47] <tetsuo--> ill ask them to fix that
[07:28:09] <tetsuo--> this is interesting: http://sourceforge.net/apps/trac/mpc-hc/browser/trunk/src/filters/transform/MPCVideoDec/ffmpeg/custom_code.txt?rev=1794
[07:30:34] <tetsuo--> unfortunately he did not make the same listing for ffdshow :(
[07:31:58] <av500> tetsuo--: getting a proper diff would be good for a start
[07:32:07] <tetsuo--> i agree
[07:33:03] <tetsuo--> i'll keep pushing for a proper diff, that matches a recent svn build
[07:33:18] <tetsuo--> and then bring it up again
[07:35:52] <tetsuo--> i see ffdshow doesnt have the licence file either
[07:39:06] <tetsuo--> ill asj them to fix it too
[07:39:09] <tetsuo--> ask*
[07:40:11] <astrange> ffdshow's installer treats the gpl as a click through license you have to "agree" to
[07:40:38] <Dark_Shikari> which is more restrictive than it needs to be, but is at least sufficient
[07:40:49] <astrange> which not only is an ffmpeg license violation but is also them violating their own license
[07:41:06] <astrange> i don't think being required to agree to the gpl even means anything. it doesn't require the end user to do anything
[07:41:23] <Dark_Shikari> well, the GPL is definitely being distributed with the application and displayed to the user
[07:41:38] <Dark_Shikari> obviously the clickthrough is stupid and pointless
[07:47:39] <av500> no point for enduser to accept gpl
[07:48:07] <Tjoppen> the gpl is meant for the benefit of the user, so: yes, there is apoint
[07:48:32] <astrange> there's nothing to "disagree" with
[07:48:49] <astrange> it's not persuasive or anything, it's just conditional statements
[07:48:53] <av500> when you disagree, you are entitled to your money back!
[07:48:55] <Tjoppen> sure there is, but then you don't get to use the software. same as any other EULA
[07:49:07] <astrange> and as you know from discrete math, those are still true if the condition is false
[07:49:27] <astrange> no, you always get to use the software. you can combine gpl and proprietary software and use it
[07:49:35] <astrange> you just can't give it to anyone else
[07:49:57] <Tjoppen> true. feels like discussing semantics anyway
[07:51:28] <Tjoppen> as long as the user is just *using* it, then there's no obligations
[08:13:56] <KotH> hoi bilboed-4
[08:14:42] <pJok> mru, ffthreads?
[08:17:04] <av500> pJok: supported out of the box on ffos
[08:42:32] <peloverde> Hmm just stream copied Pirates3.mov successfully
[08:42:40] <peloverde> Anyone else want to try?
[08:42:53] <merbzt> omg, a working streamcopy
[08:43:29] <peloverde> well with the BSF
[08:44:04] <pentanol> mru you here? I made disasm libavcodec lib compiled for arm uClib which given segfault to me.
[08:44:17] <wbs> gah roundup is slow
[08:46:46] <peloverde> "ffmpeg -i Pirates3.mov -acodec copy copy.adts && ffmpeg -i copy.adts -acodec copy -absf aac_adtstoasc out.mp4" for anyone who wants to try
[08:48:52] <peloverde> <bcoudurier> [NULL @ 0x3084d00]Multiple RDBs per frame with CRC is not implemented. Update your FFmpeg version to the newest one from SVN. If the problem still occurs, it means that your file has a feature which has not been implemented.
[09:53:25] <Tjoppen> I just remembered that I used to be annoyed that no audio encoder specifies supported_samplerates. perhaps it's time to rectify that
[09:54:03] <Tjoppen> .supported_samplerates = (const int[]){44100, 48000, 32000, 22050, 24000, 16000, 0}, <-- works well in the mp2 encoder
[09:54:25] <Dark_Shikari> +10000
[09:54:31] <Dark_Shikari> then make it automatically convert if it isn't supported
[09:54:34] <Dark_Shikari> Then do the same for channels
[09:54:41] <Dark_Shikari> then do the same for sample rate/ sample format /channel combinations
[09:54:56] <Dark_Shikari> Then people will no longer be wondering why their mp3 encodes failed with no error message.
[09:55:02] <Dark_Shikari> due to their input being 5.1
[09:56:27] <Tjoppen> right, channel_layouts. well, letting the user know for would be good for a start, for which those lists are good
[09:56:37] <Tjoppen> -for
[10:01:40] <Tjoppen> unless I'm mistaken, a list of combinations would only be needed for certain encoders, right? well, perhaps most. but the basic lists are good for encoders that have fewer limitations, where a list of combinations would become huge
[10:03:39] <merbzt> Tjoppen: what do you set for "encoder" supporting random samplerates ?
[10:03:59] <Tjoppen> nothing
[10:04:12] <merbzt> ok
[10:04:24] <merbzt> send a [RFC] I'll support the idea
[10:04:29] <Tjoppen> that's what my code assumes at the moment - unless supported_samplerates isn't set, it just goes with whichever setting it has
[10:04:49] <Tjoppen> if it fails, and supported_samplerates isn't set (which it never is), it just picks from a list of ones I know usually work
[10:06:37] <Tjoppen> might as well - don't have much else to do today. all tickets for today are done, an tests are running happily :)
[10:08:57] <Tjoppen> more fun: there's no way to figure out which bitrates are supported either
[10:09:28] <Tjoppen> except for brute forcing avcodec_open() via a list of "good" bitrates
[10:15:49] <J_Darnley> Add a new field?
[10:16:51] <Tjoppen> yeah. supported_bitrates
[10:18:52] <Tjoppen> that, and/or define something like struct audio_format { sample_rate, sample_format, channel_layout, bitrate } with "optional" ("anything goes") elements being zero (or SAMPLE_FMT_NONE)
[10:19:37] <Tjoppen> struct audio_format *supported_audio_formats
[10:20:01] <Tjoppen> lunch time. I'll ponder it a bit
[10:20:23] <av500> also take care that e.g. some canon digicams used to record 11024hz :)
[11:17:29] <Tjoppen> av500: that sounds like something on the decoder side though. I'm only considering encoders for now
[11:18:23] <BastyCDGS> greetings to all, how are u?
[11:18:50] <BastyCDGS> a small question, is there a way to pass AVFormatContext->priv_data from demuxer to decoder?
[11:19:00] <BastyCDGS> I need that for IFF-ANIM to determine HAM/ECB modes
[11:19:05] <wbs> no, you're not supposed to pass such data
[11:19:08] <BastyCDGS> and decode the colormap in a correct way
[11:19:14] <wbs> since the demuxers and decoders should be decoupled
[11:19:17] <BastyCDGS> ok so I have to find another way
[11:19:38] <wbs> you need to pack it within AVPacket in some way, or pass it as codec extradata in AVCodecContext->extradata
[11:20:15] <BastyCDGS> the current solution has only the colormap directly as extradata, so I have to create a new structure and put cmap data as well as cmap flags I suppose
[11:21:04] <wbs> ah, is the colormap something like a palette? I'm not familiar with the handling of palette formats in lavc/lavf, I think that's stored somewhere else than in the extradata field
[11:22:11] <BastyCDGS> yes but a amiga specific (planar) version of it
[11:22:26] <BastyCDGS> there are special modes like HAM/ECB which have to be handled specially
[11:22:38] <wbs> ok
[11:23:07] <BastyCDGS> HAM can be compared best to a true color mode just it's 4096 colors (6bpp) or 262144 colors (8bpp)
[11:23:22] <wbs> whichever way you do it, remember that you can't just stash some generic struct into the extradata field, the format should be well-specified (even if the extradata format is different for each codec)
[11:23:50] <BastyCDGS> so put the declaration in iff.h so it's available public
[11:24:29] <wbs> no, that wouldn't be enough, you can't memcpy a struct like that generically
[11:24:50] <wbs> what you put in AVCodecContext->extradata is the "official wire format" of that data, like what's in AVPacket->data
[11:25:01] <wbs> and should be binary compatible between different builds/architectures etc
[11:25:47] <wbs> if I for example demux the data somewhere, store the extradata and packet data somewhere, and then want to decode somewhere else, on a different machine
[11:27:01] <Tjoppen> BastyCDGS: while I'm not sure what ECB, wouldn't it and HAM count as separate codecs?
[11:27:11] <Tjoppen> *ECB is
[11:27:47] <BastyCDGS> ECB is like normal palette just that the upper half of colors is 50% brightness
[11:27:57] <BastyCDGS> of the lower half
[11:28:29] <Tjoppen> so implement that as a normal raw 8-bit video output, and HAM as an intra-only codec ("ham")
[11:28:45] <BastyCDGS> so let's say a 6 planar colormap (64 colors) in ECB mode contains 5 plane color values (0-31 color indices) and you have to initialize colors 32-63 with 50% brightness of 0-31
[11:29:09] <Tjoppen> yes, that shouldn't be too much of a problem. just look at some palette format demuxer, such as FLIC
[11:29:33] <Tjoppen> err.. except FLIC is compressed
[11:30:22] <Tjoppen> anyway, as long as the demuxer can set the palette you should be OK
[11:32:23] <BastyCDGS> the thing is that the current implementation just puts the raw CMAP in the extradata and does decoding the CMAP on the decoder side
[11:32:41] <BastyCDGS> is it appreciated to change that such the demuxer decodes the CMAP and the decoder simply applies it?
[11:32:51] <BastyCDGS> then I wouldn't need extraflags at all
[11:32:57] <Tjoppen> have both demuxer and decoder share the CMAP decoding code then
[11:33:28] <Tjoppen> that way you don't need to put that special struct in extradata, but the CMAP decode function can output it
[11:37:10] <Yuvi> how does ffmpeg read VLCs longer than 16 bits?
[11:37:52] <mru> what makes you thing 16 bits is a special length?
[11:38:52] <Yuvi> oh, I guess it's just vp3 that uses uint16_t
[11:44:38] <Yuvi> okay, new question: is it possible to read 32 bits without using tables of size 2^11?
[11:45:09] <Yuvi> and if you only have 32 symbols, is it even possible to have huffman codes of 32 bits?
[11:45:59] <mru> depends on how you construct the codes
[11:46:11] <mru> unless you're a total idiot, I doubt you'll get 32-bit codes
[11:46:29] <Yuvi> theora allows it :/
[11:46:35] <Tjoppen> 31 at most, and even that is not very likely
[11:46:40] <mru> well, they _are_ total idiots
[11:46:45] <pross-au> that would be a crap tree
[11:47:18] <mru> GET_VLC allows only 3 levels of tables
[11:47:34] <mru> so you'd have to have 11 bits per level, yes
[11:48:36] <mru> I guess the worst case is codes like this:
[11:48:37] <mru> 0
[11:48:38] <mru> 01
[11:48:44] <mru> err, 10
[11:48:46] <mru> 110
[11:48:47] <mru> 1110
[11:48:47] <mru> etc
[11:49:44] <Tjoppen> ah, right. wrong of me then. doi!
[11:50:18] <mru> doi, is that french for duh?
[11:50:22] <pross-au> mru *BUT*
[11:50:34] <pross-au> such a table would never happen
[11:50:43] <pross-au> unless it was generated by a moron
[11:50:47] <mru> that's what I said
[11:51:08] <mru> the question is, can we expect morons?
[11:51:17] <mru> and with theora, the answer is yes
[11:51:17] <pross-au> Sounds like rice coding
[11:51:21] <pross-au> With VLCs
[11:51:36] <Yuvi> given that it took this long to find an issue with using uint16_t, maybe not
[11:53:13] <pross-au> Just wait till those same people get their hands on VP8
[11:53:13] <Yuvi> lemme see if 10 vs. 11 makes a significant difference on my machines
[11:53:27] <mru> double table size
[11:53:51] <mru> otoh twice as many codes will fit in the first level
[11:54:09] <mru> make a huge difference in aac
[11:55:09] <av500> Tjoppen: it will matter when trancoding
[11:56:09] <Tjoppen> as long as the encoder supports it, no problem I guess. otherwise you can't help resampling from 11024 to 11025
[11:56:28] <Tjoppen> which'd depend on whether supported_samplerates is NULL or not
[11:56:52] <Tjoppen> or if the encoder has explicit support for such a samplerate
[11:57:07] <mru> or you pretend they're the same and adjust the video frame rate ever so slightly
[11:57:21] <av500> I think I just declared 11024=11025 in my app :)
[11:59:14] <BastyCDGS> question, is such code "legal"? I use this for ECB
[11:59:17] <BastyCDGS> pal[i] = 0xFF000000 | AV_RB24( avctx->extradata + i*3 );
[11:59:17] <BastyCDGS>         pal[j] = 0xFF000000 | (AV_RB24( avctx->extradata + i*3 ) >> 1);
[11:59:47] <BastyCDGS> the >> 1 in the pal[j] line shall make the 50% brightness
[12:00:02] <wbs> no, that won't work
[12:00:18] <mru> there's a nice macro for that somewhere
[12:00:19] <wbs> you'll shift in the lowest bits from one color into the highest bits of next
[12:00:20] <mru> hold on
[12:00:48] <BastyCDGS> wbs, argl yeah you're right...
[12:00:57] <mru> dsputil.h
[12:01:08] <mru> rnd_avg32() and no_rnd_avg32
[12:01:26] <mru> you could simplify one of those for 0 on one side
[12:01:31] <mru> if gcc doesn't do it for you
[12:01:38] <janneg> av500: max error is probably .16s since cameras are usually limited to 29:59 min of video
[12:01:51] <av500> janneg: thats why I did not care :)
[12:02:01] <janneg> to avoid higher duties on camcorders
[12:02:18] <mru> 11024 and 11025 are close enough that nobody can tell the difference
[12:02:50] <av500> sure
[12:02:57] <mru> I'll notice 1% pitch change
[12:03:13] <mru> even if not listening back to back
[12:03:27] <av500> change yes, but absolute?
[12:04:17] <mru> if I listen to a song a few times, then hear it again much later played 1% faster I can notice
[12:04:36] <mru> I wouldn't notice notes being off just by hearing it once
[12:04:53] <mru> some people do
[12:05:00] <mru> musicians typically
[12:05:06] <av500> most ppl dont notice the 4% change for 24->25fps
[12:05:17] <mru> that's because it's not there
[12:05:33] <mru> they do a pitch-preserving compression
[12:05:39] <av500> they downpitch?
[12:05:41] <av500> ah
[12:05:43] <janneg> av500: I would expect the audio to be resampled
[12:05:55] <mru> a 4% increase in pitch sounds like chipmunks
[12:06:02] <av500> janneg:  resampling does not help
[12:06:26] <BastyCDGS> calling rnd_avg32(0xFFFFFF,0) will result in 0x808080?
[12:06:31] <merbzt> 11024/11025 ~ 0.01 %
[12:06:32] <av500> whatever it is they do make the stupid movie end faster :)
[12:06:56] <mru> mythtv has a nice 1.5x mode
[12:06:56] <av500> merbzt: I was mentioning that as a real world example of why not to stritlcy match samplerate in the above proposal
[12:07:01] <mru> as does ps3
[12:07:16] <av500> not because ppl can hear the diff
[12:08:19] <janneg> yes, I ment pitch preserving tempo changes
[12:08:23] <av500> BastyCDGS: no, 0x7F,5 .)
[12:08:39] <mru> av500: that's 0x7f.8
[12:08:40] <janneg> mythtv uses soundtouch
[12:09:05] <BastyCDGS> av500 it takes uint32_t as in/out ;)
[12:09:06] <av500> mru: I am free to define my own number format :P
[12:09:23] <mru> BastyCDGS: this is #ffmpeg-devel
[12:09:29] <mru> anything goes
[12:09:55] <BastyCDGS> just want to be sure
[12:14:07] <BastyCDGS> const uint32_t col_val = AV_RB24( avctx->extradata + i*3);
[12:14:07] <BastyCDGS>         pal[i] = 0xFF000000 | col_val;
[12:14:07] <BastyCDGS>         pal[j] = 0xFF000000 | (col_val & 0xFEFEFE) >> 1;
[12:14:13] <BastyCDGS> I solved it that way, should do it ;)
[12:15:32] <BastyCDGS> this, of course, rounds downwards, but the original ECB code from IFF ANIM does it that way, too.
[12:17:05] <BastyCDGS> I seen my mistake, the original code was doing this per-byte basis thus it was legal to do / 2
[12:17:31] <KotH> we not only design our own OS to for standard compliance, but now also our own number format or what?
[12:23:55] <Tjoppen> neat trick
[12:30:04] <BastyCDGS> question, pixfmt.h is only for pixel format ffmpeg outputs (thinking about adding HAM6 and HAM8 there)
[12:30:10] <BastyCDGS> ?
[12:34:23] <mru> what are those?
[12:35:37] <BastyCDGS> they allow 4096 and 262144 colors with a 6-bit / 8-bit palette only
[12:35:45] <BastyCDGS> and are natively used by amiga hW
[12:36:02] <BastyCDGS> to be displayed at once
[12:36:47] <BastyCDGS> consider them some sort of pseudo-true-color
[12:37:00] <mru> what do the pixels look like?
[12:37:29] <BastyCDGS> http://en.wikipedia.org/wiki/Hold-And-Modify
[12:37:54] <av500> mru: they look like this: .
[12:38:20] <mru> that's two pixels in my font
[12:38:39] <av500> it was not to scale
[12:40:01] <mru> oh
[12:42:28] <Tjoppen> having HAM be a pixel format sounds wrong
[12:42:39] <Tjoppen> in that case ADPCM could be a sample format
[12:43:33] <mru> yes
[12:43:36] <ohsix> since it doesn't have to be strobed out on real hardware wouldn't it make sense to decode it to a 4096 or 262k color format?
[12:43:53] <mru> or to plain old rgb24
[12:44:07] <mru> or 32 as the case may be
[12:44:12] <BastyCDGS> there's a HAM6/8 decoder to rgb24 in iffanim.c ;)
[12:44:27] <BastyCDGS> so it's probably better to use that, but wanted to discuss this out first
[12:45:59] <BastyCDGS> when I've finished that and everything else is fine, then IFF-ANIM should display the first picture correct ;)
[12:46:38] <BastyCDGS> then I have to do the eric graham decoder (it's the most widespread in IFF-ANIM) and the iff anim demuxer should work (except sound)
[12:49:39] <Tjoppen> speaking of old formats, perhaps I should commit my "terror from the deep" fix for the flic demuxer. mike OK:ed it and has samples, so I assume he'll take it from here
[12:49:52] <jai> merbzt: ping
[12:49:53] <Tjoppen> if he wants any tests that is
[12:53:21] <pross-au> HAM flickers though
[12:53:49] <pross-au> u dont get that with current pixfmt
[13:01:42] <CIA-7> ffmpeg: vitor * r22929 /trunk/libavformat/mtv.c: Fix MTV decoding on big-endian systems
[13:06:17] <CIA-7> ffmpeg: vitor * r22930 /trunk/libavcodec/amrnbdec.c: 10l: do not try to unpack DTX frames in AMR-NB decoder
[13:12:14] <Yuvi> ok, 11 vs. 10 is enough of a wash that I can't justify not supporting stupid huff trees
[13:15:29] <BastyCDGS> is there a more recommended way than doing this in avcodec.h to support all these stuff?
[13:15:31] <BastyCDGS> CODEC_ID_IFF_ANIM0,
[13:15:31] <BastyCDGS>     CODEC_ID_IFF_ANIM0_HAM6,
[13:15:31] <BastyCDGS>     CODEC_ID_IFF_ANIM0_HAM8,
[13:15:39] <BastyCDGS> CODEC_ID_IFF_ANIM1,
[13:15:39] <BastyCDGS>     CODEC_ID_IFF_ANIM1_HAM6,
[13:15:39] <BastyCDGS>     CODEC_ID_IFF_ANIM1_HAM8,
[13:15:42] <BastyCDGS> ...
[13:16:11] <Yuvi> can you determine the version / whatever based on anything other than the codec id?
[13:16:31] <Yuvi> or stuff it in the extradata if it's only in one container
[13:16:41] <BastyCDGS> would be possible, yes...
[13:16:56] <wbs> if you unpack the color map into the palette in the demuxer, is there any need to differentiate between them in the decoder at all?
[13:17:26] <BastyCDGS> HAM also changes the image format itself
[13:17:41] <BastyCDGS> it's not only the palette
[13:17:56] <wbs> ok
[13:18:31] <BastyCDGS> so the best way is just have one CODEC_ID_IFF_ANIM but also for HAM6/8?
[13:19:11] <mru> if they are just variants of the same codec, they should probably use the same codec id
[13:19:25] <mru> it's like we don't use different IDs for PNG depending on the compression type or pixel format
[13:19:41] <av500> CODEC_ID_PNG_LOLCATZ
[13:19:53] <CIA-7> ffmpeg: conrad * r22931 /trunk/libavcodec/vp3.c: theora: coeff huffman codes are allowed to be up to 32 bits long (for 32 tokens)
[13:20:38] <BastyCDGS> i ask because the original IFF code also had two different decoders for byterun and raw image data for ILBM
[13:23:22] <av500> __attribute__((optimize("no-omit-frame-pointer"))); ???
[13:23:32] <mru> where?
[13:24:04] <av500> speex resampler
[13:24:11] <mru> go figure
[13:24:41] <av500> I have to mention we had to remove that?
[13:25:31] <peloverde> __attribute__((optimize(0))) is the only way I can manage to debug ffmpeg
[13:25:58] <merbzt> peloverde: why ?
[13:26:03] <ohsix> theres a configure parameter
[13:26:23] <peloverde> because builds with -O0 fail and even -O1 seems to fuck up gdb
[13:26:35] <peloverde> which parameter?
[13:26:37] <ohsix> just setting CFLAGS?
[13:27:54] <merbzt> peloverde: do you add -g3 ?
[13:28:17] <peloverde> I don't add anything
[13:28:20] <BBB___> merbzt: can you ask andreas to apply as google mentor?
[13:28:24] <BBB___> so I can allocate him
[13:28:27] <ohsix>   --disable-optimizations  disable compiler optimizations
[13:28:51] <ohsix> theres a grip of them
[13:28:54] <merbzt> BBB: you're soooooooo slow
[13:28:59] <BBB> huh?
[13:29:02] <BBB> I guess
[13:29:05] <merbzt> F5
[13:29:15] <BBB> I checked the google list 5 seconds ago
[13:29:31] <BBB> mentor: stefano
[13:29:33] <BBB> that's wrong
[13:29:36] <merbzt> mr oman is there since yesterday
[13:29:44] <merbzt> ahh ok, I get it
[13:29:53] <merbzt> he prefered to be co-mentor
[13:30:03] <merbzt> leave it as it is
[13:30:05] <BastyCDGS> BBB, you speaking of my mentor, I guess
[13:30:16] <merbzt> BastyCDGS: -> andoma
[13:30:29] <BBB> brb
[13:30:30] <BBB> lab meet
[13:31:01] <BastyCDGS> btw, stefano told me yesterday evening he'ld like my second mentor, too.
[13:31:10] <merbzt> peloverde: --disable-optimizations --enable-debug=3 works fine for me when debugging with kdevelop and ddd
[13:31:48] <jai> --disable-asm --disable-optimizations too
[13:32:23] <ohsix> it only took --d-o to reify gdb the few times i've needed to
[13:32:58] <peloverde> you start throwing disable-asm around and all the sudden you are using different mdct scaling and whatnot
[13:33:12] <merbzt> peloverde: true :)
[13:33:53] <Yuvi> ugh, I managed to miss a cosmetic before pushing that
[13:35:13] <peloverde> though --disable-optimizations does seem to build ok
[13:36:17] <ohsix> \m/
[13:36:19] <merbzt> add -g3 for source level debuggability
[13:45:15] <kierank> is there any way in gdb (or ddd) to continue running until a certain address?
[13:45:29] <Yuvi> break * address ?
[13:45:30] <kierank> (a breakpoint won't work)
[13:46:09] <kierank> that won't work in this case because of the mmap loaded binary
[13:46:32] <ohsix> force the full load? LD_SOMETHING :>
[13:46:35] <Yuvi> now I'm curious why not?
[13:46:51] <Yuvi> how does mmap break that?
[13:46:54] <kierank> hmmm I wonder if it will work when you're actually running in the code segment
[13:47:48] <ohsix> maybe an old gdb that wont reapply when modules are loaded
[13:48:25] <ohsix> LD_BIND_NOW btw; wont work for dlopen stuff thats to come in the future though :9
[13:48:38] <kierank> seems to work when you're actually running in the code segment
[13:49:54] <kierank> hmmm later on it fails
[14:08:54] <BastyCDGS> uhh something crazy happened
[14:09:15] <BastyCDGS> wanted to configure but kate did change to subdir of libavcodec
[14:09:35] <BastyCDGS> since I do this normally from a build dir with ../configure it created makefile files there
[14:09:44] <BastyCDGS> which broke everything totally
[14:09:58] <BastyCDGS> had to do rm -rf and svn up
[14:11:15] <BastyCDGS> when using kate with the embedded console it does automatically a cd into the dir where the file you're editing is
[14:11:29] <BastyCDGS> I didn't notice that and to the configure was exec'd in wrong dir
[14:13:00] <KotH> note: there is nothing that beats a bunch of terms and vim
[14:16:02] <BastyCDGS> joe is a good editor also
[14:17:28] <jai> sam and acme too ;)
[14:25:56] <BastyCDGS> it works!!!!!!
[14:26:01] <BastyCDGS> window opens with iff anim
[14:26:11] <BastyCDGS> although shows some garbarge right now
[14:28:43] <BastyCDGS> for testing I hardcoded it to the IFF-ILBM raw decoder
[14:29:02] <BastyCDGS> I think I just have to implement the correct decoder ;)
[14:30:03] <BastyCDGS> easiest way would be implement it with:
[14:30:26] <BastyCDGS> a different decoder each compression format supported
[14:30:32] <BastyCDGS> like the original IFF code does also
[14:30:41] <BastyCDGS> then we have ANIM0-8/ANIM-K
[14:30:59] <BastyCDGS> can i do this way right now just for getting it to work?
[14:49:27] <merbzt> sure, get it working first
[14:49:43] <merbzt> shouldn't be to hard to change if it's better another way
[15:26:22] <BastyCDGS> wb BBB
[15:26:49] <BastyCDGS> did you read that IFF-ANIM now opens window an shows first image (though garbarged)
[15:26:56] <BastyCDGS> working on the decoder stuff
[15:27:48] <BBB> no, but that's good news
[15:27:56] <BBB> andoma: can you subscribe to google as a mentor for soc?
[15:29:57] <BastyCDGS> just to reminder, deadline is 1700 UTC
[15:30:13] <BBB> yes
[15:30:15] <BastyCDGS> for scoring students
[15:30:22] <BBB> merbzt: what do we do with michael chinen?
[15:30:32] <BBB> BastyCDGS: you're fine, but keep working on the qualification task
[15:30:34] <BastyCDGS> btw, should I provide a patch now for the current state
[15:30:37] <BBB> yes
[15:30:40] <BastyCDGS> ok
[15:30:47] <BastyCDGS> just compiling if it still works ;)
[15:30:55] <BastyCDGS> if that's ok I will commit patch
[15:31:31] <BastyCDGS> btw, yesterday when I finished talking with saste something funny happened
[15:31:41] <BastyCDGS> before I went to bed I did an aptitude dist-upgrade
[15:31:47] <BastyCDGS> and what I see, ffmpeg :D
[15:31:52] <BastyCDGS> only ffmpeg :D
[15:32:13] <BastyCDGS> but it's still a 2007 cvs version
[15:34:46] <BastyCDGS> compile & ffplay successful, that is with the garbled image ;)
[15:34:51] <BastyCDGS> so I will prepare patch
[15:34:56] <andoma> BBB: i believe i've already did that?
[15:35:04] <BBB> what did you do?
[15:35:29] <BBB> ah there, you are there now
[15:35:32] <BBB> ok, you're assigned
[15:35:53] <BBB> thanks
[15:36:01] <BBB> merbzt: please advise on michael chinen again :)
[15:36:30] <andoma> BBB: ok :)
[15:36:35] <BastyCDGS> me? added EHB support etc.
[15:37:04] <BBB> BastyCDGS: no, andoma :)
[15:42:48] <BastyCDGS> patch commited to ml
[15:42:57] <BastyCDGS> could you review it, BBB?
[16:08:19] <DonDiego> BastyCDGS: you don't "commit" a patch, you "submit" it
[16:08:39] <DonDiego> "commit" is what is done to your patch subsequently if it is accepted
[16:09:00] <av500> DonDiego: you throw it into the cold waters of the ML
[16:10:03] <BastyCDGS> well, dict.leo.org says (english => german) both words are synonymous
[16:10:07] <BastyCDGS> übergeben, überreichen ;)
[16:10:57] <BastyCDGS> but if you like I will write submit instead of commit in the future ;)
[16:12:23] <BastyCDGS> it's like sign in and login
[16:14:33] <DonDiego> no, it's not synonymous
[16:14:57] <DonDiego> neither are übergeben and überreichen ..
[16:15:23] <DonDiego> "submit" means (roughly) giving something to somebody
[16:15:34] <av500> sich übergeben und sich überreichen are not the same
[16:15:46] <DonDiego> "commit" means (roughly) that there is a commitment
[16:15:49] <BastyCDGS> av: lol
[16:16:06] <DonDiego> you can commit yourself to a task
[16:16:34] <DonDiego> you cannot submit yourself to a task
[16:16:35] <iamlindoro> BastyCDGS: Submitting something implies it is for the other party to approve.  Commit means you make the change. (at least, in this context)
[16:16:48] <BastyCDGS> ahh ok...
[16:17:14] <DonDiego> BastyCDGS: i'm just teaching you the standard vocabulary so that people don't have trouble understanding you..
[16:17:38] <BastyCDGS> thank you for this, I'll write submit in the future ;)
[16:17:42] <DonDiego> :)
[16:17:58] <BBB> BastyCDGS: will review, give me a bit
[16:18:00] <BBB> busy with work
[16:18:01] <BBB> :)
[16:18:27] <BBB> ham6/8...
[16:18:28] <BBB> hmm...
[16:18:32] <BBB> I remember that from lasst year's soc
[16:19:01] <BastyCDGS> most of the movies in the anim sample pack won't work without HAM support
[16:19:16] <BastyCDGS> just try ffplay out with the patch (it bumps an error message if it's HAM6/8)
[16:20:14] <BastyCDGS> if you want intend to change my score in gsoc after reviewing it, you should do this within next 40 minutes ;)
[16:20:36] <BastyCDGS> the iff anim sample cpp source has a HAM6/8 to 24bpp converter
[16:23:32] <BastyCDGS> it's just that I still have to figure out what's the best way to integrate HAM in ffmpeg
[16:25:21] <BBB> uhm, I'm admin for soc, I can see which students will be accepted :)
[16:25:35] <av500> BBB: you got the power
[16:25:39] <BBB> \o/
[16:26:03] <BBB> BastyCDGS: score is for ranking, we don't use scores, we use mentor assignment instead
[16:26:10] <BBB> you have a mentor assigned, so you're fine
[16:26:35] <BBB> BastyCDGS: try to interact with andoma a bit so you guys get to know each other, he'll help mentoring you, he knows mod better than me or saste
[16:26:39] <BBB> but we'll all help you
[16:27:14] <BastyCDGS> I sometimes ask if I need help for mod directly at all, don't forget that this is absolutely my domain, I'll more likely need help for ffmpeg related stuff
[16:27:28] <BBB> right, so we can help with all of that :)
[16:27:38] <BastyCDGS> as completely opposed to video stuff, this is almost completely new for me
[16:27:40] <BastyCDGS> ;)
[16:27:52] <BastyCDGS> switching from iff-anim to mod will be like a fish returning to water ;)
[16:28:04] <BastyCDGS> at least for me ;)
[16:29:09] <BastyCDGS> I'm not experienced just with mod decoding also with encoding including a complete own format
[16:29:36] <BastyCDGS> so maybe ffmpeg will then able to convert xm to mod, it to s3m, s3m to tcm, whatever
[16:30:37] <BastyCDGS> bbb, one question though, you said you don't use scoring but mentoring instead...
[16:30:56] <BastyCDGS> stefano yesterday said that you got 10 slots allocated by google and if it's more than 10 the best ranked students will be accepted
[16:31:13] <BastyCDGS> maybe you could clarify on that, it sounds a little bit contraversal...
[16:32:14] <BBB> BastyCDGS: trust me, you're fine
[16:32:55] <BastyCDGS> so I can consider me accepted?
[16:33:12] <BastyCDGS> yippppppppppppppieeeeeeeeee
[16:33:21] * BastyCDGS hands out a bottle of beer to everyone
[16:34:09] <BastyCDGS> a lot of you have recommended me to switch to git
[16:34:21] <mru> oh yes
[16:34:25] <BastyCDGS> any good advices to do it best?
[16:34:36] <mru> read a primer and dive in
[16:34:38] <BastyCDGS> i.e. learn it the fastest way
[16:34:48] <BastyCDGS> so we won't lose time on that
[16:35:01] <mru> you'll save many days of frustration
[16:35:36] <BastyCDGS> apt-installing git right now ;)
[16:35:53] <BastyCDGS> git 4.3.20 is fine?
[16:35:58] <mru> uh?
[16:35:58] <bilboed> git-core
[16:36:09] <mru> 1.7.0.x is current
[16:36:18] <bilboed> yet-another fine example of why I hate debian renaming packages :)
[16:36:45] <BastyCDGS> git-core installing now...1.5.4
[16:36:45] <wbs> well, they had some other package named git earlier
[16:36:49] <kierank> http://spheredev.org/wiki/Git_for_the_lazy
[16:37:07] <wbs> but in debian unstable, that one is removed and it's available as simply "git"
[16:37:37] <mru> yeah, when you have one obscure and one wildly popular thing with the same name, which do you rename?
[16:37:56] <bilboed> use prefixes like gentoo
[16:37:57] * bilboed runs :)
[16:38:06] <mru> that's one good way
[16:38:07] <BastyCDGS> kierank: thanx looks very good
[16:38:55] <BastyCDGS> shall I remove the .svn files (i.e. do they harm) before doing a first git checkout?
[16:39:29] <mru> you can't do a git checkout on top of existing files
[16:39:31] <mru> it won't let you
[16:40:03] <bilboed> BastyCDGS, if you have no local changes, just do a fresh clone
[16:40:23] <BastyCDGS> ehm I have lots of local changes ;)
[16:40:30] <BastyCDGS> the whole IFF-ANIM stuff e.g.
[16:40:43] <BastyCDGS> so I better backup my files
[16:40:49] <bilboed> make diff into a patch, you'll be able to put it back in your git checkout later
[16:41:03] <wbs> do a separate git clone, and then apply the changes in small chunks in yout git clone
[16:41:12] <wbs> (preferrably in a separate branch there)
[16:41:33] <wbs> applying the whole patch from svn diff and adding one part at a time with git add -p may be an option, too
[16:44:43] <mru> or use git gui
[16:44:48] <mru> it's quite nice actually
[16:45:06] <BastyCDGS> there's a package git-svn I see...
[16:45:25] <BastyCDGS> and even git-buildpackage looks great!!!
[16:45:38] <BastyCDGS> so I can directly build debian packages with a git repo?
[16:45:51] <bilboed> BastyCDGS, there's mixed feeling about git-svn
[16:46:04] <BastyCDGS> what it actually does?
[16:46:10] <BastyCDGS> migrate a svn repository to git?
[16:46:19] <mru> the libswscale situation is annoying
[16:46:39] <mru> other than that it's fine
[16:46:47] <bilboed> mru, I'd say submodules... but it doesn't come without it's share of pain
[16:46:55] <bilboed> s/it's/its/
[16:46:59] <mru> submodules don't do the right thing here
[16:47:01] <peloverde_> you can't dcommit from git.ffmpeg.org
[16:47:11] <peloverde_> but can from git.mansr.com
[16:47:41] <bilboed> mru, is that the only thing blocking ffmpeg from switching to git as main repo ?
[16:47:53] <mru> that's not blocking it at all
[16:47:58] <mru> michael and diego are
[16:48:27] <elenril> michael is against?
[16:48:39] <mru> more or less
[16:48:44] <bilboed> mru, lol :) so like every project switching to git... it's about politics
[16:48:44] <mru> that's my impression at least
[16:48:45] <BastyCDGS> btw, svn is sometimes a pain in eclipse...esp. within windows
[16:48:56] <BastyCDGS> it randomly says locked even if you didn't a lock etc.
[16:49:03] <elenril> why not vote about it?
[16:49:11] <bilboed> BastyCDGS, lock ? there's no lock in git
[16:49:27] <bilboed> oh, svn /me facepalms
[16:49:35] <BastyCDGS> so git is more like a transactional db?
[16:49:39] <mru> elenril: we don't vote here
[16:50:39] <elenril> i remember a vote about ffmpeg foundation =p
[16:50:50] <mru> and look what a mess that was
[16:50:55] <peloverde> the foundation is different
[16:51:17] <BastyCDGS> anyone has experience with this?
[16:51:18] <BastyCDGS> http://www.eclipse.org/proposals/egit/
[16:51:33] * mru recommends not touching eclipse
[16:51:34] <kierank> hehe eclipse
[16:51:34] <bilboed> BastyCDGS, if you *really* want to understand git, read this : http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
[16:51:37] <BastyCDGS> (no I won't use eclipse with ffmpeg but I have some eclipse projects using svn)
[16:52:02] <bilboed> BastyCDGS, once you've groked that doc... everything else in git will be crystal clear
[16:52:11] <BastyCDGS> and if git is so much better I would transfer my other stuff from svn to git too
[16:52:32] <BastyCDGS> thanks bilboed, just wgot ist ;)
[16:52:39] <BastyCDGS> it
[16:52:54] <bilboed> once you get used to it... you will never want to go back
[16:55:15] <BastyCDGS> mru, you're right about not recommending eclipse, it's really bloat and memory wasting and sloooooow
[16:55:18] <BastyCDGS> java shice
[16:55:33] <BastyCDGS> but when I start using it long time ago I didn't knew about that
[16:56:12] <mru> always look for an escape route _before_ you start using something
[16:56:29] <BastyCDGS> I would have quit that if I wouldn't do some project with GUIs which force be to use eclipse since they use svn with eclipse project
[16:56:40] <elenril> mru: still wouldn't it be better if somebody raised the issue openly rather than all these little hidden flamewars on cvslog?
[16:57:11] <BastyCDGS> GUIs oops?
[16:57:11] <BastyCDGS> i wanted to write guys
[16:57:38] <mru> choose your friends carefully :-)
[16:58:07] <BastyCDGS> I do now, proof is that I decided for ffmpeg now ;)
[16:58:43] <BastyCDGS> at university we're forced to use eclipse also
[16:59:03] <BastyCDGS> if you ask me teaching IT in german is really bad
[16:59:03] <mru> choose universities carefully too
[16:59:09] <mru> it's bad everywhere
[16:59:18] <mru> I know, I used to do it
[16:59:22] <BastyCDGS> they even teach you to write code this:
[16:59:26] <BastyCDGS> int zaehler = 3;
[16:59:30] <BastyCDGS> i.e. german variable names etc.
[16:59:32] <BastyCDGS> argggggggh
[16:59:38] <BastyCDGS> even german comments
[16:59:50] <mru> I've had to debug customer code with comments in chinese
[16:59:51] <kierank> presumably an issue of national job security
[17:00:06] <mru> it didn't matter of course, since the comments were all wrong anyway
[17:00:32] <BastyCDGS> which really break when a linux student developer opened his project in eclipse at a reading
[17:00:39] <BastyCDGS> UTF-8 <=> cp1252 ;)
[17:00:51] <BastyCDGS> with plain english you just have us-ascii no problem
[17:01:11] <mru> they used non-7-bit characters in variable names?
[17:01:22] <av500> zähler
[17:01:25] <BastyCDGS> mostly comments
[17:01:34] <av500> / blöde scheisse
[17:01:36] <mru> java allows it, I know
[17:01:37] <BastyCDGS> remember we do java there
[17:01:41] <mru> doesn't mean you should do it
[17:01:52] <mru> just like java existing doesn't mean you should use it
[17:01:58] <kierank> oh lawd
[17:01:58] <BastyCDGS> java can't even do unsigned what holy shit is this?
[17:02:08] <av500> mru: but it makes your nice phone run nice
[17:02:18] <av500> BastyCDGS: it is "holy"
[17:02:19] <kierank> av500: and slow as hell
[17:02:27] <av500> kierank: not really
[17:02:33] <BastyCDGS> oh right
[17:02:38] <mru> java has one unsigned type: char
[17:02:43] <mru> shame it's only 16 bits
[17:03:02] <BastyCDGS> I mean unsigned like in c so you can decide for each primitive
[17:03:02] <av500> shame it is not 8bit as well :)
[17:03:20] <mru> for 16-bit numbers you can choose
[17:03:25] <mru> short is int16_t
[17:03:27] <mru> char is uint16_t
[17:03:28] <BBB> BastyCDGS: you're accepted, but we want you to finish the qual task
[17:03:33] <mru> so java is a 16-bit language
[17:03:38] <BBB> BastyCDGS: otherwise we'll still throw you out of the list ;)
[17:03:45] <BastyCDGS> as already said I want to finish the qualification task anyway ;)
[17:03:49] <BBB> good :)
[17:03:55] <BBB> and yes, do git
[17:04:03] <BBB> and vote for the git switch guys, let's do it
[17:04:06] <BastyCDGS> I also said to do the other quali task we're discussed at first
[17:04:09] <BastyCDGS> resampler stuff
[17:04:12] <BBB> all this "let's wait and see" is just not helping us move forward
[17:04:16] <BastyCDGS> making at SSE/SSE2 etc. ready
[17:04:24] <BBB> that's supercool
[17:04:43] <mru> I won't switch the repos to git until michael and diego have used git-svn for a bit
[17:05:06] <BBB> no, no
[17:05:08] <BBB> git-svn sucks
[17:05:14] <mru> it's fine
[17:05:23] <BBB> it sucks
[17:05:24] <bilboed> git-svn sucks
[17:05:25] <BBB> I hated it
[17:05:26] <BastyCDGS> today is unfortunately my last vacation day, tomorrow work begins again
[17:05:31] <mru> then you did it wrong
[17:05:43] <BastyCDGS> but we don't have too much to do
[17:05:51] <bilboed> it's like winning a ferrari but living in a country with no roads
[17:06:02] <BastyCDGS> so I guess I can continue almost as until now
[17:06:33] <mru> more like winning a ferrari but being restricted to country lanes
[17:06:36] <mru> but at least you have a car
[17:06:44] <mru> before that you had to walk everywhere
[17:06:46] <mru> backwards
[17:06:50] <BBB> mru: don't bring up git-svn, it sucks and is incompetent
[17:06:52] <BBB> just do git
[17:06:58] <BBB> let them (and me) suffer
[17:07:07] <BBB> we all know it's better
[17:07:07] <mru> what exactly sucks about it?
[17:07:14] <BBB> it can't fix commit msgs
[17:07:20] <mru> neither can git
[17:07:31] <bilboed> you can locally
[17:07:33] <mru> sure
[17:07:36] <BBB> right, you can locally
[17:07:43] <BBB> but with git-svn, that breaks completely
[17:07:47] <mru> you can do that with git-svn too before you dcommit
[17:07:48] <BBB> and then your repo is out of sync
[17:07:50] <BBB> and you're fucked
[17:07:59] <BBB> no you can't, I tried and it fucked up
[17:08:06] <mru> no, _you_ fucked up
[17:08:08] <BBB> that's my first and last try of using git-svn
[17:08:12] <BastyCDGS> lol
[17:08:12] <BBB> I fucked up indeed
[17:08:18] <BBB> and my repo stopped working
[17:08:19] <wbs> you can fuck up just as much with normal git if you don't know what you're doing :-)
[17:08:22] <BBB> that's unacceptable
[17:08:22] <mru> you can do whatever you want to commits you haven't dcommitted yet
[17:08:37] <BBB> anyway, please gitify us
[17:09:01] <BBB> I'll commit my qcelp postfilter in a sec \o/
[17:09:05] <mru> not without michael's and diego's explicit consent
[17:09:12] <mru> to git, not postfilter
[17:09:53] <av500> a large # of ppl asking for git will not convince them?
[17:09:56] <BastyCDGS> btw, bbb what's with my patch i submitted
[17:09:57] <BastyCDGS> ?
[17:10:14] <BBB> mru: got it ;)
[17:12:29] <BastyCDGS> discussing java ;) what do you guys think about C++?
[17:13:10] <mru> c++ is a combination of all things bad and evil
[17:13:43] <BastyCDGS> I don't like object orientation, too...
[17:14:20] <BastyCDGS> but at least it's still optional in c++
[17:14:21] <BBB> BastyCDGS: I'll review it
[17:14:31] <BBB> BastyCDGS: but I'm doing other stuff first (my own code ;) )
[17:14:45] <mru> sure, most of the nasty stuff in c++ is optional
[17:14:59] <BBB> BastyCDGS: C is good, it's fast, easy to compile and going from asm<->c is easy, it's easy to write optimal code and it's hard to fuck up
[17:14:59] <mru> but when you take it away you're left with a somewhat crippled C
[17:15:04] <BBB> with c++, it's too easy to fuck up
[17:15:05] <mru> better to use C directly
[17:15:15] <bilboed> BastyCDGS, c++ without OOP ... is C (give or take)
[17:15:36] <mru> c++ without the "features" is less than C
[17:15:56] <bilboed> haven't done enough (thank god) c++ to realize
[17:15:59] <BastyCDGS> templates itself aren't really OOP or force you to use OOP so it's not 100% C ;)
[17:16:16] <BastyCDGS> but I don't like templates either
[17:16:35] <BastyCDGS> the only exception where C++ is pretty well, is using wxWidgets
[17:16:41] <mru> any language where error messages span multiple pages is broken
[17:16:44] <BastyCDGS> but they use only the most basic stuff of OOP
[17:17:55] <BastyCDGS> I wonder why all these OOP guys think that it provides less error-prone code
[17:18:14] <bilboed> OOP doesn't imply that
[17:18:15] <BastyCDGS> when I compare typical OOP stuff it has more errors than C/Asm
[17:18:20] <peloverde> http://imgur.com/DanrT
[17:18:27] <bilboed> don't confuse OOP and C++
[17:18:52] <elenril> ffmpeg is oop!
[17:19:04] <BastyCDGS> that's why I wrote typical OOP ;)
[17:19:29] <BastyCDGS> ffmpeg oop and TuComposer oop isn't typical it's perfect
[17:20:45] <BastyCDGS> :D
[17:22:24] <BastyCDGS> I think the reason why C/Asm stuff is in general less error-phone is that it just requires more knowledge to get started at all with it
[17:23:14] <av500> BastyCDGS: I fail to see the connection between c vs v++ and "error prone"
[17:23:49] <BastyCDGS> in C you know you have to manage all your resources (alloc/free)
[17:24:07] <BastyCDGS> this is not implicit in java/C++ (some guys assume e.g. the destructor just doing all stuff etc.)
[17:24:49] <BastyCDGS> the other stuff is that C++ isn't ABI compatible between diff. C++ compilers
[17:25:04] <BastyCDGS> (try to link a MSVC class with a gcc class)
[17:25:44] <BastyCDGS> or even try to link a g++ 3.x class  with a g++ 4.x one
[17:26:06] <mru> or compile the same source with different compilers
[17:26:16] <mru> that usually fails too
[17:26:39] <BastyCDGS> unless you have more #ifdef's than actual source :D
[17:26:46] <mru> that's flash
[17:26:50] <mru> and it still doesn't work
[17:27:08] <mru> parts of it actually do have more ifdefs than actual code
[17:27:27] <kierank> how do you know?
[17:27:27] <mru> it was something like 15% ifdefs overall
[17:27:31] <mru> I counted them
[17:27:43] <mru> flashlite, not the full version
[17:27:51] <mru> I'm told the full version is worse
[17:30:00] <BastyCDGS> which flash stuff?
[17:30:12] <BastyCDGS> you don't really mean that adobe stuff, right?
[17:30:16] <av500> yes
[17:30:17] <mru> yes, adobe
[17:30:40] <BastyCDGS> well that's completely out of my scope never worked with that
[17:30:49] <mru> good for you
[17:31:03] * mru never worked with it either
[17:31:08] <mru> I've only done battle with it
[17:31:16] <BastyCDGS> lol
[17:31:19] <mru> and lost
[17:31:35] <av500> Total Physical Source Lines of Code (SLOC)                = 597,945
[17:31:44] <av500> 12719 #ifdefs
[17:31:51] <av500> fl3.1
[17:32:45] <bilboed> *cough*
[17:35:35] <BastyCDGS> how many #if/#elif/#else pairs?
[17:35:55] <av500> give me a cmd line and I will run it
[17:35:57] * elenril wonders how to handle removing metadata tags
[17:36:39] <mru> BastyCDGS: that's a hard question to answer
[17:36:41] <mru> they don't all pair up
[17:37:02] <elenril> should i realloc/memcpy the array of pointers to tags or just set the pointer to null?
[17:37:45] <mru> av500: I get 731615 LOC
[17:37:54] <av500> i used sloccount
[17:37:56] <mru> 87720 lines starting with #
[17:37:58] <mru> so did I
[17:38:06] <av500> i grepped for ifdef only
[17:38:23] <av500> but your ratio is even worse
[17:38:34] <av500> hey, wait a moment, you *left* NDS?
[17:38:43] <mru> ssshhh
[17:38:48] <av500> lol
[17:38:54] <BastyCDGS> :)
[17:39:16] <mru> 23452 lines matching #if
[17:39:48] <mru> the like #elif and #else a lot
[17:39:57] <mru> *they
[17:40:03] <BastyCDGS> try a regex like #(.*)if(.*)
[17:40:09] <BastyCDGS> that should match if/elif/endif
[17:40:39] <av500> 41026
[17:41:26] <BBB> #*if doesn't match #else
[17:41:39] <mru> 48050
[17:41:43] <BastyCDGS> #(*if|else)
[17:42:03] <av500> mru: how many cpp files do you have?
[17:42:52] <av500> in source/ folder
[17:43:03] <mru> are they all .cpp?
[17:43:15] <mru> 643 *.cpp
[17:43:18] <BastyCDGS> did you count header files also .h/.hpp?
[17:43:34] <mru> 52763 lines #.*(if|else)
[17:43:45] <av500> mru: 600 here, so quite close
[17:44:03] <mru> this is labeled 3.1.6
[17:44:27] <av500> 3.1.1 here
[17:44:46] <CIA-7> ffmpeg: rbultje * r22932 /trunk/libavcodec/ (acelp_vectors.c amrnbdec.c sipr.c acelp_vectors.h): Split the input/output data arguments to ff_adaptive_gain_control().
[17:46:05] <av500> mru: /scaling_cur_freq: 1000000 :)
[17:46:13] <CIA-7> ffmpeg: rbultje * r22933 /trunk/libavcodec/ (acelp_filters.h amrnbdec.c acelp_filters.c sipr.c): Split input/output data arguments to ff_acelp_apply_order_2_transfer_function().
[17:47:48] <CIA-7> ffmpeg: rbultje * r22934 /trunk/libavcodec/sipr16k.c: Make the Sipr16k postfilter function write data into the target/output buffer.
[17:47:55] <BastyCDGS> well to be fair, maybe you should sort out #if DEBUG like lines
[17:48:07] <av500> lol
[17:48:20] <BastyCDGS> :D
[17:49:04] <av500> only 2020
[17:50:57] <CIA-7> ffmpeg: rbultje * r22935 /trunk/libavcodec/qcelpdec.c: Implement QCELP postfilter.
[17:51:38] <Dark_Shikari> \o/
[17:51:53] <Dark_Shikari> btw, BBB, what were 1/2/3?
[17:52:01] <mru> http://pastie.org/928309
[17:52:02] <BBB> Dark_Shikari: see mailinglist
[17:52:10] <BBB> Dark_Shikari: 2 (you ranked highest) was my postfilter
[17:52:10] <mru> just a taster...
[17:52:13] <BBB> Dark_Shikari: 3 was none
[17:52:17] <BBB> Dark_Shikari: 1 was ref postfilter
[17:52:20] <Dark_Shikari> LOL
[17:52:26] <CIA-7> ffmpeg: jai_menon * r22936 /trunk/libavcodec/parser.c: Fix typo.
[17:52:30] <Dark_Shikari> now that is fucking funny
[17:52:32] <BBB> I was a little surprised that their postfilter made it worse
[17:52:34] <Dark_Shikari> I was sure 1 was no postfilter
[17:52:34] <BBB> but who cares
[17:52:48] <BBB> their postfilter tilts against unfiltered samples, that's a bug
[17:52:50] <mru> 1 sounded like it had had a lowpass applied
[17:52:51] <BBB> that's probably why
[17:53:47] <BBB> anyway, that's all pre-work
[17:53:56] <BBB> the real patch is the audio clipping patch which depended on all this
[17:54:03] <BBB> quickly testing my compile now
[17:54:18] <j-b> I was sure 1 was the worse one... my ears are broken
[17:54:21] <BBB> unfortunately it touches internal.h in libavutil/ so now it's rebuilding my whole tree
[17:54:38] <BBB> j-b: I think it was, like I said, it does a wrongly implemented filter
[17:54:42] <mru> get a faster computer
[17:54:43] <BBB> that's very bad
[17:54:49] <BBB> give me one
[17:54:51] <j-b> BBB: O_o..
[17:54:54] <mru> BastyCDGS: did you check that link?
[17:55:02] <BastyCDGS> pastebin?
[17:55:15] <mru> the one I posted
[17:55:52] <BastyCDGS> that's the last one from you pastie
[17:55:57] <BastyCDGS> and yes I checked it
[17:55:58] <mru> yeah
[17:56:57] <mru> well, do you like ifdefs?
[17:58:40] <CIA-7> ffmpeg: rbultje * r22937 /trunk/ (12 files in 2 dirs):
[17:58:40] <CIA-7> ffmpeg: Move clipping of audio samples (for those codecs outputting float) from decoder
[17:58:40] <CIA-7> ffmpeg: to the audio conversion routines.
[18:00:24] <av500> BastyCDGS: and that file has ~7000 lines as well
[18:01:17] <BastyCDGS> ifdef's are very good for doing perfomance stuff (removing debug code etc. in optimized release)
[18:01:28] <BastyCDGS> and for adding platform dependent stuff
[18:02:05] <mru> that's not the way to do it
[18:02:28] <CIA-7> ffmpeg: rbultje * r22938 /trunk/libavcodec/ (wmavoice_data.h wmavoice.c): WMAVoice postfilter.
[18:02:30] <BBB> hm, my patch queue is empty now
[18:02:36] <BBB> let's write new code
[18:03:37] <BastyCDGS> I didn't mean usual stuff, more GUI related stuff...sometimes there isn't another way than doing:
[18:03:37] <BastyCDGS> #ifdef WXGTK
[18:03:37] <BastyCDGS>    ... GTK stuff here
[18:03:37] <BastyCDGS> #elif WXMSW
[18:03:37] <BastyCDGS>   ... Win stuff here
[18:03:55] <av500> urg
[18:04:15] <BastyCDGS> sometimes you want to use controls which aren't available on each other platform
[18:04:38] <av500> and ifdef is the only option for that?
[18:04:49] <BastyCDGS> surely not
[18:04:57] <BastyCDGS> could also be done via configure & makefile
[18:06:37] <BastyCDGS> the above way is wxWidget's way of doing it
[18:06:41] <BastyCDGS> and it works pretty well
[18:06:56] <BastyCDGS> you need them very rarely though
[18:06:59] <BBB> wbs: what's the story with the amr parser?
[18:07:03] <BBB> wbs: do we still need that?
[18:07:41] <BBB> wbs: should I comment on it?
[18:08:01] <mru> BastyCDGS: that fragment I showed is 50 lines from 700k
[18:08:08] <mru> and it took me a minute or so to find
[18:08:08] <BBB> wbs: (my personal opinion is that we should split individual frames of speech codec data, it's too much overhead given taht each frame is like a few bytes at most)
[18:08:28] <av500> BastyCDGS: "very rarely" is the key here
[18:08:34] <BastyCDGS> oh you were mentioning this regarding to this fragment...
[18:08:44] <BastyCDGS> sorry, wasn't clear to me...
[18:09:02] <BastyCDGS> your example is of course a perfect one of not doing it ;)
[18:09:52] <mru> note the ifdef around one argument to a function call
[18:10:10] <mru> and around parts of if/else statements
[18:12:01] <mru> now imagine 700k lines of that
[18:12:04] <BastyCDGS> TuComposer:  116266 total
[18:12:09] <BastyCDGS> .c|.h
[18:12:17] <BastyCDGS> mom will count #if stuff
[18:12:45] <mru> oh, if you like ifdefs, look at libavutil/intreadwrite.h
[18:13:47] <BastyCDGS> TuComposer: 608 lines begin with #
[18:14:16] <BastyCDGS> think that's pretty good...
[18:14:30] <mru> that's more sane
[18:14:33] <BastyCDGS> but that's plain C ;)
[18:14:58] <BastyCDGS> but I guess it will be more when TuComposer is ported from amiga ;)
[18:15:03] <drv> i worked on one project where the rule was "no #if/#ifdef ever"
[18:15:18] <drv> so every line of code always compiled, no bitrotting possible
[18:15:25] <drv> but that only works for stuff that can compile on every platform ;)
[18:15:29] <av500> it was java? :)
[18:15:35] <drv> nah, C
[18:15:35] <BastyCDGS> lol
[18:17:32] <BastyCDGS> sorry I forgot escaping, it's not 608 lines, but 1569
[18:18:26] <mru> still
[18:19:37] <av500> BastyCDGS: I have the same fl codebase and trust me it is ugly
[18:19:56] <av500> it reads more like an RCS file that actual source
[18:20:11] <BastyCDGS> i was counting #'s in tucomposer
[18:20:17] <BastyCDGS> not fl
[18:20:38] <av500> and the worst is, it is impossible to know a good combination of #defines to make it compile or even work
[18:20:54] <BastyCDGS> 1569 out of 1126266 lines are beginning with # in TuComposer so far
[18:21:11] <BastyCDGS> oops 116266
[18:23:20] <kierank> crikey 116k lines
[18:26:39] <BastyCDGS> so you see I've ported quite a lot from m68k asm already ;)
[18:26:56] <BastyCDGS> I think when the MOD/S3M/XM/IT loaders are ported, too. it will be around 150k
[18:27:33] <BastyCDGS> original 100% asm code is around 40k of lines
[18:27:56] <Dark_Shikari> 40k lines of pure asm? blegh
[18:28:06] <BastyCDGS> all in one file ;)
[18:28:24] <BastyCDGS> except the external library loaders (which include MOD/S3M/XM/IT)
[18:28:28] <Dark_Shikari> this is what macros are for
[18:28:42] <BastyCDGS> I rarely used macros
[18:29:00] <BastyCDGS> there isn't even much stuff in TuComposer where macros are really useful
[18:29:07] <BastyCDGS> or save lines of code
[18:29:08] <Dark_Shikari> function prologue?
[18:29:11] <Dark_Shikari> function epilogue?
[18:29:20] <BastyCDGS> you don't need that on m68k
[18:29:21] <Dark_Shikari> Unless you made it all one function too.
[18:29:27] <Dark_Shikari> m68k doesn't have a stack?
[18:29:37] <BastyCDGS> of course it has
[18:29:45] <jai> ...
[18:29:46] <BastyCDGS> but you can save all registers with:
[18:29:51] <BastyCDGS> movem.l d0-d7/a0-a6,-(sp)
[18:29:55] <BastyCDGS> that's it, one line
[18:29:57] <BastyCDGS> restore:
[18:30:04] <BastyCDGS> movem.l (sp)+,d0-d7/a0-a6
[18:30:08] <Dark_Shikari> Nice efficiency.
[18:30:16] <BastyCDGS> and this is a m68k instruction
[18:30:18] <BastyCDGS> not a macro
[18:30:53] <Dark_Shikari> well I for one don't like pushing every single register at the start of every function
[18:31:48] <BastyCDGS> I even rarely needed movem.l at all
[18:31:56] <BastyCDGS> since I pass args on registers
[18:32:11] <BastyCDGS> m68k has 8 data regs and 8 address reg (one being stack a7=sp)
[18:32:21] <Dark_Shikari> oh dear, separation of data and address regs, fun
[18:33:07] <BastyCDGS> you can also do stuff like:
[18:33:19] <BastyCDGS> lea buffer(pc),a0
[18:33:19] <BastyCDGS> movem.l d0-d7/a1-a6,(a0)
[18:33:30] <BastyCDGS> will write regs d0-d7/a1-a6 to buffer in a0
[18:33:50] <BastyCDGS> d0 will be a0, d1 at a0+4, etc.
[18:34:42] <BastyCDGS> or even do funcy stuff like:
[18:34:43] <BastyCDGS> movem.l d0-d3/d5/d7/a1/a3-a5,(a0,d4.w*8)
[18:35:08] <BastyCDGS> you can choose the registers 100% freely
[18:37:00] <BastyCDGS> the latter example working only on 68020 onwards
[18:37:10] <BastyCDGS> d4.w*2, *4, *8 were new to 68020
[18:37:14] <Dark_Shikari> isn't RISC great ;)
[18:37:21] <BastyCDGS> but plain 68k could still d4.w*1 ;)
[18:38:38] <BBB> j-b: lucky bastard, you get to have jai ;)
[18:38:46] <BastyCDGS> jump table:
[18:38:46] <BastyCDGS> jsr (a3,d4.w*4)
[18:38:58] <av500> gsoc_dedup?
[18:39:02] <BastyCDGS> if base ptr is a3, d4.w (word) function index
[18:40:18] <BastyCDGS> dark_shikari: there is a RISC like version of m68k, called ColdFire
[18:40:29] <VideoLAN|j-b> av500: indeed.
[18:40:34] <BastyCDGS> it has still some of the original power of m68k but is reduced a lot
[18:40:55] <BastyCDGS> cold fire code running on m68k is almost 100% compatible but not the other way around
[18:41:30] <BastyCDGS> this applies to binary and source compatilibty
[18:43:30] <wbs> BBB: it's not directly needed for anything, but since e.g. the rtp depacktizer can return more than one, it could be needed e.g. if doing a stream copy
[18:43:48] <wbs> BBB: and I don't think you need to comment on it, isn't it mainly michael that should ok such stuff?
[18:48:24] <BBB> nah... if I ok, he'll ok it
[18:48:30] <BBB> but do you really need it for stream copy?
[18:48:32] <BBB> I don't think you do
[18:48:49] <BBB> all muxers I know chunk multiple frames per packet
[18:48:52] <BBB> not 2-3
[18:48:56] <BBB> but more like 10-20 or so
[18:49:11] <wbs> at least the mov muxer fails if you feed it a packet with 2 amr frames
[18:49:14] <BBB> otherwise you get micropackets of 10 bytes a piece, at a rate of like 300 per second
[18:49:17] <wbs> it has an explicit check against it
[18:49:19] <BastyCDGS> btw, very nice site about caveats when supporting 64-bit architectures
[18:49:20] <BBB> really? that's amazing
[18:49:21] <BastyCDGS> http://www.viva64.com/content/articles/64-bit-development/?f=20_issues_of_porting_C++_code_on_the_64-bit_platform.html&lang=en&content=64-bit-development
[18:49:23] <wbs> (dating back to 2002 or so ;P)
[18:49:31] <BastyCDGS> it's c++ but most of the stuff is also applicable for c
[18:50:12] <wbs> the rtp amr packetizer also just wants one packet at a time (but it could of course be improved to handle it)
[18:50:33] <wbs> the amr muxer itself should be able to handle it, since it simply writes all packets out sequentially ;P
[18:51:48] <Dark_Shikari> wow, that guide basically covers 100 things that no sane programmer should ever do
[18:51:51] <Dark_Shikari> >_>
[18:52:16] <mru> I have only one rule: don't write non-portable code
[18:52:51] <mru> once upon a time, ~2001, I wrote come sloppy code that would only work on 64-bit
[18:53:25] <mru> this was before most people had even heard of 64-bit
[18:53:42] <peloverde> I still write sloppy code that only works on 64-bit all the time, the format string values for the stdint types are ridiculous
[18:54:00] <mru> PRId64
[18:54:22] <DimStar> Hi everybody. I have an issue with openSUSE package building (there are brp checks raising well known warnings to errors and failing the package building). In the specific case I'm not entirely sure how to address it. Can somebody have a look at http://www.pastebin.org/166149 please?
[18:54:27] <peloverde> vs %ld
[18:54:34] <mru> I agree they're not pretty
[18:55:47] <peloverde> anyway outside of the windows world, 64-bit is not considered exotic
[18:55:51] <BastyCDGS> mru, the rule itself is clear, but you know sometimes it can be pretty hard to find out if code is really portable ;)
[18:55:52] <mru> wtf http://www.facebook.com/rich.felker
[18:56:14] <kierank> ?
[18:56:20] <mru> didn't expect him on facebook
[18:56:31] <wbs> BastyCDGS: after a while you learn to know immediately what's portable and what's not
[18:56:38] <mru> he's like the most paranoid person ever
[18:56:43] <wbs> and usually people try to point out such things in reviews etc
[18:56:50] <mru> if it's in the spec, it's portable
[18:56:53] <mru> if not, it's not
[18:56:55] <BastyCDGS> mru...when I open your facebook link I just get a user page not found
[18:57:30] <mru> works here
[18:57:36] <mru> but you probably don't know him anyway
[18:58:16] <peloverde> we rely on plenty of non-portable C behavior
[18:58:23] <BastyCDGS> wbs, yes of course, experience always makes the stuff ;)
[18:58:40] <mru> peloverde: we don't rely on anything with undefined behaviour
[18:58:50] <mru> relying on implementation-defined behaviour is often necessary
[18:59:00] <peloverde> punning a float to int is architecture dependent
[18:59:03] <mru> like two's complement, ieee754 etc
[18:59:19] <BastyCDGS> as well is all endianess stuff ;)
[18:59:38] <mru> since we take care of endianness properly, that's not a problem
[18:59:45] <mru> ok, we don't work on pdp endian
[19:00:24] <BastyCDGS> we're experienced and skilled coders so that isn't a wonder, but ask around an IT university ;)
[19:00:42] <BastyCDGS> portability isn't teached in the way it should be
[19:01:44] <mru> they don't teach c and asm anymore
[19:01:56] <mru> one of my classes assumed knowledge of C
[19:01:56] <BastyCDGS> very sad :(
[19:02:05] <mru> yet they didn't offer a class teaching it
[19:02:14] <mru> they assumed everybody would have learned it somehow
[19:02:22] <mru> which was true
[19:02:29] <peloverde> also don't some files still warn about undefined type punning? or did we fix that?
[19:02:41] <mru> I fixed quite a few
[19:02:49] <BastyCDGS> peloverde, there are still some
[19:02:51] <mru> quite a few remain
[19:02:59] <BastyCDGS> just compiled today the whole ffmpeg stuff
[19:03:41] <BastyCDGS> maybe I shall support with patches for fixing the remaining stuff?
[19:03:56] <mru> it's boring as hell
[19:04:39] <BastyCDGS> then even better when I support, so everyone has less to do on that boring stuff ;)
[19:05:15] <mru> you have to look for bad casts and replace them with macros from intreadwrite.h
[19:05:32] <mru> that file is pure preprocessor mayhem btw
[19:05:59] <BastyCDGS> how should I design patches for this the best way?
[19:06:03] <BastyCDGS> one patch for one file?
[19:06:43] <wbs> one patch per issue
[19:06:51] <mru> not one per cast
[19:06:55] <mru> that's too many patches
[19:07:07] <wbs> that is, one patch for fixing all occurrances of the same issue
[19:07:26] <mru> no, that's too much
[19:07:40] <mru> one per as-much-as-you-can-manage
[19:07:52] <BastyCDGS> for each library? i.e. all libavcodec issues on that in one patch?
[19:07:57] <wbs> true
[19:08:14] <mru> if you can fix mpegvideo*.c that would be swell
[19:09:08] <BastyCDGS> will take a look on it
[19:09:16] <DimStar> Hi everybody. I have an issue with openSUSE package building (there are brp checks raising well known warnings to errors and failing the package building). In the specific case I'm not entirely sure how to address it. Can somebody have a look at http://www.pastebin.org/166149 please?
[19:09:52] <wbs> DimStar: you said that already. what are brp checks?
[19:10:26] <DimStar> wbs: you can also call them lint... it's a package quality system...
[19:10:52] <DimStar> Build Result Postprocessing
[19:11:03] <wbs> ah, ok
[19:11:10] <mru> do not mention lint in my presence
[19:11:34] <DimStar> mru :) that's why I say brp :P
[19:11:38] <wbs> for those who didn't check the link, there's some "no return statement in function returning non-void" in libswscale
[19:11:38] <BastyCDGS> dimstar, looks to me that if the #if define isn't defined the function body gets empty
[19:12:05] <BastyCDGS> and therefore returns random values
[19:12:08] <mru> those should be fixed
[19:12:11] <DimStar> BastyCDGS: yes, that's rather obvious :) the question would be to get a proper solution for it
[19:12:35] <mru> why do those functions even exist if the entire body is ifdeffed out?
[19:13:41] <DimStar> mru: form what I've seen in yuv*_mmx.c, their call is not preprocessed, but only if (HAVE_7REGS), so if the function won't exist the build would fail completely... (but I might have misread the code).
[19:14:17] <DimStar> yuv2rgb_mmx.c, line 67 for example
[19:14:22] <mru> if the function does nothing, it is an error to call it
[19:14:55] <peloverde> mru, perhaps the code predates requiring DCE?
[19:15:08] <BastyCDGS> so put the #if out of the function body?
[19:15:18] <BastyCDGS> if that breaks building that should be fixed elsewhere, right?
[19:15:21] <mru> peloverde: the code predates the requirement to work?
[19:15:41] <mru> this is libswscale, I'm not looking at it
[19:15:47] <mru> last time I did, my eyes hurt for a week
[19:16:02] <peloverde> no, just predating the requirement for the compiler to remove unreachable code
[19:16:12] <peloverde> like if (PREPROCESSOR_DIRECTIVE) {}
[19:16:17] <mru> I know what dce is
[19:16:35] <peloverde> well your response did not seem to imply that
[19:16:41] <DimStar> I mean of course I can do a 'hack fix' with #else return 0 (and hope the function really never ever is called if HAVE_7REGS is not defined)... this would make the compiler happy.
[19:17:15] <BastyCDGS> dimstar, have you tested what happens if you put the #if outside the func body?
[19:17:24] <BastyCDGS> and do that in the header declaring it, too?
[19:17:52] <DimStar> BastyCDGS: actually no, did not test this... I can do that and let you know if you think that should give a valid result.
[19:19:03] <BastyCDGS> when HAVE_7REGS is defined at all?
[19:20:40] <DimStar> BastyCDGS: libavutil/x86_cpu.h:#define HAVE_7REGS (ARCH_X86_64 || (HAVE_EBX_AVAILABLE && HAVE_EBP_AVAILABLE))
[19:21:04] <BastyCDGS> so that function is empty on all non-x86_64 cpus...
[19:21:12] <mru> no
[19:22:23] <BastyCDGS> ops yes the || ;)
[19:22:38] <BastyCDGS> so it's empty on any non-x86* cpu ;)
[19:22:46] <mru> it's x86 asm...
[19:22:55] <mru> in the x86/ dir
[19:23:41] <BastyCDGS> then it should be safe to just do the if out of the function body...
[19:23:52] <BastyCDGS> since it can't be called anyway on non-x86
[19:24:54] <BastyCDGS> if this delivers compile errors that are bugs to be fixed, because calling this from non-x86 is a fatal error then
[19:25:46] <BastyCDGS> mru, do you agree on my solution idea?
[19:25:54] <mru> try and see what happens
[19:26:48] <DimStar> I have created this patch: http://pastebin.com/WXBPd7L8
[19:27:02] <DimStar> will take a while for my build host to pick it up though... can let you know soon.
[19:27:42] <BastyCDGS> I'll apply it and test a build, too...
[19:34:40] <BastyCDGS> hmm looking at makefile in there this file isn't even compiled
[19:35:06] <BastyCDGS> maybe it's just a code generation template for yuv2rgb_mmx.c?
[19:36:08] <BastyCDGS> does it need special configure parameters?
[19:36:33] <DimStar> BastyCDGS: In file included from libswscale/x86/yuv2rgb_mmx.c:52:0:
[19:37:13] <DimStar> kind of uncommon to #include a .c file, but well....
[19:37:16] <Dark_Shikari> not really
[19:37:21] <Dark_Shikari> it's how you template in C
[19:37:34] <Dark_Shikari> along with other such fun things as ALWAYS_INLINE, __builtin_constant_p, etc
[19:37:58] <mru> Dark_Shikari: that's not really C
[19:38:02] <mru> that's gcc
[19:38:15] <Dark_Shikari> it's still basically C.  It's not, say, C++.
[19:38:34] <mru> sure
[19:39:51] <Dark_Shikari> also, while I'm compiling gcc
[19:39:54] <Dark_Shikari> who the hell uses gcj
[19:39:59] <mru> nobody
[19:40:11] <mru> --enable-language=c,c++
[19:40:25] <Dark_Shikari> lol
[19:40:34] <Dark_Shikari> what does it do?
[19:40:37] <Dark_Shikari> compile java to x86?
[19:40:40] <Dark_Shikari> or java to jvm bytecode?
[19:40:40] <Dark_Shikari> or what
[19:40:47] <BastyCDGS> dimstar, what are your configure options, it's not in my makefile
[19:40:50] <mru> it compiles java to bytecode, java to asm, or bytecode to asm
[19:41:31] <DimStar> BastyCDGS: what do you mean it's not in your makefile? the _template.c is #included from the _mmx.c file. (line 52)
[19:42:13] <mru> jad is much more useful
[19:42:14] <DimStar> BastyCDGS: as such yes: it does not figure in makefile
[19:42:18] <mru> it turn bytecode into java
[19:42:33] <BastyCDGS> *bangingheadondesk*
[19:42:38] <BastyCDGS> yes sorry
[19:42:45] <DimStar> BastyCDGS: no worries...
[19:43:52] <kierank> is reverse execution in gdb any good?
[19:44:07] <mru> never tried it
[19:44:08] <BastyCDGS> you mean the new one in GDB 7?
[19:44:10] <mru> I assume not
[19:44:23] <peloverde> it's awful
[19:44:27] <BastyCDGS> probably as useful as walking backwards ;)
[19:44:33] <mru> debuggers are mostly useless anyway
[19:44:33] <peloverde> it doesn't support the sse fpu
[19:44:38] <peloverde> because that's "Exotic"
[19:45:18] <BastyCDGS> mru, without it I wouldn't have learned m68k asm ;)
[19:45:26] <BastyCDGS> I hadn't a manual about m68k assembly
[19:45:40] <BastyCDGS> so I had to find out what the m68k instructions do by stepping with a debugger ;)
[19:45:40] <mru> peloverde: just like tying your shoelaces is exotic?
[19:46:01] <mru> BastyCDGS: sounds tedious
[19:46:15] <BastyCDGS> was 1993, no google search and that's it, didn't even had a modem ;)
[19:46:29] <mru> debuggers are useful for looking at core dumps, but that's about all
[19:46:40] <BastyCDGS> or for cracking games ;)
[19:46:52] <BastyCDGS> + apps ;)
[19:47:01] <mru> disassemblers are more useful for that
[19:47:26] <BastyCDGS> debuggers contain a disassembler, don't they ;)
[19:47:35] <mru> hopefully, yes
[19:47:42] <mru> but you don't need the rest of the debugger
[19:48:01] <peloverde> Just use Hex-Rays
[19:48:45] <peloverde> If you are doing something nefarious you should have no qualms about acquiring it, if you are doing something legit it's well worth the money
[19:49:32] <Dark_Shikari> since when is cracking nefarious?
[19:49:33] <Dark_Shikari> =p
[19:49:42] <mru> sometimes cracking is necessary
[19:49:48] <mru> even when you have a licence
[19:49:53] <BBB> mru: not 100% true, I use debuggers to dump memory of binaries that I'm disassembling
[19:50:02] <BastyCDGS> yes mru
[19:50:03] <BBB> but maybe that's "backtrace" again :)
[19:50:35] <mru> put it this way, I don't think I've ever solved a problem by stepping through code with a debugger
[19:51:01] <BastyCDGS> cracking makes the stuff also more comfortable, never insert a DVD anymore, or search for line x, word y, column z in your handbook
[19:51:25] <peloverde> for dealing with segfaults valgrind is usually much more useful
[19:53:20] <wbs> peloverde: yeah, valgrind is just fantastic
[19:54:15] <_av500_> +1
[19:54:44] <peloverde> now if you really want fun zzuf + valgrind
[19:54:47] <BastyCDGS> sorry lost connection
[19:54:50] <BastyCDGS> did I miss anything?
[19:57:11] <BastyCDGS> btw, building with the patch was successful
[19:57:31] <wbs> BastyCDGS: yes, but are you sure that HAVE_7REGS wasn't set in your build?
[19:57:56] <wbs> if it was set, your test build doesn't say anything
[19:58:42] <BastyCDGS> oh damn, you're right
[19:58:52] <BastyCDGS> since I was compiling for x86 it was very probably be set
[19:59:51] <BastyCDGS> I haven't a cross-compiler for non-x86 ready
[20:00:07] <BastyCDGS> so I probably have to comment out the define
[20:24:02] <mru> build for x86 with --enable-pic
[20:24:32] <BastyCDGS> 2nd build is almost finished, did comment out HAVE_7REGS in x86_*.h
[20:24:40] <BastyCDGS> is linking
[20:25:03] <BastyCDGS> build finish and success
[20:25:59] <DimStar> Another thing I try again to push: can you extend configure's detection of libxvid to also link libm? In case the libraries are all build with -Wl,-as-needed, this results in undefined references and the detection of libxvid fails. I've been carrying a patch for that forever already.
[20:26:51] <BastyCDGS> --enable-pic uses EBP for position indepent code and thus only HAVE_6REGS defined?
[20:27:06] <BastyCDGS> shall I retest with --enable-pic anyway?
[20:27:39] <DimStar> a patch for xvidocre detection in an entire Wl-as-needed built system: http://pastebin.com/gMgi1fdQ (vs current trunk)
[20:28:21] <mru> I still think we should drop xvid support
[20:29:02] <BastyCDGS> what's the problem with xvid?
[20:29:12] <mru> redundant
[20:29:17] <mru> we already have mpeg4 codecs
[20:29:21] <_av500_> +1
[20:29:34] <mru> and we've taken their devs too
[20:30:18] <BastyCDGS> are the mpeg4 codecs 100% replacement for xvid?
[20:31:27] <mru> the decoders do exactly the same thing
[20:31:31] <BastyCDGS> meaning removing xvid support doesn't cause lesser avis etc. to be handled by ffmpeg?
[20:31:33] <mru> the encoders are of course different
[20:31:38] <mru> but they support the same features
[20:31:56] <mru> we never decode through xvid anyway
[20:32:05] <mru> it's possible to force encoding with xvid
[20:33:20] <pJok> mru, can't you just encode with the mpeg4 encoder and select an xvid 4cc?
[20:33:44] <mru> xvid encodes a bit better for some kinds of input
[20:33:46] <mru> allegedly
[20:34:14] <BastyCDGS> then dropping at least the xvid decoder is a good idea
[20:34:20] <_av500_> days of mpeg4 encode are over
[20:34:35] <mru> we've never supported decoding through xvid
[20:39:02] <BastyCDGS> what kind of inputs are handled better with xvid?
[20:39:15] <mru> don't know
[20:39:20] <mru> don't even know if it's true
[20:39:20] <_av500_> l33t dvd r1ps
[20:46:36] <BastyCDGS> configure with --enable-pic breaks stuff
[20:48:49] <BastyCDGS> can't copy it in here
[20:48:59] <mru> with the patch?
[20:49:03] <BastyCDGS> yes
[20:49:18] <BastyCDGS> error: asm operand has impossible constraints
[20:49:38] <BastyCDGS> error: can't find a register in class GENERAL_REGS while reloading asm
[20:49:41] <mru> which gcc?
[20:49:45] <BastyCDGS> 4.2.4
[20:49:59] <BastyCDGS> both errors in /home/basty/src/ffmpeg-svn/libavcodec/x86/h264dsp_mmx.c:2079
[20:50:36] <BastyCDGS> stop, that's h264...not yuv
[20:50:56] <BastyCDGS> there's also a warning
[20:51:08] <BastyCDGS> warning: ff_x264_deblock_v_luma_intra_mmxext defined but not used
[20:51:20] <BastyCDGS> in file /home/basty/src/ffmpeg-svn/libavcodec/x86/dsputil_mmx.c:2394
[20:51:29] <jai> any opinions on http://pastie.org/928666
[20:51:35] <jai> elenril: ^
[20:52:16] <BastyCDGS> doesn't have to do with the patch from DimStar
[20:52:36] <BastyCDGS> at least it looks so ;)
[20:52:52] <jai> gcc's RA sucks
[20:53:26] <BastyCDGS> can someone of you also do a build with configure --enable-pic with a different gcc?
[20:53:27] <mru> gcc's $feature sucks
[20:53:32] <BastyCDGS> and confirm this?
[20:55:05] <BastyCDGS> gcc (GCC) 4.2.4 (Ubuntu 4.2.4-1ubuntu4)
[20:55:16] <BastyCDGS> was causing this here
[20:58:30] <mru> similar errors here
[20:59:13] <BastyCDGS> I remember some h264 patches recently commited to repository
[20:59:21] <BastyCDGS> maybe one of them is causing that...
[20:59:37] <mru> x86-32 with pic has always been troublesome
[21:00:03] <BastyCDGS> why?
[21:00:35] <mru> too few registers and sucky register allocator
[21:03:42] <BastyCDGS> well x86-32 has too few regs anyway ;)
[21:04:12] <BastyCDGS> but what's the problem with reg alloc? shouldn't it be more or less the same just that ebp is always allocated?
[21:06:55] <mru> yes, and that's enough for it to fail
[21:07:02] <mru> did I mention it sucks?
[21:08:00] <BastyCDGS> yes u did
[21:14:58] <hyc> hmm, did borland turbo-C do a better job?
[21:19:34] <mru> hard to compare
[21:20:03] <mru> and I never studied any of its code
[21:20:06] <hyc> I'm having a hard time coming up with alternatives to look at
[21:20:14] <hyc> Intel ICC of course
[21:20:22] <mru> hand-written code
[21:20:22] <CIA-7> ffmpeg: stefano * r22939 /trunk/libavformat/aviobuf.c:
[21:20:22] <CIA-7> ffmpeg: Do not initialize res in url_fseek(), in the case !s->seek directly
[21:20:22] <CIA-7> ffmpeg: return AVERROR(EPIPE) rather than the pre-defined value of res.
[21:20:22] <CIA-7> ffmpeg: Slightly improve readability.
[21:20:39] <hyc> sure
[21:21:09] <hyc> but really, a compiler ought to be able to track liveness of registers and re-use them efficiently
[21:22:12] <bcoudurier> hi guys
[21:22:22] <mru> gcc usually fails when you suddenly need lots of registers
[21:22:22] <hyc> howdy
[21:22:28] <BastyCDGS> hey bcoudurier
[21:22:29] <mru> like for entering an asm block
[21:22:42] <BastyCDGS> isn't intel planning and going to place more and more of ICC into GCC
[21:22:44] <mru> guys, you're talking to a script
[21:22:50] <BastyCDGS> remember reading sth. regarding this quite a time ago
[21:23:10] <hyc> why would Intel do that? they make a lot of money on ICC
[21:23:39] <BastyCDGS> maybe to make gcc produce better code for intel than for AMD?
[21:24:05] <hyc> seems kind of silly. it would produce better code for all x86.
[21:24:27] <hyc> currently AMD-optimized gcc code runs faster on Intel than Intel-optimized gcc code
[21:24:53] <BastyCDGS> wtf!?
[21:25:04] <hyc> when you take away the CPUID-specific cheats that ICC uses, it will boost AMD chips too, not just Intel chips.
[21:25:24] <hyc> try it some time, I've tested this on a number of programs
[21:25:36] <hyc> use -march=amdfamily10 vs -march=core2
[21:25:59] <hyc> the AMD version runs faster on Core2 than the core2 version.
[21:26:15] <hyc> and the core2 version runs slower on AMD too, but that's more to be expected.
[21:26:33] <BastyCDGS> that's really crazy
[21:27:15] <hyc> better open source compiler technology benefits everybody equally.
[21:27:21] <hyc> I doubt Intel wants that.
[21:28:01] <hyc> They've demonstrated time after time, release after release, that they want to produce superior code on Intel and inferior code on AMD
[21:28:10] <BastyCDGS> http://www.phoronix.com/scan.php?page=news_item&px=NzE5Nw
[21:28:19] <BastyCDGS> there's an article about intel contribution to gcc
[21:28:58] <hyc> a year ago. haven't heard anything since.
[21:29:03] <Dark_Shikari> mru:
[21:29:09] <Dark_Shikari> s/when you suddenly need lots of registers//
[21:29:21] <mru> Dark_Shikari: that's when it usually fails first
[21:29:35] <Dark_Shikari> oh my fucking god
[21:29:36] <Dark_Shikari> this is brilliant
[21:29:37] <Dark_Shikari> http://users.telenet.be/darnley/ffmpeg/coloured_messages.png
[21:29:41] <Dark_Shikari> No more users not seeing error messages
[21:30:27] <mru> never underestimate the blindness of users
[21:30:43] <Dark_Shikari> seriously though, this will help massively
[21:31:03] <mru> adding ansi colour codes to av_log should be easy
[21:31:18] <Dark_Shikari> error = red
[21:31:19] <Dark_Shikari> warning = yellow
[21:31:26] <hyc> BastyCDGS: http://www.agner.org/optimize/blog/read.php?i=49
[21:33:13] <hyc> should use termcap/curses tho right? not just hardcoded ANSI
[21:33:32] <mru> that's much harder :-)
[21:33:45] <hyc> doing things right usually is :P
[21:34:24] <BastyCDGS> well I suggest coloring be optional...
[21:34:44] <hyc> optional? if it defaults off, naive users will never get any benefit
[21:34:56] <hyc> and they're the ones who seem to need it
[21:34:59] <BastyCDGS> then it's fine ;)
[21:35:31] <BastyCDGS> wasn't clear to me if that was intended to be default on/off
[21:38:44] <BastyCDGS> hyc thx for link it contains some details I didn't know yet
[21:38:53] <BastyCDGS> I already about that math lib stuff
[21:39:20] <Dark_Shikari> we can add -no-color
[21:40:14] <BastyCDGS> default is off, why -no-color then, should be -enable-colors more likely? ;)
[21:40:39] <Dark_Shikari> no, default is on
[21:40:40] <Dark_Shikari> if it's off it's useless
[21:40:47] <Dark_Shikari> the sole purpose of this is to help deal with idiots who cannot fucking rea
[21:40:50] <Dark_Shikari> *read
[21:41:49] <BastyCDGS> wouldn't it better that default is on when it's an interactive terminal and off if you're redirect to file?
[21:43:35] <BastyCDGS> like ls does...on interactive terminal ls defaults to colored mode but doesn't do this if ls > /foo/bar
[21:46:06] <FUautotools> How about an initial patch: http://pastebin.org/166404
[21:46:29] <Dark_Shikari> a linux patch would be preferred first
[21:46:44] <FUautotools> pfft, working on the ansi codes
[21:46:59] <Kovensky> AFAIK only mingw needs special care
[21:47:24] <Kovensky> for the standard 16 ANSI colors anyway
[21:48:20] <BastyCDGS> dark_shikari does it really care which one is finished first? if fuautotools patch does work I don't see any problem
[21:49:21] <Dark_Shikari> go try to get it accepted then without linux support ;)
[21:54:06] <BastyCDGS> well I can't decide that indeed ;)
[21:54:16] <BastyCDGS> but the win32 stuff looks ok to me
[21:54:59] <BastyCDGS> based on this patch there will be somebody just changing the linux defines
[21:55:13] <Dark_Shikari> no... you have to print extra characters for linux terminal
[21:55:41] <BastyCDGS> yes of course, but this can be done in the #defines he left yet empty
[21:56:03] <BastyCDGS> fputs ( "ESC[31m" ); etc.
[21:56:30] <BastyCDGS> ok fputs was a bad idea because of \n ;)
[21:57:20] <hyc> "hey, my default terminal background color is red. this sucks."
[21:58:10] <FUautotools> I need to set the bg then too....
[21:59:36] <BastyCDGS> or choose the color from /dev/urandom *gg*
[21:59:50] <BastyCDGS> then you have a 1/16 chance that it doesn't interfere with your bg col ;)
[22:00:14] <FUautotools> If I set only the fg colour with ansi codes, does the bg remain at its previous colour?
[22:00:31] <BastyCDGS> yes it does
[22:00:54] <FUautotools> go go gadget background_black
[22:01:28] <BastyCDGS> or you make the bg color configurable someway
[22:01:36] <BastyCDGS> fg color oops
[22:01:41] <FUautotools> Yeah, at compile time
[22:01:41] <BastyCDGS> or both ;)
[22:04:26] <hyc> or you just define an algorithm/mapping for high contrast, and choose colors based on the current settings.
[22:04:43] <hyc> this isn't rocket science, it's easy stuff.
[22:06:29] <BastyCDGS> but as said it should only be on by default if it's an interactive terminal...FUautotools patch does this for win32
[22:06:51] <BastyCDGS> since the win32 calls only affect a console window
[22:07:11] <BastyCDGS> if stderr points to a file the color info isn't put in the file
[22:08:06] <hyc> I wonder if this works with other win32 terminals, like rxvt
[22:08:40] <hyc> probably better to just emit ASNI escape codes. doesn't the default console have ANSI.SYS built in now?
[22:08:42] <BastyCDGS> not sure about this, would have to look MSDN for that
[22:09:02] <FUautotools> no
[22:09:37] <BastyCDGS> I'm just checking with wine cmd.exe, one moment...
[22:11:24] <BastyCDGS> http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/cmd.mspx?mfr=true
[22:11:40] <BastyCDGS> seems that you have to pass /a to cmd.exe
[22:13:11] <BastyCDGS> lol
[22:13:13] <BastyCDGS> http://www.netikka.net/tsneti/info/tscmd051.htm
[22:13:52] <BastyCDGS> you can use qbasic ^^
[22:14:29] <FUautotools> now featuring ansi codes: http://pastebin.org/166455
[22:17:10] <BastyCDGS> instead of %c..., 27 use \033
[22:17:16] <BastyCDGS> \033[31m e.g.
[22:17:22] <FUautotools> Oh yeah, that's it
[22:18:03] <hyc> ANSI codes work by default when I run wine cmd.exe
[22:18:40] <BastyCDGS> yes but the question is if wine uses the linux terminal capabilities in that case
[22:19:15] <BastyCDGS> I can try on my laptop with windows 7 if you wish
[22:19:57] <FUautotools> On windows they're not supported by default
[22:21:28] <FUautotools> nor do they seem to be supported with the /a switch
[22:21:44] <BastyCDGS> but still win/linux behave different on your patch, linux will output the color values to a redirected file
[22:21:47] <BBB> mru: ping
[22:22:03] <FUautotools> Link me to the linux equivalent then
[22:23:27] <hyc> call isatty() first
[22:23:47] <hyc> though frankly I don't see a problem with outputting to a file
[22:23:57] <hyc> if someone cats the file, then they'll get the colors again.
[22:24:11] <FUautotools> What #include do I need?
[22:24:24] <BastyCDGS> but then win32 and linux behave differently in that, that can be confusing if you're working on multiple platforms
[22:25:30] <BastyCDGS> I think the cleanest and expected way is it do it like the ls command
[22:25:41] <BastyCDGS> ls also doesn't out color codes if it's not a tty
[22:25:50] <FUautotools> What #include do I need?
[22:26:13] <BastyCDGS> <unistd.h>
[22:26:22] <BastyCDGS> http://www.opengroup.org/onlinepubs/009695399/functions/isatty.html
[22:27:49] <BastyCDGS> btw, is unistd.h available on macos x too?
[22:27:59] <BastyCDGS> someone here with macos coding experience?
[22:28:01] <astrange> mac os x is unix
[22:28:41] <BastyCDGS> then the patch should be fine
[22:28:44] <BBB> several of us use macosx here
[22:28:53] <Dark_Shikari> everything is unix except windows
[22:28:58] <Dark_Shikari> (and, like, plan 9)
[22:29:18] <BastyCDGS> yes it would work even on amigaos shell
[22:29:57] <BastyCDGS> except the isatty...on amiga you'd have to call dos.library/IsInteractive instead
[22:30:08] <BastyCDGS> but amigaos as ixemul.library for such cases ;)
[22:31:11] <BastyCDGS> is OS/2 a target platform of ffmpeg?
[22:31:34] <BastyCDGS> (well I doubt that anyone here would revoke the patch just of that) ;)
[22:32:17] <FUautotools> Better? http://pastebin.org/166467
[22:33:10] <BastyCDGS> looks fine to me...
[22:33:36] <FUautotools> I assume isatty(stderr) works
[22:34:15] <FUautotools> oh, small error fixed http://pastebin.org/166469
[22:35:41] <BastyCDGS> compiling a small sample: /tmp/test.c:6: attention : passing argument 1 of «isatty» makes integer from pointer without a cast
[22:39:46] <BastyCDGS> use
[22:39:47] <BastyCDGS> fileno(stderr)
[22:39:57] <BastyCDGS> isatty(fileno(stderr))
[22:40:37] <BastyCDGS> fileno is stdio.h
[22:41:07] <FUautotools> ... ok
[22:44:32] <BastyCDGS> anyone want to comment how i reviewed the patch?
[22:45:23] <BBB> stderr=2
[22:45:33] <BBB> so just isatty(2) is the same as isatty(fileno(stderr))
[22:45:39] <BBB> smaller ;)
[22:45:56] <BastyCDGS> but less readable ;)
[22:46:15] <BastyCDGS> is it safe to assume that stderr is always 2?
[22:46:22] <hyc> yes
[22:46:23] <BastyCDGS> on all unices?
[22:46:28] <hyc> that is it's definition
[22:46:38] <hyc> 0,1,2 are all set in stone
[22:47:25] <FUautotools> even on windows...
[22:48:39] <FUautotools> BBB: Do you want it replaced by 2?
[22:49:04] <BBB> use 2 /* stderr */ if you're worried about readability
[22:50:02] <FUautotools> _I'm_ not
[22:51:11] <FUautotools> but then one could say that all "stderr"s should be replaced by 2
[22:51:24] <BastyCDGS> no stderr is FILE *
[22:51:30] <FUautotools> oh...
[22:51:32] <BastyCDGS> it's a pointer not an int
[22:53:24] <FUautotools> Has everything I've real really skipped the fact that they're FILE *?
[22:53:35] <FUautotools> s/real/read
[22:54:46] <mru> BBB: pong
[22:55:01] <BastyCDGS> what have you read?
[22:56:27] <BastyCDGS> hey saste, how are u?
[22:57:51] <BBB> mru: what was that project that you wanted to give a soc slot to again?
[22:57:52] <FUautotools> BastyCDGS: lots on the net, several O'Reilly books, some not O'Reilly books
[22:58:23] <hyc> the variables stdin, stdout, and stderr are <stdio.h> handles, i.e. FILE*s
[22:58:26] <mru> BBB: he's getting a slot after all
[22:58:31] <mru> priorities were altered
[22:58:35] <BBB> ?
[22:58:36] <BBB> who?
[22:58:39] <BBB> oh, ok
[22:58:46] <BBB> sorry, my brain dysfunctioned for a second
[22:58:52] <hyc> but standard input is "whatever is attached to filedescriptor 0" and so on
[22:59:05] <BBB> ok, I'll leave the rest for goog then
[22:59:07] <saste> hey basty
[22:59:08] <mru> he got more votes later on
[23:00:39] <Dark_Shikari> what is the tab key in single-character form for comparison?
[23:00:43] <Dark_Shikari> e.g. '\n' is newline
[23:00:46] <Dark_Shikari> in C
[23:00:47] <mru> \t
[23:00:49] <Dark_Shikari> k, thx
[23:01:11] <mru> aka 'I'-0x40
[23:01:20] <mru> aka ^I
[23:01:26] <hyc> \010 in octal
[23:01:31] <hyc> hm
[23:01:42] <hyc> no \010 is backspace
[23:01:48] <mru> \011
[23:01:49] <BBB> j-b: want an extra slot?
[23:01:55] <Dark_Shikari> we have, like, 15
[23:01:55] <BBB> Dark_Shikari: or x264 extra slot?
[23:01:57] <Dark_Shikari> I think we have enough
[23:02:01] <Dark_Shikari> x264 has way enough
[23:02:01] <BBB> hm...
[23:02:03] <BBB> ok
[23:02:10] <Dark_Shikari> we only have 3 students accepted ffs
[23:02:57] <BastyCDGS> really? so andoma, FUautotools and me are the only?
[23:03:10] <Dark_Shikari> For x264.
[23:03:11] <Dark_Shikari> Not ffmpeg.
[23:04:53] <BastyCDGS> how many students are then for ffmpeg in total?
[23:05:31] <kierank> FUautotools: what are you doing in gsoc?
[23:05:33] <BastyCDGS> FUautotools, what the book wrote about file?
[23:05:47] <FUautotools> I'm not a student
[23:05:54] <BastyCDGS> oh then I was wrong, sorry
[23:05:55] <kierank> ah ok
[23:06:05] <BBB> BastyCDGS: andoma is your mentor
[23:06:15] <BBB> BastyCDGS: you have 6 colleagues, if my counting is right
[23:06:18] <BastyCDGS> ups seems I mixed sth. up ;)
[23:06:19] <FUautotools> I wish I could get 5k from google for some work though
[23:06:22] <BBB> BastyCDGS: you'll meet them later
[23:07:37] * BBB goes eat
[23:07:48] * BastyCDGS goes to sleep very soon
[23:09:58] <BastyCDGS> so I wish you all a wonderful night and nice dreams ;)