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

[irc at mansr.com]

[00:11:57] <Compn> ahhhhh
[00:12:16] <Compn> slim mini business pc very slow to boot, only allows one hd
[00:12:30] <Compn> make sure everything is set to master, because 'slave' doesnt exist on it
[00:12:33] <Compn> how stupid.
[01:45:08] <CIA-63> ffmpeg: rbultje * r25136 /trunk/libavcodec/x86/ (Makefile dsputilenc_yasm.asm dsputilenc_mmx.c):
[01:45:08] <CIA-63> ffmpeg: Move sse16_sse2() from inline asm to yasm. It is one of the functions causing
[01:45:08] <CIA-63> ffmpeg: Win64/FATE issues.
[01:57:03] <CIA-63> ffmpeg: rbultje * r25137 /trunk/libavcodec/x86/ (dsputilenc_yasm.asm x86util.asm dsputilenc_mmx.c):
[01:57:03] <CIA-63> ffmpeg: Move hadamard_diff{,16}_{mmx,mmx2,sse2,ssse3}() from inline asm to yasm,
[01:57:03] <CIA-63> ffmpeg: which will hopefully solve the Win64/FATE failures caused by these functions.
[03:02:48] <CIA-63> ffmpeg: rbultje * r25138 /trunk/libavcodec/x86/dsputilenc_mmx.c:
[03:02:48] <CIA-63> ffmpeg: Properly add HAVE_YASM around yasmified symbols. Should fix compile error
[03:02:48] <CIA-63> ffmpeg: on configurations using --disable-yasm.
[07:46:21] <cartman> http://fate.ffmpeg.org/x86_32-ubuntu-clang my new fate target :P
[07:46:54] <KotH> yet another x86*?
[07:47:10] <mru> we need another field to distinguish all these different targets
[07:47:17] <KotH> why dont we have any ppc 603? or so?
[07:47:23] <mru> and why another clang/x86?
[07:47:30] <cartman> mru: this is clang trunk
[07:47:40] <mru> that's what I'm testing too
[07:47:45] <cartman> oh damn :P
[07:48:10] <cartman> because its fun to test ffmpeg?
[07:48:27] <mru> we could use some testing with common distro compilers though
[07:48:47] <cartman> gcc is boring ;(
[07:48:53] <mru> e.g. suse ship(ped?) a broken one
[07:49:10] <spaam> cartman: use pcc!
[07:49:11] <KotH> mru: that was RH
[07:49:16] <cartman> spaam: donate one! :D
[07:49:18] <KotH> mru: and it was calledd 2.96
[07:49:26] <mru> no, suse shipped a broken 4.3
[07:49:33] <mru> iirc
[07:49:36] <KotH> oh..
[07:49:40] <spaam> cartman: you can do it!
[07:49:40] <mru> 4.something
[07:49:44] <cartman> spaam: how! :D
[07:49:44] <KotH> people still havent learned to mess with compilers?
[07:49:50] <KotH> not to*
[07:49:56] <cartman> KotH: and Suse has shitloads of gcc developers
[07:49:57] <spaam> cartman: compile it!
[07:50:09] * cartman compiles himself
[07:50:12] <cartman> internal error!
[07:50:14] <KotH> cartman: so does rh, but they screwed up big time nontheless
[07:50:22] <cartman> KotH: yeah the irony
[07:51:04] <mru> probably different people
[07:51:22] <cartman> packagers influenced by managers
[07:51:30] <mru> package managers
[07:51:33] <cartman> lol
[07:53:04] <kshishkov> KotH: may I remind you that Suse gave us ALSA?
[07:53:20] <KotH> kshishkov: i defected from suse after 3 months of using
[07:53:20] <mru> suse gave us greg kh
[07:53:21] <cartman> nooooooooooooooooooooooooooooooooo
[07:53:27] <cartman> noooooooooooooooooooooooooooooooooooo^2
[07:53:41] <KotH> kshishkov: not to mention that it was the first 3 months of owning a pc at all
[07:53:44] * mru doesn't like greg kh much
[07:53:49] <mru> too single-minded
[07:54:16] <KotH> mru: hmm...path is still the worst compiler...
[07:54:20] <cartman> he has done everything to break nvidia kernel module
[07:54:24] <cartman> wonder if he gave up now
[07:54:25] <kshishkov> KotH: defected? Personally I don't think I used it that long. And the only good thing about Mandrake is that it introduced me to FFmpeg.
[07:54:32] <mru> KotH: open64 is worse
[07:54:36] <mru> yeah, same code base
[07:54:37] <kshishkov> mru: do you like some RedHat guys then?
[07:54:43] <KotH> mru: open64 is basically dead
[07:54:46] <cartman> kshishkov: Mandrake was good
[07:54:57] <mru> KotH: codestr0m requested it
[07:55:03] <KotH> mru: he did?
[07:55:10] <mru> he wanted to see how they compared
[07:55:21] <KotH> mru: prolly as a marketing trick :)
[07:55:21] <mru> and open64 has regular commits
[07:55:29] <mru> possibly
[07:55:48] * cartman requests a fate with msvc
[07:55:49] <cartman> :P
[07:55:55] <KotH> mru: yes, but it's a centrally controlled research project
[07:55:56] <kshishkov> cartman: no - in distro I got half of packages could not be installed because of missing dependencies (and those were on all CDs). Luckily it was all extra stuff
[07:55:56] <Dark_Shikari> actually, a fate with ICL might be interesting.
[07:56:10] <kshishkov> cartman: though I liked to toy with several Prolog interpreters
[07:56:16] <cartman> kshishkov: I would install glibc and had to reinstall, good old days :P
[07:56:21] <KotH> Dark_Shikari: ICL?
[07:56:25] <cartman> KotH: intel
[07:56:29] <Dark_Shikari> KotH: Windows MSVC-compatible ICC
[07:56:31] <mru> intel emulating msvc
[07:56:34] <Dark_Shikari> Supports C99
[07:56:44] <mru> but we already test icc
[07:56:50] <KotH> how is a c99 compatible compiler compatible to msvc?
[07:56:53] <mru> icl is just a slightly different frontend
[07:57:03] <kshishkov> huh? I fit emulates MSVC it should not support C99 by any means!
[07:57:06] <kshishkov> *If it
[07:57:25] <Dark_Shikari> kshishkov: you could make the same argument for emulating gcc
[07:57:32] <cartman> it correctly emulates crap command line
[07:57:33] <Dark_Shikari> "if icc really did emulate gcc, it would suck a lot more"
[07:57:42] <mru> it does
[07:57:47] <mru> it fails multiple tests
[07:57:57] <kshishkov> especially H.264
[07:58:19] <kshishkov> (well, used to)
[07:58:19] <mru> no
[07:58:26] <mru> yeah, a long time ago
[07:58:39] <kshishkov> 10.x IIRC
[07:58:50] <cartman> Reimar fixed most of them afaik
[07:59:04] <kshishkov> mru: luckily, now we have pathscale to fail them
[08:28:41] <lu_zero> kshishkov: pathscale at least has a more or less responsive upstream that doesn't say is our bug (so far)
[08:29:20] <mru> they agree it's their bug
[08:29:26] <mru> but they don't consider it important
[08:29:27] <lu_zero> (on the other hand they use cmake and that makes them go down in my scale)
[08:29:32] <mru> s/it/them/
[08:30:07] <mru> they're in this weird mindset where a bug doesn't count unless you paid for the privilege of reporting it
[08:30:07] <lu_zero> ffmpeg will be _the_ C conformance test sooner or later ^^;
[08:30:33] <lu_zero> mru: the bug happens on open64 as well?
[08:30:48] <mru> the bugs, yes
[08:30:52] <mru> open64 even has a few more
[08:31:00] <lu_zero> uhmm
[08:31:23] <kshishkov> lu_zero: do you consider cmake to be worse than the way our beloved gcc builds?
[08:31:43] <lu_zero> last time I tried to build open64 it had some unpleasant side reference to the libstdc++
[08:31:44] <Dark_Shikari> cmake and gcc are not mutually exclusive
[08:31:45] <Dark_Shikari> nor related
[08:31:55] <mru> he means the gcc build system
[08:32:02] <mru> which is among the worst possible
[08:32:05] <lu_zero> kshishkov: so far the best build system in a compiler is the llvm/clang one
[08:32:15] <Dark_Shikari> the problem with cmake is that it can only do what the developers happened to think of
[08:32:19] <Dark_Shikari> and if you want to do something else, you're stuck
[08:32:26] <lu_zero> the cmake one of pathscale has its share of annoyance
[08:32:39] <mru> Dark_Shikari: that's something all these "alternative" systems have in common
[08:32:49] <lu_zero> and more or less works, the gcc works and I know all the quirks
[08:33:04] <mru> knowing the quirks does not make it any less horrible
[08:33:29] <kshishkov> lu_zero: I've tried building GCC crosscompiler on my MacOSX/PPC for Linux/ARM, guess the result
[08:33:51] <lu_zero> kshishkov: last time I tried it worked
[08:34:08] <mru> it's annoying that gcc doesn't let you build the common parts only once
[08:34:08] <kshishkov> I doubt it
[08:34:22] <lu_zero> kshishkov: clang^Wapple way might be nicer
[08:34:26] <mru> i.e. a single build with multiple backends
[08:34:59] <kshishkov> maybe it's because independent GCC backend is a lie?
[08:35:24] <lu_zero> kshishkov: mostly because it's structured in a way that makes that less useful
[08:35:46] <mru> gcc is an entangled mess to make it impossible to insert non-gpl stages
[08:35:48] <lu_zero> so you have a common backend that you must copy in a different path per arch...
[08:35:59] <lu_zero> mru: how so?
[08:36:04] <kshishkov> lu_zero: structured? really?
[08:36:21] <lu_zero> kshishkov: yup
[08:36:36] <mru> lu_zero: they were afraid that if they made clean interfaces between the stages, someone could drop in, say, a non-gpl optimiser
[08:37:11] <lu_zero> $prefix/$chost/$ctarget or something like that
[08:37:15] <mru> and because "freedom" is more important than quality, they did everything they could to make that impossible
[08:37:49] <lu_zero> and thus now then they are in need a fork
[08:37:59] <lu_zero> xorg-like fork hopefully
[08:38:03] <cartman> and a spoon please
[08:38:12] <mru> gcc needs to die
[08:38:15] <lu_zero> a spork
[08:38:17] <lu_zero> mru: why?
[08:38:21] <mru> just look at it
[08:38:28] <mru> it's beyond rescue
[08:38:32] <lu_zero> nah
[08:38:34] <spaam> mru: can you make it better? :)
[08:38:37] <mru> unfortunately the only current contender is clang
[08:38:41] <mru> and that is owned by apple
[08:38:58] <lu_zero> and is the cleanest C++, yet C++
[08:38:59] <mru> spaam: give a time machine and a shotgun
[08:39:10] <cartman> ok cpu experts, my system says cpu model is 37 but the Intel docs has no model 37, any idea how to convert it according to intel docs?
[08:39:11] <mru> *give me
[08:39:18] <kshishkov> lu_zero: GCC is migrating to C++ as well
[08:39:20] <lu_zero> mru: w/out a shotgun you can do that as well
[08:39:29] <lu_zero> kshishkov: was lovely
[08:39:40] <lu_zero> now they are getting the C++ parts back to C
[08:39:40] <mru> kshishkov: and in the meantime they'll not be fixing any bugs, rest assured
[08:39:49] <kshishkov> mru: still, Apple owns it in rather stealth manner while GCC seems to be the major FSF seeling point
[08:39:53] <kshishkov> *selling
[08:39:53] <lu_zero> like graphite
[08:40:14] <mru> apple can still pull the plug whenever they like
[08:40:44] <mru> one day, they'll decide they don't need the free labour anymore and stop releasing changes
[08:41:06] <lu_zero> mru: ack could even try to build ffmpeg nowadays?
[08:41:29] <mru> lu_zero: ?
[08:41:32] * lu_zero was looking for alternate C compilers
[08:41:36] <cartman> clang builds ffmpeg fine :D
[08:41:41] <lu_zero> ack is the minix3 compiler
[08:41:57] <mru> then it's got to be useless
[08:42:06] <lu_zero> cartman: clang has a nice and clean interface, nifty ideas and a good build system
[08:42:50] <lu_zero> still I'm scared of C++
[08:43:05] <cartman> a subset of C++
[08:43:06] <cartman> is OK
[08:43:16] <mru> is unnecessary
[08:43:19] <lu_zero> cartman: it's called C
[08:43:19] <mru> just use C
[08:43:25] <cartman> nope
[08:43:34] <cartman> but I won't argue ;)
[08:43:35] <lu_zero> cartman: tell me what you want from C++
[08:43:40] <cartman> thats just the wrong channel ;)
[08:43:49] <mru> if you insist on c++, you'll have to cut it down to the intersection of c and c++
[08:44:01] <mru> and that means giving up a lot of good things in c
[08:44:08] <kshishkov> int class, new;
[08:44:18] <mru> void *
[08:44:20] <cartman> lu_zero: basic object oriented things, like classes
[08:44:35] <mru> real problems are not object oriented
[08:44:39] <mru> that's the problem
[08:44:41] <lu_zero> cartman: in syntax sugar on structs?
[08:44:41] <Dark_Shikari> mru: no, some problems are.
[08:44:44] <Dark_Shikari> But many are not.
[08:44:50] <mru> Dark_Shikari: very, very few
[08:44:54] <Dark_Shikari> object-oriented programming is a single one of many solutions
[08:44:55] <cartman> lu_zero: structs can't inherit can they?
[08:45:00] <Dark_Shikari> the problem is languages that force you to use it for everything
[08:45:01] <lu_zero> cartman: yes
[08:45:04] <Dark_Shikari> C++ isn't such a horrible offender there
[08:45:07] <Dark_Shikari> Java is much much much worse
[08:45:22] <cartman> I use Qt, it abstracts C++ out
[08:45:26] <mru> sure, c++ doesn't force you to have useless objects
[08:45:29] <kshishkov> yuck!
[08:45:39] <mru> java is worse in that regard
[08:45:47] <lu_zero> cartman and the C closures proposed by apple might be interesting
[08:45:54] <mru> meh
[08:45:57] <cartman> lu_zero: right maybe objective-c
[08:46:04] <cartman> but the syntax is disgusting
[08:46:13] <kshishkov> lu_zero: so Apple proposed C closures and cartman?
[08:46:18] <Dark_Shikari> we already have closures in C
[08:46:21] <Dark_Shikari> a closure is a function + data
[08:46:29] <Dark_Shikari> myfunc( functionpointer *f, data *d );
[08:46:31] <Dark_Shikari> there, a closure.
[08:46:38] <cartman> kshishkov: they propose me right :P
[08:46:43] <lu_zero> Dark_Shikari: you are missing ^
[08:47:13] <Dark_Shikari> ?
[08:47:13] <mru> imo c needs to be kept free of "magic"
[08:47:14] <lu_zero> but I do agree that's mostly sugar
[08:47:37] <Dark_Shikari> mru: if there's one thing C could use, it's a better preprocessor.
[08:47:46] <Dark_Shikari> that's about it (in terms of "big features") that I think C needs.
[08:47:46] <lu_zero> still what I'd love is a nonpreprocessor
[08:47:46] <cartman> what would be the worst part of C++? templates?
[08:47:48] <kshishkov> yes!
[08:47:53] <lu_zero> Dark_Shikari: agreed =)
[08:47:59] <Dark_Shikari> templates are made entirely unnecessary by a sufficiently good preprocessor.
[08:48:05] <mru> the preprocessor could be improved, yes
[08:48:14] <Dark_Shikari> kshishkov: a lot of parts of C++ are both extremely useful and extremely dangerous
[08:48:21] <lu_zero> possibly making track preprocessed stuff in the debugger
[08:48:26] <Dark_Shikari> e.g. operator overloading
[08:48:30] <mru> macros expanding to preprocessor directives would be a nice improvement
[08:48:32] * kshishkov would like proper macroprocessor, something at least GAS-level
[08:48:34] <twnqx> i'd love operator overloadign for further types
[08:48:39] <Dark_Shikari> kshishkov: yeah, yasm-like would be good
[08:48:48] <Dark_Shikari> or gas, pretty much similar.
[08:48:53] <cartman> I would like a useful non-gdb debugger first
[08:48:55] <twnqx> and proper multi-file inlining (which of course requires linker interaction)
[08:49:10] <merbzt> I would like a 0b1011 syntax in c
[08:49:14] <Dark_Shikari> what merbzt said.
[08:49:17] <twnqx> that too
[08:49:28] <Dark_Shikari> A lot of the stuff that would improve C are "little things".
[08:49:30] <Dark_Shikari> like that.
[08:49:33] <twnqx> but that can be arranged with #include <binaryconstants.h>
[08:49:45] <mru> just learn hex already
[08:50:05] <mru> 0xd
[08:50:17] <kshishkov> mru: curses!
[08:50:48] <merbzt> portable vararg generation
[08:51:01] <mru> varargs are dangerous
[08:51:11] <Dark_Shikari> the only real purpose of varargs is for printf
[08:51:13] <Dark_Shikari> and sscanf and friends
[08:51:15] <mru> unfortunately I can't think of a safe way to do it
[08:51:30] <lu_zero> mru: still preprocessor improvements could be made in a nearly portable way
[08:51:31] <kshishkov> Dark_Shikari: can be good for eval()
[08:51:37] <mru> I made some macros to build a va_list once
[08:52:27] <Dark_Shikari> oh yeah, and I think the type promotion rules need a bit of work.  of course that would only be doable for a new language
[08:52:32] <Dark_Shikari> int32_t * uint32_t should not result in uint32_t.
[08:52:54] <mru> it's easy to make a case for either choice there
[08:53:02] <Dark_Shikari> that is, "the signedness of an expression is the most important aspect of it"
[08:53:06] <mru> they had to pick one
[08:53:27] <Dark_Shikari> It might be nice to have a compiler option to warn about those.
[08:53:44] <mru> that could be useful
[08:54:26] <Dark_Shikari> i.e. "signed expression implicitly promoted to unsigned" etc
[08:54:45] <mru> otoh that would probably spew false warnings left and right
[08:54:50] <Dark_Shikari> not really
[08:54:58] <Dark_Shikari> you don't multiply int * unsigned int very often
[08:55:03] <Dark_Shikari> and usually when you do, you fucked up
[08:55:09] <mru> uint8_t * uint32_t
[08:55:17] <mru> uint8_t gets promoted to int first
[08:55:18] <Dark_Shikari> that's not a signed expression
[08:55:28] <Dark_Shikari> Oh, but you'd have the compiler figure that out.
[08:55:39] <Dark_Shikari> it would only spew the warning if it KNEW a variable COULD be negative.
[08:55:52] <Dark_Shikari> obviously something promoted from uint8_t cannot be negative.
[08:56:36] <Dark_Shikari> It's really stupid how (ptr + -1 * stride) is not the same as (ptr - stride) if stride is unsigned.
[08:56:56] <merbzt> definition order rules could be relaxed a bit
[08:57:17] <Dark_Shikari> Oh, and they should fix that fucking goto label definition shit
[08:57:20] <Dark_Shikari> i.e.
[08:57:21] <Dark_Shikari> label:
[08:57:22] <mru> merbzt: no static prototypes?
[08:57:22] <Dark_Shikari> int blah;
[08:57:24] <Dark_Shikari> should be allowed.
[08:57:29] <Dark_Shikari> I hate that.
[08:58:04] <lu_zero> Dark_Shikari: what's the use?
[08:58:11] <mru> merbzt: I guess the compiler could do a prepass and collect all declarations
[08:58:23] * kshishkov wants only better preprocessor macro expansion
[08:58:44] <mru> kshishkov: you can do amazing things with recursive #includes
[08:58:49] <lu_zero> kshishkov: make an ffcpp as part of ffmpeg and use it in ffmpeg ^^
[08:58:50] <merbzt> mru: yes something like that
[08:58:55] <mru> amazingly incomprehensible, that is
[08:59:02] <lu_zero> mru: swscale.
[08:59:26] <mru> lu_zero: no, not like that
[08:59:32] <Dark_Shikari> lu_zero: declaring variables after a label?
[08:59:33] <Dark_Shikari> it's kinda useful.
[08:59:40] <mru> lu_zero: files including themselves
[08:59:40] <kshishkov> IIRC some IOCCC winner calculated prime numbers with preprocessor
[08:59:47] <Dark_Shikari> or after a case:
[08:59:54] <mru> Dark_Shikari: {
[09:00:03] <Dark_Shikari> mru: yeah, but what if I don't want to?
[09:00:03] <Dark_Shikari> ;)
[09:00:15] <kshishkov> lazy
[09:00:16] <lu_zero> in the cases in which is useful I'm thinking about a block
[09:00:36] <mru> Dark_Shikari: what you're asking for is mostly useful for spaghetti code
[09:00:42] <mru> and we don't want more of that
[09:01:30] <Dark_Shikari> mru: well, I see no reason why the rule should be different ther
[09:01:31] <Dark_Shikari> *there
[09:01:36] <Dark_Shikari> you can put "int x;" anywhere else
[09:01:38] <Dark_Shikari> why not after case: ?
[09:02:08] * mru doesn't like mid-block declarations
[09:02:25] <Dark_Shikari> I'm fine with them as long as they're conceptually separate.
[09:02:59] <mru> many of these restrictions are direct consequences of how compilers worked in ancient times
[09:03:01] <Dark_Shikari> e.g. int x = a();  do stuff with x.  int y = b();  do stuff with y.  etc
[09:03:08] <merbzt> um how do I profile FFmpeg best ?
[09:03:12] <Dark_Shikari> yeah.  IMO making our languages based on the restrictions of the 1980s is not a good idea =p
[09:03:15] <Dark_Shikari> merbzt: oprofile
[09:03:20] <mru> remember they were written in assembler and had to run in like 16k of memory
[09:03:35] <mru> 80s?
[09:03:37] <mru> 60s
[09:06:03] <Dark_Shikari> hmm.  an x264 commercial license customer is requesting that we mention something about the commercial license in the license headers
[09:06:12] <Dark_Shikari> since having a "this is GPL" header on every file is kind of contradictory
[09:06:19] <mru> Dark_Shikari: are you familiar with the term basic block?
[09:06:23] <Dark_Shikari> mru: yes
[09:06:39] <Dark_Shikari> hmm.  I wonder if we can modify a license header to say "this is GPL, or commercial, contact <email> for the latter"
[09:06:47] <mru> then you know that if you were to jump into the middle of one, all hell would break loose
[09:07:02] <mru> Dark_Shikari: why not?
[09:07:05] <mru> on the licence
[09:07:12] <Dark_Shikari> why not to what
[09:07:28] <mru> add a note about non-gpl options
[09:07:36] <Dark_Shikari> Nothing wrong with it, I just have never seen it done before
[09:07:39] <Dark_Shikari> so I'm not quite sure how to put it
[09:08:13] <Dark_Shikari> The other option would be to give them a separate copy of the code instead of pulling from git
[09:08:22] <Dark_Shikari> which is annoying maintainability-wise
[09:08:26] <Dark_Shikari> since I want to tell customers to pull from git
[09:09:42] <mru> just a line like "for other licensing options, contact $email" after the gpl blurb
[09:10:28] <Dark_Shikari>  * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston, MA  02111, USA.
[09:10:31] <Dark_Shikari>  *
[09:10:34] <Dark_Shikari>  * This program is also available under a commercial proprietary license.
[09:10:36] <Dark_Shikari>  * For more information, contact us at licensing at x264.com.
[09:11:14] <Dark_Shikari> now to update a gajillion license headers...
[09:11:30] <mru> perl ftw
[09:11:52] <Dark_Shikari> I figure I'll update the dates while we're at it.
[09:12:07] <Dark_Shikari> and maybe file descriptions too
[09:12:17] <mru> and the code
[09:12:24] <Dark_Shikari> lol
[09:12:31] <Dark_Shikari> that goes in a separate patch ;)
[09:12:50] <Dark_Shikari> god damn this is like poison
[09:12:57] <Dark_Shikari> I'm watching an h264 stream, in ogg, with VLC.
[09:13:19] <kierank> lol h.264 in ogg
[09:13:25] <Dark_Shikari> GomTV uses h264 in ogg
[09:13:51] <Dark_Shikari> for streaming, it doesn't work too badly really, considering that's what ogg was designed for
[09:14:01] <Dark_Shikari> and OGM actually specifies a consistent timestamp/etc mapping too
[09:19:27] <mru> ogg may have beed designed for streaming, but it's not suitable for it
[09:20:12] <kshishkov> well, at least nobody tries to transcode APE-in-MKV into Ogm
[09:22:21] * kshishkov hopes that nobody found a way to encapsulate APE in something else
[09:22:44] <Dark_Shikari> what's so atrocious about ape
[09:22:49] <mru> all of it
[09:23:06] <Dark_Shikari> be more specific
[09:23:14] <mru> 100%
[09:23:32] <Dark_Shikari> be more specific
[09:23:32] <kshishkov> for example, it packs data into 32-bit LSB words and frame boundaries are inside those words
[09:23:34] <Dark_Shikari> list things that are atrocious
[09:23:47] <mru> frame size is practically unbounded
[09:23:49] <kshishkov> 1280-point filter
[09:24:17] <kshishkov> mru: in practice it's rarely more than 10 seconds of audio though
[09:24:30] <mru> doesn't matter
[09:24:39] <mru> a decoder has to cope with the theoretical max
[09:24:55] <Dark_Shikari> you can have an h264 video be 1000000x10000000 too
[09:25:22] <mru> that's why profiles and levels exist
[09:25:49] <kshishkov> Dark_Shikari: and it has several things changed in version from 3.96 to 3.99 that alter bitstream reading and demuxing too
[09:25:57] <Dark_Shikari> those sound like lame version numbers
[09:26:17] <kshishkov> and they are lame
[09:27:15] <pJok> quite lame
[09:27:23] <pJok> god förmiddag, kshishkov :)
[09:27:32] <kshishkov> god dag, pJok
[09:29:09] <kshishkov> Dark_Shikari: well, and decoding 48 kHz audio may eat more CPU than decoding DVD-size H.264
[09:29:29] <Dark_Shikari> lol
[09:31:53] <kshishkov> here on i7 860 MPlayer reports using > 7% CPU
[09:52:38] <mru> so with this hdcp key being published, why are the internets all abuzz about bluray?
[09:52:46] <mru> it has fuck-all to do with bluray
[09:53:13] <mru> bluray discs are encrypted with aacs
[09:53:36] <kierank> because the blogosphere needs to simplify things
[09:53:38] <Dark_Shikari> mru: not quite
[09:53:46] <Dark_Shikari> it means that no matter WHAT they do to encrypt blu-ray
[09:53:51] <Dark_Shikari> even if they had a magical unbreakable copy protection
[09:53:55] <Dark_Shikari> you can still rip them with no quality loss
[09:53:57] <Dark_Shikari> and they CANNOT patch hdcp
[09:54:14] <Dark_Shikari> they can update the JVM protection shit on blu-ray, and there are no open source cracks for it that are up-to-date
[09:54:23] <Dark_Shikari> so it's just a neverending war
[09:54:37] <Dark_Shikari> of course, it's a war they are consistently losing
[09:54:40] <mru> the hdcp key lets you build an unauthorised hdcp sink
[09:54:41] <Dark_Shikari> but nevertheless a war
[09:55:27] <mru> the bloggers are rambling about how it will affect bluray _players_
[09:56:03] <Dark_Shikari> bloggers are stupid?  call the presses
[09:56:24] <mru> having the hdcp key doesn't help you decode the aacs
[09:56:36] <mru> which is what they general assumption seems to be
[09:57:02] <iive> some time ago they talked about analog hole, and how you can record anything that is analog.
[09:57:35] <mru> yes, but that's gone now
[09:57:39] <iive> HDCP master key is just restoring digital output to their analog counterparts.
[09:57:46] <mru> errr no
[09:57:49] <iive> key leaking.
[09:58:20] <iive> of course, not so simple...
[09:58:24] <mru> if you have the master key, you can build your own hdcp receiver
[09:58:48] <Dark_Shikari> now the real question is
[09:58:50] <Dark_Shikari> was it leaked?
[09:58:51] <Dark_Shikari> or was it derived?
[09:58:59] <iive> yes, intel confirmed it.
[09:59:07] <iive> oh
[09:59:08] <mru> collecting the 40-odd devices keys needed can't be that hard
[09:59:23] <Dark_Shikari> mru: but it could have been leaked too
[09:59:26] <Dark_Shikari> i.e. both are perfectly possible
[09:59:27] <mru> it could have
[09:59:40] <iive> actually, i'm surprised it took them this long.
[09:59:42] <Dark_Shikari> the theory I had is that it was leaked AGES ago.... but they intentionally waited to release it
[09:59:44] <mru> but I doubt there were many people with access to the master
[09:59:46] <Dark_Shikari> Or was derived ages ago
[09:59:54] <Dark_Shikari> in order to ensure that HDCP became mainstream first
[09:59:58] <Dark_Shikari> So that they couldn't back out and change it.
[10:00:06] <Dark_Shikari> this happened with DVD CSS as well.
[10:01:44] <mru> nevertheless, this publication isn't going to change anything overnight
[10:02:00] <Dark_Shikari> of course
[10:02:04] <mru> building an hdcp receiver is hard regardless
[10:02:09] <Dark_Shikari> except perhaps reduce confidence in the copy protection
[10:02:25] <Dark_Shikari> I absolutely love intel's response though
[10:02:30] <Dark_Shikari> "
[10:02:35] <Dark_Shikari> "you need it in silicon, so it's not a threat!"
[10:02:37] <mru> it's probably easier to modify an existing display and extract the signals
[10:02:48] <Dark_Shikari> Because pirates have never made custom chips before to break copy protection.
[10:02:52] <Dark_Shikari> You know, some kind of... "mod chip".
[10:02:59] <Dark_Shikari> And of course, because FPGAs don't exist.
[10:03:13] <mru> many mod chips are just a small flash or eeprom
[10:03:15] <mru> not the case here
[10:03:24] * kshishkov has never heard about illegally decoding satellite signal
[10:03:29] <mru> you're processing 3Gbps of data
[10:03:31] <Dark_Shikari> still, you can order a chip from shenzhen and get it in a week
[10:03:36] <Dark_Shikari> for cheap
[10:03:42] <mru> an fpga can easily handle it
[10:03:44] <Dark_Shikari> or just grab a Spartan III
[10:03:47] <Dark_Shikari> yeah, fpgas are plenty
[10:03:50] <merbzt> when I play a file from http I get lousy performace, but when I play from harddrive it works perfectly, how do I find the code that takes up all the time ?
[10:03:56] <Dark_Shikari> oprofile
[10:04:13] <twnqx> <Dark_Shikari> or just grab a Spartan III <-- spartan 3 can't deserialize 3gbit
[10:04:22] <Dark_Shikari> really?  it's that bad?
[10:04:26] <iive> you don't have to build your own hdcp receiver, you can use ready one. The only problem is that once you put the key you can't change it.
[10:04:27] <mru> but it's still not something you can simply download of the net
[10:04:33] <Dark_Shikari> mru: but that doesn't matter
[10:04:33] <twnqx> it doesn't have hardware deseiralizer
[10:04:35] <iive> so put the chip on socket.
[10:04:40] <twnqx> you'll need a spartan 6 :P
[10:04:41] <merbzt> Dark_Shikari: ok, did a profile, how do I get a time spent in functions report ?
[10:04:49] <Dark_Shikari> merbzt: opreport
[10:04:50] <kshishkov> opreport
[10:04:54] <mru> opreport -l
[10:04:58] <Dark_Shikari> mru: the "pirate" rips the disc to a file
[10:05:03] <Dark_Shikari> then normal users download and play
[10:05:04] <thresh> heard of dbus in lunix kernel by the very same guys who brought us pulseaudio, gstreamer and telepathy?
[10:05:09] <Dark_Shikari> the ripping can be arbitrarily difficult; the pirate doesn't care
[10:05:10] <mru> Dark_Shikari: yes, yes, I know
[10:05:13] <Dark_Shikari> nor do the users, etc
[10:05:37] <mru> but if all it takes to become a pirate is a piece of software, there will be many pirates
[10:05:50] <kshishkov> thresh: the last bit actually sounds useful in customer support
[10:05:53] <mru> if custom hardware is required, there will be fewer
[10:05:57] <Dark_Shikari> mru: there need only be one
[10:06:08] <Dark_Shikari> also, pirates love their exclusiveness.
[10:06:11] <mru> one pirate can't possibly rip every bluray and tv show
[10:06:17] <iive> don't worry, with new acta it would be illegal to create such software in first place, worldwide.
[10:06:25] <Dark_Shikari> iive: nobody cares
[10:06:39] <Dark_Shikari> as in, you can make pot illegal, but people will still get high.
[10:06:39] <merbzt> did that and I'm just getting bogus data :/
[10:06:45] <mru> but the main point is still, bluray is being ripped already
[10:06:45] <Dark_Shikari> merbzt: opreport -l ffmpeg
[10:06:47] <mru> so nothing changes
[10:06:49] <Dark_Shikari> mru: of course.
[10:07:01] <Dark_Shikari> it matters more from a business/marketing standpoint for copy protection
[10:07:13] <mru> it's getting more attention than it deserves
[10:07:13] <Dark_Shikari> it means that they can no longer validly claim "if our copy protection works, users cannot rip the video"
[10:07:34] <Dark_Shikari> it's not getting nearly as much attention as the aacs crack got
[10:07:40] <Dark_Shikari> you just don't remember how much attention *that* got =p
[10:08:05] <kshishkov> 2F 11 whatever
[10:08:14] <Dark_Shikari> 09 etc
[10:08:28] <mru> f00fc7c8
[10:10:33] <merbzt> Dark_Shikari: how can I include time waiting in external libs and subsystem ?
[10:10:43] <mru> waiting?
[10:10:48] <Dark_Shikari> hmm, that might be hard
[10:10:51] <Dark_Shikari> oprofile only counts time doing things
[10:10:53] <Dark_Shikari> intentionally so
[10:11:03] <Dark_Shikari> it can profile the kernel, but I don't think it can catch waiting
[10:11:20] <mru> it can count many different events
[10:11:27] <mru> but not lack of events
[10:11:42] <mru> what instruction was executing when this didn't happen?
[10:11:56] <merbzt> mru: yes, something in the http code makes it dead slow
[10:12:14] <mru> is it blocking on something?
[10:12:15] <lu_zero> merbzt: your kernel is recent enough to use perf?
[10:12:39] <thresh> kshishkov: indeed if it was it...
[10:12:45] <merbzt> lu_zero: ubuntu lucid
[10:12:54] <mru> does cpu load shoot up?
[10:12:59] <merbzt> mru: no
[10:12:59] <mru> if so, it can be measured
[10:13:03] <mru> oh
[10:13:14] <mru> then you need to find out where it's blocking
[10:14:40] <mru> hmm, set up a period timer, in the signal handler fork() and dump core
[10:14:58] <merbzt> yeah, I know that's why I tried with profiling, but I guess it only counts cpu cycles
[10:15:19] <KotH> does anyone have a good idea how i can get rid of a "Backtrace stopped: frame did not save the PC" in gdb backtrace, i already compile with -g3 -O0. google doesnt say anything usefull
[10:15:21] <mru> if it's sleeping/blocking a lot, the core files will show a pattern
[10:15:50] <mru> KotH: did you use -fomit-frame-pointer or such flags?
[10:15:58] <KotH> nope
[10:16:05] <mru> first frame?
[10:16:19] <lu_zero> KotH: use valgrind
[10:16:26] <KotH> mru: what do you mean by first frame?
[10:16:34] <mru> does it stop on the first frame?
[10:16:43] <mru> or does it print a few frames before stopping?
[10:16:45] <KotH> nope
[10:16:49] <mru> no what?
[10:17:02] <lu_zero> merbzt: https://perf.wiki.kernel.org/index.php/Main_Page
[10:17:08] <KotH> it stops at teh first frame that enters my code (everything else is libc)
[10:17:21] <KotH> #29 0xb76df7f4 in ?? () from /lib/i686/cmov/libc.so.6
[10:17:21] <KotH> #30 0x30a7ced0 in ?? ()
[10:17:23] <KotH> [..]
[10:17:24] <lu_zero> KotH: on a break or on a segfault?
[10:17:28] <KotH> #37 0x08056f8b in SQL_freeFileInfo (info=0x80588f0) at sqlitelist.c:352
[10:17:38] <KotH> lu_zero: free of invalid pointer
[10:17:52] <mru> valgrind
[10:17:55] <lu_zero> wonderful
[10:17:56] <KotH> *** glibc detected *** /root/unl/UNL_sender: munmap_chunk(): invalid pointer: 0x080588f0 ***
[10:18:07] <lu_zero> definitely valgrind is your friend ^^
[10:18:09] <KotH> ok
[10:18:10] <KotH> thanks boys
[10:18:31] * KotH wonders why that error didnt apear on the old system
[10:18:38] <mru> random chance
[10:18:43] <KotH> probably
[10:18:52] <lu_zero> newer libc ?
[10:19:12] <iive> merbzt: maybe callgrid could help with that?
[10:19:37] <iive> callgrind, it's tool from valgrind
[10:20:01] <KotH> lu_zero: definitly. teh old system was running a debian version so old, that the repo servers do not have it anymore
[10:20:31] <lu_zero> then the libc might have caught it now by themselves
[10:20:37] <KotH> juup
[10:22:11] <merbzt> iive: I tried that already, no help
[10:23:31] <mru> merbzt: you need something that samples the current location periodically even when the process is blocked
[10:25:21] <merbzt> mru: yeah, no off the shelf solution for that ?
[10:25:29] <mru> can't think of one
[10:25:44] <mru> other than said periodic core dump
[10:26:56] <Dark_Shikari> I got an image of a periodic table of core dumps when you said that
[10:28:20] <iive> i thought this is how oprofile works
[10:28:20] <mru> oprofile counts events
[10:28:20] <mru> events occur only when something is doing something
[10:29:08] <Dark_Shikari> mru: hmm, random question re licenses
[10:29:13] <Dark_Shikari> in x264, we have your asm.S of course for the neon
[10:29:14] <iive> merbzt: can you pastebin the result of callgrind?
[10:29:17] <Dark_Shikari> this is LGPL of course
[10:29:20] <Dark_Shikari> it says in the license header
[10:29:21] <Dark_Shikari>  * You should have received a copy of the GNU Lesser General Public
[10:29:21] <Dark_Shikari>  * License along with FFmpeg
[10:29:29] <mru> Dark_Shikari: the one I wrote?
[10:29:31] <Dark_Shikari> does this mean we have to include the LGPL with x264 too?
[10:29:39] <mru> license that as you please
[10:29:43] <mru> I don't care
[10:29:48] <Dark_Shikari> k, I'll just stick it as GPL then
[10:29:58] <Dark_Shikari> If you want to make it more powerful/general, you could do something like what we did with x86inc.asm
[10:30:02] <Dark_Shikari> which we BSD'd
[10:30:11] <Dark_Shikari> so everyone can use it (and so nobody has an excuse for awful inline asm)
[10:30:18] <merbzt> iive: I end up in h264 decoder code, I know that isn't blocking
[10:30:25] <merbzt> I think I found a way now
[10:33:57] <merbzt> did as mru said, but I just ran the process under a debugger and interrupted it from time to time
[10:33:57] <mru> I was afraid that would interfere too much with the timing
[10:34:13] <mru> the fork and core trick can be quite useful in such cases
[10:34:47] <merbzt> tcp_open is called alot of times
[10:35:03] <merbzt> and getaddrinfo takes 6 seconds each time
[10:35:08] <mru> whoa
[10:35:21] <mru> both of those sound wrong
[10:35:41] <mru> why does it call tcp_open repeatedly?
[10:36:13] <merbzt> not sure, but I have a guess
[10:36:29] <merbzt> the 3gp file I have is a fragmented file
[10:36:33] <mru> and why does getaddrinfo take so long?
[10:36:43] <mru> still shouldn't need to reopen
[10:36:45] <merbzt> crappy net I think
[10:36:57] <mru> do all hostname lookups take that long?
[10:37:20] <kierank> merbzt: have you run it under strace?
[10:38:11] <iive> getaddrinfo probably have something to do with dns?
[10:38:21] <mru> dns shouldn't be that slow
[10:38:34] <merbzt> the fragmented file has all track 1 data in one chunk followed by the track 2 data
[10:38:54] <merbzt> thus when getting packets one has to seek alot
[10:39:09] <mru> yes, but that doesn't mean it needs to reopen the socket
[10:39:31] <kshishkov> mru: it can happen when, say, first nameserver in /etc/resolv.conf is dead
[10:39:46] <mru> that's pebkac imo
[10:40:05] <merbzt> Query time: 3464 msec
[10:40:18] <merbzt> dns lookup with dig
[10:40:22] <mru> what crappy name server are you using?
[10:40:25] <cartman> :D
[10:40:40] <mru> does it take that long for all hostnames?
[10:40:44] <mru> or just some?
[10:40:54] <merbzt> oh, it's just the network of a major network company
[10:41:04] <mru> what hostname did you look up?
[10:41:34] <merbzt> dig cnn.com -> Query time: 3214 msec
[10:41:44] <cartman> ;; Query time: 71 msec
[10:41:45] <mru> Query time: 393 msec
[10:41:47] <cartman> really bad dns
[10:41:51] <mru> Query time: 0 msec
[10:41:57] <mru> cached now
[10:41:59] <merbzt> I think I'm routed through the uk
[10:42:20] <mru> this was querying the nameserver under the sofa
[10:43:07] <mru> in the uk
[10:44:45] <merbzt> kierank: strace gives alot slow connects()
[10:45:44] <kshishkov> well, add that host to /etc/hosts and try again
[10:52:51] <merbzt> yey with that I get a stable 2 fps
[10:53:10] <merbzt> my bad a stable 1 fps
[10:53:37] <CIA-63> ffmpeg: ramiro * r25139 /trunk/configure:
[10:53:37] <CIA-63> ffmpeg: configure: print minimum lame version number required after revision 25128
[10:53:37] <CIA-63> ffmpeg: Patch by James Darnley <james dot darnley at gmail dot com>.
[10:54:58] <kshishkov> now make it reuse connection
[11:15:08] <merbzt> ok, who knows most of the http code ?
[11:15:27] <merbzt> the comments aren't really helping
[11:16:32] <mru> read code, not comments
[11:16:47] <mru> btw, clang/freebsd seems unhappy
[11:17:50] <cartman> mru: clang bug
[11:17:54] <cartman> fixed in trunk
[11:18:16] <cartman> mru: http://llvm.org/bugs/show_bug.cgi?id=8154 fwiw
[11:18:54] <mru> guess he needs to update clang on that machine again
[11:21:21] <merbzt> mru: well I guess I have to
[11:24:13] <lu_zero> merbzt: did you spot the issue/issues?
[11:24:23] * lu_zero is digging in librtmp right now
[11:25:18] <lu_zero> hyc: the gnu-coding style is compulsory for contribution?
[11:28:21] <merbzt> lu_zero: not really, but I think it has to do with the funky interleaving
[11:30:44] <Dark_Shikari> siretart: when do you want me to give you an x264 version for maverick?
[11:51:13] <merbzt> hmm, the demuxer seeks from 100k back to 20k and then forward to 100k again
[11:51:30] <merbzt> I think that is killing the performance of the buffer system
[11:51:51] <kshishkov> quite possible, yes
[11:52:34] <merbzt> causing it to call url_fseek() instead of using cached data
[11:54:52] <lu_zero> so the cure would be having a configurable cache and let you set it for something large
[11:55:06] <lu_zero> or you want a smarter cache?
[11:55:59] <mru> 2-way set associative should do it
[11:56:52] <lu_zero> mru: you forgot predictive
[11:57:45] <lu_zero> merbzt: that happens many times btw?
[11:58:42] <merbzt> what ?
[12:00:02] <lu_zero> seek back and forth with that pattern
[12:25:05] <Compn> http://spaceweather.com/
[12:25:15] <CIA-63> ffmpeg: rbultje * r25140 /trunk/libavcodec/x86/dsputilenc_yasm.asm: Don't access upper 32 bits of a 32-bit int on 64-bit systems.
[12:27:42] <funman> Compn: jupiter is incredibly bright Oo
[12:28:20] <KotH> Compn: sunny, no clouds and a light asteroid shower in the afternoon ?
[12:29:24] <Compn> KotH : every 10 years we get a peak of solar flares.
[12:29:34] <mru> KotH: there's wind in space
[12:29:36] <mru> solar wind
[12:30:02] <funman> and rainbows at night. next what, unicorns?
[12:30:09] <BBB> ponies
[12:30:14] <Compn> double rainbows...
[12:30:22] <Compn> would be next
[12:30:41] <mru> Compn: never seen a double rainbow?
[12:30:54] <Compn> maybe once a long time ago
[12:30:58] <mru> how about a purple cow?
[12:31:08] <Compn> i ate a purple carrot yesterday
[12:31:08] <mru> I've never seen a purple cow
[12:31:16] <mru> I hope I'll never see one
[12:31:22] <mru> but I can tell you here and now
[12:31:26] <funman> mru: do you ski?
[12:31:27] <mru> I'd rather see than be one
[12:31:32] <mru> funman: no
[12:32:01] <funman> http://5f.img.v4.skyrock.net/5f9/loulavache/pics/441881633_small.jpg you don't know what you miss!
[12:32:24] <cartman> I can eat that cow
[12:33:12] <funman> so ♃ and ♅ are in ☍ .. nice
[12:33:15] * BBB throws a penny for a beer
[12:33:39] * KotH wonders whether BBB meant a purple bear
[12:33:56] <BBB> pink gummybeer
[12:36:05] <kshishkov> BBB: while you may be proud as a Dutch, it was Swiss guy who discovered LSD
[12:36:19] <BBB> kshishkov: how's wvp2 going?
[12:36:53] <BBB> and in all reality, how's your new job anyway? I have no idea where you work now :-p
[12:37:21] <mru> he's at the desk next to mine
[12:37:38] <mru> staring at code by the looks of it
[12:38:05] <kshishkov> BBB: mostly REing codec from reference source
[12:38:19] <kshishkov> (so it's almost dream job)
[12:39:05] <Dark_Shikari> "reference source"?
[12:39:06] <Dark_Shikari> SOURCE?
[12:39:08] <KotH> kshishkov: friend of mine dated the daughter of said guy ;)
[12:39:54] <kshishkov> Dark_Shikari: yes, small pieces of it gave mru few facepalms already
[12:40:15] <spaam> KotH: so you have some LSD at home? ;D
[12:40:24] <spaam> that will explain a lot..
[12:40:48] <kshishkov> spaam: why do you think he praises Swiss chocolate?
[12:40:57] <KotH> spaam: producing lsd is quite easy, anyone with a kitchen can do that
[12:41:02] <BBB> source does not count as RE'ing
[12:41:04] <BBB> it's like cheating
[12:41:12] <BBB> yay make fate passed on win64
[12:41:13] <spaam> KotH: aha. so that is his code word.. :D
[12:41:13] <kshishkov> BBB: have you seen it?
[12:41:15] * BBB off to work now
[12:41:20] <BBB> kshishkov: what codec is it?
[12:41:28] <kshishkov> DTS-HD
[12:41:46] <BBB> oh that must be well-written
[12:41:50] <BBB> isn't that committee-designed?
[12:41:53] <BBB> :-p
[12:41:56] * BBB off to work
[12:41:59] <BBB> bbl
[12:42:14] <kshishkov> well, it looks like that sometimes
[12:43:31] <lu_zero> kshishkov: indian-implemented with chinese comments in non utf-8 encoding?
[12:44:08] <kshishkov> lu_zero: chinese-implemented with comments full of typos
[12:46:20] <KotH> so, it is REing after all
[12:46:42] <Dark_Shikari> kshishkov: where did you get the source?
[12:47:06] <kshishkov> Dark_Shikari: none of my concern
[12:47:51] <Dark_Shikari> lol
[12:48:21] <kshishkov> really
[12:48:30] <Compn> does the re part come in when you find bugs in the implementation , like wma ?
[12:48:32] <Compn> ehe
[12:48:38] <lu_zero> it was from paper and you have to fix the ocr glitches?
[12:49:03] <Compn> btw did anyone ever report that error to microsoft ?
[12:49:09] <kshishkov> lu_zero: it's horrible C++ in million files
[12:49:30] <spaam> Compn: what kind of error was that? :)
[12:49:34] <lu_zero> C++ ooo
[12:49:41] <lu_zero> industry level code then
[12:50:00] <KotH> hehe
[12:50:20] * KotH always pisses people off when he says that he doesnt trust any code written by a company
[12:50:31] <kshishkov> mru likes this code
[12:50:49] <Compn> spaam : wma voice i think, let me find it
[12:51:07] <spaam> Compn: i will wait here for you :)
[12:51:30] <Compn> spaam : http://blogs.gnome.org/rbultje/2010/01/25/wmavoice-codec-dissection/
[12:53:53] <lu_zero> kshishkov: likes in which way?
[12:54:22] <kshishkov> lu_zero: see my description above
[12:55:20] <spaam> Compn: nice :)
[12:58:23] <kierank> kshishkov: do you have dts-lbr source as well ;)
[13:59:20] <Vitor1001> mru: Just wondering, have you ever tried adding the PGI compiler to FATE?
[13:59:32] <mru> pgi?
[13:59:33] <Vitor1001> http://www.pgroup.com
[14:00:19] <kshishkov> I wonder why they place Fortran first everywhere
[14:00:28] <mru> is it free of charge?
[14:00:31] <Vitor1001> I've tried it once, it does compile ffmpeg (I had to patch it a little), but doesn't pass tests
[14:00:33] <mru> kshishkov: HPC
[14:00:45] <Vitor1001> has some "trial download" blablah
[14:00:55] <mru> is it time-limited?
[14:01:05] <Vitor1001> kshishkov: People who do numerical calculations love fortran
[14:01:17] <Vitor1001> mru: I think yes, but I'll recheck
[14:01:19] <kshishkov> Vitor1001: I believe that
[14:01:36] <Vitor1001> kshishkov: Actually they love fortran77 :-p
[14:01:58] <kshishkov> yes, Fortran III is a bit outdated
[14:02:44] <KotH> why do people who do numerical calculations love fortran?
[14:03:00] <kshishkov> because it was intended for that work
[14:03:02] <mru> fortran is older than c
[14:03:17] <kshishkov> Fortran = FORmula TRANslator after all
[14:03:18] <merbzt> and it has a vector type IIRC
[14:03:40] <mru> and it doesn't have pointer aliasing problems
[14:04:02] <mru> or at least they're different from c
[14:04:13] <kshishkov> and old versions would drive Diego crazy since whitespaces were fully optional
[14:05:04] <KotH> driving diego crazy is easy
[14:05:08] <KotH> no challange in that
[14:05:23] <Vitor1001> KotH: Fortran does not have pointers, thus no problems with aligning or aliasing. It _might_ be faster than C and be easier to auto-vectorize
[14:05:53] <kshishkov> KotH: that language gave us "i" and "j" as loop variables
[14:05:54] <mru> it is faster if some nice assumption is safe that isn't valid in c
[14:05:57] <mru> and such cases exist
[14:06:12] <mru> becuase a-k were float originally
[14:06:31] <KotH> lol
[14:06:43] * KotH wonders who will remember this reason in 100 years
[14:07:01] <mru> a-h of course
[14:07:02] <kshishkov> hence that saying "god is real unless declared as int"
[14:07:10] <Vitor1001> mru: Time limited :-(
[14:07:18] <mru> crackable?
[14:07:19] * KotH wonders when there will be a "programming" section in archeology
[14:07:43] <Vitor1001> mru: Also a case where "asking nicely" might work. They give free academic licenses.
[14:07:43] * kshishkov gives KotH COBOL in case he discovers one
[14:07:44] <mru> Vitor1001: maybe they'd give us a licence if we asked
[14:09:33] <Vitor1001> mru: If they agree with giving a license, can you set up the conf? I don't have any servers I can run fate continuously...
[14:09:57] <mru> sure
[14:10:01] <KotH> kshishkov: thanks, c is arcane enough for my tastes
[14:10:16] <mru> KotH: apl?
[14:10:17] <Vitor1001> mru: BTW, the Compaq results are interesting. Failing, but with a good psnr...
[14:10:27] <kshishkov> KotH: but it's too new! Fortran is ~20 years older
[14:10:38] <Vitor1001> mru: I'll try to write a nice email to then soonish...
[14:10:38] <mru> Vitor1001: the ones that don't segv
[14:10:45] <Vitor1001> mru: of course
[14:10:57] <kshishkov> mru: you can write APL program only with your home keyboard
[14:11:26] <KotH> mru: ever seen an apl program in the wild?
[14:11:48] <kshishkov> KotH: I heard about functioning RDBMS written in APL
[14:12:00] <mru> Vitor1001: do you mean the vorbis ones?
[14:12:06] <KotH> kshishkov: i've seen rdbms written in basic
[14:12:06] <mru> they're crashing halfway through
[14:12:11] <mru> after outputting some good samples
[14:12:21] <superdump> fortran 77 syntax made my eyes bleed
[14:12:23] <Vitor1001> mru: No, I mean the non-crashing vsynth*
[14:12:30] <superdump> f90 and beyond was ok
[14:12:45] <mru> Vitor1001: only off by a little
[14:13:02] <superdump> and it seems to deal with algorithmic precision issues better than C, at least from my experiments with determinants
[14:13:22] <superdump> but i was a complete newb programmer then, so i probably did something stupid
[14:13:22] <Vitor1001> mru: might be related with float usage in libavforrmat/mpegenc.c...
[14:14:07] <Vitor1001> mru: The vorbis ones looks easy to at least see in which line it is FPE'ing...
[14:14:24] <mru> maybe
[14:14:31] <mru> FPE might not be what you think
[14:14:50] <mru> and gdb often crashes when loading apps compiled by non-gcc
[14:15:07] <Vitor1001> :p
[14:15:47] <mru> that compiler also hates modern glibc and binutils with a vengeance
[14:16:03] <mru> some of those crashers could be bugs related to that
[14:16:03] <kshishkov> maybe it has a good reason
[14:16:16] <mru> I should get tru64 running on the other alpha
[14:17:04] <kshishkov> but not now :P
[14:18:41] <mru> impossible before I get back to the uk
[14:18:51] <kshishkov> that's what I implied
[14:40:48] <Vitor1001> mru: Since you are a pro of compiler politics, do you have any opinion: http://ffmpeg.pastebin.org/941726 ?
[14:41:30] <kshishkov> uhm, capitalize Firefox?
[14:42:22] <Vitor1001> kshishkov: fine
[14:59:04] <KotH> Vitor1001: you doubled  "our" in line 5
[15:17:42] <Vitor1001> KotH: Thanks
[15:35:06] <Compn> Vitor1001 : html5-enable > html5-enabled
[15:35:24] <Vitor1001> Compn: Thanks, I had already spotted that ;)
[15:35:52] <Compn> whats this new compiler anyways? :P
[15:36:35] <Vitor1001> Compn: One of these new auto-parallelizing one
[15:39:35] <Compnn> heh
[15:39:35] <Compnn> >tracert google.com
[15:39:35] <Compnn> reports: Destination host unreachable.
[15:39:35] <Compnn> think my isp is having the problems
[16:16:36] <BBB> IT'S GREEN!!!11223
[16:16:55] <BBB> what build sys shall I use as an excuse to not work on xvp8 now...
[16:17:35] <elenril> doing actual work is more fun than trolling xiph?
[16:17:41] * elenril wonders what's wrong with BBB 
[16:23:52] <BBB> :-p
[16:26:29] <BBB> mru: can you kick the owner of http://fate.ffmpeg.org/i686-pc-cygwin-gcc-4.2/20100902152935 to replace the hardware?
[16:27:16] * mru kicks ramiro
[16:28:37] <Vitor1001> BBB: Congrats for the w64 fix
[16:28:43] <Vitor1001> BBB: That was a hard one
[16:28:45] <BBB> thanks
[16:28:51] <BBB> I'm starting to get good at this kind of shit
[16:28:56] <Vitor1001> ;)
[16:29:08] <BBB> which means I should stop doing it and learn a new trick
[16:29:25] <BBB> although I thinks there's some easy h264-related optimizations left to be done
[16:29:32] <BBB> I should write down what they are so I don't forget
[16:38:06] <lu_zero> =)
[16:43:38] <lu_zero> BBB: btw what's the status of xvp8?
[16:46:03] * BBB wonders how kick works
[16:46:09] * BBB looks @ lu_zero
[16:46:17] <BBB> they say practice makes perfect
[16:46:20] <BBB> ...
[16:46:22] <BBB> hmm...
[19:34:54] <CIA-63> ffmpeg: vitor * r25141 /trunk/libavcodec/sipr.c: Remove pointless semicolon
[19:37:25] <Dark_Shikari> BBB / mru
[19:37:31] <Dark_Shikari> 01:08 < pengvado> do you think it would matter if I did the committing and threatened to fork libavfilter if people complain?
[19:37:34] <Dark_Shikari> :)
[19:37:43] <mru> of what?
[19:37:50] <Dark_Shikari> hqdn3d, yadif, etc
[19:37:54] <Dark_Shikari> i.e. actually useful filters
[19:38:01] <mru> no commits without reviews
[19:38:07] <Dark_Shikari> they're already reviewed in mencoder.
[19:38:15] <mru> doesn't count
[19:38:20] <Dark_Shikari> And they've been reviewed
[19:38:21] <Dark_Shikari> about 50 times
[19:38:23] <mru> there's piles of shitty code there
[19:38:24] <Dark_Shikari> they're just stuck in bikeshed land
[19:38:27] <Dark_Shikari> see the ML
[19:38:34] <Dark_Shikari> Odds are they will get into x264 before they get into ffmpeg
[19:38:45] <mru> the yaif that was posted on ml is not fit for commit
[19:38:52] <mru> yadif
[19:39:01] <mru> the rest have not been posted
[19:39:25] <Dark_Shikari> my point stands.  x264 is going to have a working filter system before lavf does.
[19:39:39] <mru> it's an untidy mess of mixed C and x86 asm
[19:39:41] <Dark_Shikari> siretart: ping again
[19:39:48] <Dark_Shikari> Oh yeah, I agree. it's pretty horrible
[19:39:50] <mru> _all_ asm must go in arch/ dirs
[19:39:56] <Dark_Shikari> I required that the contributor at least fix the syntax
[19:40:16] <mru> otherwise we'll end up with a new swscale
[19:40:22] <mru> and I'm not having that
[19:44:44] <lu_zero> avfilter has yet another problem.
[19:44:57] <mru> it has many
[19:45:01] <lu_zero> right now it breaks a fringe but significant usage of ffmpeg...
[19:46:24] <spaam> you all complain about it. why not fix those problems? :)
[19:46:41] <Dark_Shikari> because it's easier to make a new one
[19:46:48] <mru> nobody understands how it'ss meant to work
[19:47:11] <Dark_Shikari> x264's filter system goal is to make the first basic video filtering system that works internally in a high enough bit depth to not be shit
[19:47:19] <Dark_Shikari> and then if we're lucky, we can go encode in high bit depth too
[19:47:22] <Dark_Shikari> and then we can fix lavc to decode it
[19:47:23] <spaam> Dark_Shikari: then do it ? :)
[19:47:28] <Dark_Shikari> and then we can switch the entire world over to 10-bit.
[19:47:32] <Dark_Shikari> and then BANDING IS DEAD, FOREVER
[19:47:42] <cartman> Dark_Shikari: x264 getting filtering system? Are you forking ffmpeg? :p
[19:47:42] <mru> libavfilter is a good example of overengineering
[19:48:04] <Dark_Shikari> cartman: we announced that a year ago
[19:48:07] <Dark_Shikari> it already has a filtering system
[19:48:09] <Dark_Shikari> we're just making it better
[19:48:16] <spaam> mru: who came first with the idea about it ?
[19:48:17] <Dark_Shikari> we're going to have to write a downsampling/dither module since swscale doesn't have one
[19:48:20] <spaam> michael+
[19:48:20] <spaam> ?
[19:48:25] <cartman> uhm also I noticed it can optionally use ffmpeg too
[19:48:31] <cartman> cyclic dependency makes me dizzy
[19:48:53] <Dark_Shikari> that's the point
[19:48:56] <Dark_Shikari> it uses ffmpeg for swscale
[19:49:01] <Dark_Shikari> since even though swscale is a shitty wheel
[19:49:02] <BBB> Dark_Shikari: I'd prefer if pengvado helped make them fit
[19:49:05] <Dark_Shikari> reimplementing it is bad
[19:49:16] <cartman> Dark_Shikari: yeah cyclic dep. you got there
[19:49:19] <cartman> ffmpeg uses x264 too
[19:49:31] <BBB> Dark_Shikari: but unlike mru, if pengvado promises to help fix yadif after committing it, I'm fine with it being committed
[19:49:39] <BBB> Dark_Shikari: but I'll hold it against him if he ends up not fixing it
[19:49:46] <Dark_Shikari> cartman: it isn't really
[19:49:49] <Dark_Shikari> ffmpeg uses libx264
[19:49:51] <mru> I don't believe in fixing things later
[19:49:51] <Dark_Shikari> x264CLI uses ffmpeg
[19:49:54] <Dark_Shikari> x264CLI uses libx264
[19:50:16] <cartman> Dark_Shikari: Packagers are having a hard time figuring it out, I bet :)
[19:50:21] <mru> I know from experience that it never happens
[19:50:31] <mru> cartman: build one of them twice
[19:50:35] <Vitor1001> The problem with libavfilter is avoiding memcpy()
[19:50:41] <cartman> right
[19:50:49] <mru> libavfilter is very memcpy-happy
[19:51:01] <Vitor1001> how so?
[19:51:04] <mru> buffer_source does two copies per frame
[19:51:06] <Dark_Shikari> cartman: they already have to deal with this with many other apps
[19:51:07] <mru> TWO
[19:51:18] <Dark_Shikari> mru: IMO it's better to be inefficient than to be shit.
[19:51:25] <cartman> Dark_Shikari: I hate it, as a retired packager ;)
[19:51:31] <Dark_Shikari> Now, I agree it should be efficient when possible.
[19:51:31] <cartman> and I packaged thousands of stuff
[19:51:34] <mru> there is no excuse for copying raw video frames
[19:51:36] <mru> ever
[19:51:46] <Dark_Shikari> mru: well, btw, take for example how x264's works
[19:51:51] <Dark_Shikari> 1) get source frame
[19:52:02] <mru> x264 can have flaws too
[19:52:02] <Dark_Shikari> 2) if source frame is in a bizarre colorspace that the filter chain doesn't handle, convert it to one of the few allowed internal ones via swscale.
[19:52:04] <Vitor1001> mru: I only find one
[19:52:09] <Dark_Shikari> otherwise, don't copy anything, just pass it on.
[19:52:21] <Dark_Shikari> 3) apply the main filter chain to it.  no copies here unless necessary.
[19:52:27] <mru> Vitor1001: one on "input", one on output
[19:52:58] <Dark_Shikari> 4) apply the final swscale call.  iirc, this always copies.
[19:53:05] <Dark_Shikari> 4) is the only part that isn't 100% right imo
[19:53:18] <Dark_Shikari> "final call" ---> prepare it for the encoder
[19:53:26] <Dark_Shikari> since the filter chain can run in, say, 16-bit RGB, whereas the encoder can't do that.
[19:53:48] <Dark_Shikari> so we have the concept of "input picture", "picture being filtered", and "picture ready for the encoder".
[19:53:55] <Vitor1001> mru: One is in vsrc_buffer.c
[19:55:01] <Vitor1001> I don't find the other
[19:55:09] <Vitor1001> But I already dislike this one
[19:55:26] <mru> hmm, I guess I was mistaken
[19:55:36] <BBB> I'm tempted to say gstreamer does a better job at its core
[19:55:52] <BBB> it copies 10x more, but the core design allows to write a filterchain without memcpys
[19:56:21] <BBB> </flame>
[19:56:24] <mru> a turd is a turd even with a diamond core
[19:56:27] <Dark_Shikari> gstreamer isn't a bad idea, nor a bad design
[19:56:31] <Dark_Shikari> it evolved into a terrible system
[19:56:35] <Dark_Shikari> but neither the idea nor the design is wrong
[19:56:50] <Dark_Shikari> The biggest problem is the fact that most of the elements are shit, and require hacking IN THE FILTERCHAIN to make them work
[19:56:55] <Dark_Shikari> and there's no consistent set of rules that they abide by
[19:57:04] <BBB> sure there is
[19:57:07] <Dark_Shikari> e.g. "let's add queues after every single element until it stops breaking"
[19:57:09] <BBB> if it works in gst-launch, it's golden
[19:57:10] <BBB> :-p
[19:57:21] <Dark_Shikari> no, if it works in gst-launch with arbitrary-length queues after every element
[19:57:28] <Dark_Shikari> get it right
[19:57:31] <BBB> haha :)
[19:58:35] <Dark_Shikari> The best part was how rc-lookahead in x264 broke gstreamer
[19:58:40] <Dark_Shikari> because they assumed no element would have a delay over 1 second
[20:02:35] <lu_zero> why that assumption?
[20:03:11] <mru> lack of imagination
[20:07:05] <lu_zero> uhm
[20:10:54] <Dark_Shikari> how does one svn revert an svn delete?
[20:11:20] <mru> no idea
[20:13:33] <funman> you just said how
[20:13:55] <cartman> Dark_Shikari: svn rm? svn cp -r$existing_rev
[20:14:39] <Dark_Shikari> svn revert -R directory
[20:14:42] <Dark_Shikari> is how you do it, apparently
[20:15:23] <CIA-63> ffmpeg: darkshikari * r25142 /trunk/ffpresets/ (6 files):
[20:15:23] <CIA-63> ffmpeg: Remove legacy x264 presets
[20:15:23] <CIA-63> ffmpeg: Since we now have the official x264 presets in ffmpeg, there's no reason to
[20:15:23] <CIA-63> ffmpeg: keep around the old ones.
[20:15:23] <CIA-63> ffmpeg: Patch by Lou Logan <lou AT fakeoutdoorsman DOT com>.
[20:15:26] <cartman> thats if you didn't commit it
[20:26:06] <jannau> fast update for the merged git tree implemeted. rewriting the commit author based on commit message is no problem in principle
[20:27:19] <jannau> the current tree has a fix for the commits michael did with arpi's account
[20:43:10] <lu_zero> \o/
[21:00:30] <BBB> jannau: that's cool, great work
[21:00:34] <BBB> let's get moving to git :)
[21:08:34] <jannau> BBB: that's the intention of this
[21:08:50] <BBB> what's your eta?
[21:09:32] <jannau> BBB: do you want to have your full name and email in the git history?
[21:13:35] <jannau> I think the current tree is pretty good (except missing metadata changes). someobdy else should review the script.
[21:16:02] <jannau> it needs a firm decission to switch and somebody (probably mru) to setup a full blown (pushable) git setup
[21:23:40] <siretart> Dark_Shikari: regarding x264 for maverick: about 3 months too late, sorry. but a good version for natty would be cool!
[21:29:52] <BBB> jannau: I don't mind either way, whichever is easier
[21:33:00] <Dark_Shikari> siretart: what?
[21:33:04] <Dark_Shikari> the freeze was just a day or two ago
[21:33:14] <Dark_Shikari> this is the same point on the timeline as you did for lucid
[21:33:24] <Dark_Shikari> Don't you have to pick a version at some point?
[21:34:31] <jannau> BBB: fixups is to insert a single line into the script. The only reason why I haven't done it for all committers is that I'm unsure how impolite it is to expose email addresses
[21:34:59] <jannau> but given the current feedback I should have asked who's against it
[21:42:12] <siretart> Dark_Shikari: the freeze was on June, 17
[21:42:30] <siretart> Dark_Shikari: cf. https://wiki.ubuntu.com/MaverickReleaseSchedule
[21:42:43] <_troll_> gotta freeze early to ensure everything is suitably outdated by release
[21:43:02] <siretart> err, sorry, it was August 12. /me just got home, tired
[21:51:49] <kierank> _troll_, lol
[21:54:18] <_troll_> hmm...
[21:54:26] <_troll_> "Under the terms of the PGI evaluation license agreement, a given user is permitted to generate 15 day trial license keys every six months"
[21:55:11] <kierank> so basically you need 24 alter egos
[21:55:27] <ohsix> or 24 gmail labels
[21:55:49] <Dark_Shikari> siretart: then can we at least pick a revision from back then that works?
[21:55:49] <_troll_> 24?
[21:55:51] <_troll_> 13
[21:56:00] <Dark_Shikari> Also, last year, you asked for the version WAY past the feature freeze
[21:56:07] <Dark_Shikari> you specifically told me that the feature freeze didn't matter for 3rd party apps
[21:56:31] <Dark_Shikari> I mean, arbitrarily picking a revision without consulting devs is probably a bad idea
[21:56:35] <_troll_> or you can just bypass the licence entirely
[21:56:38] <_troll_> can't be hard
[21:56:53] <_troll_> it uses flexlm
[21:57:00] <_troll_> all you need to do is fudge the date
[21:57:01] <ohsix> Dark_Shikari: they backport fixes anyways
[21:57:06] <Dark_Shikari> ohsix: no they don't
[21:57:17] <ohsix> ehhh
[21:57:51] <kierank> what are the portland group famous for, they sound familiar
[21:58:01] <_troll_> probably something sinister
[21:58:01] <ohsix> that fancy compiler
[21:58:13] <_troll_> all "foo group" organisations are sinister
[21:58:26] <_troll_> especially those named after a place
[21:58:59] <ohsix> and it could be portland oregon or portland maine! *conspiracy*
[21:59:36] <_troll_> or portland, england
[22:18:51] * _troll_ notices suncc/x86_64 on fate
[22:35:44] <BBB> mru: looks good no?
[22:36:42] <mru> yes
[22:36:55] <mru> curious that it fails on 32-bit
[22:39:42] <BBB> in general fate looks quite good nowadays