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

[irc at mansr.com]

[00:01:00] <bcoudurier> astrange :)
[02:07:48] <j0sh> is there a way to specify whether to use ffrtmp or librtmp at runtime? (ffmpeg command line)
[02:14:19] <BBB> Dark_Shikari: patch sent
[02:14:45] <Dark_Shikari> to where
[02:14:50] <Dark_Shikari> I expected a pastebin
[02:21:41] <BBB> email
[02:21:43] <Dark_Shikari> ok, I see it
[02:21:45] <BBB> I'll pastebin it
[02:21:50] <BBB> or is email ok?
[02:22:02] <Dark_Shikari> got it
[02:24:43] <BBB> should I rename the function from x264 to h264?
[02:24:48] <BBB> maybe I should
[02:24:50] <BBB> little confusing
[02:25:13] <Dark_Shikari> no
[02:25:19] <Dark_Shikari> because they're still imported from x264
[02:25:36] <Dark_Shikari> imo
[02:25:59] <BBB> yeah you're right
[02:26:00] <Dark_Shikari> done
[02:26:01] <BBB> let's leave it
[02:26:03] <BBB> thanks
[02:26:16] <CIA-11> ffmpeg: darkshikari * r25092 /trunk/libavcodec/x86/ (Makefile h264_idct_sse2.asm h264dsp_mmx.c):
[02:26:16] <CIA-11> ffmpeg: LGPL SSE2 H.264 iDCT
[02:26:16] <CIA-11> ffmpeg: This leaves no more GPL-only H.264 decoding asm code.
[02:26:16] <CIA-11> ffmpeg: Approved by Loren.
[03:32:25] <CIA-11> ffmpeg: rbultje * r25093 /trunk/LICENSE: Remove h264 asm items off the GPL-only list. They are LGPL now.
[04:17:23] <astrange> http://astrange.ithinksw.net/clang/ffmpeg-experimental/ clang-svn gets through most of ffmpeg without crashing now
[04:17:26] <astrange> that's progress
[04:17:30] <astrange> i think it
[04:17:43] <astrange> nearly compiles if 3dnow is off
[05:23:51] <thresh> moroning
[05:32:14] <_av500_> +1
[05:32:56] <kshishkov> thresh: steal a fine Swiss morning from some Turk instead of complaining
[05:34:50] <thresh> wouldnt help, we had a 'corporative event'...
[05:35:11] <kshishkov> steal it and leave your hangover as a compensation
[05:35:41] <thresh> that's the problem, i'm not hungover and I remember everything
[05:36:00] <kshishkov> ouch
[05:47:21] <thresh> still, I remember some pretty ladies too
[05:48:12] <kshishkov> "... бывает мало водки"
[05:49:27] <thresh> they were nice even before we got alcohol! that is something new...
[05:54:56] <_av500_> so it was not too bad after all...
[05:55:05] <_av500_> dont complain!
[05:55:55] <thresh> it's morning, the whole purpose of it is to complain!
[05:56:55] * kshishkov does not drink alcohol and coffee so he sees no reason to complain
[06:20:20] <CIA-11> ffmpeg: mstorsjo * r25094 /trunk/libavcodec/ (options.c utils.c): Allow the lowres option to affect audio codecs, too
[06:23:45] <saintd3v> hmm, don't think gabriel is going to get back to me :/
[06:24:30] <Tjoppen> god morgon
[06:24:41] <kshishkov> god morgon
[06:26:43] <Tjoppen> back from two days sick. ooh, replies to my dllimport patch
[06:49:30] <Tjoppen> interesting.. git made one of my branches disappear
[06:50:06] <Tjoppen> luckily I have a copy of it. rather strange though
[06:52:09] <Tjoppen> shouldn't got rebase --onto C A B move the range (A,B] onto C?
[06:57:37] <mru> it should
[06:58:22] <Tjoppen> although C is a tag in this case. maybe that has something to do with it
[06:58:35] <mru> should work
[06:58:47] <Tjoppen> well, it simply moved the branch head to C
[06:59:14] <wbs> sure commits A-B aren't already included in C?
[07:01:30] <Tjoppen> quite sure. C is just a tag for.. r24135
[07:02:10] <Tjoppen> A is r25094 and B was two local commits ahead of that
[07:02:39] <mru> then a simple rebase would work
[07:02:53] <mru> git checkout B; git rebase C
[07:03:23] <mru> anyway, are you sure it didn't stop due to a conflict?
[07:03:56] <Tjoppen> yep
[07:04:24] * mru still subscribes to pebkac theory
[07:05:12] <Tjoppen> probably. I just redid my work
[07:05:21] <Tjoppen> btw, _WIN32 is defined on mingw gcc
[07:05:50] <wbs> you chould have dug out the old branch tip and reset the branch to that, and redone the rebase, too
[07:06:02] <wbs> the actual commits are very, very, very seldomly lost
[07:07:52] <Tjoppen> it's probably still there in the garbage
[07:08:04] <mru> look in .git/logs/
[07:11:46] <Tjoppen> whatever
[07:14:48] <Tjoppen> I think #if defined(_WIN32) && !defined(__MINGW32__) might do as an "is this microsoft's compiler?" detection
[07:15:02] <kshishkov> nope
[07:15:10] <mru> for what purpose?
[07:15:11] <kshishkov> there's ICC, BCC and whatever
[07:15:17] <kshishkov> (Watcom too)
[07:15:25] <wbs> Tjoppen: what about _MSC_VER?
[07:15:30] <mru> dllimport?
[07:15:35] <Tjoppen> let me rephrase that: "do we need dllimport?"
[07:15:40] <Tjoppen> yes
[07:15:51] <mru> does it harm gcc-ming?
[07:15:55] <mru> W
[07:15:55] <Tjoppen> wbs: is that defined outside MSVC though? like when using the compiler on its own
[07:16:11] <wbs> Tjoppen: yes, of course it's defined when calling cl from the command line, too
[07:16:22] <mru> __GNUC__
[07:16:36] <mru> or _MSC_VER
[07:16:42] <mru> depending on what you want
[07:17:23] <Tjoppen> it seems mingw-gcc accepted it, but it's a bit ugly to defined it that way
[07:17:46] <Tjoppen> at the very least it should use dllexport when compiling the dlls, or?
[07:18:09] <Tjoppen> however, it linked and runs fine
[07:18:22] <mru> if works, we shall have no more hacks
[07:20:13] <KotH> grüezi
[07:39:27] <Tjoppen> is it likely that any non-const variables will ever be exported?
[07:39:45] <Tjoppen> my guess is no. just thinking of the possibility
[07:40:06] <mru> why does it matter?
[07:40:20] <mru> do not even think of putting const in the macro
[07:40:34] <Tjoppen> no no, I'm just htinking of the name
[07:40:50] <Tjoppen> and the small piece of documentation I'm adding to it
[07:40:59] <mru> const has nothing do with it
[07:41:04] <mru> so leave it out of the name
[07:42:06] <Tjoppen> I was thinking AV_EXTERN_VAR, but then realized that no globals can be modified
[07:42:24] <mru> DATA
[07:42:34] <mru> covers all
[07:42:43] <Tjoppen> fair enough
[07:43:21] <mru> what's special about data symbols anyway?
[07:43:31] <mru> why do they need ugly hacks like that?
[07:44:34] <Tjoppen> they aren't imported properly otherwise. my problem is simple: I can use them on linux/mingw but not in msvc
[07:44:45] <Tjoppen> maybe there's a better way to do it?
[07:44:48] <mru> yes but _why_ arent'y they imported?
[07:44:55] <mru> -typos
[07:45:20] <wbs> mru: the PE binary format handles them in a weird way, and gcc can handle it automatically via some workarounds, msvc can't
[07:45:35] <mru> microsoft fuckup as usual
[07:45:37] <Tjoppen> hm. come to think of it, how are the methods imported if they don't have dllimport added to them?
[07:45:53] <mru> they're called functions
[07:46:06] <mru> "method" is nasty java-speak
[07:46:07] <Tjoppen> is it the old "list all symbols, awk a bit -> import manifest"
[07:46:55] <Tjoppen> eventually you end up with an import library
[07:47:18] <mru> how could anyone ever even come with an idea for such a stupid design?
[07:48:22] <Tjoppen> good question. at the moment, if I understand correctly, msvc doesn't just use the dll directly but uses the stubs in the automatically generated import library instead
[07:48:40] <Tjoppen> while mingw-gcc does. I think.
[07:49:07] <Tjoppen> or at least it generates the stubs automagically, without the need for an import lib
[09:02:41] <Tjoppen> bah, doesn't work with static build
[09:05:12] <mru> what happens?
[09:06:10] <Tjoppen> fails to find __imp_av_pix_fmt_descriptors etc.
[09:06:19] <mru> blegh
[09:06:28] <Tjoppen> I'll try with _MSC_VER instead of _WIN32
[09:06:30] <mru> I can't think of a clean solution to that
[09:06:47] * KotH would have expected "somebody set up us the bomb" as the answer to the question "hat happens"
[09:06:48] <Tjoppen> hopefully that should only make it apply to cl.exe
[09:07:10] <mru> the preprocessor can't possibly know how you're intending to link it
[09:08:22] <mru> and I don't see how using a different macro test would help
[09:09:40] <Tjoppen> well, cl.exe and link.exe are typically used together. that would at least fix linking in that case
[09:09:55] <mru> no
[09:10:06] <mru> you can use those with static libs too
[09:11:53] <Tjoppen> ah, right. isn't it possible to detect --enable-shared though?
[09:12:00] <mru> no
[09:12:07] <mru> you can have both in the same build even
[09:12:12] <Tjoppen> ugh
[09:12:40] <Tjoppen> then this needs to be handled wherever lib.exe is run
[09:12:41] <mru> and the _application_ using lav* surely can't detect it
[09:13:18] <mru> this is the problem of an incestuous design like that
[09:13:26] <Tjoppen> so basically improving the import library generation is the only way
[09:13:52] <mru> there's got to be some way
[09:16:20] <Tjoppen> greping around for .lib and .def might be a good start, but I'm not too familiar with how such generation is done. I remember reading about it and going "fuck that"
[09:16:48] <mru> that's an option I'd be ok with
[09:19:37] <Tjoppen> it seems like this calls for a new thread
[09:19:55] <mru> start as many as you like
[09:19:58] <mru> forking is cheap here
[09:37:53] <saste> mru: hi mans
[09:38:02] <mru> hi
[09:38:12] <saste> mru: do you want to have another look at the frei0r wrapper or is it ok to apply?
[09:38:26] <saste> mru: I have no hurry so i can wait some days
[09:38:30] <mru> I'd like to look it over once more
[09:38:48] <mru> I have it flagged in my mailbox
[09:38:56] <saste> mru: ok so I'll wait...
[09:53:04] <merbzt> hmm, shouldn't all input opened from http urls set the flag is_streamed ?
[09:53:32] <wbs> merbzt: no, if the http server supports range requests, you can seek in the file, and is_streamed is set to 0
[09:54:30] <merbzt> ah ok
[09:54:32] <merbzt> tnx
[09:55:37] <merbzt> maybe I would get a clue if I bothered to read the dox :/
[10:43:35] <lu_zero> interesting
[10:43:36] <lu_zero> error: implicit declaration of function 'asm'
[10:44:07] <mru> __asm__
[10:45:59] <lu_zero> that's from the system headers from android
[10:46:11] <mru> fuck android then
[10:46:30] <lu_zero> eh
[10:46:39] <mru> 'asm' is a perfectly valid identifier in C
[10:47:08] <av500> I once called a global var "data"
[10:47:21] <av500> linker had a field day
[10:47:40] <wbs> lu_zero: is this in usr/include/asm/byteorder.h perhaps?
[10:47:47] <lu_zero> oui
[10:47:57] <wbs> fix it, change asm into __asm__
[10:48:07] <lu_zero> just done
[10:48:18] <mru> because __asm__ is not a valid identifier for applications to use
[10:48:21] <lu_zero> feel strange anyway
[10:48:30] <mru> __* being reserved and all
[10:49:08] <wbs> the issue is that some linux kernel header is using inline asm using asm(), where it should be __asm__()
[10:49:22] <wbs> I dug a bit into it, and someone had reported it to LKML around 2004 but nobody wanted to fix it
[10:49:32] <mru> which header?
[10:50:03] <mru> afaik the userspace-visible kernel headers are purged of all such thigns
[10:50:26] <wbs> one moment, I'll look it up
[10:50:45] <mru> the kernel headers should only be used to define syscalls, ioctls, and data types for these
[10:51:00] <wbs> iirc this was some header that the kernel shouldn't normally export, but the android bionic headers include it anyway
[10:51:05] <mru> i.e. define the interface to the kernel
[10:51:17] <mru> wbs: as I said, fuck android
[10:51:24] <mru> it's the only viable long-term choice
[10:51:25] <av500> wbs: iirc android has a script to generate kernel headers
[10:57:08] <wbs> this file: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=blob;f=arch/arm/include/asm/byteorder.h;h=4fbfb22f65a0f4444818e455422b60d3e61545d0
[10:57:47] <av500> bionic/libc/kernel/README.TXT
[10:57:47] <wbs> (or some similar one)
[10:58:44] <mru> that code should not be visible to userspace
[10:59:55] <wbs> exactly.. it's exported in /usr/include/asm/byteorder.h on another arm/linux I've got access to, too, but I guess the main problem is that the normal non-kernel headers in bionic piggyback on this header for getting some things defined
[11:00:26] <av500> wbs: that very file is mentioned as an exception in the README
[11:00:42] <mru> my exported asm/byteorder.h doesn't have that code
[11:00:50] <mru> as it should be
[11:01:02] <lu_zero> nor mine
[11:01:07] <mru> so android is fucked up
[11:01:11] <mru> nothing new, move along
[11:01:23] <wbs> mru: actually, most probably because of this: http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.30.y.git;a=commitdiff;h=af8e24e96facfd42eb12d13c8120e3e95de40aba
[11:01:26] <av500> http://lxr.e2g.org/source/bionic/libc/kernel/README.TXT#L163
[11:02:13] <lu_zero> and now at link undefined references on __aeabi_ulcmp
[11:02:18] <lu_zero> and friends =_=
[11:02:45] <mru> that function is required by the arm eabi
[11:02:51] <mru> usually provided by libgcc
[11:03:33] <mru> wbs: the installed byteorder.h doesn't include swab.h
[11:03:54] <wbs> mru: no, it doesn't but if you'd have gotten the byteorder.h from an earlier kernel version, you would have had the inline asm
[11:03:57] <av500> http://lxr.e2g.org/source/bionic/libc/kernel/tools/defaults.py#L46
[11:04:19] <lu_zero> yup
[11:04:27] <lu_zero> adding it solved the thing
[11:04:37] <wbs> av500: if they intentionally want to keep that function, they should at least change asm into __asm__
[11:04:52] <av500> wbs: patches welcome I guess :)
[11:05:17] <lu_zero> now I need to try it and then we could say how easy ffmpeg could be built using the ndk...
[11:05:21] <wbs> av500: of course. ;P that one is a bit more complicated, so I didn't push any patch for it when I encountered it
[11:05:41] <mru> lu_zero: don't even try using the ndk as is
[11:05:41] <wbs> lu_zero: it's not particularly hard, i've done it quite some time ago
[11:05:47] <mru> the shipped compiler is horribly broken
[11:06:03] <lu_zero> wbs: now I got something
[11:06:34] <lu_zero> mru: you know of an easily reachable compile that is usable for the purpose?
[11:06:47] <mru> what purpose?
[11:06:52] <av500> bionic
[11:06:57] <mru> you can use any gcc cross-compiler
[11:07:08] <av500> that has bionic patches
[11:07:14] <mru> none needed
[11:07:18] <mru> they follow eabi
[11:07:30] <wbs> av500: I at least got this one merged: https://review.source.android.com/#change,11671
[11:07:38] <lu_zero> so my normal cross compiler would work?
[11:07:42] <mru> might be easiest to link with their gcc
[11:07:49] <mru> but compile with your own
[11:07:59] <mru> that's why we have --cc and --ld flags to configure
[11:08:03] <mru> well, one reason
[11:08:15] <av500> mru: right, their linker
[11:09:05] * lu_zero wanted to prepare a small doc giving directions like the one for iphone
[11:09:27] <mru> should be much easier
[11:09:44] <mru> since they use ELF, you can use whatever tools you like to compile
[11:10:07] <lu_zero> mru: from what you are saying it would require as first step to get 2 toolchains...
[11:10:18] <mru> use the linker from the ndk
[11:10:48] <av500> lu_zero: one you have, ot comes with android
[11:10:51] <av500> it
[11:11:35] <lu_zero> av500: if the compiler provided is broken you won't make much progress by getting a broken ffmpeg out the process ^^
[11:11:47] <av500> is it?
[11:11:50] <mru> it's fine for linking
[11:11:55] <av500> broken I mean
[11:12:21] <av500> I cant say, I compile and link ffmpeg with a non android tc
[11:12:26] <merbzt> why does android need bionic ?
[11:12:27] <mru> they've messed up something so it's almost impossible to make it optimise for armv7/neon
[11:12:40] <av500> merbzt: nice troll :)
[11:12:40] <mru> it more or less insists on using armv5+softfloat
[11:12:55] <av500> mru: the newer one should not
[11:13:15] <mru> if they've updated the compiler it might be worth trying it as is
[11:13:48] <av500> they added a 4.4.0
[11:13:55] <mru> avoid that like the plague
[11:14:07] <mru> build your own 4.3 or 4.5
[11:14:16] <lu_zero> ^^;
[11:14:21] <lu_zero> 4.5.1 you mean
[11:14:23] <mru> or codesourcery 2009q1
[11:14:44] * mru should take a look at linaro-gcc
[11:14:59] <av500> mru: we use whatever is google patched with bionic
[11:15:00] <lu_zero> 4.5.0 is probably worse than 4.4.0
[11:15:15] <mru> no
[11:15:21] <mru> it's back at 4.3 performance
[11:15:23] <mru> mostly
[11:15:33] <mru> sometimes faster, sometimes slower
[11:16:28] <merbzt> so it is mostly a license issue
[11:17:30] <av500> merbzt: word is that manufs are afraid of the GPL
[11:17:48] <av500> (in user space)
[11:17:51] <merbzt> better safe then sorry I guess
[11:19:12] <mru> what's that got to do with anything?
[11:19:17] <mru> all gcc are gpl
[11:19:29] <av500> they dont end up on the product
[11:20:32] <mru> I thought we were discussing gcc versions
[11:22:15] <av500> its not mandated in $topic
[11:25:51] <merbzt> um, how do I get av_log to print out AV_LOG_DEBUG ?
[11:26:06] <merbzt> -v 10 does not work
[11:26:08] <mru> -loglevel something
[11:26:21] <merbzt> new command neat
[11:26:26] * mru has no idea how those two options interact
[11:27:36] <merbzt> :)
[11:28:00] <merbzt> I remember the good old times when -v 9 was all you needed
[11:28:51] <mru> det var bättre förr, ju förr desto bättre
[11:43:05] <mru> ot http://news.ycombinator.com/item?id=1677013
[11:48:49] <lu_zero> ?
[11:49:02] <av500> mru: was it like that at NDS?
[11:49:08] <mru> a bit
[12:17:03] <Compn> mru : that article is depressing as hell
[12:18:38] <mru> Compn: it's also all too true
[12:20:07] <Compn> quite
[12:27:21] <mru> fyi, -mfpmath=sse fixes lavf-nut test with gcc 4.5
[12:28:03] <mru> is that flag safe to use by default for supported cpus?
[12:30:19] <pengvado> yes
[12:30:30] <mru> no abi issues?
[12:30:46] <pengvado> it doesn't change the abi, only within-function arithmetic
[12:30:50] <mru> ok
[12:31:12] <merbzt> no precision issues compared to x87 ?
[12:31:16] <mru> doesn't fix the nut muxer as such of course
[12:31:23] <mru> omg it's ugy
[12:31:26] <mru> +l
[12:31:37] <kierank> why does nut need floating point?
[12:32:00] <mru> keycode  34 = bracketleft braceleft aring Aring
[12:32:00] <mru> keycode  47 = semicolon colon odiaeresis Odiaeresis
[12:32:00] <mru> keycode  48 = apostrophe quotedbl adiaeresis Adiaeresis
[12:32:03] <mru> fuck
[12:32:09] <pengvado> it doesn't have the *same* precision as x87, but if your code runs on any non-x86-32 cpus, then you already aren't depending on x87
[12:32:51] <mru> clipboard totally fucked up here...
[12:33:52] <mru> also it's on by default on x86_64
[12:35:06] <mru> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavformat/nutenc.c#l564
[12:35:28] <mru> I bet that line or line 568 is the problem
[12:40:37] <mru> it's the latter
[12:41:01] <superdump> i do something like that mru, except i have the ring and diareses on a e and o respectively
[12:41:03] <superdump> with alt gr
[12:41:05] <superdump> :)
[12:41:23] <mru> those are the keys that have those letters in the swedish layout
[12:45:03] <mru> it's scary that gcc seems to be putting effort into x87 optimisations though
[12:45:35] <mru> http://pastebin.ca/1937228
[12:49:28] <merbzt> mru: looks correct in theory
[12:49:37] <mru> and passes tests
[12:50:01] <merbzt> same hash on !gcc4.5 ?
[12:50:20] <mru> hmm, should probably test that
[12:51:54] <mru> works with 4.3
[12:52:25] <merbzt> commit and see what the rest says
[12:56:22] <mru> I can't imagine it will break anything
[13:15:27] <Tjoppen> uhm.. the tcp doesn't seem to resolve localhost
[13:16:37] <Tjoppen> meaning when I do ffprobe http://localhost/something  it just blocks, while ffprobe http://127.0.0.1/something works
[13:16:57] <CIA-63> ffmpeg: mru * r25095 /trunk/libavformat/nutenc.c: nutenc: fix unstable floating-point calculations
[13:18:08] <mru> Tjoppen: did you try tcpdump/wireshark to see what's happening?
[13:18:21] <mru> and is your /etc/hosts correct?
[13:19:05] <Tjoppen> it's on windows
[13:19:30] <mru> c:\windows\system32\etc\hosts then
[13:19:44] <Tjoppen> appearently there's no loopback. but I put lots of av_log() in the http code, and it blocks when it opens tcp://localhost
[13:19:46] <mru> or whatever the name is
[13:19:53] <Tjoppen> hm. good idea
[13:19:56] <mru> blocks on what?
[13:20:10] <Tjoppen> haven't dug that much yet
[13:20:42] <Tjoppen> appearently they've removed localhost from hosts
[13:20:44] <Tjoppen> in win7
[13:20:56] <mru> I'm guessing it's doing a dns lookup and waiting for it to time out
[13:21:21] <Tjoppen> well, we had it on over lunch without it doing anything
[13:21:37] <mru> maybe it's a very long timeout
[13:21:44] <Tjoppen> perhaps
[13:22:02] <mru> unplug the network cable and see what happens
[13:22:13] <mru> usually that makes windows nuke all sockets
[13:23:44] <Tjoppen> heh. I think we'll simply not use localhost
[13:24:08] <mru> what if you ask for some other random single-word name?
[13:25:12] <Tjoppen> ffprobe http://foo
[13:25:23] <Tjoppen> http://foo: Input/output error
[13:25:27] <Tjoppen> while localhost blocks
[13:25:39] <mru> hmm
[13:25:40] <mru> odd
[13:25:48] * mru blames redmond
[13:26:16] <Tjoppen> <colbert>REDMOND!</colbert>
[13:27:07] <merbzt> Tjoppen: I think it resolves to an ipv6 address or something like that
[13:28:43] <Tjoppen> shouldn't it do something in that case, not just block?
[13:28:57] <mru> dude, this is windows
[13:29:05] <mru> don't expect anything behave rationally
[13:30:03] <wbs> Tjoppen: the issue probably is that we use ipv6 where available. so localhost might resolve to both ::1 and 127.0.0.1 and we try them all in the order the OS returns them
[13:30:10] <merbzt> what does nslookup localhost say ?
[13:30:20] <wbs> so if you're on a broken ipv6 setup, you're screwed
[13:30:51] <Tjoppen> name: localhost \n addresses: ::1 \n 127.0.0.1
[13:31:17] <mru> well, there you have it
[13:35:34] <mru> hi DonDiego
[13:41:42] <DonDiego> hoi
[13:54:24] <mru> yay, one more green on fate
[14:00:28] <Vitor1001> mru: Nice!!
[14:00:50] <mru> and a one piece of ugly code less
[14:00:52] <mru> -a
[14:01:36] <Vitor1001> :D
[14:01:54] <Vitor1001> BTW, do you know which commit introduced the invalid read in valgrind?
[14:02:31] <Vitor1001> I suspect r25066...
[14:02:32] <mru> fate tells you the last known-working rev
[14:02:44] <mru> but there was a flurry of commits during those days
[14:03:13] <Vitor1001> something between 25054 and 25072...
[14:03:17] <mru> yes
[14:07:25] <Vitor1001> mru: About the funny x86_64/freebsd errors, do you know if it is a HW problem?
[14:07:32] <mru> probably
[14:07:50] <mru> or VM if he's using one
[14:08:01] <Vitor1001> possible too
[14:10:04] <mru> bisecting
[14:10:10] <mru> the valgrind error
[14:10:44] <Vitor1001> I'm trying to see if xxx66 is the culprit, but you will probably find it before I finish compiling in my atom...
[14:11:10] <mru> I'm on my laptop, but still much faster
[14:12:28] <Vitor1001> BBB: The patch is fine for me too, feel free to apply as soon as you wish
[14:15:52] <mru> I'm closing in on that revision
[14:17:56] <Vitor1001> I'm still halfway into finishing compilation ;p
[14:18:10] <mru> bisect says r25066
[14:20:06] <Vitor1001> Do you want me to flame in -cvslog?
[14:20:30] <mru> feel free
[14:22:15] <KotH> no open fires in the mailinglists please. the interior of the server has been redone using wooden walls
[14:24:19] <pJok> KotH, looks more like cheap platic veneer...
[14:24:25] <av500> KotH: wooden walls stand fire longer than others
[14:24:41] <av500> the charring acts as insulation
[14:24:44] <av500> -r
[14:25:17] <mru> +r
[14:25:29] <mru> -r would sound differently
[14:25:32] <av500> right
[14:25:56] <mru> but is that signed or unsigned char?
[14:26:26] <av500> singed
[14:26:30] <mru> sung
[14:26:37] <peloverde> just use stdint walls, they solve a lot of headaches
[14:27:00] <mru> make sure to use the _fast types for the lifts
[14:27:08] <mru> KotH gets so annoyed by slow lifts
[14:45:41] * kshishkov reads news about planned ARM CPU and tries to guess next version numbers: A8, A9, A15, A16, A17, A31
[14:47:21] <mru> no
[14:47:29] <mru> it was a8, a9, a5, a15
[14:47:47] <mru> so next we'll see a16, a12
[14:47:52] <mru> then perhaps a22
[14:49:03] <mru> otoh the previous naming series ran linearly from 1-3 in the long-forgotten past, through the well-documented 4-11
[14:50:31] <kshishkov> maybe it has bus failure or race condition now
[14:57:36] <KotH> long forgotten past?
[14:57:47] <KotH> sounds like the beginning of a fantasy novel
[14:58:12] <mru> well, have _you_ ever seen an arm2?
[14:58:23] <mru> heck, anything prior to arm7 is hard to find
[14:58:27] <kshishkov> in BBC Micro?
[14:59:00] <mru> come to think of it, I'm not even sure those low numbers ever existed
[14:59:31] <mru> arm7 is the lowest one mentioned on their website
[14:59:55] * KotH has an arm 610 at home
[15:00:12] <KotH> you've one guess what kind of device it is :)
[15:00:14] <kshishkov> wikipedia says arm1 (experimental) was in BBC Micro and v2/v3 in many Acorn machines
[15:16:00] <KotH> does anyone know whether there are any uP/uC with Gbit in a QFP (aka not BGA) case?
[15:17:08] <av500> QFP?
[15:17:23] <av500> that still exists?
[15:17:26] <kshishkov> is that even logical to exist?
[15:18:09] <KotH> av500: ofc
[15:18:23] <KotH> av500: all uC available in QFP cases
[15:18:54] <kshishkov> microcapacitors or microcontrollers?
[15:18:59] <KotH> av500: mostly because it's easier to solder and in the low pin count (ie <300 pins) a lot smaller
[15:19:16] <KotH> kshishkov: uC != uF :)
[15:19:41] <av500> uff!
[15:19:47] <kshishkov> KotH: I'd still consider uR to be microresistor
[15:20:42] <mru> resistance is futile
[15:21:01] <kshishkov> mru: only if you have wire in parallel
[15:21:01] <KotH> ( if < 1 ohm )
[15:21:11] * KotH is currently wearing that t-shirt
[15:21:59] <kshishkov> KotH: still, do you believe such controllers exist? Gbit is not that common even on more thick embedded SoCs
[15:22:37] <av500> kshishkov: what would the poor uC do with one gbit of data each second?
[15:22:42] <av500> err, KotH
[15:23:03] <av500> send to I2C?
[15:23:32] <mru> bitbang on gpio
[15:23:36] <mru> like that dram of yours
[15:23:45] <kshishkov> fill bitbucket
[15:24:29] <av500> annoy /dev/null
[15:25:05] <kshishkov> av500: /dev/null is device created by kernel bitbucket driver
[15:28:00] <mru> Vitor1001: found the problem
[15:28:20] <Vitor1001> mru: ?
[15:28:30] <mru> the valgrind error
[15:29:31] <Vitor1001> Nice! Do you have a clean fix?
[15:29:34] <mru> no
[15:29:37] <mru> I have no fix at all
[15:29:43] <mru> wait for email explaining
[15:30:09] <mru> also wtf is going on with all the memcpy shit?
[15:30:49] <Vitor1001> Have to look at it attentively when I'd have some time, no idea now...
[15:36:32] <mru> there, flames fanned
[15:38:19] <KotH> kshishkov: maybe. i know there are such uC with HS USB
[15:38:58] <KotH> kshishkov: there are uC's (arm9, cortex-a8/a9 class) that have gbit, sata and all that stuff.. but most of them are BGA or even FBGA which is a pain to solder by hand
[15:40:18] <kshishkov> KotH: I thought that applies to any modern ICs
[15:40:37] <KotH> nope
[15:41:13] <av500> kshishkov: the mountain people sometimes still use older technology :)
[15:41:14] <KotH> kshishkov: i've no probs to solder most chips, down to 0.5mm pitch (unless they are bga or qfn)
[15:41:51] <KotH> kshishkov: and people try to avoid qfn and bga as much as possible, because they have a very low yield in production
[15:42:15] <KotH> (or you have to hand tune the process parameters, which only pays back if you produce a few 1000 pieces)
[15:42:36] <kshishkov> av500: well, old languages should affect thinking somehow
[15:45:36] <av500> KotH: not all people :)
[15:50:11] <KotH> av500: well.. handheld stuff in the consumer section doesnt :)
[15:52:06] <kshishkov> KotH: handheld as in "lots of devices using dinosaur-shit conceptually old WinCE"?
[15:52:33] <av500> s/handheld/portable/
[15:54:00] <kshishkov> Soviet definition - "portable: has a handle; half-portable: has two handles"
[15:54:17] <KotH> av500: just that you dont think we build huge and heavy bricks. we're currently doing a project where we have to integrate 3 chips and some additional electronics into a microSD case :)
[15:55:35] * mru hand KotH a high-pressure vice
[15:56:18] <kshishkov> av500 can do that by feet
[16:00:28] <BBB> now now now mru
[16:00:34] <BBB> I wouldn't let my baby read ffmpeg-devel
[16:00:42] <BBB> (or ffmpeg-cvslog)
[16:02:02] <spaam> BBB: what did you do ?
[16:02:14] <BBB> nothing (honestly this time)
[16:02:15] <mru> I don't think BBB did anything
[16:02:32] <mru> this is michael's and/or saste's doing
[16:03:43] * BBB marks ffmpeg-cvslog as nsfw and 18+
[16:04:35] <mru> have you become totally americanised?
[16:04:44] <BBB> hehe, I was waiting for that :-p
[16:50:01] <lu_zero> BBB: isn't nsfs for you?
[16:50:51] <lu_zero> wbs: poing
[17:10:28] <BBB> nsfs=not suited for the states?
[17:16:46] <lu_zero> could work
[17:16:53] <lu_zero> states/study/school
[17:34:21] <CIA-63> ffmpeg: reimar * r25096 /trunk/libavcodec/cscd.c:
[17:34:21] <CIA-63> ffmpeg: Fix 24 bpp CSCD decoding, as for Windows bitmaps in this (and only this)
[17:34:21] <CIA-63> ffmpeg: case the stride must be aligned to a multiple of 4.
[17:45:02] <CIA-63> ffmpeg: stefano * r25097 /trunk/libavfilter/vf_crop.c: Cosmetics: remove useless parentheses.
[18:02:39] <CIA-63> ffmpeg: alexc * r25098 /trunk/libavcodec/ (aac.h aacdec.c):
[18:02:40] <CIA-63> ffmpeg: aacdec: Rework channel mapping compatibility hacks.
[18:02:40] <CIA-63> ffmpeg: For a PCE based configuration map the channels solely based on tags.
[18:02:40] <CIA-63> ffmpeg: For an indexed configuration map the channels solely based on position.
[18:02:40] <CIA-63> ffmpeg: This works with all known exotic samples including al17, elem_id0, bad_concat,
[18:02:40] <CIA-63> ffmpeg: and lfe_is_sce.
[18:55:09] <lu_zero> mru: ping
[18:55:14] <mru> pong
[18:55:25] <mru> what can I flame you for?
[18:56:06] <lu_zero> libavcodec/arm/mpegvideo_arm.c:33: error: size of array 'x_H263_AIC' is negative
[18:56:12] <lu_zero> rings any bell?
[18:56:25] <mru> what are you building for?
[18:57:10] <_av500_> android
[18:57:11] <lu_zero> iphone
[18:57:16] <_av500_> close
[18:57:27] <mru> good
[18:57:33] <mru> I was afraid it might have broken
[18:57:44] <mru> is that the only error?
[18:57:48] <lu_zero> _av500_: next time will be will be something more strange =P
[18:57:50] <lu_zero> so far yes
[18:58:24] <mru> edit libavcodec/arm/asm-offsets.h and fix the numbers for apple
[18:58:32] <mru> probably add or subtract 4
[18:59:01] <lu_zero> which is the way to get that number?
[18:59:20] <mru> offset of corresponding field in MpegEncContext
[19:00:24] <lu_zero> there isn't a safer way to get that?
[19:02:02] <mru> this is perfectly safe
[19:02:08] <mru> it refuses to build if it's wrong
[19:03:42] <lu_zero> subtracting 4 made it build
[19:04:19] <lu_zero> _av500_: the next step will be making it build for the iphone-x86
[19:04:20] <mru> then you may commit that change
[19:04:30] <mru> iphone-x86?
[19:04:32] <mru> wtf/
[19:04:45] <lu_zero> maybe would be nicer if somebody with the hw would test it
[19:04:53] <lu_zero> mru: the iphone simulator is x86
[19:05:01] <mru> who cares about that?
[19:05:09] <lu_zero> I do
[19:05:17] <lu_zero> since I don't have an iphone =P
[19:05:25] <mru> and ffmpeg builds fine on darwin/x86
[19:05:31] <lu_zero> yes
[19:05:34] <mru> if you don't have an iphone, why do you care about building for it?
[19:05:43] <lu_zero> so I'm not expecting it to fail
[19:06:13] <lu_zero> mru: I'm building something for the iphone as target platform
[19:06:27] <mru> do you want us to feel sorry for you?
[19:06:28] <lu_zero> and I'm not willing to buy an iphone at this stage ^^
[19:06:38] <mru> I will never buy an iphone
[19:06:44] <mru> at any stage
[19:06:50] <lu_zero> ^^
[19:07:14] <mru> if you see me using any apple product, you must send me to some kind of correctional facility
[19:07:27] * Kovensky hides the apple pies from mru
[19:08:00] * mru does not _use_ apple pies, he _eats_ them
[19:08:11] <lu_zero> mru: do you happen to print anything?
[19:08:50] * lu_zero points cups
[19:09:00] <mru> what of it?
[19:09:05] <lu_zero> apple's
[19:09:09] <mru> explains a lot
[19:09:16] <lu_zero> theheh
[19:09:19] <mru> anyway, I was talking about hardware
[19:09:22] <lu_zero> ah
[19:09:41] <lu_zero> then I guess you are clean
[19:09:46] <mru> if they happen to release some useful opensource sw, I see no reason to avoid it
[19:10:01] <mru> if something works, I'll use it
[19:10:15] <mru> works well, I should say
[19:10:45] <mru> I'm not one of those purists who refuses to use a good product for philosophical reasons
[19:10:48] <mru> aka RMS
[19:11:02] <lu_zero> =)
[19:11:19] <mru> now as it happens, I don't find apple's hw useful
[19:11:44] <mru> I'd rather not turn myself into one of jobs' minions
[19:11:44] * lu_zero ponders about fetching an svn from here or start another pc with the svn checkout in place...
[19:12:12] <lu_zero> uhmm booting would be faster =P
[19:26:35] <CIA-63> ffmpeg: lu_zero * r25099 /trunk/libavcodec/arm/asm-offsets.h: Update H263_AIC asm offset for the apple variant
[19:26:41] <mru> thanks
[19:33:02] <lu_zero> =)
[19:52:34] <CIA-63> ffmpeg: vitor * r25100 /trunk/libavcodec/ (amr.h amrnbdec.c):
[19:52:34] <CIA-63> ffmpeg: Move AMR-NB frame unpacking code to a common file so it can be reused in
[19:52:34] <CIA-63> ffmpeg: the AMR-WB decoder.
[19:52:34] <CIA-63> ffmpeg: Patch by Marcelo Galv?o P?voa.
[20:12:19] <astrange> my profiler thinks ff_put_h264_chroma_mc8_ssse3_rnd.next2rows is a function, i wonder if yasm can strip those out
[20:13:17] <Dark_Shikari> Yes
[20:13:22] <Dark_Shikari> strip -x or whatever
[20:27:25] <astrange> that removes static functions too if i run it on the linked output, i guess it could go in the makefile
[20:27:39] <astrange> maybe prepend L to local labels
[20:40:59] <mru> astrange: normally local symbols start with .
[20:41:15] <mru> if they're present at all in the symbol table
[20:49:30] <astrange> yasm outputs them as _ff_x264_deblock_v_luma_intra_sse2.end here, i didn't check what it does with elf
[21:13:50] <_av500_> mru: btw, im just building felipes stuff
[21:30:50] <mru> astrange: that's just the normal macfag prefix
[21:34:05] <BBB> lol @ macfag
[22:40:42] <mru> peloverde: did you get a job or something?
[22:40:53] <peloverde> yes
[22:41:18] <mru> something exciting?
[22:42:31] <peloverde> yeah, it's with Zoran's camera group
[22:42:49] <mru> doesn't mean much to me
[22:43:22] <_av500_> peloverde: zoran the chip guys
[22:43:40] <peloverde> yeah those guys
[22:48:05] <_av500_> what will you do?
[22:49:34] <mru> ultimately he'll emerge a little more cynical than before
[22:50:07] <peloverde> Well they said that wanted to apply my multimedia knowledge, I'm not sure if I can say more at the moment
[22:50:51] <mru> they say all sorts of things when they hire you
[22:51:04] <mru> "they" not being zoran specifically
[22:51:37] <mru> they always make it sound like you're oh so valuable to them
[22:51:49] <mru> then you end up doing something totally unrelated anyway
[22:51:52] <peloverde> yeah I know, I'll see what they actually have me working on when I start
[22:54:22] <mru> when do you start?
[22:54:53] <peloverde> In 11 days
[22:56:21] <mru> damn, you won't have time to finish aacenc before that
[22:58:07] <peloverde> nope, but I did try to fix some of the deocder stuff like supporting more broken files
[23:02:19] <peloverde> This will get me out of ohio which has been on my agenda for quite some time
[23:02:36] <_av500_> and into?
[23:02:41] <_av500_> kansas?
[23:03:18] <mru> how'd you end up in ohio anyway?
[23:03:36] <_av500_> burlington?
[23:03:52] <_av500_> sunnyvale?
[23:03:58] <_av500_> linköpping?
[23:04:37] <mru> -p
[23:04:51] <peloverde> to silicon valley
[23:05:01] <peloverde> I wound up in ohio for university
[23:05:35] <peloverde> ohio actually has several pretty good universities, just no jobs for anyone who graduates
[23:05:55] <mru> solution: don't graduate
[23:06:33] <_av500_> peloverde: good luck then in the valley
[23:07:18] <mru> and if you get bored of the job, plenty to choose from there
[23:08:37] <peloverde> thanks
[23:29:57] <CIA-63> ffmpeg: cehoyos * r25101 /trunk/libavformat/flvenc.c:
[23:29:57] <CIA-63> ffmpeg: FLV Metadata
[23:29:57] <CIA-63> ffmpeg: Patch by Tom?s Touceda, chiiph gentoo org
[23:42:03] <CIA-63> ffmpeg: cehoyos * r25102 /trunk/libavcodec/mpegvideo_enc.c:
[23:42:03] <CIA-63> ffmpeg: Allow mpeg encoding with qscale and very low frame rate.
[23:42:03] <CIA-63> ffmpeg: Patch by James Darnley, james D darnley A gmail