[FFmpeg-devel-irc] IRC log for 2010-02-01

[irc at mansr.com]

[00:02:15] <sab> how can I change my nick? I see sab is already taken
[00:02:24] <sab> (i mean registered)
[00:02:36] <mru> /nick
[00:02:53] <sab> oh i see
[00:03:13] <ramiro> mru: what's the topic on reddit?
[00:03:21] <mru> http://www.reddit.com/r/programming/comments/aw6vo/even_the_best_compilers_are_still_no_match_for_a/
[00:08:21] <sab> nick stefano
[00:08:27] <sab> oops
[00:19:39] <CIA-17> ffmpeg: michael * r21580 /trunk/libavcodec/options.c:
[00:19:39] <CIA-17> ffmpeg: Set reordered_opaque during context alloc by default to AV_NOPTS_VALUE.
[00:19:39] <CIA-17> ffmpeg: This should make sure that pictures allocated prior to avcodec_decode_video()
[00:19:39] <CIA-17> ffmpeg: get AV_NOPTS_VALUE assigned.
[00:19:39] <iive> mru: does any compiler produce faster code if you have p[i].b++; instead of p[i].b+=a; ?
[00:20:17] <mru> don't know
[00:23:21] <iive> hum, in your hand written code, i think r2 is used without been filled.
[00:23:38] <mru> r2 is the function argument
[00:23:47] <iive> hum.
[00:23:52] <mru> the first four args are passed in r0-r3
[00:23:55] <iive> oh, i see
[00:24:01] <iive> i got confused by .a
[00:26:57] <DonDiego> gnite
[00:28:07] <saste> good night all!
[00:28:19] <Vitor1001> good night saste!
[00:29:38] <ramiro> saste: manchester?
[00:29:57] <ramiro> I thought you lived in italy
[00:30:05] <mru> ramiro: random server
[00:30:09] <ramiro> oh, right...
[00:30:19] <ramiro> it's freenode that has a server there.
[00:30:31] <mru> I'm apparently connected through paris
[00:31:07] <mru> saste: now register
[00:40:30] <ramiro> bye...
[00:49:45] <Yuvi> hm, how could an configure endian check work with llvm LTO?
[00:49:45] <Yuvi> -c with LTO implies llvm bitcode, which is always little endian and stores integer constants as variable length
[00:50:17] <mru> I guess it would break
[00:50:32] <mru> but it's not a problem
[00:50:40] <mru> the endian check is done before optimisation flags are added
[00:51:06] <Yuvi> but not before user cflags are added
[00:51:49] <mru> I'll have to think of something then
[00:52:06] <astrange> 1. forbid doing it 2. generate a program instead of an object 3. make llvm do hybrid LTO like gcc
[00:52:10] <astrange> ?
[00:52:24] <mru> 2 sounds like a good option
[02:56:04] <BBB> mru, can you ok my msg to ffmpeg-devel again?
[02:56:33] <mru> hmm, why was I expecting that?
[02:57:04] <mru> you might want to omit the huge tables in future patch postings
[02:58:03] <BBB> nobody said I could commit them
[02:58:17] <BBB> reply to the list and tell people to allow me to commit data...
[02:58:30] <mru> I meant omit them from the patch you post to the list
[02:58:37] <mru> nobody is going to be looking at them right now
[02:58:38] <BBB> hm... ok
[02:58:53] <BBB> next time I will
[03:05:20] <astrange> unsigned int acb_type:2; <- can you make enum types a bitfield and end up with the right layout?
[03:06:28] <mru> uh?
[03:06:58] <astrange> enum ACBType {ACB_TYPE_NONE,...}; ... ACBType acb_type:2;
[03:07:06] <mru> why would you want to do that?
[03:07:16] <mru> didn't we just agree that bitfields are bad?
[03:07:39] <mru> and the memory layout is unspecified
[03:08:39] <astrange> i was thinking of reading from a file using bitfield structs when i said that
[03:08:57] <mru> as I said, unspecified
[03:09:02] <astrange> but for local data just uint8_t is still better, yeah
[03:09:12] <mru> *never* read from a file or whatever into a struct
[03:09:47] <Vitor1001> BBB: the function aw_pulse_set2() still bothers me
[03:11:42] <Vitor1001> It takes as input five values: s->aw_first_pulse_off[block_idx], s->aw_pitch_range, s->aw_n_pulses[0], s->aw_next_pulse_off_cache and get_bits(gb, s->aw_n_pulses[0] ? 5 - 2 * block_idx : 4);
[03:11:59] <Vitor1001> and it output basically just start_off
[03:12:52] <CIA-17> ffmpeg: michael * r21581 /trunk/ffplay.c: 10l, forgot HAS_ARG, -drp segfaulted.
[03:13:12] <Vitor1001> for that, it uses a intermediary bit buffer, do a double for-loop (one outer one running up to 500 iterations)
[03:13:34] <BBB> Vitor1001, I agree it sucks, I unfortunately don't really understand the function
[03:13:49] <BBB> set1() was a mess also, multiple loops and double-loops, but I was able to sort of clear that up
[03:13:54] <BBB> and your comment made it even simpler
[03:14:03] <BBB> set2() sucks, and I don't quite get it :(
[03:14:19] <Vitor1001> set1() is nice now
[03:14:49] <mru> bedtime, it's pi o'clock here
[03:14:50] <BBB> you should look at the original :)
[03:15:08] <BBB> g'night mru
[03:15:12] <Vitor1001> I can imagine ;)
[03:15:34] <Vitor1001> About reimar's comments
[03:15:36] <Vitor1001> "> > I guess you can find all of those on your own. "
[03:15:50] <Vitor1001> He was talking about doxy comments inside functions
[03:16:02] <Vitor1001> it generates crazy nonsense doxy output
[03:16:50] <BBB> I noticed
[03:16:51] <BBB> the doxy looks weird
[03:16:59] <BBB> it looks nice in the code though
[03:17:05] <BBB> maybe I should remove them anyway...
[03:17:13] <Vitor1001> So what reimar suggested (and I agreed) is not to doxyfy them
[03:17:22] <BBB> ok, I'll go through the code
[03:17:36] <Vitor1001> And about finding the first non-zero bit
[03:18:15] <BBB> I suppose there's some hideous asm for that?
[03:18:16] <Vitor1001> You first find the first non-zero byte
[03:18:27] <BBB> they're ints, not bytes
[03:18:32] <Vitor1001> and them you use av_log()
[03:18:32] <BBB> you suggest I make them bytes first?
[03:18:35] <Vitor1001> Better yet.
[03:18:44] <Vitor1001> No. Just find the first non-zero int
[03:18:48] <Vitor1001> and av_log() it.
[03:19:07] <Vitor1001> should be more than 32x faster
[03:19:23] <astrange> i was going to complain about the use of 'double', but i guess that's already brought up
[03:19:34] <BBB> I will change it to float as I test all of them
[03:19:48] <BBB> I can make wmavoice float but it won't make a difference
[03:19:54] <BBB> lsf->lpc is still float
[03:19:57] <BBB> er, double
[03:20:02] <BBB> I want that function double first
[03:20:32] <BBB> and I need to test sipr, g729, acelp, etc. for that also
[03:20:38] <Vitor1001> sipr is ok
[03:20:42] <Vitor1001> g729 is fixed point
[03:20:51] <Vitor1001> acelp == sipr
[03:20:55] <BBB> well there was one where it was bad
[03:20:58] <BBB> qclep?
[03:20:59] <Vitor1001> QCELP
[03:20:59] <BBB> celp?
[03:21:03] <BBB> oh ok
[03:31:04] <astrange> +    s->lsp_q_mode        =  flags & 0x2000; <- !!(flags & 0x2000)
[03:31:09] <astrange> and the associated variable (and more) can be uint8_t
[03:32:24] <astrange> +        for (idx = pulse_start; idx < 0; idx += fcb->pitch_lag); <- space before ; (and in some other places)
[03:33:09] <astrange> and then lower down
[03:33:15] <astrange> +            int fac = ((n << 1) | 1); <- n * 2 + 1
[03:33:21] <astrange> that's enough for now
[03:36:10] <BBB> isn't n<<1|1 faster?
[03:36:44] <BBB> at least, isn't |1 faster than +1?
[03:36:46] <astrange> no
[03:36:49] <BBB> oh
[03:37:00] * BBB changes several useless occurrences of |1
[03:37:24] <BBB> is <<1 faster than *2?
[03:37:40] * BBB always thought shifts were faster than muls
[03:37:55] <astrange> on x86 n (<< 1)/(* 2) (+ 1)/(| 1) all compile to lea 1(%x,%x) so it's all the same
[03:38:40] <astrange> and << 1 is faster than * 2 but nearly any compiler will change it back
[03:38:51] <astrange> but n*2+1 needs less parens
[03:40:17] <BBB> !!(flags&0x2000)?
[03:40:19] <BBB> why that?
[03:40:28] <BBB> so it fits in a int8_t?
[03:40:30] <BBB> does that matter?
[03:40:36] <astrange> the comment for the var says it's [0,1]
[03:40:40] <astrange> flags & 0x2000 isn't 0,1
[03:40:50] <BBB> oh
[03:40:52] <BBB> hm...
[03:40:57] <BBB> shall I say [bool]?
[03:41:26] <astrange> you could put != 0 if you like that better
[03:41:39] <astrange> i think it's easier to read in a debugger if the bools are just 0,1
[03:42:27] * BBB doesn't really care
[03:42:37] <BBB> no more gdb for me on this one
[03:42:40] <BBB> I'll add !=
[03:42:42] <BBB> != 0
[03:44:02] <BBB> hm
[03:44:09] <BBB> I think I never tested with that flag set
[03:44:18] <BBB> I just see I use the second one as a table index
[03:44:21] <BBB> so [0] or [0x4000]
[03:44:22] <BBB> bad
[03:44:26] * BBB changes to !!
[03:46:00] <BBB> ok, time to go, thanks so far
[03:46:05] <BBB> Vitor1001, will work on set2()
[03:46:11] <Vitor1001> Thanks
[03:46:16] <Vitor1001> I was looking at it now
[03:46:38] <BBB> send replies to the mailinglist i you have more suggestions, I'll try using av_log2() to find unset bits
[03:46:50] <BBB> the first line of that 500-time-loop can be moved out of the loop
[03:46:53] <BBB> it's always the same
[03:46:57] <Vitor1001> Please try first getting rid of the loops ;)
[03:47:07] <BBB> I will try
[03:47:12] <BBB> can't guanantee
[03:47:13] <BBB> :)
[03:47:24] <Vitor1001> I also have a hard time understanding what this func does
[03:47:47] <BBB> there's research papers on this kind of coding
[03:47:53] <BBB> I think I need to read one of them
[03:47:57] <BBB> do you have free access to them?
[03:47:58] <Vitor1001> And I _hate_ wmavoice habit of using negative vector indexes!
[03:48:10] <BBB> yes, ... :(
[03:48:11] <Vitor1001> its unlikely, but I can try
[03:48:15] <Vitor1001> send me the link in pvt
[03:48:23] <BBB> ok, but tomorrow
[03:48:26] <BBB> wife is calling :)
[06:55:51] <ohsix> mru: have you looked at the graphite changes in gcc?
[06:56:43] <astrange> they aren't useful for anything we do
[06:56:50] <astrange> maybe for that sbr kernel
[06:57:36] <Dark_Shikari> aren't they designed to compensate for stupid programmers?
[06:57:42] <Dark_Shikari> e.g. people looping the wrong way around a 2D array
[06:58:50] <ohsix> heh, preconditions can change, loop transformations can ensure they're always correct with regard to cache sizes and whatnot, has nothing to do with "stupid programmers"
[06:59:05] <elenril> wait, svn log downloads the log from server?
[06:59:19] <Dark_Shikari> ohsix: um, but it's the programmer's job to consider the cache size
[06:59:31] <Dark_Shikari> for any code that iterates overly a sufficiently gigantic array
[06:59:35] <ohsix> it just makes it more scalable without murdering your code
[06:59:38] <Dark_Shikari> since such code is _so incredibly rare_
[06:59:59] <Dark_Shikari> I mean, how often do people loop over 50 megabyte arays?
[07:00:44] <ohsix> the compiler knows the cache size, if you're doing something for a cache size thats more than available here then what are you really doing, with the loop transforms i can have it chunk it up and reorder it for the small cache size without manual effort
[07:01:16] <Dark_Shikari> >the compiler knows cache size
[07:01:16] <Dark_Shikari> hahahahahaha
[07:01:41] <Dark_Shikari> that's impressive, an optimization that doesn't work with any march other than native
[07:02:02] <Dark_Shikari> by comparison, the programmer could just detect the cache size and make it handle all kinds of cache sizes with a few minutes of effort
[07:02:11] <ohsix> it wont transform the code
[07:02:28] <ohsix> you end up with a certain degree of waste doing that too
[07:02:39] <Dark_Shikari> sure, but much less than the compiler would have
[07:03:24] <ohsix> you know that for sure in every case that may ever be encountered?
[07:04:03] <Dark_Shikari> why does it matter?
[07:04:14] <Dark_Shikari> even if the compiler is worse only 90% of the time as opposed to 100%, that's good enough to not trust it
[07:04:35] <ohsix> its your foil, not mine; if you know that to be true, and thats why you said it, surely nothing i could say matters
[07:04:36] <Dark_Shikari> plus, I don't think I can name a single optimization, of all the things gcc does, that a human isn't better at
[07:05:40] <Dark_Shikari> better or tied, at least
[07:05:48] <Dark_Shikari> though I'd be hard-pressed to even find a tie case
[07:05:50] <ohsix> i get it
[07:06:00] <ohsix> but its a straw man
[07:06:10] <Dark_Shikari> yes, I agree with mru, deal with it ;)
[07:06:35] <ohsix> i guess its better than a religion in some ways :>
[07:07:05] <ohsix> btw, enjoying flaming people doesn't neccisarily mean you agree, or understand the perspective of someone; just that you enjoy throwing your shit in
[07:07:12] <benoit-> moin
[07:07:28] <Dark_Shikari> ohsix: I'm pretty sure mru will confirm that he agrees with me.
[07:07:55] <ohsix> thats a red herring
[07:08:22] <Dark_Shikari> I prefer blue herrings.
[07:08:49] <ohsix> loglcal fallacies follow with irrationality i guess :D
[07:09:15] <Dark_Shikari> red herrings are a type of logical fallacy?
[07:09:21] <Dark_Shikari> nor is that a red herring
[07:09:32] <Dark_Shikari> you made bizarre accusations that made no sense
[07:09:36] <Dark_Shikari> simply because I said "mru would agree with me"
[07:09:50] <Dark_Shikari> and then when I called you on your bull, you yelled "red herring"
[07:10:07] <Dark_Shikari> I said "mru would agree with me" because *we were having this discussion earlier, and he agreed with me*
[07:10:12] <ohsix> i'm not making accusations, you know not what you do
[07:10:23] <Dark_Shikari> ... I "know not what I do"?
[07:10:28] <Dark_Shikari> wtf
[07:10:38] <Dark_Shikari> I said someone would agree with me because they agreed with me.
[07:10:45] <astrange> gcc is probably better at RISC register allocation for a large function
[07:10:46] <Dark_Shikari> Is there now something wrong with this?
[07:10:58] <astrange> and some non-gcc compiler is probably better at minimizing instruction size
[07:11:19] <Dark_Shikari> I wouldn't be surprised about that, minimizing instruction size is easier than making fast code
[07:11:31] <Dark_Shikari> humans have tricks up their sleeves though
[07:11:50] <Dark_Shikari> But most of the really evil ones that compilers can't do (self-modifying code, etc) are so horrific
[07:11:52] <Yuvi> astrange: 32+ registers? what I've seen of gcc register allocation on arm it was pretty stupid
[07:11:59] <ohsix> humans = http://en.wikipedia.org/wiki/Oracle_machine
[07:12:26] <Dark_Shikari> ohsix: that's actually how they do AI problem computational complexity
[07:12:32] <Dark_Shikari> treat a human as an Oracle machine for a Turing machine
[07:12:48] <astrange> 4.4 or earlier than 4.4?
[07:12:55] <ohsix> no kidding? wow
[07:13:02] <Yuvi> mostly earlier I guess
[07:13:20] <astrange> it was rewritten for 4.4, the algorithm is much better now (and better than llvm's)
[07:13:54] <ohsix> anyways; graphite has been in gcc for a while, its still disabled on some distros, its worth a shot trying clean, dumb code to see how it does against the rearranged stuff
[07:14:05] <astrange> the interaction with reload (the last pass) is still bad and destroys lots of good work in 4.5 though, so it sometimes acts badly anyway
[07:14:12] <Dark_Shikari> for reference, someone tested graphite on x264, iirc it was slightly slower
[07:14:26] <Dark_Shikari> ohsix: http://en.wikipedia.org/wiki/AI-complete#Results
[07:14:40] <astrange> oh, and on x86 it's faster to recalculate stuff than it is to save to stack, gcc never does that
[07:14:44] <ohsix> someone? did they keep track of what they were doing
[07:15:11] <Yuvi> is that why gcc 4.4 will still emit useless reg->reg movs on arm?
[07:15:17] <Dark_Shikari> ohsix: it's probably somewhere in the depths of the x264 builds thread on doom9
[07:15:23] <astrange> probably
[07:15:30] <astrange> can i bootstrap an arm compiler from the iphone sdk?
[07:15:50] <ohsix> Dark_Shikari: i was being facetious, and no incredulous that you understand what an oracle machine is to a turing machine but you don't understand that what you're saying about gcc with regard to doing it by hand is a logical fallacy
[07:16:15] <ohsix> s/no/now
[07:16:15] <Yuvi> I haven't tried a fsf gcc targeting iphone, I'd be surprised if apple's patches for that made their way upstream
[07:16:51] <astrange> i don't care what it targets, i just want to read gcc -S
[07:18:52] <Dark_Shikari> ohsix: you have yet to actually name a specific logical fallacy
[07:19:13] <ohsix> Dark_Shikari: you can use --param l1(2)-cache-size to set it if gcc doesn't get it
[07:19:22] <Dark_Shikari> but again, it only works with native
[07:19:28] <ohsix> i do? i'd rather you figure it out
[07:19:30] <Dark_Shikari> i.e. conceptually compiling for the current machine only
[07:20:01] <Dark_Shikari> "I'd rather you figure it out" <--So you have no clue what you're talking about, so you instead request that I try to dig you out of the hole you dug
[07:20:04] <Dark_Shikari> sorry, no
[07:20:11] <ohsix> --param  has a lot of machine description stuff so you can set it straight if it doesn't have the right information
[07:20:26] <Dark_Shikari> again, the point is that kind of optimization is extremely machine-specific
[07:20:40] <Dark_Shikari> most use-cases for gcc don't involve compiling for a single computer
[07:20:42] <ohsix> it'd be a much more useful device if you would figure out what it is yourself
[07:20:46] <Dark_Shikari> except Gentoo
[07:20:54] <Dark_Shikari> and we don't care about Gentoo
[07:21:43] <Dark_Shikari> ohsix: so in order, you have decided to spend today trolling
[07:21:53] <Dark_Shikari> *so, in short
[07:22:09] <Dark_Shikari> well, unfortunately, trolls don't get fed for long here.
[07:22:10] <ohsix> and you had already been set on ad hominem
[07:22:44] <superdump> morning
[07:22:52] <Dark_Shikari> \o
[07:23:18] <pJok> mornings :)
[07:28:01] <ohsix> hrmph when did /join stop switching to the right channel if you're already on it on irssi
[07:30:34] <jai> why the kb?
[07:31:15] <Dark_Shikari> ban to prevent autorejoin, then instant unban
[07:31:43] <Dark_Shikari> if you mean the reason, he was trolling for like the past 20 minutes
[07:31:59] <Dark_Shikari> accusing me of a logical fallacy and not shutting up about it--but when asked what it was, refusing to tell me
[07:32:18] <jai> right, i should've read the log
[07:32:53] <ohsix> there was no accusation; i was merely informing, as was the original query about recent changes in gcc and if anyone had evaluated them
[07:33:04] <Yuvi> astrange: http://www.mediafire.com/?ywkmbzhgtjo if you haven't compiled a toolchain yet
[07:33:24] <ohsix> i frankly don't much care what you'll do with any information beyond answering the original query :)
[07:33:58] <jai> ohsix: *awnsering :)
[07:34:09] <ohsix> thx
[07:35:06] <ohsix> speaking of, is there a clean/dumb version of every component in ffmpeg available somewhere? like a reference impl; so you can check it against the permuted versions
[07:37:08] <ohsix> anything that tries to outsmart the compiler will be affected in different ways as the compilers change, global transformation stuff can reach lower global minimums, but if you cant test if they do when they're added to the compiler, you cant know :\
[07:38:15] <ohsix> the irony being, this type of "optimization" diverges from the literal definition of it in the end, huhuhuhu
[07:39:08] <ohsix> its more like simulated annealing without the statistical check, and human inputs that aren't in the same measurement space
[07:39:52] <ohsix> which of course perverts the original intent
[07:40:20] <astrange> --disable-asm is the closest thing available
[07:40:34] <ohsix> k, thanks
[07:41:59] <astrange> but if you're running acovea or something on that the results will be different from with asm
[07:42:05] <astrange> and the profiles will also be completely different
[07:42:10] <ohsix> dark_shikari: as to this wrt: x264, i have no doubt it would be slower, but not to what degree
[07:42:19] <astrange> and it's more useful to optimize the default configuration than to optimize c only...
[07:42:39] <ohsix> astrange: ah, nah acovea isn't on the map, just checking out some of the program transformation that came with graphite/cloog
[07:42:39] <astrange> anyway if fate can track speed i'll be sure to bug gcc@ about it
[07:44:38] <ohsix> what i have in mind though; is how it scales by cache size, cuz theres some rather anemic stuff out there thats on the cusp of working just fine without changes, but you cant reasonably account for the entire breadth of cache sizes and processors with certain types of modifications that should rightly be done for the best case
[07:45:12] <ohsix> like places where -Os can swamp -O3 just because the code is smaller
[07:45:38] <astrange> that's most places actually. -O3 is badly overtuned
[07:45:54] <astrange> mostly because of loop unrolling never being beneficial on x86-32
[07:46:05] <ohsix> well heh yea, but you know what i mean
[07:48:23] <ohsix> you could make gcc stop doing that sort of thing, one of the --param things is a quantum/chunk size for that sort of decision, set it so it never decides to do it, or under rarer/smaller circumstances
[07:57:15] <ohsix> has anyone tinkered with this ? http://trad4.sourceforge.net/
[07:59:02] <KotH> moin
[08:00:00] <osaft> moin moin
[08:07:41] <astrange> Yuvi: yours and the iphone one can't find their crt1.o, i think i can bootstrap with the DS compiler i have
[08:10:13] <Yuvi> oh yeah, I stripped out the sysroot since it was like 200 MB, http://www.beagleboard.org/uploads/arm-2007q3-macosx-20080828.tar.bz2 has a sysroot
[08:11:36] <ohsix> trad4 basically just makes closures for objects you put in the template and schedules threads/ordering, its neat
[08:50:27] <astrange> ugh, some of the hq mpeg4 encoding stuff doesn't work with sse2
[08:51:11] <astrange> and dsp_mask isn't in the cli
[08:51:29] <Dark_Shikari> why would it not work with sse2?
[08:51:37] <Dark_Shikari> if the alignment requirements are wrong, there need to be multiple function pointers
[08:52:31] <astrange> alignment for some things isn't satisfied
[08:53:37] <astrange> oh, it's the same one snow crashes on
[09:12:50] <astrange> sse2 idct crashes too, that's definitely the caller's fault
[09:13:11] <astrange> well, it works with simpleidct, i forgot how slow b-strategy 2 was....
[09:14:26] <Dark_Shikari> what does b-strategy 2 actually do anyways?  is it viterbi?
[09:14:43] <Dark_Shikari> because you can't compare 2 b-frames and 3 b-frames since the number of frames each covers is different
[09:16:36] <astrange> brute force rd estimate with optional input downscaling
[09:16:57] <Dark_Shikari> I know that part
[09:17:05] <Dark_Shikari> but what does it actually _compare_?
[09:17:09] <Dark_Shikari> you can't compare PBBP to PBBBP
[09:17:15] <Dark_Shikari> because they cover a different number of frames
[09:20:00] <astrange> http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/mpegvideo_enc.c;h=aaf0cad41173abc8a0cdda8aa1b5ffda823fc9b5;hb=HEAD#l1006 whatever pattern 1020 results in
[09:21:08] <Dark_Shikari> oh.  it  does it the stupid way
[09:21:30] <superdump> patches welcome
[09:21:48] <Dark_Shikari> fixing it would involve an x264-alike lookahead system
[09:22:13] <Dark_Shikari> and it would get a lot slower
[09:22:15] <superdump> so without lookahead, it's the best that can be done?
[09:22:23] <Dark_Shikari> well it already effectively does have a lookahead
[09:22:26] <Dark_Shikari> I'm not sure how far it looks ahead though
[09:22:30] <Dark_Shikari> er, I mean
[09:22:38] <Dark_Shikari> I'm not sure how much work it would require to make it look ahead much further
[09:22:49] <Dark_Shikari> it'd definitely have to cache the rd values for various P/B combinations
[09:23:14] <astrange> mpegvideo enc needs a lot of work. it'd be a great soc project except the student would have to already be an encoder developer
[09:23:21] <Dark_Shikari> :/
[09:23:27] <Dark_Shikari> I wonder if it would be easier to turn x264 into an mpeg2 encoder
[09:24:39] <superdump> it'd be GPL though
[09:24:51] <Dark_Shikari> true
[09:24:57] <superdump> GPL/commercial?
[09:25:03] <superdump> have you done the dual licensing thing?
[09:25:05] <Dark_Shikari> it'd also be bloated as hell
[09:25:13] <Dark_Shikari> because it would be extra work to remove a lot of unnecessary stuff
[09:25:22] <Dark_Shikari> dual licensing work is ongoing
[09:25:27] <Dark_Shikari> got most of the CLAs in
[09:26:00] <Dark_Shikari> waiting on Avail--apparently their lawyers didn't get the clue and decided to play the "let's add every single clause we've ever seen to the agreement, just to make sure" game, much to te chagrin of both me *and* my friends at Avail
[09:26:50] <superdump> :/
[09:27:06] <Dark_Shikari> so my boss there is going to whack them into shape
[09:27:18] <CIA-17> ffmpeg: michael * r21582 /trunk/ffplay.c: Simplify get_video_clock()
[09:27:46] <Dark_Shikari> though another question is how much people care about mpeg-2 anymore
[09:27:58] <Dark_Shikari> by the time an improved mpeg-2 encoder is done, even fewer people will care about it
[09:28:07] <Dark_Shikari> and a lot of the more useful improvement would be stuff like vbv etc
[09:54:26] <CIA-17> ffmpeg: thilo.borgmann * r21583 /trunk/libavcodec/alsdec.c: Remove unnecessary fields in ALSSpecificConfig.
[10:00:33] <siretart`> morning
[10:17:30] <KotH> vormittag
[10:19:20] <siretart`> KotH: did you receive my mail in time?
[10:20:21] <KotH> yes
[10:20:32] <KotH> thanks
[10:20:41] <KotH> you were the only one who told us ^^'
[10:33:05] <CIA-17> ffmpeg: michael * r21584 /trunk/ffplay.c:
[10:33:05] <CIA-17> ffmpeg: Try to more completely update time variables on unpause.
[10:33:05] <CIA-17> ffmpeg: Could not notice a differenc in behavior.
[10:45:17] <benoit-> OMG
[10:45:28] <benoit-> seen on the wiki at my workplace:
[10:45:32] <benoit-> "NOTE: Using dash as /bin/sh may cause some problems, please change /bin/sh to bash. "
[10:45:40] <benoit-> :'(
[10:45:51] <thresh> lol
[10:45:54] <benoit-> (I had to share that crying moment with you)
[10:46:05] <benoit-> well
[10:46:11] <benoit-> this is wiki, I can correct that :)
[10:47:09] <pross-au> Wikis, helping morons and experts since 1999
[10:54:43] <benoit-> pross-au: :)
[10:56:44] <CIA-17> ffmpeg: michael * r21585 /trunk/ffplay.c: Fix race condition with reading between video_current_pts and video_current_pts_time.
[10:57:13] <jez9999> Ward Cunningham started developing WikiWikiWeb in 1994
[10:57:14] <jez9999> ;-)
[10:58:43] <pross-au> Ah crap, just proved i am a moron
[11:00:24] <merbzt> pic size stuff ?
[11:14:00] <elenril> anyone can apply a patch for me?
[11:16:51] <pross-au> sure. is it approved?
[11:18:16] <elenril> yes, michael and bcoudrier reviewed it
[11:18:27] <elenril> thread 'add a list of generic tag names'
[11:21:07] <pross-au> Sat, 16 Jan 2010 12:52:23 +0100 <-- this one
[11:26:18] <elenril> yes
[11:26:44] <elenril> but it probably won't apply cleanly, i'll upload a rebased version in a sec
[11:27:07] <elenril> http://filebin.ca/dzezck/0001-Add-a-list-of-generic-tags.patch
[11:28:56] <pross-au> rgr
[11:31:20] <CIA-17> ffmpeg: michael * r21586 /trunk/ffplay.c:
[11:31:20] <CIA-17> ffmpeg: Schedule refreshes from a thread that actually knows the PTS.
[11:31:20] <CIA-17> ffmpeg: Fixes wernfried_1.avi
[11:31:38] * elenril sighs
[11:31:58] <elenril> now you'll have to increment revision in docs/APIchanges
[11:32:50] <pross-au> Cool
[11:39:10] <merbzt> awesome !!!
[11:40:00] <CIA-17> ffmpeg: pross * r21587 /trunk/ (12 files in 2 dirs):
[11:40:00] <CIA-17> ffmpeg: Add a list of generic tags and change demuxers to follow it.
[11:40:00] <CIA-17> ffmpeg: Patch by Anton Khirnov, wyskas at gmail dot com
[11:40:11] <elenril> pross-au: thanks
[11:41:13] <pross-au> thank you
[11:57:01] <DonDiego> fftrollbot: greetings, troll
[11:57:49] <siretart`> DonDiego: hi
[11:57:53] <DonDiego> hi
[11:58:08] <DonDiego> siretart`: repent evil sinner!
[11:58:21] <siretart`> DonDiego: regarding 'butchering', I of course did 'only' append to config.h.
[11:58:40] <siretart`> DonDiego: but in the end, I did locate and backport the patch from trunk to 0.5
[11:58:42] <DonDiego> that's still a penance
[11:59:03] <DonDiego> the sins of the mind are no less sins than the sins of the actions
[11:59:10] <siretart`> DonDiego: regarding the next release, that's exactly what I wanted to discuss with you at FOSDEM
[11:59:26] <DonDiego> 7 hail marys for you
[11:59:52] <siretart`> DonDiego: the thing is that the backported patch does have other changes that I rather wanted to avoid
[12:00:07] <DonDiego> which revision? 18380?
[12:00:20] <siretart`> DonDiego: well, it turned out that most of them were indeed trivial, so I just took them
[12:00:39] <siretart`> sec, I'm looking up the patch
[12:02:04] <siretart`> DonDiego: how are your studies going along?
[12:02:48] <siretart`> http://git.ffmpeg.org/?p=ffmpeg;a=commitdiff_plain;h=dd47be64953f558826456ee3696220f587ec8a20
[12:02:52] <siretart`> is what I've backported
[12:02:59] <DonDiego> stalled, my professor broke his leg..
[12:03:06] <siretart`> oh :-(
[12:03:12] <av500> you tripped him?
[12:03:20] <ohsix> ^ ++
[12:03:46] <DonDiego> hehe
[12:03:57] <DonDiego> siretart`: you also want libswscale r29154
[12:04:14] <DonDiego> siretart`: and i would prefer you to backport this to the 0.5 branch
[12:04:42] <siretart`> DonDiego: since my packages track the 0.5, I backport to nothing else
[12:04:56] <siretart`> DonDiego: or do you want me to commit them to svn?
[12:06:19] <siretart`> oh indeed, r29154 of libswscale is very relevant. damn
[12:06:54] <DonDiego> yes, commit to svn
[12:07:02] <DonDiego> that's the whole point of the branch
[12:07:18] <DonDiego> i don't want every other packager to duplicate your work
[12:07:28] <siretart`> well, then you'd need to authorize me. I can only commit to mplayer, not ffmpeg
[12:07:42] <DonDiego> i don't think so, let me doublecheck..
[12:07:58] <siretart`> I think I've tried a few days ago…
[12:08:19] <DonDiego> indeed
[12:09:49] <DonDiego> fixed
[12:10:16] <DonDiego> siretart`: do you know how to properly backport changes with subversion?
[12:10:35] <DonDiego> i.e. using svn merge and an svn version >= 1.5
[12:10:38] <siretart`> okay. do I need to care about magic svn merge properties, or can I stage my commit via git-svn?
[12:11:08] <siretart`> oh, obviously the latter
[12:11:20] <siretart`> err, the former
[12:11:36] <DonDiego> dunno
[12:11:49] <DonDiego> if in doubt, use the original client
[12:11:49] <mru> svn makes simple things so complicated...
[12:11:52] <siretart`> okay, I'll read up the documentation for the details.
[12:12:08] <ohsix> so does cvs ;)
[12:12:14] <mru> no
[12:12:17] <mru> cvs is very simple
[12:12:31] <mru> the trouble is it can only do very simple things
[12:12:32] <siretart`> but may I ask you why you insist on that feature? AFAIUI it is only useful if you intend to merge back to trunk, which I don't think is something we would want anyways
[12:14:36] <DonDiego> mru: stop your stupid trolling, i'm already getting sick of it
[12:14:44] <mru> what now?
[12:14:48] <DonDiego> especially since you know italy squat about svn
[12:14:53] * DonDiego shakes his head
[12:15:09] <ohsix> oh boy
[12:15:15] <mru> you didn't write it
[12:15:18] <mru> why do get so offended?
[12:15:21] <siretart`> I don't think mru is trolling over svn nor cvs. at least not in the last 10 minutes
[12:15:31] <DonDiego> he was yesterday ;)
[12:15:40] <DonDiego> anyway, i've already cooled down again
[12:16:13] <siretart`> bah, r29154 doesn't apply cleanly at all :/
[12:16:23] <DonDiego> http://svnbook.red-bean.com/en/1.5/svn.branchmerge.advanced.html#svn.branchmerge.cherrypicking
[12:16:24] <mru> it's widely accepted that svn handles branches very poorly
[12:16:55] <DonDiego> mru: that's a thing of the past, it improved by leaps and bounds since 1.5
[12:17:05] <ohsix> not even accepted, admitted by the developers
[12:17:34] <pross-au> is there a way of getting incremental build numbers with git yet?
[12:17:43] <pross-au> s/build/revision/
[12:17:45] <mru> pross-au: who cares?
[12:17:48] <pross-au> ME
[12:18:10] <ohsix> tag the versions
[12:18:12] <pross-au> (and those of us incapable of parsing sha hashs)
[12:18:24] <mru> pross-au: git log --oneline | wc -l ;-)
[12:18:24] <ohsix> if you must, anyways
[12:18:34] <pross-au> oh cool
[12:18:38] <DonDiego_> fucking isp...
[12:18:42] <siretart`> DonDiego: you still didn't answer my earlier question, did you read it?
[12:19:47] <DonDiego> siretart`: please repeat
[12:20:00] <siretart`> DonDiego:  may I ask you why you insist on that feature? AFAIUI it is only useful if you intend to merge back to trunk, which I don't think is something we would want anyways
[12:20:26] <CIA-17> ffmpeg: michael * r21588 /trunk/ffplay.c:
[12:20:26] <CIA-17> ffmpeg: "Flush" the picture que on seeks, this prevents the display thread from
[12:20:26] <CIA-17> ffmpeg: having frames from before and after the seek which just isnt a good idea.
[12:20:28] <DonDiego> the metadata is useful as-is
[12:20:42] <siretart`> okay, but what are you using it for?
[12:20:45] <DonDiego> so that you know which revisions have been applied, etc.
[12:21:34] <siretart`> if you want to have that information, no problem, you're the 0.5 release manager. but I still don't see what you want to do with it.
[12:22:51] <pross-au> um, without these revision numbers, we wouldnt nearly be as aware of the approaching 30kth commit
[12:23:03] <CIA-17> ffmpeg: michael * r21589 /trunk/ffplay.c:
[12:23:03] <CIA-17> ffmpeg: Insert a flush packet into the que on init, that way common code between
[12:23:03] <CIA-17> ffmpeg: flush and init can be put into the flush handling.
[12:25:15] <ohsix> which is important cuz that means you're done
[12:27:55] <siretart`> DonDiego: let's discuss that in person this weekend
[12:28:12] <DonDiego> fine
[12:28:19] <CIA-17> ffmpeg: michael * r21590 /trunk/ffplay.c:
[12:28:19] <CIA-17> ffmpeg: Reset frame_last_pts on flush (and thus also at start)
[12:28:19] <CIA-17> ffmpeg: fixes issue558 and probably others.
[12:28:43] <DonDiego> but what's the big deal about not merging now?
[12:30:27] <siretart`> it's not a big deal at all
[12:30:43] <siretart`> besides it seems pointless to me and prevents people to use git-svn to stage their changes
[12:31:06] <CIA-17> ffmpeg: michael * r21591 /trunk/ffplay.c:
[12:31:06] <CIA-17> ffmpeg: Move frame_last_delay into flush code as it must be reset on seeks to,
[12:31:06] <CIA-17> ffmpeg: otherwise the first frame after a seek would be delayed by that amount.
[12:32:17] <CIA-17> ffmpeg: michael * r21592 /trunk/ffplay.c:
[12:32:17] <CIA-17> ffmpeg: Reset frame_last_delay to 0.
[12:32:17] <CIA-17> ffmpeg: This avoids a few ms delay for the first frame after a seek in theory.
[12:32:19] <siretart`> that's why I asked if you had some tools/scripts whatever that actually make use of this revision information
[12:36:30] <DonDiego> ok, i think we can talk now
[12:36:51] <siretart`> my last comment was:
[12:36:53] <DonDiego> i've logged onto another machine and started irssi in screen
[12:37:01] <DonDiego> fuck vodafone
[12:37:02] <siretart`> it's not a big deal at all
[12:37:05] <siretart`> besides it seems pointless to me and prevents people to use git-svn to stage their changes
[12:37:09] <siretart`> that's why I asked if you had some tools/scripts whatever that actually make use of this revision information
[12:37:20] <DonDiego> it's useful information
[12:37:32] <DonDiego> that may well get used in the future
[12:37:37] <siretart`> useful for what/whom?
[12:37:47] <DonDiego> to see which revisions got merged
[12:37:49] <siretart`> statistics?
[12:38:07] <DonDiego> i must say i'm puzzled by the question
[12:38:09] <mru> that can be done with a simple note in the commit message
[12:38:22] <siretart`> I tend to agree with mru
[12:38:35] <DonDiego> nope, that should be metadata in the revision control system
[12:38:38] <DonDiego> same as renames
[12:38:46] <DonDiego> copies, etc.
[12:39:05] <ohsix> D:
[12:39:10] <mru> DonDiego: are you aware that git manages to track renames etc much better than svn?
[12:39:25] <mru> if you move a few lines from one file to another, the blame tool will follow it
[12:39:49] <siretart`> I really don't want to get into trolling, but currently, it *looks* to me that the main point was to please the tool svn
[12:40:41] <pross-au> is there a git->svn gateway?
[12:40:56] <siretart`> pross-au: there is git-svn, it can nicely commit to an svn repository
[12:41:06] <pross-au> no, the other way round
[12:41:10] <mru> that how I do all my commits
[12:41:15] <siretart`> pross-au: there is http://git.ffmpeg.org
[12:41:32] <mru> I think he wants an svn frontend to a git repo
[12:41:37] <siretart`> pross-au:  which is managed with git-svn as well
[12:41:38] <mru> no such thing exists afaik
[12:41:48] <pross-au> thanks mru
[12:41:52] <pross-au> i too use git.ffmpeg.org
[12:41:53] <mru> it's easy enough to set up a read-only mirror
[12:42:11] <siretart`> oh, I see.
[12:42:25] <siretart`> pross-au: well, there is tailor, which should be able to do that.
[12:43:56] <pross-au> ic
[12:45:58] <siretart`> I used it some years ago, but for bzr that time. It turned out to be rather fiddly, but it targets at pretty exactly what you are asking for.
[12:46:09] <siretart`> for any VCS
[12:46:18] <DonDiego> fucking, fucking, fucking isp
[12:51:33] <DonDiego> *sigh*
[12:51:54] <DonDiego> i'm getting disconnected every other minute..
[12:52:21] <iive> dsl?
[12:52:26] <DonDiego> yes
[12:52:36] <iive> cold weather ?
[12:52:40] <DonDiego> yes
[12:52:44] <iive> with lots of ice?
[12:52:57] <DonDiego> define lots.. - it's snowing
[12:53:15] <siretart`> fucked dsl modem.. such things do happen
[12:53:27] <siretart`> perhaps you can decrease the syncronisation speed on your modem. that usually helps
[12:54:00] <DonDiego> anyway
[12:54:06] <DonDiego> git does not track renames, it guesses
[12:54:29] <siretart`> so?
[12:54:36] <DonDiego> the way that svn tracks renames can still be improved
[12:54:43] <DonDiego> it can guess wrong
[12:54:47] <DonDiego> (git)
[12:54:56] <ohsix> its a pretty good guess if it has every tracked files history :O
[12:55:10] <siretart`> are wrongly guessed renames a practical problem?
[12:55:14] <DonDiego> yes
[12:55:24] <DonDiego> and to cut the trolling short:
[12:55:45] <DonDiego> i maintain the 0.5 branch and backports will be done with svn merge
[12:55:47] <DonDiego> period
[12:55:49] <siretart`> my experience tells something different, but anyway, this really wasn't my point
[12:55:50] <iive> hum, have git actually guessed wrong for you?
[12:56:15] <mru> for very small files git guesses can be a bit random
[12:56:35] <mru> 20-line licence boilerplate followed be 3 lines of actual content...
[12:57:30] <iive> :))
[12:58:23] * pJok reminds mru to stop making so many "hello world!" apps
[12:59:40] <siretart`> DonDiego: do you have a list of open issues that are targeted for a 0.5.1 release?
[12:59:53] <DonDiego> no
[13:00:03] <DonDiego> i expect to get that list from you
[13:00:27] <ohsix> eh, isn't that what the issue tracker is for??
[13:00:27] <DonDiego> the 0.5 branch is targeted at packagers
[13:00:31] <pross-au> 0.6?
[13:01:09] <DonDiego> some day
[13:01:53] <siretart`> hm. roundup doesn't seem to support 'targeting' issues at releases
[13:02:12] <ohsix> roundup doesn't do much of anything, huhuhu
[13:02:43] <ohsix> metabugs should still work, but are hard to track without that stuff
[13:03:41] <siretart`> DonDiego: the debian package carries now a rather large amount of patches that apply to the 0.5 branch. However I imagine that you might be rather skeptical about the neon backports
[13:03:57] <ohsix> was bugzilla too hard to set up back in the day? why roundup, its like alsa heh, they use mantis (??? lol)
[13:04:35] <CIA-17> ffmpeg: michael * r21593 /trunk/ffplay.c:
[13:04:35] <CIA-17> ffmpeg: Make sure the faulty timestamp detection is just done when we have a picture
[13:04:35] <CIA-17> ffmpeg: from the decoder.
[13:05:11] <ohsix> speaking of, have any of you guys used any of those issue tracker things that keep the data in tree with git?
[13:05:20] <siretart`> who runs/maintains the roundup instance?
[13:05:58] <siretart`> ohsix: please, not another pointless bugtracker bashing/trolling discussion
[13:07:06] <pross-au> DonDiego: cool
[13:07:44] <ohsix> heh, my intent was only to see if anyone had; it seems ideal for some scenarios
[13:08:27] <ohsix> if you pull from someones tree you get their issues against their tree
[13:08:30] <siretart`> pross-au: I've read yesterday that this weekend there is going to be some discussion/planning on a potential 0.6 release at FOSDEM.
[13:08:36] <DonDiego> siretart`: lu_zero "maintains" roundup
[13:08:50] <siretart`> needless to say that I'm very interested in participating in that discussion :-)
[13:09:00] <siretart`> DonDiego: ah, excellent!
[13:09:15] <pross-au> gotta love 'discussion'
[13:09:32] <DonDiego> why did you amass so many 0.5 patches in the debian tree anyway?
[13:09:40] <ohsix> people tend to make more sense in person
[13:09:56] <siretart`> well, I'm constantly prodding you to have a look at them :-)
[13:10:29] <siretart`> now that you've granted me commit access, I can see to apply some of the more obvious ones to svn, and discuss the rest with you
[13:11:06] <DonDiego> you should not amass *any* patches
[13:11:22] <siretart`> DonDiego: the most important one (at least to me) is the symbol versioning patch.
[13:11:26] <ohsix> siretart`: OT but do you know how much ffmpeg/gst-ffmpeg diverges in ubuntu, if at all?
[13:11:58] <siretart`> ohsix: I'm not sure I understand the question. gst-ffmpeg is linked against the system ffmpeg
[13:12:51] <siretart`> DonDiego: do you have a written policy to assess what patches are acceptable for the 0.5 branch?
[13:12:55] <ohsix> right ... but if debian and ubuntu have the same packages, or at least comparable ones; i have some bugs i'd like to discuss, cuz other people aren't very interested :>
[13:13:30] <siretart`> I think the policy for the debian package is more lax, which would explain the large pile of patches
[13:13:44] <siretart`> ohsix: they do
[13:14:03] <ohsix> keen
[13:14:31] <ohsix> if you have a few minutes later i can explain, bbiab
[13:15:10] <DonDiego> the 0.5 branch is for packagers, so anything that helps them and keeps them from hoarding patches
[13:15:23] <DonDiego> which every packager seems hell-bent on doing anyway.. :-(
[13:16:16] <DonDiego> i don't understand why patches need to be staged in distro packages *at all*
[13:16:38] <siretart`> well, I'm not hell-bent on that, but so far working on the 0.5 branch hasn't been exactly "inviting"
[13:16:58] <siretart`> a clear process on how to work on that would be a great step to lower the entry barrier
[13:18:03] <DonDiego> what's uninviting?
[13:18:56] <siretart`> e.g. yelling at people that don't use svn 0.5 merge capabilites properties properly is one reason
[13:19:19] <siretart`> the lack of process documentation is another one, IMO
[13:19:45] <siretart`> for example: do you want me to have you approve each and every backported patch, or do you trust my assessment in suitability for 0.5.1?
[13:19:57] <iive> siretart`: Diego never yells at people. never!
[13:19:59] <ohsix> k, back
[13:20:14] <mru> diego is usually well-mannered
[13:20:19] <DonDiego> iive: second warning
[13:20:22] <mru> the last few weeks he's been a bit irritable
[13:20:28] <mru> perhaps related to his exams
[13:20:33] <mru> cut him some slack
[13:20:38] <DonDiego> thx
[13:20:40] <DonDiego> anyway
[13:20:50] <DonDiego> proper tool usage is not up for discussion
[13:20:53] <ohsix> warnings are for chumps, people are goingn to mess with you if you're going to respond :O
[13:20:56] * siretart` feels like the biggest troll on the hill. and I really wanted to avoid that :-(
[13:21:00] <benoit-> mru: you're sooooooo cute when you speak about him like that ;)
[13:21:37] <ohsix> DonDiego: not up for discussion, but also not written anywhere?
[13:21:40] <iive> DonDiego: ?
[13:21:50] <DonDiego> sometimes you have to access the advanced capabilities of the tools
[13:22:21] <DonDiego> yes, it should all probably be documented better
[13:22:31] <ohsix> any time you have a free moment
[13:22:36] <ohsix> derp
[13:23:12] <DonDiego> and i'd like to approve the first few patches, after that we shall see
[13:23:16] <DonDiego> ohsix: derp?
[13:23:32] <ohsix> http://www.urbandictionary.com/define.php?term=derp&defid=134579
[13:23:41] <siretart`> ohsix: your questions on the distro packages would probably be most on-topic on http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers. that list is also available on gmane if you prefer
[13:23:53] <ohsix> it was supposed to be a message
[13:24:35] <ohsix> its a pretty clean issue with gst-ffmpeg and its use of systme libraries, the gstreamer guys wont touch it
[13:25:20] <DonDiego> ohsix: tread carefully, next insult earns you a kick
[13:25:39] <ohsix> i didn't insult anyone
[13:26:01] <siretart`> DonDiego: okay, then I think I'll proceed in rounds of batches via email on the mailing list, ok?
[13:26:17] <ohsix> all this meta discussion is pretty hard on the snr
[13:26:55] <siretart`> ohsix: then finally stop contributing to the noise
[13:27:19] <ohsix> hmm? i'm not going to let an accusation stand
[13:28:02] <DonDiego> you called me "derp", anyway, please just shut up now so that we can get some work done, thx
[13:28:13] <DonDiego> siretart`: i'm not following the ml currently
[13:28:15] <ohsix> i didn't call you a derp, heh
[13:28:25] <siretart`> DonDiego: okay, I'll CC you then.
[13:28:34] <DonDiego> whatever, then i take it back
[13:28:53] <siretart`> take back what?
[13:29:06] <DonDiego> the threat to kick ohsix
[13:29:09] <ohsix> a derp is just an utterance used when you make a mistake, and i said it was supposed to be a message :<
[13:29:23] <siretart`> ah, wrong thread of discussion :-)
[13:31:29] <ohsix> siretart`: long story short; gst-ffmpeg with system ffmpeg hits this with some files i have http://git.ffmpeg.org/?p=ffmpeg;a=blob;f=libavcodec/mpegvideo.c;h=21fa5ed7948912fc9e6920ba33f0d97648f4da17;hb=8429f189c709def21645e858a633225745904dd5#l857
[13:33:23] <siretart`> ohsix: okay. so?
[13:33:43] <ohsix> thats it, gstreamer guys wont look at it at all because they dont support using the system ffmpeg
[13:36:47] <siretart`> they track the 0.5 branch as well, so the bug should be also present with their copy
[13:37:26] <ohsix> right, i guess i can prod them some more, but they weren't even willing to look at the samples cuz it used the system ffmpeg
[13:37:33] <DonDiego> what's the point in fixing bugs in the distro package anyway?
[13:37:44] <DonDiego> (if they will go away with the next upload)
[13:37:51] <ohsix> i went upstream first
[13:38:04] <DonDiego> any program the size of ffmpeg will have plenty of bugs at any time
[13:39:04] <ohsix> its their distinction that an out of tree ffmpeg is unsupported, so you need to talk with the distro since thats how they chose to package it (at least for now, i've been trying to get it looked at for almost a week)
[13:39:57] <siretart`> ohsix: instead of prodding, better do a proper investigation of the issue, including samples and proper analysis of the defect. just prodding without that is merily annoying and not helpful
[13:40:51] <ohsix> heh, they've got all the goods and the knowhow to bisect it, but the fact remains; the division between in tree and system ffmpeg is there, i would have to do work i dont know how to do to fix it, where they could pin it in a few minutes
[13:41:38] <ohsix> they just told me to build from git for everything, which doesn't solve anything, even if it did work
[13:41:57] <siretart`> so you want some clever advice how to make them work for you. that's how free software work!
[13:41:59] <siretart`> s
[13:42:41] <ohsix> no, just so someone that cares can see it
[13:43:02] <ohsix> its a problem with packaging
[13:43:11] <ohsix> and they refuse to touch it
[13:43:12] <siretart`> if you say so
[13:43:20] <ohsix> heh
[13:43:56] <ohsix> you know what gst-ffmpeg is right?
[13:44:14] <siretart`> I do
[13:44:31] <siretart`> I even know the packager in debian&ubuntu
[13:45:20] <ohsix> thats the person that needs to know, i'm ready and able to take instruction; but it has to be acknowleged first
[13:45:41] <ohsix> that they can play the file and see the problem without installing another distro helps a bit!
[13:46:06] <iive> ohsix: ffplay?
[13:46:35] <ohsix> iive: yea i tried that before i did anything
[13:46:46] <iive> and?
[13:46:57] <ohsix> ffplay works fine; its the interaction between gstreamer and ffmpeg
[13:46:58] <siretart`> I had the impression that you knew about bugtrackers.
[13:47:47] <ohsix> siretart`: bugs are on the ubuntu bug tracker, i tried to get input from upstream to investigate myself
[13:48:12] <siretart`> good luck then!
[13:48:36] <ohsix> heh, thats as good as "we dont support ffmpeg out of tree", thanks
[13:49:29] <iive> there are people who have/are working on gst, but not sure there are here now. e.g. BBB
[13:50:13] <ohsix> iive: right, i've talked to BBB about some other bugs, he's not interested; he was even kind of angry :O they had a falling out i wasn't there to see apparently
[13:50:49] <ohsix> bilboed strides both sides too; he was the one that was interested but decided not to help when he heard it was built the way it is :\
[14:15:17] <mru> http://thedailywtf.com/Articles/Else-where.aspx
[14:17:07] <siretart`> heh
[14:17:08] <ohsix> heh thats cute :D
[14:17:16] <jez9999> mru: not the worst WTF ive ever seen :-)
[14:17:21] <ohsix> beats a goto
[14:17:27] <jez9999> just remember the 'break' at the end ;-)
[14:17:30] <ohsix> or so the fellow probably thought
[14:18:02] <jez9999> looks like a candidate for a switch though
[14:19:17] <ohsix> superdump: how did the enum switch thing work out
[14:19:39] <siretart`> reminds me of homework from some of our students who have "programming in C" as minor subject. but even they aren't that confused…
[14:20:29] <superdump> ohsix: ?
[14:21:19] <ohsix> superdump: oh the thing you asked about with the bitfields and the exclusive switch i think you called it
[14:22:43] * superdump doesn't recall
[14:26:19] <Honoome> mru: I've seen stuff like that in my daily job :|
[14:26:36] <mru> Honoome: but you work on web stuf, what do you expect? ;-)
[14:26:55] <Honoome> I *don't* work on web stuff…
[14:27:03] <Honoome> or rather, I'm working on web stuff now, and it's an exception…
[14:27:15] <mru> ok
[14:27:23] <mru> what kind of work do you normally do?
[14:27:28] <twnqx> let's do that with ffmpeg, maybe gcc can optimize it :]
[14:28:03] <Honoome> usually, “embedded” and support (I use quotes there because I wouldn't call Java code compiled with GCJ embedded…)
[14:30:04] <mru> I wouldn't call java embedded, ever
[14:30:27] <ohsix> what about jazelle!
[14:30:50] <Honoome> well GCJ-compiled Java code on ARM is an entirely different league from usual Java
[14:30:53] <mru> ohsix: dead
[14:30:57] <Honoome> another league of insanity, obviously
[14:31:05] <ohsix> well, dead now; hhuuhhu
[14:40:15] * KotH knows people who call a full blown arm/mips system running linux "embedded"
[14:41:41] <ohsix> :> hey they may have had to do their own bsp!
[14:42:14] <mru> bsp, yuck
[14:42:49] * mru suspects "board support package" refers to the board of directors
[14:43:43] <ohsix> its a generic cover for twiddling all the right bits and enabling the ram and stuff
[14:44:06] <mru> I know what usually comes with that label
[14:44:15] <mru> and it's usually something entirely useless
[14:44:40] <ohsix> yea but you can show the suits it runs
[14:44:43] <mru> just give me a boot loader
[14:44:55] <mru> as I said, board of directors
[14:45:00] <mru> aka suits
[14:45:14] <ohsix> ah, i missed that
[14:45:17] <twnqx> reminds me of my current job...
[14:45:26] <twnqx> asked the sales guy about recommended dress code
[14:45:38] <twnqx> "don't use suit and tie, they won't take you serious!"
[14:45:44] <ohsix> but if they got the money they wanna see it work, even if you need to throw it all out
[14:45:48] <twnqx> <3 tech jobs
[14:46:27] <mru> I worked at a place once where the ceo dressed in ragged jeans and t-shirt
[14:46:54] <kierank> me too except the ceo was a billionaire
[14:47:11] <mru> mine was a wannabe billionaire...
[14:47:18] <mru> never quite panned out though
[14:47:31] <twnqx> i'd be happy with the first few millions :X
[14:47:46] * mru is a millionaire
[14:47:47] <twnqx> billions are nice, though
[14:47:48] <mru> in some currencies
[14:47:50] <twnqx> in rubel?
[14:47:55] <twnqx> old turkish lira?
[14:48:05] <thresh> 'rouble'
[14:48:14] <twnqx> simbabwe <whatever they have there>
[14:48:20] <thresh> dollars, i think
[14:48:25] <mru> dust?
[14:51:04] <KotH> mru: my current bos often comes in ragged jeans and t-shirt
[14:51:25] <KotH> mru: especially then, when we have guests from far east :)
[15:19:59] <ohsix> hi BBB
[15:20:04] <BBB> hi
[15:24:24] <DonDiego> hi
[15:24:42] <DonDiego> siretart`: what was the exact command you used to merge the symbol stuff?
[15:25:15] <siretart`> svn merge -c svn merge -c21235 svn://ffmpeg.org/ffmpeg/trunk
[15:25:32] <BBB> superdump, I'm confused now
[15:25:37] <DonDiego> siretart`: what?
[15:25:59] <siretart`> svn merge -c21236 svn://ffmpeg.org/ffmpeg/trunk
[15:26:21] <siretart`> and later then additionally 'svn merge -c21235 svn://ffmpeg.org/ffmpeg/trunk' as I noticed that this commit is necessary as well
[15:27:24] <DonDiego> k
[15:27:32] <DonDiego> you also need to add the libswscale stuff
[15:27:57] <siretart`> I added that manually
[15:27:59] <DonDiego> siretart, siretart`, you have two nicks here, which one is your proper account?
[15:28:14] <siretart`> backporting directly is not possible as libswscale is a different svn repository
[15:28:25] <DonDiego> yes, i know :-/
[15:28:42] <siretart`> DonDiego: siretart is my irssi instance. at work I prefer rcirc (an elisp irc client) as it distracts me less
[15:29:01] <siretart`> perhaps I ditch some day that irssi instance. currently I mainly use it for logging
[15:29:25] <DonDiego> i must say i find it somewhat confusing
[15:29:34] <DonDiego> and you might miss somebody highlighting you..
[15:29:37] <DonDiego> are the nicks linked?
[15:29:54] <siretart`> they are, and I don't miss highlights
[15:30:04] <DonDiego> ok, fine then
[15:30:12] <DonDiego> i just oped you in the access list
[15:30:24] <DonDiego> but the channel does not pick that up..
[15:30:25] <DonDiego> so..
[15:30:39] <siretart`> :-)
[15:30:59] <DonDiego> can you quickly show me the complete diff?
[15:31:05] <siretart`> if you mean linked as in Freenode nicks linked, then I haven't automated that in rcirc. probably I should someday
[15:31:29] <siretart`> DonDiego: how can I retrieve that? 'svn diff' produces exactly what I pasted in the mail
[15:31:33] <siretart`> wait, I'll post 'svn status'
[15:32:10] <DonDiego> try --notice-ancestry
[15:32:16] <siretart`> http://pbot.rmdir.de/e3d0d445bd796b3d356bd47a82b7d724
[15:32:48] <siretart`> --notice-ancestry doesn't help
[15:34:39] <DonDiego> libswscale changes are missing
[15:34:53] <jez9999> BBB: hiya
[15:34:59] <BBB> hi jez9999
[15:36:07] <Compn> http://news.bbc.co.uk/2/hi/health/7813637.stm
[15:36:27] <siretart`> indeed. I forgot to 'svn add' it
[15:37:46] <jez9999> BBB: you never gave a suggestion as to how to implement the packet blocking
[15:37:47] <jez9999> :-)
[15:38:03] <BBB> true
[15:38:05] <BBB> let me start thinking
[15:38:06] <siretart`> DonDiego: fun. now libswscale/swscale.v appears in the diff. but not the other .v files..
[15:38:10] <BBB> it's not easy, I'll admit that
[15:38:35] <jez9999> not easy as in i already provided a patch that does it?
[15:39:00] <siretart`> DonDiego: http://pbot.rmdir.de/ffb7221cd80743569de18ca81221c1ca <- that is the swscale.v diff
[15:39:10] <DonDiego> siretart`: that's because libswscale is not merged..
[15:39:18] <BBB> jez9999, as in "what's the best way"
[15:39:21] <BBB> jez9999, needs some thinking :)
[15:39:29] <jez9999> ah
[15:39:59] <DonDiego> siretart`: for the runtime cpudetect merge you need to do the same
[15:40:11] <siretart`> OK
[15:42:00] <DonDiego> see, that's why i wanted to do a bit of hand-holding before giving you carte blanche to commit on the branch..
[15:42:17] <siretart`> DonDiego: mru: I think I should add "- enable symbol versioning by default for linkers that support it" to Changelog in trunk as well, right?
[15:42:19] <jez9999> BBB: still, have you thought about it?  lol
[15:42:26] <jez9999> you must have some vague idea of what to do
[15:42:28] <jez9999> (ideally)
[15:42:34] <ohsix> you have a lot of responsibilities a normal release manager doesn't :\
[15:42:54] <DonDiego> siretart`: yes, please update the trunk changelog, ideally before the merge and make it a separate commit ..
[15:43:08] <BBB> jez9999, I'm not sure what's the best way yet
[15:43:13] <BBB> I'm thinking about it, but it's not easy
[15:43:21] <BBB> who wants to mentor tasks for soc related to lossless audio?
[15:43:51] <siretart`> DonDiego: ok
[15:44:08] <jai> siretart`: did you get around to proposing security relevant fixes for the 0.5 branch?
[15:44:18] <siretart`> jai: I'm on it
[15:44:32] <jai> siretart`: cool
[15:53:02] <CIA-17> ffmpeg: siretart * r21594 /trunk/Changelog: mention symbol versioning
[15:53:13] <siretart`> muhaha!
[15:53:20] <DonDiego> hehe
[15:53:26] <DonDiego> first commit, welcome aboard :)
[15:53:35] <siretart`> thanks :-)
[15:53:50] <DonDiego> remember that
[15:53:58] <DonDiego> with great power comes great responsibility
[15:54:02] <DonDiego> young padavan
[15:54:04] <DonDiego> :)
[15:54:10] <BBB> don't forget to promote the gsoc2010 on your blog people!
[15:54:11] <BBB> </spam>
[15:54:15] <DonDiego> oops, i'm mixing up a few things there..
[15:54:39] <siretart`> how nice that svn stores passwords in plaintext in ~/.subversion. I probably would have had to ask for it :-)
[16:01:12] <CIA-17> ffmpeg: siretart * r21595 /branches/ (11 files in 9 dirs): backport symbol versioning patch
[16:03:59] <CIA-17> ffmpeg: siretart * r21596 /branches/ (0.5 0.5/Changelog): mention symbol versioning
[16:04:00] <siretart`> DonDiego: ok. I think I've followed your protocol for working on the 0.5 branch closely.
[16:04:35] <DonDiego> \o/
[16:04:50] <siretart`> DonDiego: next patch will be the cpu-runtime patches
[16:05:52] <siretart`> I guess you still want to approve them by mail first?
[16:07:37] <DonDiego> yes please
[16:08:49] <DonDiego> one more note for the next time:
[16:08:58] <DonDiego> the changelog update should be part of the commit itself
[16:09:01] <DonDiego> less clutter
[16:09:33] <siretart`> DonDiego: you said before 'make it a seperate commit', so that's what I did
[16:11:21] <DonDiego> oh, that was a misunderstanding
[16:11:36] <DonDiego> the changelopg update for trunk should be separate
[16:11:42] <DonDiego> nm
[16:11:43] <siretart`> ok
[16:12:02] <kierank> [15:43] <@BBB> who wants to mentor tasks for soc related to lossless audio? --> presumably that's dts-hd you're talking about?
[16:12:13] <kierank> or one of those other dts codecs
[16:13:03] <DonDiego> is there a wiki page for soc 2010 yet?
[16:13:33] <merbzt> DonDiego: there is
[16:15:56] <DonDiego> ah, the main soc page has not yet been updated..
[16:15:56] <jai> kierank: probably wmals or ralf
[16:16:06] <jai> kierank: maybe even alsenc
[16:16:28] <jai> (just a guess, dont go by what i say)
[16:21:06] <BBB> Dondiego: I will add it
[16:21:16] <BBB> kierank, I meant ralf/wmals
[16:21:24] <BBB> but dts-hd is fine also
[16:21:26] <jez9999> BBB: what nick are you on the bugtracker?
[16:21:31] <BBB> rbultje
[16:21:47] <DonDiego> BBB: i beat you to it ;)
[16:21:52] <jez9999> ah ok
[16:21:59] <BBB> darnit :)
[16:22:02] <BBB> thanks
[16:22:12] <BBB> any other tasks that I'm missing?
[16:22:19] <BBB> and we need to do suggested qualification tasks
[16:22:23] <BBB> if possible, where appropriate, etc.
[16:25:10] <DonDiego> finishing amr-nb is missing
[16:25:26] <ohsix> is this aliasing business a near term cleanup goal or is it just dark_shikari talking about it being done
[16:25:31] <DonDiego> add all the qual tasks from previous years
[16:25:45] <mru> ohsix: right now michael is pissing on it
[16:25:49] <DonDiego> and all suggestions for projects
[16:25:53] <DonDiego> the more the merrier..
[16:26:02] <ohsix> is that good or bad? and is that the cleanup idea or the aliasing =)
[16:26:18] <ohsix> i hope he knows what aliasing is
[16:27:21] <mru> aliasing must be kept in check
[16:27:28] <mru> otherwise the compiler will surprise you
[16:27:51] <ohsix> well ya; any plans to start sprinkling the code liberally with restrict?
[16:28:09] <mru> that's unrelated
[16:28:17] <BBB> DonDiego, I'm sure vitor / colin will finish amrnb before summer 2010
[16:28:36] <BBB> DonDiego, it's been submitted to -devel a few times already
[16:28:50] <BBB> (maybe superdump should help also :) )
[16:29:37] <superdump> huh wuh what's going on?
[16:29:45] * superdump reads the backlog
[16:31:04] <superdump> aha
[16:32:34] <DonDiego> hmm
[16:32:44] <DonDiego> isn't a better regtest system already done?
[16:38:39] <mru> lol, someone got to my blog by googling for gcc bashing
[16:50:47] <superdump> :)
[16:51:59] <mru> bashing is fun
[17:03:56] <mru> now I'm bashing libjpeg
[17:04:37] <Honoome> speaking about bashing, I'd really have to write more autotools bashing just to show how the heck they are making our lives more miserable… and pushing people who have no clue into writing _worse_ buildsystems >_<
[17:04:40] <ohsix> isn't that like bashing 1998
[17:05:21] <mru> a bit, yes
[17:05:45] <mru> but he deserves it
[17:06:07] <Honoome> autotools you mean?
[17:06:12] <mru> libjpeg
[17:06:19] <mru> autotools too of course
[17:07:47] <Honoome> libjpeg… I don't remember the last time a library changed ABI twice the same year
[17:07:53] <ohsix> 1998 stole my bike
[17:09:17] <Honoome> mru: the heck is that a technical proposal or a marketing brochure?
[17:09:35] <mru> good question
[17:10:10] <DonDiego> Honoome: please do, also, point out the ways to do things better.. - your autotools docs were very helpful to me..
[17:10:39] <Honoome> DonDiego: I always try to :) although this time the ones that would need to change the way they do things is upstream…
[17:10:58] <Honoome> I can go on repeating to use AS_HELP_STRING as much as I want, but when the macros provided by autoconf and automake themselves don't………
[17:15:03] <Honoome> mru: I can't believe the excerpt at the end… please tell me it's just a joke gone bad
[17:15:17] <mru> go read the thread for yourself
[17:20:27] <DonDiego> which thread?
[17:20:59] <mru> the one I linked to
[17:21:30] <mru> http://groups.google.com/group/comp.dsp/browse_frm/thread/4eb02c1d668daa7d
[17:26:03] <av500> mru: typo: "...as the quantiser in increased.."
[17:26:18] <mru> where's the typo?
[17:27:13] <av500> in -> is, no?
[17:27:22] <mru> I'm blind
[17:36:26] <Compn> Honoome : i think the 1mb configure script is enough of a reason to hate auto*
[17:36:43] <ohsix> you mean the generated files?
[17:36:54] <Compn> nope
[17:37:39] <ohsix> nice, people usually break em up, and the project into submodules before that happens
[17:38:42] <Compn> of course, now i cant find it
[17:38:50] <Compn> google only has two hits for '1mb configure script'
[17:39:09] <mru> what about 2mb?
[17:39:19] <jai> Compn: try "autotools sucks"
[17:40:14] <Compn> It's really disturbed me, sometimes, shipping a package of 50kB source
[17:40:14] <Compn> and 2MB configure+libtool.
[17:40:23] <Compn> http://www.mail-archive.com/linux-embedded@vger.kernel.org/msg00349.html
[17:41:20] <Compn> ah "huge configure script" mentions autotools more
[17:41:29] <ohsix> its always best to judge something on how random people abuse it :>
[17:41:42] <Compn> you bet.
[17:45:59] <Honoome> Compn: I'd still take that over about 3/4 of the custom-tailored build systems
[17:47:03] <ohsix> bodging' another test in a script instead of modifying the build tool is nice
[17:49:20] <Compn> ohsix : so you are saying its broken a lot too? :P
[17:50:11] <ohsix> it allows for some pretty crazy circumstances without having to switch to another tool, cant say that about the others
[17:51:24] <Compn> just trolling ;p
[18:38:26] <DonDiego_> hey, anybody here for whom dcc works?
[18:38:37] <DonDiego_> i want to try my new router configuration
[18:38:51] <ohsix> me, why? people can recieve if they have their stuff set up, sending is the hard part :>
[18:39:44] <DonDiego_> can you dcc me a file please?
[18:40:44] <ohsix> sure, but it will work; my stuff is set up right
[18:41:11] <DonDiego_> i want to verify both directions, please try, thx
[18:41:39] <ohsix> dcc is one direction :D sender says HEY theres a port at this file! then the other guy connects back
[18:41:52] <ohsix> file at this port, even
[18:41:55] <DonDiego_> lol, good one :)
[18:42:08] <DonDiego_> the file you sent i mean :)
[18:42:12] <ohsix> :)
[18:42:27] <DonDiego_> i assume this is coming from a private nat address?
[18:42:46] <ohsix> yea, you need to tell your irc client to use the outside address; 10:42 [freenode] DCC SEND from DonDiego_ [192.168.2.42 port 38880]: dude.txt [9kB]
[18:46:44] <ohsix> its weird, i was just explaining dcc to someone else; they always just leave it "broken" but they dont know that means they can still recieve files :>
[18:46:56] <ohsix> unless both ends are broken, then its hopeless
[18:53:48] <DonDiego_> hmm, i guess my client needs to know the ip of the router in any case..
[18:53:55] <DonDiego_> i.e. the external real ip..
[18:56:33] <ohsix> DonDiego_: yea, but most can be setup to get it from USERHOST when your irc client connects (then the irc server tells them their address)
[18:58:09] <DonDiego_> do you happen to know the irssi setting?
[18:58:31] <ohsix> hm i haven't had to set it, sec
[18:59:35] <ohsix> it may need a script to do it, i dont see anything about it being automatic, but dcc_own_ip is what needs to be set
[18:59:47] <ohsix> something like that will be in the irssi script repo
[19:00:20] <DonDiego_> ok, i just set dcc_own_ip
[19:00:25] <DonDiego_> are you getting something?
[19:01:42] <ohsix> http://scripts.irssi.org/scripts/dcc_ip.pl
[19:02:12] <ohsix> i only just tried to recieve, if it timed out you'll have to resend
[19:02:34] <DonDiego_> i just resent
[19:02:46] <ohsix> its picking random ports
[19:02:58] <ohsix> set dcc_port to something
[19:04:28] <DonDiego_> next try ..
[19:04:53] <ohsix> 11:04  DonDiego_ GET: 0B of 9kB (0%) - 0.00kB/s - ETA (stalled) - dude.txt
[19:04:59] <ohsix> 11:04 [freenode] DCC SEND from DonDiego_ [84.63.14.108 port 50000]: dude.txt [9kB]
[19:05:13] <ohsix> (stalled means i cant reach the port)
[19:05:28] <DonDiego_> ok, i'll need to forward it of course..
[19:09:19] <DonDiego_> one more time..
[19:10:54] <ohsix> huzzah
[19:11:38] <DonDiego_> you got it..
[19:11:46] <ohsix> i did
[19:12:10] <ohsix> you might want to change your port from 50000 now :> people can hammer it and get any file you offer
[19:14:20] <DonDiego_> enough for today
[19:14:25] <DonDiego_> thx for the assistance...
[19:51:09] <CIA-17> ffmpeg: stefano * r21597 /trunk/libavfilter/vf_scale.c: Use pixel format descriptors to check if the input format is paletted.
[20:31:13] <Dark_Shikari> hmm, who was it who wanted me to write up some qualification tasks for ffmpeg soc projects?
[20:32:40] <BBB> me
[20:32:48] <BBB> if you have time etc.
[20:33:01] <Dark_Shikari> I won't write up full qual tasks but I can go through them and note my ideas
[20:33:04] <BBB> http://wiki.multimedia.cx/index.php?title=FFmpeg_Summer_Of_Code_2010
[20:33:08] <BBB> yeah, that's what I mean
[20:33:10] <Dark_Shikari> WVP2: It'll have to be something reverse-engineering based, since it's primarily an RE task
[20:33:13] <BBB> I'll write it out in the next few days
[20:33:19] <BBB> all those projects aren't full-fledged either
[20:33:20] <Dark_Shikari> I'd suggest some BASIC RE task involving WVP2
[20:33:29] <BBB> basic as in...?
[20:33:35] <BBB> RE the frame parser for wvp2?
[20:33:40] <BBB> or get the dll running?
[20:33:53] <Dark_Shikari> i.e. make your best attempt to RE the header formats
[20:33:57] <Dark_Shikari> or something like that
[20:34:00] <BBB> ok
[20:34:06] <Dark_Shikari> doesn't matter, something simple but not trivial
[20:34:38] <Dark_Shikari> Flash Screen Video 2: I don't really know about this format enough to give a good task
[20:35:18] <Dark_Shikari> yeah, some of these are harder to make x264-style qual tasks for
[20:35:25] <Dark_Shikari> though it could just be because I don't know enough about them
[20:35:59] <Dark_Shikari> for libavfilter: write one filter
[20:40:08] <BBB> merbzt, what happened to your RE wiki page?
[20:40:10] <BBB> it's gone
[20:44:25] <BBB> ok, added some description to wvp2
[20:45:11] <BBB> jai: have you worked on ralf yet?
[20:45:24] <BBB> oh he's not here
[20:45:46] <drv> there is a thread with some encoder and decoder patches for flashsv2 on the ML
[20:47:47] <mru> saste: you still haven't registered
[20:48:09] <saste> yes doing that now
[20:52:57] <saste> I should be registered now
[20:53:13] <saste> can someone confirm that this is actually a bug:
[20:53:16] <saste> http://thread.gmane.org/gmane.comp.video.ffmpeg.user/25100
[20:53:29] <saste> ffmpeg 0.5 is not installing the imgconvert.h header
[20:53:48] <saste> or am i badly missing something?
[20:55:00] <saste> thanks mru
[21:28:22] <BBB> I'm confused
[21:28:30] <BBB> what should the last argument of INIT_VLC_STATIC() be?
[21:30:30] <mru> the size
[21:30:36] <mru> of the allocation
[21:30:38] <mru> it is a bit confusing
[21:30:43] <mru> put something large first
[21:30:47] <mru> then run it
[21:30:54] <mru> it'll print what size was actually needed
[21:31:05] <BBB> ?
[21:31:11] <BBB> I'm very confused
[21:31:15] <BBB> is it defined?
[21:32:11] <BBB> I have tiny tables, 22 entries
[21:32:14] <BBB> I put 500
[21:32:16] <BBB> it still aborts
[21:32:36] <BBB> isn't that weird?
[21:32:52] <mru> what value for bits are you passing?
[21:33:57] <BBB> oh, it reinitializes
[21:34:00] <BBB> that's bad?
[21:34:05] <mru> uh?
[21:34:35] <mru> pass (1<<bits)*(max_length/bits)
[21:34:42] <mru> or just put something huge
[21:34:48] <mru> it will tell you what the correct value is
[21:34:51] <BBB> yeah, 132 worked
[21:34:55] <mru> because it's hard to calculate
[21:35:00] <BBB> but it still aborts because the table is already initialized
[21:35:04] <BBB> I'm wondering why
[21:35:07] <BBB> (line 264 of bitstream.c)
[21:35:08] <mru> you're doing something wrong then
[21:35:37] <mru> look at some other place that does it
[21:46:47] <BBB> ok now it works
[21:49:13] <aclarke> i'm in process of trying to add codec-specific options support
[21:49:35] <aclarke> I assume introducing the concept of "avcodec_init()" and "avcodec_free()" before calls to avcodec_open and avcodec_close will be shot down?
[21:49:46] <aclarke> (I need something to allow allocing of codec specific options structs)
[21:50:00] <mru> every attempt at codec options or even defaults has been shot down
[21:50:14] <aclarke> the methods would be OPTIONAL (i.e. if you don't call them, you just can't set codec-specific options)
[21:50:44] <aclarke> do you know the major reasons why it was shot down?  hate to reinvent the flame^H^H^H^H^Hwheel.
[21:51:13] <mru> michael didn't believe it was necessary
[21:51:36] <Dark_Shikari> not long ago, he approved the idea
[21:51:37] <Dark_Shikari> iirc
[21:51:39] <Dark_Shikari> in an email
[21:51:46] <mru> ah, that's progress
[21:51:50] <Dark_Shikari> codec-specific defaults he did too I think
[21:52:27] <BBB> yes
[21:52:34] <BBB> I remember that
[21:52:58] <aclarke> k; progress good
[21:53:18] <aclarke> now, i need a way to alloc a codec-specific options struct in a AVCodecContext, but it has to happen before avcodec_open
[21:53:55] <aclarke> my proposal is "avcodec_init(AVCodecContext*,AVCodec*)" and "avcodec_free(AVCodecContext*)" if you called init
[21:53:58] <aclarke> thoughts?
[21:54:49] <aclarke> my thinking here is that then we can add various libx264 options that don't need to pollute AVCodecContext but use the existing AVOption-based method of setting/getting
[21:55:04] <Dark_Shikari> well we should start by adding codec-specific defaults
[21:55:14] <mru> that shouldn't be too hard
[21:55:18] <Dark_Shikari> i.e. have param_default call a per-codec itnitialization function
[21:55:23] <Dark_Shikari> which is optional
[21:55:25] <aclarke> yeah; there would be a callback on the AVCodec* option that can set defaults when you call avcodec_init
[21:55:25] <Dark_Shikari> thus trivial to implement
[21:55:30] <Dark_Shikari> yup
[21:55:32] <mru> you don't even need that
[21:55:35] <Dark_Shikari> in fact, we should do that right now
[21:55:41] <mru> just an optional AVOption array in each codec
[21:55:43] <Dark_Shikari> then we can clean up the vpres
[21:56:37] <aclarke> @mans I could just assume priv_data is an option-settable think if AVCodec->options is an option array?
[21:56:40] <aclarke> s/think/thing
[21:56:40] <mru> and add an avcodec_alloc_context3() that takes an AVCodec*
[21:56:58] <aclarke> that was my first attempt exactly
[21:57:02] <mru> aclarke: not so hasty
[21:57:35] <aclarke> I thought avcodec_init(...) worked better because once we do this, you can no longer just av_freep(avctx) like you can the results of avcodec_alloc_context3
[21:57:47] <aclarke> @mans ok... will type slower?
[21:58:29] <mru> there isn't an alloc3
[21:58:45] <mru> we could certainly add a context_free() function too
[21:58:56] <mru> that's rather unrelated to the interface used to init it
[21:59:06] <aclarke> i could do that as well
[21:59:40] <aclarke> i could change avcodec_alloc_context2 to take a type or a AVCodec since 'technically' it's not part of the public API, but I think it's been there long enough that people treat it as public
[22:00:36] <mru> we'd have to mess with the lib version either way
[22:01:54] <aclarke> or require codecs to be able to work if for some reason their codec-specific-options are NULL (which I prefer because it's more backwards compatible).
[22:02:07] <aclarke> and really the main area where I'd be adding this is into libx264.c
[22:02:27] <aclarke> (well, I plan to do a similar think eventually in AVFormatContext and for flvenc.c to enable some speex packaging options)
[22:09:40] <CIA-17> ffmpeg: michael * r21598 /trunk/ (tests/ref/lavf/ogg tests/seek.regression.ref ffmpeg.c):
[22:09:40] <CIA-17> ffmpeg: Check pkt.pts against the recording time.
[22:09:40] <CIA-17> ffmpeg: This fixes at least ogg encoding with -t where the file was slightly too long.
[22:12:45] <aclarke> k; to avoid overriding priv_data I'll take the approach of adding a new member
[22:18:04] <CIA-17> ffmpeg: stefano * r21599 /trunk/ffplay.c: Reindent.
[22:24:06] <CIA-17> ffmpeg: stefano * r21600 /trunk/ffplay.c:
[22:24:06] <CIA-17> ffmpeg: Use parentheses around && within ||, fix the gcc warning:
[22:24:06] <CIA-17> ffmpeg: ffplay.c: In function ?video_thread?:
[22:24:06] <CIA-17> ffmpeg: ffplay.c:1391: warning: suggest parentheses around && within ||
[22:32:58] <KotH> bon nuit mes enfants
[22:41:53] <aclarke> au revior
[23:07:43] <iive> mru: 2 blog posts in just 2 days...
[23:08:18] <iive> ok 3.
[23:08:56] <mru> the jpeg one has been a while in the making
[23:09:34] <iive> the scan order seems intresting. does it produce any better results?
[23:10:54] <CIA-17> ffmpeg: cehoyos * r21601 /trunk/libavformat/ (mpegts.c rtpdec.c mpegts.h):
[23:10:54] <CIA-17> ffmpeg: Fix warnings about implicit function declaration when compiling rtpdec.c
[23:10:54] <CIA-17> ffmpeg: Patch by Alexis Ballier, alexis D ballier A gmail
[23:15:06] <Dark_Shikari> mru: you should linkify "major breakthrough"
[23:15:08] <Dark_Shikari> to your old blog post
[23:15:27] <aclarke_> ugh; ffmpeg.c option setting is squicky
[23:17:36] <Dark_Shikari> mru: why don't you add an h264 comparison to the post?
[23:17:38] <Dark_Shikari> that would make it more awesome
[23:19:32] <Dark_Shikari> mru: also, the phrase is "swings again"
[23:19:36] <aclarke_> @mans what's the blog link?
[23:25:33] <saste> aclarke: there was a discussion on ffmpeg-devel sometime ago on per-codec options
[23:25:41] <saste> should be easy to find it
[23:31:20] <CIA-17> ffmpeg: mru * r21602 /trunk/libavformat/mpegts.c: Fix build
[23:32:13] * mru looks at fate and weeps
[23:57:42] <ramiro> is anyone able to shed some light on michael's response for me here: http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-January/082066.html
[23:58:04] <ramiro> I still don't understand how this array_index type would work nor how it would make things better
[23:58:23] <mru> me neither
[23:58:31] <mru> there's nothing that special about array indexes