[FFmpeg-devel-irc] IRC log for 2011-02-16

[irc at mansr.com]

[00:00:07] <j-b> iive: ok
[00:00:07] <kierank> it's also consistent with x264 which is good
[00:00:53] <michaelni> LGTM
[00:01:10] <michaelni> .... but iam sure you can biekshed it more ....
[00:01:13] <j-b> http://pastebin.com/ySqdSiNu
[00:01:22] <j-b> for the libavutil part
[00:01:26] <iive> j-b: you could assume that the buffer is filled with constant speed (TS stream, dvd/cd), but frames are of different size.
[00:01:28] <j-b> not sure about the MICRO part though
[00:01:45] <kierank> iive: in vbv the buffer is filled at a constant rate
[00:01:59] <kierank> i.e maxrate
[00:02:12] <Dark_Shikari> only in cbr
[00:03:02] <michaelni> j-b, LGTM but its bikeshedable like retunrned error code and what ver to bump
[00:03:42] <mru> it adds something to external api -> minor bump
[00:03:55] <j-b> ok
[00:04:04] <michaelni> blue ! :)
[00:04:08] <j-b> but error code?
[00:04:20] <mru> inval seems ok
[00:04:27] <michaelni> something permission and access denied maybe :)
[00:04:38] <mru> it's not really a permission thing
[00:04:45] <mru> it's an invalid thing to attempt
[00:04:57] <j-b> not EIO, nor ENOENT, nor EILSEQ or ENOMEM nor ENOSYS
[00:05:05] <iive> j-b: actually I think that vbv should be decided entirely by the encoder. it is the one who knows frame complexity and how big frames would be. this means that the delayed setting of it is the best course of action.
[00:05:09] <mru> ENOPAINT
[00:05:10] <j-b> EDOM is a bit different
[00:05:14] <dalias> lu_zero, lifted?
[00:05:26] <mru> EDOM would be correct for out of range values
[00:05:29] <lu_zero> dalias: like from boehm
[00:05:30] <Sean_McG> EEPIC_FAIL?
[00:05:34] <j-b> iive: I think I understand it
[00:05:36] <dalias> ah
[00:05:49] <dalias> i'm sure there's some source you could look at to find how to do them on arm
[00:05:51] <j-b> iive: the tip of the iceberg. thx
[00:05:57] <michaelni> premission is not so wrong, read only here means you as outsider cant write toi  it the codec after all can
[00:05:58] <dalias> i just know x86 asm so i wrote the originals myself
[00:06:07] <iive> j-b: i'm glad i've been of some use.
[00:06:24] <mru> there are perfectly good manuals from arm and linux kernel
[00:06:28] <lu_zero> I wrote some fixes for ppc64 loong ago to libatomic_ops
[00:06:40] <lu_zero> so that code looked quite similar
[00:06:45] <mru> atomic ops on arm are similar to ppc
[00:07:29] <iive> kierank: it can't be filled at max rate, because then it should be emptied at max rate. it should be filled at average rate. aka the normal rate.
[00:07:49] <mru> iive: constant rate is constant
[00:07:49] <kierank> iive: read annex c
[00:07:57] <Dark_Shikari> iive: "max rate" is the rate of inflow to the buffer
[00:08:00] <Dark_Shikari> there is NO maximum on outflow rate.
[00:08:19] <mru> Dark_Shikari: each coded picture has to fit in the buffer
[00:08:21] <j-b> michaelni: EPERM ?
[00:08:24] <mru> that does impose a limit
[00:08:28] <mru> j-b: no, perm is wrong
[00:08:39] <mru> that implies that someone else could do it
[00:08:47] <michaelni> mru, encoder ...
[00:08:56] <j-b> EINVAL seems the best, so far
[00:09:06] <michaelni> j-b, perfectly fine with me :)
[00:09:23] <mru> j-b: care to send a git patch?
[00:09:23] <j-b> ok, then I should create 2 patches and send them?
[00:09:27] <j-b> mru: sure
[00:09:30] <mru> j-b: please do
[00:09:33] <dalias> are you guys choosing which posix error codes make sense for codecs to return? :)
[00:09:43] <michaelni> :)
[00:09:43] <mru> something like that
[00:09:45] <j-b> mru: that'll make me learn to read the doc
[00:10:00] <dalias> nice not to be reinventing the wheel :)
[00:10:17] <mru> dalias: exactly
[00:10:48] <michaelni> POSIX should have a EPATCHWELCOME ...
[00:10:57] <michaelni> and EBIKESHED
[00:11:02] <Sean_McG> hahah
[00:11:25] <mru> 00:05 <@mru> ENOPAINT
[00:11:32] <michaelni> yes
[00:12:01] <j-b> mru: should I send 2 patches for the 2 different trees?
[00:12:19] <michaelni> j-b, commit to videolan :)
[00:12:41] <j-b> michaelni: well, to send to the mls
[00:13:09] <michaelni> doesnt one apply to both trees?
[00:14:08] <j-b> well, libavutil.MICRO is 37 vs 38
[00:14:16] <michaelni> hmpf
[00:14:29] <mru> j-b: send whatever, I'll fix that
[00:14:33] <michaelni> id say send one, cherry picking and fixing up is trivial
[00:25:49] <Sean_McG> mru: I'm still not sure why your and kostylev's ppc builds don't both have the vp8 SEGVs
[00:26:17] <mru> probably a memory alignment thing
[00:26:32] <Sean_McG> the only real difference is that he builds with -O3
[00:26:45] <Sean_McG> oh wait and gcc 4.5.2
[00:26:58] <mru> everybody builds with -O3
[00:27:04] <mru> it's the default
[00:27:09] <mru> in configure
[00:27:22] <mru> my guess is some read is slightly out of bounds and some machines happen to have an unreadable page there
[00:27:50] <mru> valgrind complains
[00:27:50] <Sean_McG> but looking at the patch that broke them, I think I know why... there's a 24-element char array that's being fed to altivec that probably isn't 16-byte aligned
[00:28:18] <Sean_McG> which would actually match the valgrind complaint
[00:28:23] <mru> gcc 4.0 is plain broken
[00:28:26] <mru> it never passed
[00:28:29] <j-b> mru: michaelni: sent to ml, and http://people.videolan.org/~jb/f-ffmpeg-patches/ http://people.videolan.org/~jb/v-ffmpeg-patches/
[00:28:39] <j-b> I hope I didn't mess up too much...
[00:28:46] <j-b> hopefully, I am French :)
[00:29:02] <mru> are you hopefully french?
[00:29:08] <mru> what would be the worse option?
[00:30:07] <j-b> I am French, so I can't be worse than that. So anything I do that is stupid is expected :D
[00:30:49] <mru> hmm, that will still print the option in the -help listing
[00:30:58] <mru> unless I'm missing something subtle
[00:31:38] <michaelni> needs a change to show_help_options()
[00:31:47] <michaelni> to not proint read only fields
[00:32:08] <mru> wrong function
[00:32:42] <mru> opt_list() in opt.c seems like the right place
[00:34:28] <j-b> hmm, exact
[00:34:41] <michaelni> no
[00:34:53] <michaelni> why dont you want to list read only options?
[00:35:07] <mru> show_help_options() doesn't even touch that list
[00:35:14] <michaelni> for "internal" ABI options yes
[00:35:24] <michaelni> opt_list() would be correct
[00:35:28] <j-b> show_help_options doesn't seem to use AVOption, I was confused
[00:35:36] <mru> j-b: it doesn't
[00:35:48] <michaelni> j-b, yes it would have been insufficient
[00:35:48] <j-b> <= confused
[00:36:19] <michaelni> if you guys insist on readonly flag then its updating the show_whatever stuff in ffmpeg/ffplay.c
[00:36:36] <michaelni> or add a abi flag like i suggested and do the chek in opt_list()
[00:36:39] <mru> add the flag to the skip mask in show_help()
[00:36:42] <michaelni> but iam happy to hear better ideas
[00:37:22] <michaelni> mru, yes thats what iove meant with updating ffmpeg/ffplay.c
[00:37:33] <mru> I didn't imply otherwise
[00:37:41] <michaelni> its a much bigger change though
[00:37:52] <michaelni> than what a abi flag would need
[00:38:20] <michaelni> and it break AVOption ABI/API a little
[00:38:35] <j-b> then, this is out of my capabilities
[00:38:37] <michaelni> by apps needing such change ...
[00:38:51] <j-b> Did my best though
[00:39:09] <michaelni> j-b, thanks anyway
[00:39:17] <j-b> sure
[00:41:53] <Sean_McG> hmmm patches.ffmpeg ain't responding
[00:43:36] <j-b> gn people
[01:02:36] <Sean_McG> I think it's almost beer o-clock
[01:14:57] <lu_zero> dalias: half of the code you need is available in libatomic_ops (MIT)
[01:15:39] <dalias> the atomics are like a 5-min job :)
[01:16:06] <lu_zero> less since is copy&paste =P
[01:16:21] <dalias> its clone, set_thread_area, setjmp/longjmp, unmapself that take a little work
[01:16:30] <dalias> unmapself is my fav asm in musl
[01:16:51] <dalias> it written in asm because the function unmaps its own stack :)
[01:17:06] <mru> scary
[01:17:22] <dalias> used so that detached threads can cleanly exit without leaking memory
[01:17:26] <lu_zero> x_x
[01:17:44] <dalias> glibc's approach is to keep a linked list of orphaned thread stacks and reuse them
[01:18:11] <dalias> but that can waste lots of memory and has potential for lock contention updating the list
[01:18:19] <lu_zero> the math ops aren't already provided by gcc btw?
[01:18:32] <dalias> on gcc 4, yes
[01:19:45] <dalias> i'm thinking about updating the code to use them if the compiler provides them and only fallback to asm when it doesn't
[01:20:16] <dalias> but i'd like to support tcc, pcc, etc. without having to wait for them to mimic gcc __builtin_*
[01:20:43] <mru> the atomics in gcc suck badly on arm
[01:20:49] <mru> those that exist at all
[01:21:38] <dalias> then its prolly best not to use them
[01:22:10] <dalias> btw i hear some old arms lack proper atomic ops
[01:22:40] <mru> maybe some really ancient ones
[01:22:50] <dalias> is it worth trying to support that crap?
[01:23:30] <dalias> my thought is to target the modern stuff and if really necessary, maybe add an "arm-ancient" arch with workarounds for broken stuff
[01:23:48] <mru> do you need byte, halfword, or double-word atomics?
[01:24:12] <dalias> just 32-bit and pointer-sized
[01:24:16] <dalias> mostly 32-bit
[01:24:23] <mru> and pointers are 32-bit on arm
[01:24:37] <mru> then you can support armv6 and later with the modern implementation
[01:24:49] <mru> armv5 uses a different strategy for atomic ops
[01:24:57] <dalias> how does v5 work?
[01:25:07] <mru> locks the bus
[01:25:13] <mru> which doesn't scale well
[01:25:18] <mru> and is hard to implement
[01:25:49] <mru> armv6 added ldrex/strex instructions
[01:26:11] <mru> same style as on ppc, alpha, etc
[01:26:27] <dalias> http://lwn.net/Articles/314561/
[01:26:27] <mru> v6k added non-word size versions of those
[01:28:01] <mru> that's not atomic
[01:28:16] <BBB> hm, I wrote the idct and it didn't crash
[01:28:19] <BBB> it doesn't work either
[01:28:20] <BBB> but hey
[01:28:23] <BBB> that's better than nothing
[01:28:24] <BBB> :-p
[01:28:39] <dalias> mru, the kernel makes it atomic
[01:29:06] <dalias> by resetting the instruction pointer if it got interrupted in the middle
[01:29:12] <mru> ah, kernel helps
[01:29:18] <mru> sneaky
[01:29:25] <mru> but it's not smp-safe, as he points out
[01:29:39] <mru> and almost all arm systems do have another processor
[01:29:39] <dalias> and it stores that code at a special address so it can know if it's in the middle of an atomic op
[01:29:42] <dalias> right
[01:29:46] <dalias> even v5?
[01:29:50] <mru> of course
[01:29:53] <dalias> ah
[01:29:55] <dalias> that's useless then
[01:29:56] <mru> they're usually teamed up with a dsp
[01:30:04] <dalias> oh
[01:30:13] <dalias> not smp, specialized stuff
[01:30:26] <dalias> thats a whole 'nother game of hackery :)
[01:30:38] <mru> from this point of view, not really
[01:30:41] <mru> it's another bus master
[01:30:57] <mru> anything with access to the system bus can write to memory
[01:31:21] <dalias> yes but using the dsp to write to implementation-internal locking structures has UB anyway
[01:31:24] <mru> a truly atomic operation must somehow snoop or block such traffic
[01:31:46] <dalias> i agree for atomic ops on data shared with the dsp it matters
[01:31:53] <mru> you often need atomic ops to synchronise the arm and the dsp...
[01:32:12] <mru> for purely arm-side things it doesn't matter of course
[01:32:19] <dalias> but i doubt you use pthread_mutex_t for it :)
[01:32:27] <mru> you might actually
[01:32:39] <mru> if you're _really_ careful
[01:32:49] <dalias> only if you have a pthread implementation that's for both arm and the dsp..
[01:32:57] <mru> exactly
[01:33:07] <dalias> :)
[01:33:15] <mru> would make sense
[01:33:18] <dalias> that's cool but way outside the current problem domain
[01:33:51] <dalias> if armv5 is not going to be used in smp, for musl's purposes i probably don't have to care if there might be dsps
[01:34:28] <mru> there are actually some really obscure armv5 smp systems
[01:34:36] <mru> but I wouldn't worry about those
[01:34:46] <dalias> perhaps armv5 is just worth considering as a separate arch anyway
[01:34:53] <dalias> uclibc's approach is the worst
[01:35:05] <mru> supporting v6 and later is a good start
[01:35:16] <dalias> "getting interrupted between those 2 instructions will probably only happen once in 10 years and the device is more likely to fail for other reasons anyway"
[01:35:46] <dalias> :) :)
[01:35:48] <mru> be careful with such reasoning
[01:35:56] <dalias> i said it's the worst :)
[01:36:04] <dalias> i was mocking it
[01:36:05] <mru> sometimes it's applicable
[01:36:26] <mru> if the failure mode is catastrophic it's probably ok
[01:36:35] <mru> if it silently gives wrong answers, it's not
[01:36:45] <dalias> if that's really the case, i'd probably throw in a random spin of ~1000 cycles or so before the lock attempt
[01:36:51] <dalias> to make it even more unlikely
[01:44:15] <dalias> btw just a note
[01:44:35] <dalias> musl's use of atomics requires them actually be the same as the underlying types
[01:44:51] <dalias> no hacks of making an atomic_int type that has a separate lock incorporated in it
[01:47:18] <BBB> anyone wants to develop a codec for $1000?
[01:47:27] <mru> are you joking?
[01:47:32] <BBB> that's what I thought
[01:47:33] <BBB> :-p
[01:47:39] <BBB> https://roundup.ffmpeg.org/issue421
[01:47:54] <BBB> maybe there's a 0 missing, plus a *2-5 multiplier
[01:48:08] <mru> 50k would be worth considering
[01:48:16] <bcoudurier> 50k ?
[01:48:19] <BBB> some people would do it for 25k
[01:48:23] <Jumpyshoes> BBB: how hard is it :P
[01:48:23] <BBB> I'd probably do it for 25k
[01:48:29] <BBB> Jumpyshoes: requires RE'ing
[01:48:31] <BBB> Jumpyshoes: it'd be fun
[01:48:35] <BBB> Jumpyshoes: want to try?
[01:48:43] <Jumpyshoes> hrm... sure
[01:48:46] <BBB> Jumpyshoes: warning, $1000 is not a lot :)
[01:48:47] <bcoudurier> nobody's gonna pay 25k
[01:49:02] <Jumpyshoes> BBB: when your income is 0, it is
[01:49:04] <BBB> bcoudurier: probably not in public, no :(
[01:49:26] <mru> let's just say I've done business with codecs...
[01:49:42] <mru> 25k to RE and implement an entire codec is low
[01:49:53] <bcoudurier> I've done business as well
[01:49:59] <bcoudurier> 25k is high
[01:50:03] <bcoudurier> for a single entity
[01:50:03] <mru> then you're underpaid
[01:50:37] <bcoudurier> you're paid what people want to pay for
[01:50:37] <mru> ok, for a lossless audio codec perhaps 25k is enough
[01:51:13] <dalias> :)
[01:51:19] <mru> chances are it's another variant of rice+lpc
[01:51:36] <bcoudurier> besides the foundation was offering $4000 for prores, if that is low I'd say we need to reconsider
[01:51:44] <kierank> mru: good to hear I have the right kind of ballpack figures as you ;)
[01:51:47] <BBB> bcoudurier: foundation doesn't pay market rate
[01:52:01] <bcoudurier> BBB and why not ?
[01:52:08] <BBB> bcoudurier: good question
[01:52:15] <BBB> bcoudurier: maybe it should, you're right
[01:52:26] <mru> maybe if had the funds, it could
[01:52:34] <BBB> although for prores I doubt we can achieve market rate
[01:52:37] <BBB> prores would cost a lot
[01:52:41] <BBB> as you no doubt know :)
[01:52:50] <bcoudurier> yes, that's why you get paid what people want to pay for it
[01:53:00] <Jumpyshoes> i think
[01:53:05] <Jumpyshoes> this file has debug info in it
[01:53:30] <BBB> Jumpyshoes: I have a wmavoice binary with debug in it
[01:53:31] <BBB> er
[01:53:33] <BBB> wmalossless
[01:53:35] <BBB> same thing btw
[01:53:35] <dalias> mru, looks like the kernel approach is considered the right way to do atomics on arm
[01:53:40] <BBB> it's the same binary
[01:53:46] <Jumpyshoes> lol
[01:53:47] <BBB> debugging it is relative easy
[01:53:48] <mru> dalias: armv6 doesn't need kernel help
[01:53:53] <dalias> it will use the real atomic opcodes on armv6
[01:53:56] <BBB> Jumpyshoes: it's the "wma" binary :)
[01:54:19] <mru> dalias: a function call for a 4-instruction sequence is silly
[01:54:32] <mru> call overhead is more than that
[01:54:44] <Jumpyshoes> haha
[01:55:06] <dalias> are you sure? i've found calls are pretty damn cheap these days but i dunno about arm
[01:55:21] <BBB> Jumpyshoes: if you're in, I can probably help you, I did the wmavoice part of the binary and it was quite fun, you could continue working from there on, but warning, it's audio, not video
[01:55:27] <mru> dalias: the call itself yes
[01:55:35] <dalias> if benchmarking showed an improvement for inlining the 4 ops tho, i'd have separata targets for arm6 and oldarm
[01:55:35] <mru> but you have to set up the arguments etc
[01:55:41] <BBB> (in the department of "well, that was kind of obvious" warnings)
[01:55:47] <Jumpyshoes> BBB: ah, true
[01:55:49] <dalias> mru, it's pass-by-register
[01:55:53] <mru> I know
[01:56:08] <mru> but what if your values aren't in the argument registers?
[01:56:24] <dalias> still just a couple cycles
[01:56:27] <mru> and if you're in an otherwise leaf function, you need to save your return address
[01:56:31] <mru> dalias: not so simple
[01:56:51] <mru> you need to shuffle whatever is in the arg regs elsewhere
[01:57:04] <mru> dalias: I write arm asm for a living, I should know...
[01:57:09] <dalias> :)
[01:57:30] <dalias> anyway benchmark is probably best
[01:57:45] <Jumpyshoes> BBB: they're nice enough to give decrypted strings :p
[01:57:50] <dalias> if there's measuable performance to be gained by inlining and making an arm6-specific build, go for it :)
[01:58:30] <BBB> Jumpyshoes: imagine that you know all function names
[01:58:39] <BBB> Jumpyshoes: and the binary looks like it's been compiled with -O0
[01:58:45] <BBB> Jumpyshoes: believe me, much nicer :)
[01:58:57] <Jumpyshoes> do you know the function names for this binary?
[01:59:57] <BBB> they're in the binary
[02:00:10] <BBB> we'll make you a master reverse engineer
[02:00:20] <BBB> you'll be able to figure it all out yourself
[02:00:35] <bcoudurier> I remember when hexrays wasn't available ...
[02:00:52] <BBB> I did it without hexrays :-p
[02:00:58] * BBB used just plain ida
[02:01:01] <bcoudurier> yes
[02:01:02] <Jumpyshoes> hexrays would... probably work really well on this binary
[02:01:17] <bcoudurier> wma3 started without hexrays
[02:01:48] <BBB> bcoudurier: want to help out teaching Jumpyshoes for wmalossless?
[02:02:00] <BBB> I can help him with the day-to-day stuff, if you help him setting up hexrays
[02:02:09] <BBB> which I've tried but apparently not enough
[02:02:11] <bcoudurier> do we have the linux .so ?
[02:02:22] <BBB> yes
[02:02:31] <BBB> but the wince binary has better debug symbols
[02:02:38] <bcoudurier> well cool
[02:02:40] <Jumpyshoes> >please bump back if not adequate. <-- maybe i should do this :p
[02:02:41] <BBB> (they're from the same source, just slightly different struct offsets)
[02:02:45] <bcoudurier> but after some point it's nice to hook up the lib
[02:02:51] <BBB> oh
[02:02:55] <BBB> you can do that with the wince one also
[02:02:58] <BBB> objconv
[02:03:13] <BBB> it gives individual object files
[02:03:14] <BBB> very easy
[02:03:41] <bcoudurier> you can execute them ?
[02:03:48] <BBB> yes
[02:03:53] <bcoudurier> that's nice
[02:04:01] <BBB> I did the whole thing for wmavoice
[02:04:13] <BBB> since it's the same binary, doing the same for wmalossless with the binary should be easy
[02:04:33] <BBB> (each codec has its own api in that lib, but once you know the functions and its parameters, it's easy)
[03:48:26] <funyun> hi. can anyone help me with crop? i've read the documentation but still don't understand it. i simply need to crop 2 pixels from the top
[04:13:18] <Compn> funyun : did you try #ffmpeg ?
[05:47:03] <astrange> BBB: https://roundup.ffmpeg.org/issue2609 wrote a diagnosis but i might not be able to get to it (or anything else) until monday
[07:13:48] <wbs> BBB: re the rtsp udp/tcp resetup bug, I do think it's valid, I just have to figure out how to reproduce it :-)
[07:49:53] <elenril> .....wow
[07:50:02] <elenril> git can deal with renamed files when mergind/rebasing
[07:51:13] <Tjoppen_> git is awesome :)
[07:51:29] <andoma> git is divine
[07:54:26] <KotH> einen wunderherrlichen guten morgen!
[07:54:36] <cartman> moin
[07:55:07] <KotH> selam cartman
[07:55:22] <cartman> ve aleyküm selam KotH :D
[07:57:53] <elenril> KotH: http://tvtropes.org/pmwiki/pmwiki.php/Main/BlackSpeech
[07:59:43] <KotH> elenril: es isch aber ka dütsch!
[08:04:01] <pJok> ohayou gozaimasu
[08:19:03] <uau> elenril: other VCSes can deal better with renamed files
[08:19:25] <elenril> how "better"
[08:20:48] <kshishkov> ClearCase?
[08:21:12] <uau> git's whole rename support is kind of hacky
[08:22:24] <uau> it has no proper rename tracking (as everything is based on heuristics), and as a result the things that try to do something with renames aren't very consistent or reliable about it
[08:22:45] <uau> for example git has no concept of directory renaming at all
[08:23:19] <uau> which can lead to various breakage when the unreliable per-file heuristics return different results
[08:24:33] <uau> for example i've seen one directory rename case where git thought that one file in the renamed directory was deleted, and a copy of another was created...
[08:26:32] <lu_zero> uau: it's the problem of having per line tracking
[08:35:49] <divVerent> uau: yes, personally, I prefer to "help" git to know about renames
[08:35:58] <divVerent> by doing a rename-only commit, and fixing up the references in a second commit
[08:52:59] <CIA-15> ffmpeg: Janne Grunau <janne-ffmpeg at jannau.net> master * rec25f83bd9 ffmpeg/libavformat/spdifenc.c:
[08:52:59] <CIA-15> ffmpeg: spdifenc: update 482d98f69b2eb7a7b0b5054101a43db384e9432b to the latest patch
[08:52:59] <CIA-15> ffmpeg: "spdifenc: IEC 61937 encapsulation of DTS-HD for HDMI"
[09:15:33] <DonDiego> btw, is anybody aware that our ogg demuxer fails when tracks change in streams?
[09:16:01] <DonDiego> ubitux mentioned that he could reproduce this issue
[09:16:14] <DonDiego> ubitux could you report a bug for this issue?
[09:16:28] <ubitux> on bugzilla?
[09:17:24] <ubitux> it's simple, start http streaming with icecast/mpd or just a recent mpd, run mplayer on the stream, switch song, shit bricks
[09:19:00] <DonDiego> no, on roundup please
[09:19:16] <DonDiego> also, can you reproduce with ffplay?
[09:19:42] <av500> can ffplay handle song changes at all?
[09:19:47] <iive> DonDiego: ogg puts each new track into new stream
[09:20:11] <kshishkov> av500: FFplay is overly British in spirit - it ignores any changes
[09:20:32] <ubitux> DonDiego: on sorry, i though i was on #mplayerdev.
[09:20:43] <j-b> good moroning
[09:21:40] <av500> +1
[09:21:50] <cartman> <<1
[09:22:08] <kshishkov> j-b: come visit Russia
[09:22:20] <j-b> kshishkov: great idea
[09:22:24] <thresh> not really
[09:22:29] <thresh> it's -23°C here now
[09:22:52] <thresh> well was in the moroning
[09:23:05] * cartman is freezing with 4°C atm.
[09:23:13] <kshishkov> thresh: Zoich?
[09:23:34] <kshishkov> thresh: or other warmer place?
[09:24:13] <kshishkov> thresh: and our Ben has visited Murmansk, big deal
[09:24:18] <pJok> kshishkov, so FFplay also only speaks one language?
[09:24:23] <thresh> kshishkov: zoich is a cool mascot, what do you mean by place?
[09:25:23] <ubitux> DonDiego: are you sure there isn't any issue already filled?; i asked several times and everyone seems aware of the issue
[09:26:21] <ubitux> (i can't test right now with ffplay)
[09:26:22] <kshishkov> thresh: a place where Zoich-2018 is held? Там где прикуп знают
[09:28:00] <thresh> kshishkov: 2014
[09:28:49] <thresh> it's actually a cool idea to held a winter olympics at a place with no snow in winter
[09:29:03] <cartman> "I donated you the same amount I give to beggars in the city; hope it helps you in finding a job. Best wishes!"
[09:29:05] <kshishkov> thresh: видимо с футболом попутал, магу ли йа скасать ат чистава серца паруски?
[09:29:08] <cartman> stylish donation
[09:30:12] <DonDiego> ubitux: no, i'm not sure, but i'm not aware of such a bug either and i did look for all ogg-related bugs at some point
[09:30:22] <thresh> for those of you who are still puzzled by what zoich is: http://rt.com/files/sport/other/sochi-2014-mascot-zoich/sochi-2014-mascot-zoich.n.jpg
[09:30:35] <thresh> it won an internet voting for a mascot for winter olympics
[09:30:41] <cartman> lol
[09:30:53] <av500> thresh: can it patch kde2 on bsd?
[09:31:12] <thresh> somehow officials didnt allow it to a second phase of voting ;( and only left the stupid ones :(
[09:31:18] <thresh> av500: most probably so
[09:31:51] <kshishkov> thresh: it's Russia and Zoich was not a member of ER
[09:33:56] <CIA-15> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r5d820db2f9 ffmpeg/libavformat/avformat.h:
[09:33:56] <CIA-15> ffmpeg: Document that av_write_header sets stream time_base to a value of it chosing.
[09:33:56] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[09:34:04] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r938b62538a ffmpeg/libavcodec/avcodec.h:
[09:34:04] <CIA-15> ffmpeg: Document audio_resample_close().
[09:34:04] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[09:34:06] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r5495528365 ffmpeg/libavcodec/avcodec.h:
[09:34:06] <CIA-15> ffmpeg: Apply minor cosmetics fixes to the av_audio_resample_init() doxy.
[09:34:06] <CIA-15> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[09:34:06] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[09:34:19] <iive> thresh: it is mighty quite, no wonder it won. ;)
[09:35:33] <thresh> indeed: http://zhgun.ru/pics/zoich/glory.gif
[09:36:37] <DonDiego> what is this beast? a hairy frog on lsd?
[09:37:00] <kshishkov> DonDiego: so you've never seen Futurama, eh?
[09:38:35] <iive> kshishkov: hipnotoad is much more cute.
[09:39:26] <kshishkov> iive: well, of course, but here it's not about world domination either
[09:40:26] <thresh> but Zoich actually shows the Russian majesty and spirituality
[09:40:35] <thresh> it has a crown
[09:42:21] <iive> thresh: and the crown looks like hand showing a finger...
[09:43:02] <thresh> iive: for this words I will invade .bg in May
[09:43:55] <iive> thresh: too late, it was invaded 66 years ago, in september.
[09:48:12] <thresh> yeah we beat the crap out of nazis
[09:50:57] <kshishkov> yes, Russia remembers all great victories it had, there are too few of them anyway
[09:53:34] <thresh> yeah not much to be proud of now :(
[10:23:03] <j-b> anyone near Hannover?
[10:24:01] <DonDiego> define near :)
[10:24:07] <DonDiego> i'm in the same country...
[10:25:39] <kshishkov> I'm in different Bunderländle
[10:25:53] <kshishkov> so Janne may be the closest
[10:26:31] <jannau> j-b: looking for a place to sleep during cebit?
[10:26:52] <av500> j-b: sleep in göttingen and take the ICE in the morning
[10:27:07] <av500> is faster than car/pubic transport in hannover
[10:27:23] <DonDiego> you are welcome to sleep here in aachen, the thalys from paris passes through here...
[10:27:24] <jannau> and probably less expensive
[10:27:29] <av500> yep
[10:27:43] <kshishkov> av500: more punctual too?
[10:27:43] <KotH> av500: pubic transport?
[10:29:24] <j-b> near, as in can go attend the opening ceremony, so I can give him free tickets
[10:30:55] <jannau> j-b: the free tickets are still physical tickets and not coupons for electronic tickets?
[10:31:33] <j-b> jannau: for the opneing ceremony, it is quite special, I think
[10:31:51] <av500> special as in mrs merkel will be there
[10:32:11] <kshishkov> av500: do you care about her?
[10:33:05] <kierank> hmmm I want to see angela merkel
[10:33:18] * kierank considers going again
[10:33:41] <av500> kshishkov: nope, thats why i think that cebit opening is useless
[10:33:52] <jannau> but who wants to go to the opening ceremony? /me has trouble to imagine less interesting events
[10:33:58] * av500 files kierank under "wierd brit"
[10:34:57] <kierank> av500: along with mru
[10:35:04] <kierank> ?
[10:35:16] <j-b> av500: yes, which is why they break our b*lls with security and registration
[10:36:00] <kierank> they are not particularly paranoid about security for the prime minister or the royal family here
[10:36:13] <av500> j-b: as her how to patch KDE2 under BSD
[10:36:34] <j-b> av500: I really doubt I will go
[10:36:58] <elenril> what's up with obscure russian memes
[10:37:02] <kshishkov> kierank: have you ever thought that Brit with name MÃ¥ns may be not weird but rather not Brit?
[10:37:11] <kierank> av500: ?
[10:38:14] <kierank> kshishkov: no
[10:38:27] * kierank doesn't see why mru shouldn't be classed as british
[10:38:48] <spaam> why should he?
[10:39:04] <spaam> swedish > british
[10:39:04] <kshishkov> kierank: double-classed
[10:39:24] <kshishkov> spaam: it's Britain, they have a long history of importing their great men
[10:39:35] <kierank> kshishkov: importing our royalty too
[10:40:03] <spaam> kshishkov: haha
[10:40:20] <kshishkov> kierank: almost everybody got their royalty from Germany (except Danes and Scandinavia)
[10:40:55] <spaam> kshishkov: you know.. our king grand grand... father is not swedish..
[10:41:10] <kshishkov> spaam: jag vet det
[10:41:18] <spaam> kshishkov: vad bra :)
[10:41:37] <kshishkov> spaam: men Bernadotte är riktig svensk namn nu
[10:41:59] <spaam> kshishkov: ja.
[11:18:42] <mru> kierank: so why should I be classed as british?
[11:19:08] <kshishkov> mru: as the guy who lives in Southampton probably
[11:19:31] <av500> and goes to pub lunches every day
[11:20:09] <kierank> mru: why one is classed as british is unwritten. It's like the british unwritten constitution
[11:20:13] <kierank> you just *are* british
[11:20:50] <mru> how do you know, you haven't even met me?
[11:21:02] <kierank> true
[11:21:20] <mru> the occasional monty python quote doesn't make a man truly british
[11:21:38] <kierank> i've heard your accent though
[11:22:25] <av500> mru: viciously denying it make you all the more suspect :)
[11:22:41] <Flameeyes> mru: you sure look a heck of a brit :)
[11:23:09] <av500> [VOTE] is Mans a brit?
[11:23:20] <av500> i vote YES
[11:23:21] <kshishkov> just ask him if he has a spare morakniv
[11:23:24] * Flameeyes votes YES
[11:23:26] <spaam> i vote NO
[11:23:44] <kshishkov> spaam: you should vote NEJ then
[11:23:50] <spaam> kshishkov: ok
[11:23:54] * kshishkov does not vote (as usual)
[11:23:56] <spaam> jag röstar NEJ
[11:24:40] <spaam> since im from .se my vote counts more :)
[12:07:32] <lu_zero> NEJ
[12:07:49] <lu_zero> is that a pop-quiz?
[12:09:42] <kshishkov> lu_zero: lära svenska, är du snäll?
[12:13:19] <lu_zero> Försöker
[12:13:56] <CIA-15> ffmpeg: Balint Marton <cus at passwd.hu> master * r22ec6b738f ffmpeg/libavformat/utils.c:
[12:13:56] <CIA-15> ffmpeg: Fix av_find_best_stream when using a program
[12:13:56] <CIA-15> ffmpeg: The current implementation has a bug, it is returning the stream index
[12:13:56] <CIA-15> ffmpeg: in the found program, and not the stream index in the list of all
[12:13:56] <CIA-15> ffmpeg: streams. The attached patch fixes this issue.
[12:13:56] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[12:26:16] <j-b> michaelni: mru: don't fight for my stupid patch... There is no reason to. I did a patch on ffmpeg that actually compiles. /me happy
[12:27:38] <kshishkov> j-b: I've produced such patch once too
[12:28:16] <j-b> a VC-1 interlaced patch?
[12:28:18] * j-b runs
[12:28:50] <mru> no interlaced patches on our ml, please
[12:29:41] <kshishkov> j-b: there was a guy asking me about it at FOSDEM. Be thankful he got home alive
[12:29:41] * kierank waits for the ffmpeg-interlaced fork
[12:29:56] <j-b> kshishkov: :)
[12:30:10] <j-b> kshishkov: do not worry, my next hobby is MVC :)
[12:30:42] <j-b> and except jason, michaelni or lorenm, I don't know who is actually able to do it
[12:30:46] <kshishkov> j-b: you need to go to USA then
[12:30:48] <twnqx> j-b: i'd have some weird container/PCM audio stuff id you'd like :P
[12:31:16] <j-b> kshishkov: why?
[12:31:32] <twnqx> though it's an mpeg-ps variant, and that avformat is utterly horrid, and contains several read-beyond-end-of-buffer parts in my oppinion
[12:31:53] <kshishkov> j-b: x264 guys are in USA. And MN is too paranoid to let you see him
[12:32:03] <kshishkov> j-b: and judging from what I see any above-average developer can write fast H.264 decoder
[12:32:21] <j-b> kshishkov: your average is screwed
[12:32:40] <kshishkov> j-b: ask mru
[12:32:45] <JEEB> even that chinese dude can do it >_>
[12:32:53] <JEEB> (who jointed with neuron2)
[12:32:58] <kshishkov> j-b: he knows two guys who created commercial H.264 decoders
[12:33:02] <j-b> kshishkov: mru isn't average
[12:33:19] <j-b> kshishkov: average developer knows VB.Net and C#. Or maybe Java
[12:33:37] <Dark_Shikari> j-b: MVC seems to just be header and ref frame stuff
[12:33:40] <Dark_Shikari> which is the stuff I'm worst at
[12:33:48] <CIA-15> ffmpeg: Maksym Veremeyenko <verem at m1stereo.tv> master * r41cdc1ff1e ffmpeg/libavformat/nsvdec.c:
[12:33:48] <CIA-15> ffmpeg: fix nsvdec.c compilation if DEBUG macro defined
[12:33:48] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[12:33:52] <j-b> Dark_Shikari: ok
[12:34:10] <j-b> kshishkov: anyway, I submitted the idea of putting ads on v.o to get money for such bounties
[12:34:32] <kshishkov> j-b: what about putting some money to get rid of autotools for VLC build?
[12:34:42] <j-b> rofl
[12:34:54] <j-b> noone would do that, even for 10000000$
[12:35:00] <j-b> autotools is hell
[12:35:12] <kshishkov> so why do you keep it?
[12:35:15] <kierank> j-b: you should make the bounties more prominent on v.o
[12:35:30] <JEEB> at least VLC didn't go the mkvtoolnix way and added some ruby for the building process >_>
[12:35:59] <kshishkov> mplayer2 uses Python scripts
[12:36:05] <j-b> kshishkov: because anything else was worse
[12:36:13] <kshishkov> j-b: look at FFmpeg
[12:36:15] <j-b> kshishkov: the tryout of cmake was horrible
[12:36:21] <JEEB> python at least is pre-installed on mostly used distros and it's somewhat more used overall
[12:36:23] <kshishkov> j-b: and hire mru to do the same
[12:36:31] <mru> shell scripts rock
[12:36:34] <JEEB> cmake is relatively horrible for cross-compilation, yeah
[12:36:34] <j-b> kshishkov: yes, but FFmpeg doesn't depend on 60+ libraries :D
[12:36:41] <j-b> JEEB: exactly
[12:36:44] <Dark_Shikari> Have you looked at configure lately?
[12:36:45] <mru> j-b: how is that relevant?
[12:36:45] <Dark_Shikari> I think it does~
[12:36:56] <j-b> scons was tried and stopped within the same day
[12:37:12] <JEEB> lol scons
[12:37:17] <j-b> kshishkov: but yes, something like ffmpeg could be done.
[12:37:20] <mru> what became of jam?
[12:37:23] <j-b> and would actually be clever
[12:37:36] <kshishkov> Dark_Shikari: well, some mru forgot to refresh his zlib replacement for new FFmpeg
[12:37:51] <kshishkov> mru: they ran out of tea
[12:38:02] <JEEB> perl/python/bash is still understandable for building processes I guess :3 Python being on the line.
[12:38:05] <kshishkov> mru: which is the worst British horror
[12:38:12] <j-b> JEEB: -perl
[12:38:27] <uau> kshishkov: bare mplayer2 doesn't actually use python for building
[12:38:30] <mru> kshishkov: the usual english tea is indeed dreadful
[12:38:42] <JEEB> yeah, the python is used to automate the building of all of the parts
[12:38:59] <uau> if you use the build repo wrapper to build ffmpeg at the same time then the scripts it that do use python
[12:39:01] <kshishkov> mru: why do people consume it large quantities then?
[12:39:03] <mru> JEEB: I prefer using only posix tools and make
[12:39:10] <mru> kshishkov: you'll have to ask them
[12:39:19] <kshishkov> uau: yes but you have mplayer-build for it
[12:39:26] <j-b> kshishkov: python is clean, I like it
[12:39:49] <JEEB> mru, if possible that's a good one
[12:39:51] <mru> python is a huge dependency
[12:39:56] <JEEB> the less is used the better
[12:39:59] <JEEB> :3
[12:40:18] <j-b> pyton is too gue a dep for us
[12:40:29] <j-b> python is too huge a dep for us
[12:40:45] <mru> the nice thing about shell tools is they don't change
[12:40:48] <mru> python does
[12:40:56] <j-b> kshishkov: I would love if changing the configure wouldn't trigger an almost full rebuild :)
[12:40:56] <JEEB> true
[12:40:58] <mru> what works in one version might suddenly break
[12:41:05] <mru> and you have to scramble to fix your code
[12:41:25] <mru> j-b: in ffmpeg?
[12:41:31] <mru> j-b: that can be fixed
[12:41:39] <j-b> mru: in VLC, of course
[12:41:56] <j-b> mru: I really like ffmpeg build-system
[12:42:32] <j-b> but contrary to kshishkov I don't consider it a priority
[12:43:07] <kshishkov> what are your priorities then?
[12:43:25] <av500> MVC
[12:43:41] <kshishkov> av500: and multichannel WavPack till recently
[12:43:51] <av500> meh
[12:44:02] <kshishkov> and VC-1 interlaced
[12:44:15] <j-b> kshishkov: fixing important broken parts of VLC's core (including "clock for audio", "vout rework", especially for subtitle)
[12:44:40] <mru> you need to get rid of that ghastly resampler
[12:44:47] <mru> for file playback
[12:45:01] <j-b> kshishkov: and for users, (mac interface improvement, win interface simplification, and media library)
[12:45:06] <av500> kshishkov: vc1 interlaced is only dead HD-DVD, no?
[12:45:20] <j-b> and some early BD, I thing
[12:45:38] <av500> j-b: media library? you want to do it like winamp, kill the product by making it like itunes?
[12:45:41] <kshishkov> av500: dead Blu-Rays, IIRD HD-DVD was progressive
[12:45:43] <j-b> kshishkov: then, about codec support, nothing is very important, but I am sure people are going to break our balls with MVC quite soonish
[12:46:08] <kshishkov> j-b: just invite us to watch the process
[12:46:12] <mru> 3D film is a passing fad
[12:46:20] <mru> at least this time
[12:46:25] <j-b> kshishkov: doesn't wtv accept vc-1i ?
[12:46:25] <av500> it was in the 50's
[12:46:39] <mru> the tech is still too crude
[12:46:41] <kshishkov> j-b: if yes then bug pross-au for patch
[12:46:46] <j-b> av500: optionnal to use. but it is mandatory for audio playback
[12:47:09] <mru> now if they were to invent the holodeck...
[12:47:24] <j-b> kshishkov: I haven't read anything about wtv yet (except some people harassing for supporting this "major format" (lol))
[12:47:33] <kshishkov> mru: for committing suicides?
[12:47:41] <mru> huh?
[12:47:49] <j-b> mru: indeed, that is what I meant by "audio clock"
[12:47:53] <kshishkov> j-b: it's minor filesystem, not major format
[12:48:00] <j-b> kshishkov: exact
[12:48:13] <kshishkov> mru: has Star Trek taught you anything about holodeck usage?
[12:48:25] <kierank> kshishkov: some current BD's too
[12:48:27] <j-b> kshishkov: and then, final thing would be to work on mobile ports (Android), but that is easier, because it is fun, so people want to work on it
[12:48:38] <mru> kshishkov: don't disable the safety protocols
[12:48:41] <j-b> kshishkov: (end of answer)
[12:48:57] <mru> and don't ask it to create a character smarter than you
[12:49:36] <kshishkov> and don't run control system under Windows ST without firewall and plugged into Internet
[12:50:18] <{V}> mru, re: jam. Last I heard, nothing changed on the official version. I know Haiku uses jam (and I think they customized it a little or maybe that was just for their port to beos and haiku)
[12:50:23] <kshishkov> j-b: all things I don't care about but I don't use VLC then
[12:50:51] <mru> {V}: I don't see anyone using it anymore
[12:50:52] <j-b> kshishkov: as much as mru is not the average developer, you aren't an average user
[12:51:21] <kshishkov> j-b: I'm under-average user then
[12:53:18] <{V}> mru, that's probably self-sustaining; nobody choses jam, (because they don't know about it,) because nobody else uses it.
[12:53:33] <thresh> and it should stay the same
[12:53:33] <mru> it was all the rage a few years ago
[12:53:46] <mru> then they all switched to cmake
[12:54:17] <mru> or cmake became the make replacement du jour
[12:54:45] <mru> scons reared an ugly head there too for a while
[12:55:00] <mru> and let's not even think about what the java crowd uses
[12:55:16] <j-b> and both are crap, and not better than autohell
[12:55:38] <mru> tell that the to the trolls that use it
[12:56:32] <j-b> I don't see the idea in moving from autotools to go to something that isn't better
[12:56:44] <kshishkov> mru: coremake!
[12:56:52] * mru is not a fan
[12:57:01] * kshishkov neither
[12:57:10] <mru> it sucks less than cmake though
[12:57:26] <mru> you're stuck on an ancient version too
[12:57:35] <mru> there have been improvements
[12:57:51] <mru> such as proper dependency tracking and parallel build support
[12:58:11] * kshishkov does not care
[12:58:24] <kshishkov> I don't care even for the newest GNU Make release
[12:58:43] <mru> some of the changes in 3.82 are actually for the better
[12:58:53] <mru> it's more consistent in behaviour
[12:59:06] <mru> unfortunately it breaks some existing makefiles
[12:59:34] <kshishkov> exactly
[12:59:46] <kshishkov> so waiting for 3.84
[13:03:54] * {V} doesn't like debugging makefiles
[13:04:17] <mru> then get them correct to begin with
[13:04:32] <mru> most likely, you're using the wrong approach
[13:04:50] <mru> makefiles are, like all computer programs, pure logic
[13:06:16] <{V}> probably. Mostly it's just my lack of experience with them.
[13:06:54] <mru> people who instinctively reach for the single-step button will have trouble with makefiles
[13:08:02] <kshishkov> make CC=echo
[13:08:11] <mru> make -n
[13:11:27] <{V}> remake :p
[13:12:42] <mru> usual debugging techniques for procedural languages don't work with the declarative make
[13:14:20] <lu_zero> btw
[13:14:41] <lu_zero> waf hadn't been mentioned yet
[13:14:42] <mru> and on that note, much of the ffmpeg configure script is declarative in nature
[13:16:03] <lu_zero> the ffmpeg configure should be split in modules to be easily reusable by other projects
[13:16:25] <mru> +1
[13:16:32] <mru> send more time, and I'll do it
[13:16:53] <wbs> making ffmpeg configure/make reusable would be a humanitarian effort to save the world from the other evil build systems
[13:17:01] <andoma> yeah
[13:17:01] <wbs> as in +1000 from me ;P
[13:17:24] <andoma> i've borrowed some smaller functions from it to my project
[13:18:25] <andoma> but i'm thinking of reworking my configure script so it generates one .h file per option .. to get rid of full rebuilds when reconfiguring
[13:18:55] <mru> how does linux kernel build do that?
[13:19:14] <andoma> no idea ..
[13:19:18] <mru> #including dozens of config_foo.h in every file isn't practical either
[13:19:25] <andoma> indeed
[13:19:49] <mru> I've thought about splitting them up in categories at least
[13:29:41] <wbs> the worst part mostly is rebuilding everything when lavc minor/micro is bumped
[13:30:09] <DonDiego> we could move that stuff into a version.h header
[13:30:20] <Kovensky> 09:50.51 mru: {V}: I don't see anyone using it anymore <-- boost does
[13:30:29] <mru> lol boost
[13:30:33] <Kovensky> 09:54.17 mru: or cmake became the make replacement du jour <-- cmake writes makefiles, it doesn't replace make
[13:30:44] <mru> Kovensky: minor detail
[13:31:06] <jannau> DonDiego: doesn't help since avcodec.h would include version.h
[13:31:17] <mru> jannau: it wouldn't need to
[13:31:27] <DonDiego> that was my point...
[13:31:50] <mru> which reminds me, there are a number of cross-includes I'd like to drop
[13:31:58] <kshishkov> send a patch
[13:32:22] <Kovensky> boost is pretty much the only thing I've seen using jam so far
[13:33:39] <jannau> as long as we have #if LIBAVCODEC_VERSION_* in avcodec.h we need version.h
[13:33:52] <lu_zero> http://ffmpeg.pastebin.com/m8C3kXGc <- what I'm doing wrong?
[13:34:11] <mru> we could also split avcodec.h
[13:34:21] <mru> possibly
[13:34:29] <mru> if there are unrelated parts in it
[13:36:45] <kshishkov> look into it first
[13:37:54] <kshishkov> lu_zero: line 46 - copypaste error
[13:43:03] <DonDiego> mru: what do you mean by "cross-includes"?
[13:43:25] <kshishkov> a includes b and b includes a
[13:44:18] <mru> that especially
[13:44:33] <mru> but may of our headers include others needlessly
[13:44:40] <{V}> Kovensky, "boost is pretty much the only thing I've seen using jam so far" look at haiku, then you'll have seen two :D
[13:44:41] <lu_zero> kshishkov: uh
[13:44:59] <kshishkov> lu_zero: anything else?
[13:45:03] <Kovensky> {V}: :P
[13:45:28] <lu_zero> kshishkov: try the code =)
[13:45:37] <lu_zero> what you'd expect to see?
[13:46:01] <kshishkov> let's see
[13:47:19] <kshishkov> I see moving gray gradients in top half
[13:48:40] <lu_zero> and what's in the bottom?
[13:48:49] <kshishkov> nothing
[13:48:53] <lu_zero> exactly
[13:49:01] <lu_zero> (nothing -> yuv green)
[13:49:27] <lu_zero> so you take a frame twice as big, you feed swscale to it to scale it down
[13:49:33] <lu_zero> and you got that
[13:49:53] <lu_zero> I'm not sure where I'm messing up
[14:00:54] <uau> mplayer2 uses the libavformat avi demuxer by default
[14:01:15] <uau> that has uncovered an annoying property in it, namely that for some files it seeks audio to a significantly later position than video
[14:01:25] <Rathann> what's mplayer2?
[14:01:36] <kshishkov> mplayer-uau
[14:01:38] <uau> so that when starting playback after seeking audio is missing for a while
[14:01:38] <Rathann> ah
[14:02:03] <uau> i think the new avformat seek api is supposed to solve issues like that
[14:02:14] <uau> but that's still marked "under construction"
[14:03:01] <uau> any ideas how to solve that?
[14:04:09] <uau> anyone willing to make the default behavior of the current API saner for avi? (i'd rather concentrate on mplayer2 code myself)
[14:04:31] <uau> or the new seek api becoming the standard or at least stable in the next bump, assuming that's reasonably soon?
[14:06:22] <kshishkov> lu_zero: in sws_scale you forgot to pass c->height*2 for source image height!
[14:08:41] <kshishkov> lu_zero: and if you think passing source image height after initialising context is redundant - blame me not
[14:14:49] <Kovensky> 11:02.03 uau: i think the new avformat seek api is supposed to solve issues like that <-- does it also solve the seeking-in-ts issue? specially when there are repeated timestamps?
[14:16:01] <mru> Kovensky: that's a hard problem to solve
[14:16:17] <lu_zero> kshishkov: eh eh
[14:16:43] <kshishkov> lu_zero: see why it's useful to read docs sometimes?
[14:16:49] <uau> Kovensky: which issue do you mean? the unreliability of mpeg timestamps is orthogonal at least
[14:17:09] <lu_zero> kshishkov: not overlook you mean ^^;
[14:17:33] * lu_zero assumed that param being the other way round
[15:34:56] <BBB> lu_zero: you have mingw32, can you fix AVERROR -> FFNETERROR in https://roundup.ffmpeg.org/issue2611 ?
[15:37:29] <cartman> BBB: had time to debug clang VP8 problems?
[15:37:38] <Flameeyes> BBB: you have knowledge of mms/mmst, don't you?
[15:37:38] <BBB> no
[15:37:41] <BBB> Flameeyes: yes
[15:37:46] <cartman> BBB: :(
[15:37:54] <cartman> my fate is not green anymore :(
[15:37:56] <Flameeyes> BBB: is the protocol _officially_ documented?
[15:37:57] <BBB> cartman: I'm almost certain it's a compiler issue, I don't have time to look into it right now
[15:38:08] <BBB> Flameeyes: yes, look for ms-http on msdn
[15:38:18] <cartman> BBB: give me a pointer (void* is good) to debug a function then
[15:38:20] <BBB> Flameeyes: mmst (afaik) is not publicly documented
[15:38:25] <Flameeyes> BBB: thanks!
[15:39:02] <cartman> sigh
[15:39:07] <BBB> cartman: I don't really know, the path isn't big, I've said before, try making random modifications in that patch (or the code touched by it), e.g. making stuff not inline, not using AV_ZERO32 but =0 instead, etc.
[15:39:32] <cartman> ok if it turns out to be an FFmpeg bug you owe me a fix :P
[15:39:35] <BBB> cartman: in other words, apply that patch line-by-line (I'm assuming you understand the code here) and run make fate-vp8 after every line of change
[15:39:55] <BBB> cartman: I think it's quite likely that the AV_ZERO32() or inlining causes the issue
[15:40:01] <BBB> that's still a compiler bug imo
[15:40:02] <BBB> but whatever
[15:41:42] <mru> it breaks even with --disable-asm fwiw
[15:41:47] <mru> but works at -O2
[15:42:22] <BBB> mru: the patch basically does some processing only when necessary, but with identical code, and uses AV_ZERO32() for some stuff that should be aligned but might not be depending on the compiler
[15:42:36] <BBB> mru: I think that second part might break on exotic compilers that don't get much real-world testing
[15:42:41] <BBB> oh, hi there clang :)
[15:42:45] <cartman> uh oh
[15:43:00] <cartman> next time I won't report clang bugs ;)
[15:43:14] <BBB> cartman: did you fix it already?
[15:43:25] <cartman> BBB: debugging atm.
[15:43:29] <BBB> cartman: awesome
[15:43:39] <BBB> if you can't figure stuff out, ask me, I can help you apply the patch "change-by-change"
[15:44:03] <cartman> thanks, I will break decode_mvs into 2-3 parts and see what part is borking
[15:44:07] <cartman> that worked before
[15:44:29] <lu_zero> BBB: let me have a look
[15:44:34] <BBB> lu_zero: ty
[15:45:32] <lu_zero> ugh
[15:45:37] <lu_zero> remind me this night...
[15:49:37] <DonDiego> does anybody know of a tool to detect write-only variables and similar?
[15:50:48] <mru> compiler?
[15:51:09] <mru> gcc 4.6 does a much better job than older versions of finding them
[15:52:00] <kshishkov> or any of those code analyzers like clang
[15:52:07] <DonDiego> i can trivially trick gcc 4.2 here on this mac at work...
[15:52:39] <DonDiego> int unused = 0; unused = 42;
[15:52:47] <mru> 6 > 2
[15:53:03] <DonDiego> never use that value and gcc never complains
[15:53:12] <DonDiego> ok, might be worth compiling a new gcc then...
[15:56:58] <Dark_Shikari> Clang is pretty good at that.
[15:57:17] <Dark_Shikari> ... to the point where it's too good, it complains about the last i++ in a loop
[15:57:39] <mru> isn't that referenced by the loop condition?
[15:58:15] <mru> in a while(i++ < foo) I guess it isn't
[16:15:37] <BBB> mru: also, mkv doesn't have a dts field, so where does the dts come from in these files anyway?
[16:16:30] <BBB> mru: I'm gonna do a rough guess here: lavf utils.c made them up in av_read_frame() or so
[16:16:41] <mru> it's made up
[16:16:43] <BBB> and then we """""fix""""" them later on :):):):):):):):):):)
[16:16:55] <Dark_Shikari> =_=
[16:17:42] <BBB> . o O (... ... ... is there anything else left to say? ...)
[16:18:32] <elenril> yes
[16:18:39] <elenril> you need to merge the rest of -mt =p
[16:18:52] <BBB> has anyone gotten a hold on astrange lately?
[16:19:21] <elenril> he's usually around at ~6-7 in the morning (CET)
[16:19:25] <Dark_Shikari> Hmm, BBB, I have an evil hack idea for making MV clamping faster.
[16:19:28] <Dark_Shikari> in vp8
[16:19:37] <Dark_Shikari> 1) copy the trick in me.c in x264
[16:19:37] <Dark_Shikari>     uint32_t mv_min = pack16to32_mask2( -mv_x_min, -mv_y_min );
[16:19:38] <Dark_Shikari>     uint32_t mv_max = pack16to32_mask2( mv_x_max, mv_y_max )|0x8000;
[16:19:45] <Dark_Shikari> 2) increment mv_max and mv_min per-MB
[16:20:03] <{V}> BBB, about 11 hours ago: <astrange> BBB: https://roundup.ffmpeg.org/issue2609 wrote a diagnosis but i might not be able to get to it (or anything else) until monday
[16:20:24] <Dark_Shikari> The only trick I see is that the "min" values can be negative, so incrementing them might be tricky.
[16:20:46] <Dark_Shikari> Also, if there's a lot of mv0 or things that don't require clamping, it might not be worth it
[16:21:51] <BBB> {V}: thanks, I missed that
[16:22:01] <BBB> my backlog isn't long enough, it seems
[16:22:11] <{V}> you're welcome :)
[16:22:16] <mru> solution: sleep less
[16:26:16] <ubitux> mru: you're a bit hard with Nicolas :)
[16:26:21] <mru> not at all
[16:26:24] <mru> I'm too soft
[16:26:36] <mru> but the others won't let me toast him properly
[16:27:25] <ubitux> the questions are interested for a new comer like me; i guess this thread will help me to understand that stuff better
[16:27:27] <av500> you are medium raw
[16:27:35] <ubitux> interesting*
[16:27:50] <BBB> mru is a little hostile to him, but inviting him to spill his mind so we can find what he's talking about
[16:27:57] <BBB> he finally mentioned the case he's fixing
[16:28:01] <BBB> we told him the fix is wrong and why
[16:28:05] <BBB> now he can fix it correctly
[16:37:41] <lu_zero> now we'll see
[16:38:23] <lu_zero> I hope he gets at least that there isn't a "Leader", Czar, Alpha or whatever
[16:40:28] <mru> you are all my mindless minions, muahahaha
[16:41:35] * BBB happy to be a "mindless minion" if this is what it means
[16:41:52] <BBB> I'm a mindless minion, muhahahahhahahahha
[16:49:47] <Kovensky> 11:16.49 uau: Kovensky: which issue do you mean? the unreliability of mpeg timestamps is orthogonal at least <-- ffmpeg can't seek in ts, at all, IIRC (I haven't tried it myself, it's what I hear from ffms people)
[16:50:37] <Kovensky> the last time I mentioned that people mentioned something to do with the seeking API using absolute timestamps and .ts by design having repeated timestamps (overflow), so it doesn't know where exactly to seek to
[16:50:42] <uau> quite a posting spree on ffmpeg-dev
[16:51:10] <Kovensky> this could be workarounded by having a relative seek API (which would be useful not just for .ts too)
[16:52:27] * av500 sees in TS and PS using the file pos only
[16:52:29] <av500> seeks
[16:52:42] <Kovensky> also, is there no way to have frame-accurate seeking other than by doing it user-side? for example when seeking somewhere with precision mode on it could return the needed reference frames without a pts and then only start returning pts when you reach the specific frame requested
[17:03:19] <Dark_Shikari> am I stupid, or is clip(x, y, z) equal to median(x, y, z)?
[17:03:32] <Dark_Shikari> if x is less than y, the middle is y (correct value)
[17:03:40] <Dark_Shikari> if x is greater than z, the middle is z (correct value)
[17:03:43] <Dark_Shikari> so median is the same as clip?
[17:04:54] <Dark_Shikari> or, I guess, clip is a special case of mid_pred
[17:04:57] <Dark_Shikari> where y > x.
[17:05:00] <Dark_Shikari> er, z>y
[17:13:34] <ubitux> about "RTMP: trailing slash in content-base", can't path be ""?
[17:14:03] <Dark_Shikari> BBB: Any objection to moving all the vp8 struct declarations into a vp8.h?
[17:14:06] <Dark_Shikari> or what should we do with that
[17:14:31] <BBB> Dark_Shikari: which struct?
[17:14:48] <BBB> you want to share stuff with x86/vp8_stuff.c?
[17:14:58] <BBB> in that case, yes, you can export the struct
[17:15:12] <BBB> \o/ make fate-vc1 passes again
[17:15:44] <BBB> let's see if it's faster
[17:15:51] <j-b> hello *<tab>
[17:16:00] <BBB> (btw I only did mmx so far, will do sse2 and ssse3 in a little, that's probably much more fun)
[17:16:39] <ubitux> is Ronald or Martin on IRC?
[17:16:48] <Dark_Shikari> BBB is ronald.
[17:17:08] <ubitux> oh, ok, then BBB, can you confirm path can't be "" in the rtmp patch?
[17:18:00] <j-b> and wbs is martin
[17:20:33] <BBB> ubitux: we can do a len > 0 if you think that's helpful
[17:20:53] <BBB> I am not familiar enough with the ffserver.c code to tell for sure...
[17:22:26] <ubitux> i'm not either at all, it just looks suspicious from a quick view
[17:22:39] <BBB> funny artifact:
[17:22:40] <BBB> [null @ 0x101021800] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 8705697 >= 8705697
[17:22:49] <BBB> and I wasn't even looking for it :(
[17:25:23] <wbs> ubitux: hmm, perhaps it potentially can be ""
[17:25:39] * lu_zero did something evil...
[17:26:42] <BBB> what on earth is that
[17:27:24] <lu_zero> -dcodec copy ^^;
[17:29:08] <elenril> lu_zero: what muxers support that?
[17:29:45] <lu_zero> nut, mpegts
[17:29:50] <lu_zero> so far I tried that
[17:31:34] <elenril> wow, even avi
[17:32:09] <lu_zero> elenril: well feel free to play with the concept ^^;
[17:33:54] <siretart> can someone please comment on the severity of this: https://roundup.ffmpeg.org/issue2584
[17:34:41] <siretart> the last two comments indicate that it is
[17:35:14] <wbs> ubitux: and that issue actually is RTSP, not RTMP, it's Nicolas typo in the first mail ;P
[17:35:45] <ubitux> wbs: ok :)
[17:35:55] <peloverde> speaking of minor overreads does someone want to do that padding thing before the bump?
[17:36:28] <mru> padding?
[17:37:15] <peloverde> allowing codecs to specify how much input buffer padding they need
[17:37:39] <mru> oh, that old one
[17:38:20] <mru> there's one thing about it that bothers me
[17:38:41] <mru> it means feeding information backwards from the decoder to the demuxer
[17:38:48] <mru> which can be all but trivial
[17:39:39] <BBB> hm
[17:39:40] <BBB> yummy
[17:39:46] <BBB> kurosu: 15% faster overall, one single function
[17:39:51] <BBB> kurosu: that's optimizations :)
[17:40:13] <BBB> wbs: no patch attached
[17:40:24] <mru> BBB: I more than doubled the speed of a client's vc1 decoder with neon
[17:40:38] <BBB> mru: I've only just started, give me a little time :)
[17:40:48] <Dark_Shikari> BBB: what are you doing now?
[17:40:55] <wbs> BBB: ah crap, new mail sent
[17:40:55] <mru> and why?
[17:41:20] <BBB> Dark_Shikari: evading xvp8 until end of march, I guess
[17:42:53] <Dark_Shikari> really though
[17:44:15] <Dark_Shikari> vp8data.h is missing include guards btw
[17:44:17] <thresh> kshishkov: another nice Winter Olympics mascot, http://yaicom.ru/o/2010/11/stakasha-geroj-sochinskoj-olimpiady-foto_47472_s__1.jpg
[17:45:34] <BBB> Dark_Shikari: not really anything specific. I've noticed our decoding of vc1 is particularly slow and think it's not hard to fix a little
[17:45:39] <BBB> Dark_Shikari: so I'm doing that a little
[17:45:41] <Dark_Shikari> oh.
[17:45:46] <Dark_Shikari> "a little slow" is an understatement
[17:45:50] <BBB> I apologize
[17:45:51] <Dark_Shikari> I wrote some opts for that a while back
[17:45:53] <Dark_Shikari> I think I was the last one to.
[17:45:57] <BBB> "it's a disgrace to humanity"
[17:45:59] <BBB> that better?
[17:45:59] <Dark_Shikari> by a while back I mean 2 years ago
[17:46:01] <Dark_Shikari> lol
[17:46:30] <BBB> I mean my cpu is busy with HD resolution HD content
[17:46:33] <BBB> that's kind of sad
[17:46:34] <Dark_Shikari> What is VP8_MAX_QUANT used for?
[17:46:36] <Dark_Shikari> It isn't referenced anywhere.
[17:46:38] <Dark_Shikari> watafuck
[17:46:40] <elenril> who uses vc1 :/
[17:47:01] <mru> nobody
[17:47:07] <BBB> is anyone going to review my patches?
[17:47:08] <BBB> :-p
[17:47:11] <mru> Dark_Shikari: delete it then
[17:47:15] <Dark_Shikari> Oh, wait, I see where it is
[17:47:18] * BBB goes work on sse2/ssse3 idct
[17:47:19] <Dark_Shikari> It's in the one file I didn't look
[17:47:23] <Dark_Shikari> >_>
[17:47:37] <mru> vp8.c?
[17:47:40] <Dark_Shikari> vp8data.h
[17:47:42] <elenril> Dark_Shikari: git grep?
[17:48:30] <mru> BBB: aughgggh, it's PERMUTED, not permutated
[17:48:40] <Dark_Shikari> mru: repetetetive
[17:49:23] <mru> pretumed
[17:50:10] <lu_zero> tumated
[17:50:41] <mru> tomatoed
[17:57:47] <DonDiego> cu
[18:03:13] <thresh> ahahhah, de icaza is sooo stupid
[18:03:26] <thresh> http://tirania.org/blog/archive/2011/Feb-14.html , love the first comment
[18:04:41] <mru> old joke
[18:04:45] <mru> originally about java
[18:05:18] <thresh> yeah I know, but suits the post really good
[18:05:27] <mru> indeed
[18:08:13] <j-b> de icaza, still an ass
[18:08:35] <j-b> http://news.ycombinator.com/item?id=2226260 <= no gpl on WP7
[18:11:22] <Dark_Shikari> mru: so what should we do about av_always_inline and avutil?
[18:11:29] <Dark_Shikari> and things like av_clip not being inlined.
[18:11:48] <mru> Dark_Shikari: make it av_always_inline, do some quick sanity tests, send patch
[18:12:09] <Dark_Shikari> I'd have to it to every single arch and everything
[18:12:15] <Dark_Shikari> it'd be a change all over avutil
[18:12:28] <mru> "all over" for on function?
[18:12:34] <mru> one
[18:12:41] <Dark_Shikari> I meant to always_inline everything in common.h
[18:12:49] <Dark_Shikari> seems inconsistent to always_inline one clip
[18:12:50] <Dark_Shikari> and not 50 others
[18:14:17] <BBB> mru: I'm not native, I'm allowed to screw up :-p
[18:14:22] * BBB fixes locally
[18:14:25] <mru> do the change, check code size difference, speed test something likely to show a difference
[18:15:05] <mru> I said quick sanity test
[18:15:18] <mru> just make sure something common didn't get slower
[18:15:26] <mru> like h264 on x86
[18:15:29] <mru> it's gcc after all
[18:16:35] <av500> irc is more quiet than the ml today...
[18:16:54] <mru> we should set up a balancing gateway
[18:17:05] <av500> yes, ml overspill to irc
[18:17:08] <BBB> thresh: heh :)
[18:17:30] <BBB> mru: also, subject fixed too
[18:17:36] <j-b> av500: hello French-lover, how are you?
[18:18:29] <av500> j-b: soso
[18:22:25] <uau> Dark_Shikari: gcc actually leaves the clip functions as function calls with non-forced "inline"?
[18:22:57] <mru> in some cases at least
[18:23:37] <Dark_Shikari> due to hitting the inline cap
[18:23:50] <Dark_Shikari> some versions of gcc have a max inlined % per file
[18:23:55] <Dark_Shikari> in files like vp8.c, everything is inlined
[18:24:01] <Dark_Shikari> so the smallest functions don't get inlined instead
[18:26:06] <BBB> I don't think we're inlining too much
[18:26:36] <mru> vp8.c is a difficult case
[18:26:51] <Dark_Shikari> we aren't inlining too much
[18:26:52] <Dark_Shikari> GCC is dumb
[18:26:59] <Dark_Shikari> because if you have a function used ONCE, and it gets inlined
[18:27:04] <Dark_Shikari> it counts that against its inlined %
[18:27:07] <Dark_Shikari> even though that makes NO SENSE AT ALL.
[18:27:14] <Dark_Shikari> Because inlining a function used once can never hurt.
[18:27:20] <mru> inlining call-once functions isn't necessarily good
[18:27:26] <Dark_Shikari> Why?
[18:27:31] <mru> it can pollute i-cache
[18:27:39] <Dark_Shikari> But it can pollute i-cache either way.
[18:27:44] <Dark_Shikari> It's the compiler's job to arrange its code.
[18:27:44] <mru> only when actually called
[18:28:20] <mru> if it's called rarely, keeping separate might be better
[18:28:47] <mru> stays out of cache when not needed, and since it's called rarely, the call overhead is probably irrelevant
[18:29:00] <mru> the compiler can't generally know the probabilities
[18:29:01] <Dark_Shikari> the compiler can arrange the code like that even if it's inlined.
[18:29:19] <mru> a call or a branch is pretty much the same thing
[18:29:23] <mru> unless you're gcc of course
[18:29:37] <mru> gcc is too stupid to use custom calling conventions for static functions
[18:29:47] <mru> even though the manual says it might
[18:30:02] <mru> there's some -f flag for that
[18:30:07] <mru> on by default at some -O level
[18:35:39] <BBB> mru: can you test a patch for me on ppc?
[18:36:19] <mru> I can give you a login so you can test yourself
[18:37:21] <kshishkov> BBB: you're lucky we don't have NEON optimisations for VC-1
[18:37:29] <BBB> mru: ok
[18:37:33] <BBB> kshishkov: true
[18:37:40] <BBB> or I can just break it
[18:37:45] <mru> BBB: what's your favourite username?
[18:37:46] <BBB> hm... who did that before?
[18:37:49] <BBB> mru: rbultje
[18:39:31] <mru> BBB: try ssh saracen.mansr.com
[18:39:57] <BBB> permission denied
[18:40:00] <BBB> (public key)
[18:40:05] <BBB> oh wait wrong username
[18:40:06] <BBB> sorry
[18:40:15] <BBB> works
[18:40:33] <BBB> can I just git pull?
[18:40:39] <mru> sure
[18:40:59] <mru> usual dev tools installed
[18:41:04] <mru> lots of gcc versions
[18:41:45] <BBB> ty
[18:41:57] <mru> various samples in /misc/samples
[18:41:59] <BBB> kshishkov: how to fix transpose()?
[18:42:01] <mru> you'll figure it out
[18:42:37] <mru> it's a dual-proc machine so make -j2 can save you some time
[18:42:43] <mru> unless fate is running
[18:43:05] <BBB> mru: --samples=?
[18:43:13] <BBB> (for fate
[18:43:15] <BBB> )
[18:43:27] <mru> /misc/samples/mphq/fate-suite
[18:43:35] <mru> double-check that
[18:44:22] <BBB> yeah that's correct
[18:44:23] <BBB> thanks
[18:45:51] <kshishkov> BBB: just write it without macro (maybe with comment)
[18:52:50] <BBB> kshishkov: ok
[18:55:03] * BBB notes ppc is slow
[18:55:48] <kshishkov> it's 800 MHz
[18:55:50] <kshishkov> IIRC
[18:56:41] <kierank> nothing is as slow as emulating ppc through qemu
[18:56:58] <BBB> it's only at mpeg4videodec.c
[18:57:04] <BBB> it's been running for a couple of minutes already
[18:57:12] * BBB remembers compiling ffmpeg on his P-II 400MHz
[18:57:14] <BBB> that sucked
[18:57:46] <Dark_Shikari> BBB: any thoughts on the mv patch?   it might be slower if zero mv is very common or intra is common
[18:58:07] <kshishkov> kierank: have you tried emulating x86 on non-x86?
[18:58:47] <kierank> no
[18:59:37] <kshishkov> well, it's hard to imagine CPU worse than x86
[18:59:59] <Dark_Shikari> mips
[19:00:18] * kshishkov mourns Dark_Shikari
[19:02:25] <BBB> Dark_Shikari: I thought I OK'ed that already?
[19:02:32] <BBB> or a different mv patch?
[19:02:39] <BBB> if it's the one from several days ago, it needs benchmarking
[19:02:55] <Dark_Shikari> no, the one from today
[19:03:00] <Dark_Shikari> the several days ago was already committed
[19:05:19] <BBB> how do I turn off vim autoformatting?
[19:06:07] <mru> use emacs
[19:06:13] <Dark_Shikari> :set noai
[19:06:34] <mru> vim autoformatting is a bit too stupid
[19:06:40] <Dark_Shikari> My patch is kinda hard to bench, I think
[19:06:44] <Dark_Shikari> because you'd have to bench the entire decode loop
[19:06:48] <Dark_Shikari> and try to sneak out a few cycles
[19:06:56] <Dark_Shikari> I don't have low enough stdev, not even close
[19:07:03] <Dark_Shikari> My worry is too many mv0 blocks.
[19:07:08] <Dark_Shikari> It would help more with mmx inline asm though.
[19:10:46] <BBB> let's take the embedded x86 as a benchmark though
[19:10:53] <BBB> it's gonna have performance issues at high-motion
[19:10:57] <BBB> rather than mv0
[19:11:05] <BBB> therefore, we should focus on making high-motion quicker
[19:11:05] <Dark_Shikari> ?
[19:11:09] <Dark_Shikari> ah
[19:11:13] <Dark_Shikari> true.
[19:11:15] <BBB> and your patch does that
[19:11:36] <BBB> right, if high-moion takes 120% cpu and mv0 takes 55% cpu, then I don't care if mv0 goe to 60 to get high-motion to 110%
[19:11:42] <Dark_Shikari> yup
[19:11:43] <BBB> even if mv0 is more common
[19:11:48] <BBB> because you want to get both under 100%
[19:11:53] <BBB> so it plays back on the stupid device
[19:12:08] <BBB> kshishkov: fate vc1 passes
[19:12:24] <kshishkov> BBB: resend a patch for approval then ;)
[19:12:26] <j-b> vc1 interlaced? /me is out
[19:12:34] <kshishkov> j-b: of course not
[19:12:44] <kshishkov> j-b: even Bonald is not going to implement it
[19:12:52] <kierank> Bonald B Bultje
[19:12:55] <j-b> kshishkov: ok, I'll change joke (I need to find a new one)
[19:13:46] <kierank> j-b: svc
[19:13:52] <kshishkov> j-b: talk about WVP2, it's going to be not implemented by Dark_Shikari
[19:14:44] <j-b> kierank: svc, noone will believe I am serious :D
[19:14:46] <Dark_Shikari> `-`
[19:15:15] * elenril stabs kshishkov 
[19:15:21] <elenril> go deprecate stuff in avcodeccontext
[19:15:37] <kierank> j-b: how many people have requested it?
[19:15:50] <kshishkov> elenril: tell it about life in Ukraine till it will selfdeprecate?
[19:16:11] <kshishkov> kierank: big number of small ignore them all
[19:16:40] <j-b> kshishkov: none.
[19:16:44] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r1f004fc512 ffmpeg/libavcodec/x86/ac3dsp.asm:
[19:16:44] <CIA-15> ffmpeg: ac3dsp: Change punpckhqdq to movhlps in ac3_max_msb_abs_int16().
[19:16:44] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[19:16:45] <j-b> kierank: none.
[19:17:01] <kierank> wow, people have common sense
[19:17:17] <BBB> kshishkov: I like transpose(), can I keep it pretty-please?
[19:17:20] <mru> kierank: where?
[19:17:21] <BBB> kshishkov: maybe under a new name
[19:17:30] <BBB> kshishkov: I'm too lazy to write out that macro in full 4x
[19:17:42] <kierank> mru: by not being stupid enough to request svc decoding in vlc
[19:17:43] <mru> BBB: just copy&paste
[19:17:52] <BBB> mru: takes effort :(
[19:17:53] <mru> BBB: oh right, apple users don't believe in copy&paste
[19:17:57] <kshishkov> BBB: if it doesn't clash just don't undefine it
[19:18:06] <BBB> if I remove the #undef is it ok?
[19:18:08] <mru> kierank: svc lol
[19:18:14] <BBB> it doesn't clasg
[19:18:18] <mru> clang
[19:18:34] <BBB> clash
[19:18:37] <kierank> now if we could get rid of the people who ask for svc in x264 every few months
[19:20:20] <wbs> am I right that SVC works like each layer being it's own h264 stream - if you drop a packet in one such stream, you'll have artefacts for the rest of the GOP unless you drop that layer completely?
[19:20:48] <kshishkov> probably you'll have artefacts in any case
[19:20:48] <Dark_Shikari> and all layers above too
[19:20:57] <wbs> Dark_Shikari: yeah
[19:21:43] <mru> when they ask for svc, say x264 already supports temporal scalability (aka non-reference frames)
[19:22:47] <mru> spatial scalability is more annoying
[19:22:59] <BBB> kshishkov: sent
[19:23:12] <mru> and I don't remember quite how it's supposed to work
[19:23:12] * BBB goes work on sse2 version
[19:23:15] <BBB> probably much easier
[19:23:32] <mru> does the enhancement layer encode the difference against an upscaled version of the base layer?
[19:23:47] <kshishkov> BBB: you have D_S for second patch to check
[19:23:56] <BBB> D_S: please review patch#2
[19:24:58] <Dark_Shikari> I'll leave a fullr eview to loren, he's better at that
[19:26:28] <Dark_Shikari> pmullw by 12: store the 12 to avoid loading it twice
[19:26:28] <BBB> peloverde: care to review my vc1#2 patch on the mailinglist?
[19:26:38] <Dark_Shikari> same with pw_6
[19:28:49] <Dark_Shikari> ... is there some reason that vc1_idct doesn't output directly to pixels?
[19:28:57] <Dark_Shikari> i.e. outputs to 16-bit words instead of 8-bit?
[19:29:25] <Dark_Shikari> there should be an idct_add and idct_put etc
[19:29:36] <Dark_Shikari> also if you're optimizing vc1 you should fish up my old ML patch for the asm overlap filter
[19:29:46] <BBB> uh, one thing at a time
[19:30:12] <BBB> it does use the unrounded/clipped values for something
[19:30:17] <Dark_Shikari> Go check it.
[19:30:19] <BBB> but I haven't looked very carefully
[19:30:30] <Dark_Shikari> If you're going to optimize, you should look carefully
[19:30:32] <BBB> (i.e. I don't know what that something is, kshishkov would know)
[19:30:34] <Dark_Shikari> bad to write asm and then find out you need to change it again
[19:30:36] <Dark_Shikari> Read the code
[19:30:55] <BBB> kshishkov: ping :-p
[19:30:57] <BBB> kshishkov: ^^
[19:31:15] <kshishkov> why it operates? Because 16-bit is DCTELEM
[19:31:35] <kshishkov> and look at creation date - it was written by a student more than four years ago
[19:32:08] <BBB> kshishkov: does it use the unclipped values for anything?
[19:32:14] <BBB> or can I clip them inside and it's ok?
[19:32:43] <kshishkov> it may output to two ranges
[19:33:06] <kshishkov> because of overlap even I-frames may need an additional +128
[19:34:48] <BBB> can we do that in the idct function?
[19:34:59] <Dark_Shikari> just grep for idct in the c
[19:35:03] <Dark_Shikari> srsly
[19:35:09] <kshishkov> +0.5
[19:35:14] <BBB> hm...
[19:35:16] * BBB goes look
[19:38:25] <BBB> you've got to be fscking kidding me, it does a conditional <<= 1 or += 128 just for the heck of it? dude
[19:38:43] <kshishkov> nope, that's special overlap mode they invented
[19:38:50] <kshishkov> and intensity compensation
[19:38:56] <BBB> += 128 is easy though, just packsswb instead of packuswb and then ^= 128 or so
[19:39:14] <kurosu> for the vc1 idct, i'm wondering if the *12 and *6 could be somehow factored
[19:39:29] <kshishkov> no gain
[19:39:57] <kurosu> for the c code
[19:40:20] <BBB> omg @ vc1_put_block
[19:40:25] <BBB> that's a 3-level loop
[19:41:06] <mru> that decoder probably needs some high-level restructuring
[19:41:56] <_av500_> vc-1 is dead
[19:42:31] <kshishkov> well, it's used as a base for some other decoders - like WMV9 and WMVP at least
[19:43:13] <BBB> kshishkov: and they are not-dead?
[19:43:41] <kshishkov> they are undead
[19:44:03] <kshishkov> and Dark_Shikari wanted to write WVP2 decoder (which is also based on WMV9)
[19:44:07] * Dark_Shikari punts kshishkov 
[19:44:52] <kshishkov> Dark_Shikari: you're the only one who showed any interest in it
[19:45:00] <elenril> do we have a flvdec maintainer?
[19:45:01] <kshishkov> Dark_Shikari: and you're capable of doing it
[19:45:11] <BBB> kshishkov: block[k][i + j*8] = ((block[k][i + j*8] - 128) << 1) + 128; isn't that the same as block[k][i + j*8] = ((block[k][i + j*8] - 64) << 1); ?
[19:45:24] <elenril> kshishkov: lies, Dark_Shikari wanted to go deprecate stuff in avcodeccontext
[19:45:39] <BBB> elenril: flv=baptiste
[19:45:50] <Dark_Shikari> kshishkov: no, I have no RE experience
[19:45:51] <elenril> BBB: seems not
[19:46:01] <elenril> MAINTAINERS says michaelni
[19:46:08] <kshishkov> Dark_Shikari: time to get some!
[19:46:38] <kshishkov> BBB: could be, I derived that from the spec
[19:48:26] <BBB> "could be" :)
[19:52:01] <mru> elenril: MAINTAINERS says a lot of things
[19:53:45] <elenril> anyway, there's a patch for reading index in flv that needs some love
[19:54:17] <elenril> also can i has avio renames?
[19:54:33] <kshishkov> all from MN?
[20:03:33] <BBB> Dark_Shikari: so you want me to include all post-idct "changes" to the coeffs into the idct function, and then include the put/add also?
[20:06:15] <Dark_Shikari> I mean that idct should output to 8-bit data.
[20:06:56] <mru> same as for every other decoder
[20:07:28] <BBB> elenril: I'll apply the avio put/get prefixes
[20:07:43] <BBB> not today though, remind me tomorrow
[20:07:50] <BBB> I have a date with my wife tonight
[20:09:09] <elenril> BBB: you fail at being an unsocial nerd ;)
[20:09:28] <BBB> elenril: sorry, can't fix that
[20:09:31] <BBB> it's in my genes
[20:09:35] <BBB> or is it?
[20:09:50] <BBB> "the evil plan to turn every person in the world into an unsocial nerd"
[20:09:59] <BBB> next james bond title
[20:10:55] <dalias> :)
[20:16:51] <lu_zero> enjoy your date =)
[20:19:18] <microchip_> elenril: it's asocial :p
[20:21:25] <mru> or antisocial
[20:21:37] <microchip_> antisocial are the psychos
[20:21:46] <mru> yes, that's a step worse
[20:22:05] <mru> asocial just doesn't socialise, antisocial ruins it for others too
[20:22:12] <microchip_> yeah
[20:22:27] * dalias wonders if antignostic is a word
[20:22:41] <dalias> or better yet, anti-GNUstic :)
[20:22:47] <_av500_> antipasta is one, lu_zero eh?
[20:25:50] <lu_zero> uhmm
[20:26:14] <lu_zero> in that case is from ante
[20:26:19] <lu_zero> as in before
[20:26:31] <lu_zero> so before pasta (or pasto -> meal)
[20:27:29] <dalias> lol
[20:28:12] <_av500_> lu_zero: no, pasta and antipasta cancel each other out, thats why you eat so much and stay slim
[20:29:03] <dalias> hmm, lame compiles fine with musl :)
[20:31:29] <microchip_> lol musl
[20:34:01] <dalias> lol? :)
[20:34:10] <microchip_> silly name :p
[20:34:21] <kshishkov> yep, not very healthy
[20:34:51] <lu_zero> dalias: btw why musl?
[20:35:29] <kierank> If I had a ts file and I wanted to use lavf to output the stream as udp, how do I go about doing that
[20:35:42] <dalias> short, unique, nice interpretations as acronym, nice homophones
[20:36:09] <microchip_> dalias: you forgot the 'im' at the end :P
[20:36:19] <lu_zero> microchip_: =P
[20:36:34] <lu_zero> dalias: still looks quite promising
[20:36:37] <lu_zero> btw
[20:36:42] <dalias> microchip_, that's for when you compile pidgin against it :)
[20:36:53] <lu_zero> what about using ffconf?
[20:37:06] <lu_zero> (give that probably it will get more options)
[20:37:09] <dalias> configure system?
[20:37:12] <lu_zero> yup
[20:37:47] <dalias> the options for musl are pretty much limited to target arch, compiler optimization options, and compiler warning flags
[20:38:05] <dalias> i don't want to follow the uclibc path of having 20+ compiletime options to enable/disable features
[20:38:14] <lu_zero> indeed
[20:38:18] <dalias> that's a big part of the reason they haven't had a single release since adding nptl
[20:38:29] <dalias> 20 options = 2^20 combinations = impossible to test
[20:38:39] <dalias> especially when they all interact
[20:39:45] <dalias> i'm thinking of having a configure script to detect (or manually set) the target, install prefix, etc. and choose nice warning options for your compiler version
[20:41:26] <lu_zero> ffconf should help
[20:43:04] <kshishkov> ffmru
[20:43:16] <dalias> i'm thinking i could get by with something a lot smaller than ffconf
[20:44:22] <lu_zero> dalias: picking just the useful bits helps
[20:44:54] <dalias> i'll look at it :)
[20:45:12] <dalias> *sigh* there's one nasty ICE compiling ffmpeg
[20:45:22] <dalias> and the funniest part is that it goes away if i just type "make" again after it stops
[20:45:46] <dalias> hard to know if it's my bug or a gcc bug, or a hardware problem
[20:45:58] <mru> dalias: ICE is always gcc or hw
[20:46:39] <dalias> mru, if gcc is compiled with a known-good libc, yes
[20:46:49] <mru> right
[20:47:02] <mru> ltrace it
[20:47:14] <dalias> but since gcc is linked to musl, it's *possible* (altho unlikely) that it's a libc bug
[20:47:26] <dalias> i should just get gcc 4.x working..
[20:47:49] <dalias> still using 3.4 because in early development getting 4.x to build against musl was looking too hard
[20:47:53] <lu_zero> which gcc would work with musl?
[20:48:17] <dalias> any gcc 3.2 and later should be able to compile musl and link programs against it (maybe 3.0 too)
[20:48:45] <dalias> i know 3.2 and 3.4 build well against musl
[20:49:39] <lu_zero> what's wrong with gcc-4x?
[20:49:42] <dalias> mru, ltrace requires shared libs. i can just use gdb, but the problem is it's not reproducible - the crash goes away when i rerun make
[20:49:58] <dalias> i'm betting it's OOM
[20:50:05] <dalias> gcc probably ICE's on malloc failure
[20:50:16] <lu_zero> dalias: make clean && make?
[20:50:27] <dalias> and more memory is available when i rerun make after it crashes once
[20:50:55] <dalias> as for gcc 4..
[20:51:49] <dalias> it has a lot more deps (all the mpc/float crap), decimal float, and wants to integrate more closely with OS threads for TLS support stuff
[20:52:07] <dalias> i can disable some of that (but it's undocumented)
[20:52:45] <mru> dalias: have malloc log a message if it fails
[20:52:55] <dalias> and it's just a lot more to deal with "is everything this functionality needs working in musl yet?" "am i seeing a musl bug or a gcc glibc assumption?" etc.
[20:52:58] <kierank> BBB: you know the URLProtocol stuff right? How hard would it be to have direct passthrough so you could stream arbitrary data over udp?
[20:57:25] <BBB> kierank: well, udp is internally packetized, so that's one issue
[20:58:38] <mru> I once wrote a simple app to stream out a ts file over udp
[20:58:44] <mru> was about a page in size
[20:58:58] <kierank> well yeah but lavf already does the igmp join stuff i need for mulitcast
[20:59:10] <mru> that's 10 lines or so
[20:59:47] * kierank still considers igmp magic
[20:59:53] <bcoudu> wtf is that pts discussion again
[21:00:06] <mru> bcoudu: ridiculous
[21:00:10] <bcoudu> when people talking have the smallest clue about what's happening in the wild
[21:00:42] <bcoudu> and please mru, commit your code and see how many users will complain, besides mkv stream copy issue is completely unrelated
[21:00:54] <bcoudu> -> no clue
[21:00:58] <mru> commit what?
[21:01:10] <BBB> he probably means the pts += 1/framerate
[21:01:11] <mru> mkv stream copy comes from lavf guessing incorrect dts
[21:01:23] <bcoudu> be my guest and compute them
[21:01:33] <mru> and it guesses wrong because it assumes an mpeg2 b-frame model
[21:01:38] <mru> which isn't valid for h264
[21:02:01] <bcoudu> it doesn't
[21:02:04] <bcoudu> this code is disabled
[21:02:10] <mru> oh?
[21:02:14] <mru> what's doing it then?
[21:02:26] <bcoudu> read the code
[21:02:29] <BBB> bcoudu: stop it
[21:02:33] <mru> I give up
[21:02:34] <bcoudu> 1/framerate doesn't work for wmv
[21:02:37] <BBB> enouhg personal insults
[21:02:38] <bcoudu> BBB stop it as well
[21:02:44] <bcoudu> you have no clue
[21:02:50] <BBB> uh, right
[21:02:52] <mru> bcoudu: and you do?
[21:02:56] <BBB> of course he does
[21:02:58] <bcoudu> yes I do
[21:03:02] <BBB> I'm an airplane
[21:03:18] <mru> I actually wrote a ts muxer producing valid output
[21:03:24] <mru> or valid enough for my needs
[21:03:32] <mru> which were a kasenna server and amino decoders
[21:03:32] <bcoudu> and every day I get hundreds of files
[21:03:47] <mru> the kasenna server is exceedingly picky
[21:03:51] <bcoudu> producing ts is completely different than reading files correctly
[21:04:05] <BBB> enough, stop ot
[21:04:08] <BBB> it*
[21:04:08] <mru> it's the inverse, yes
[21:05:14] <bcoudu> besides, when playing it's not a big deal if you have one or two wrong values
[21:05:20] <bcoudu> when stream copying it's broken
[21:13:47] <lu_zero> btw
[21:14:01] <lu_zero> I guess I should add to my random data patchset
[21:14:10] <lu_zero> the example code to produce it
[21:14:34] <lu_zero> and then we could use it to weight how strange is libavformat.
[21:14:36] <lu_zero> hint
[21:14:47] <lu_zero> gdb --args ./ffmpeg_g -dump -y -i libavformat/test.nut -vcodec mpeg2video -acodec copy -dcodec copy /tmp/test.nut
[21:18:31] <lu_zero> gets
[21:18:34] <lu_zero> "fun"
[21:21:52] * lu_zero finds yet another bug in his code meanwhile
[22:04:56] <CIA-15> ffmpeg: Carl Eugen Hoyos <cehoyos at ag.or.at> master * r2e3c56a29f ffmpeg/libavcodec/mjpegdec.c:
[22:04:57] <CIA-15> ffmpeg: Set maximum lowres value for the MJPEG decoder to 3.
[22:04:57] <CIA-15> ffmpeg: While 4 works for some samples, 3 is the correct value since 8x8
[22:04:57] <CIA-15> ffmpeg: DCT is used by (m)jpeg.
[22:04:57] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[22:05:07] <CIA-15> ffmpeg: Michael Niedermayer <michaelni at gmx.at> master * r50a82c2c75 ffmpeg/libavcodec/options.c:
[22:05:07] <CIA-15> ffmpeg: vbv_delay AVOption for ABI compatibility
[22:05:07] <CIA-15> ffmpeg: Signed-off-by: Michael Niedermayer <michaelni at gmx.at>
[22:05:07] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[22:19:44] <Jumpyshoes> BBB: for avx support for ffmpeg, i need a function similar to x264_cpu_xgetbv, but it's written in yasm in x264... i could probably do it in inlined asm, but could you do it if you have time?
[22:19:54] * Jumpyshoes is not comfortable with futzing around with inlined assembly
[22:20:40] <mru> didn't Dark_Shikari already post a patch for that?
[22:21:17] <mru> http://patches.ffmpeg.org/patch/779/
[22:21:57] <Jumpyshoes> oh, it seems like he did. has it been pushed?
[22:22:02] <mru> no
[22:22:51] <Jumpyshoes> also seems there has been no activity for 10 days or so, can i bump it?
[22:23:46] <mru> it needed some fixes
[22:23:59] <mru> feel free to fix it and resubmit
[22:24:39] <Jumpyshoes> hrm, okay
[22:25:08] <dalias> i hate gcc
[22:25:20] <dalias> how the hell do you pass CPPFLAGS to configure to build gcc?
[22:25:22] <mru> dalias: feeling's probably mutual
[22:30:17] * lu_zero notices there is something more wrong...
[22:31:20] <lu_zero> but seems working to a point now =P
[22:32:04] * lu_zero now needs to make sure mpegts keeps the data
[22:32:15] <mru> floating point or fixed point?
[22:33:19] <lu_zero> fixed for nut
[22:33:29] <lu_zero> floating around on mpegts =P
[22:33:54] <lu_zero> it claims to do stuff but you don't get anything in the file in the end =-=
[22:35:42] * lu_zero opens the ts file with an editor...
[22:35:47] <lu_zero> the packets seems here
[22:37:43] <dalias> haha i eventually just went with CC="gcc -D_GNU_SOURCE"
[22:38:15] <mru> why would you want that?
[22:47:37] <astrange> BBB: the existence of files with input packet count != output packet count makes it difficult to implement timestamps entirely in libavformat
[22:48:37] <astrange> BBB: for instance, if you take an h264 file with mixed PAFF/not PAFF, and assign the same timestamp increment to each packet, some of your frames will display twice as long. it could work if we had completely implemented AVParser
[22:52:53] <mru> timestamp increment should be per frame, not per packet or field
[22:52:55] <mru> of course
[23:07:05] <iive> of course. If there is a way to distinguish them.
[23:08:06] <mru> parse the frame headers, duh
[23:09:02] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r009026efb1 ffmpeg/tools/graph2dot.c:
[23:09:02] <CIA-15> ffmpeg: In graph2dot, print more specific audio information for audio links.
[23:09:02] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[23:09:11] <CIA-15> ffmpeg: Anssi Hannula <anssi.hannula at iki.fi> master * r6c60fcf89a ffmpeg/libavformat/spdifenc.c:
[23:09:11] <CIA-15> ffmpeg: spdifenc: set flag AVFMT_NOTIMESTAMPS
[23:09:11] <CIA-15> ffmpeg: There are no timestamps in IEC 61937.
[23:09:11] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[23:09:13] <CIA-15> ffmpeg: James Zern <jzern at google.com> master * r0fa904c9d8 ffmpeg/doc/ (encoders.texi ffmpeg.texi):
[23:09:13] <CIA-15> ffmpeg: documentation: add encoders chapter
[23:09:13] <CIA-15> ffmpeg: Signed-off-by: Janne Grunau <janne-ffmpeg at jannau.net>
[23:11:58] <Sean_McG> evening folks
[23:12:27] <mru> good $localtime
[23:12:33] <Sean_McG> mru :)
[23:12:51] <jannau> mru: can you push http://patches.ffmpeg.org/patch/981/ FATE_SAMPLES env variable?
[23:13:06] <mru> jannau: will do later
[23:14:37] <Sean_McG> is mplayer svn supposed to be able to be built against ffmpeg HEAD?
[23:14:46] <mru> no idea
[23:15:03] <mru> DonDiego would know, but he's not here
[23:15:15] <Sean_McG> I just tried here (I used to build it against astrange's ffmpeg-mt branch) and I'm getting swscale missing symbols
[23:15:30] <mru> that's odd
[23:16:17] <Sean_McG> I'll ask the mplayer folks
[23:17:20] <lu_zero> Sean_McG: which missing symbol?
[23:17:29] <Sean_McG> quite a few
[23:20:42] <lu_zero> mind providing me a list?
[23:21:11] <Sean_McG> oh wait shit no... this is a local build issue, ignore me
[23:21:29] <Sean_McG> those libs are distinctly missing from the link line
[23:21:43] * Sean_McG pokes it with a stick
[23:22:06] <Sean_McG> probably because I've been mucking around with paths
[23:22:19] <lu_zero> ^^;
[23:22:38] <uau> Sean_McG: generally mplayer svn may fail to compile against any new ffmpeg revision, as it uses internal symbols which are not part of the API (even if that's not the problem you hit)
[23:23:01] <Sean_McG> uau: but ffmpeg-mt wouldn't have had the same problem?
[23:23:16] <uau> i cleaned that up for mplayer2, that should compile reliably against all ffmpeg versions
[23:23:24] <uau> i'm not sure what you're asking
[23:23:46] <mru> uau: btw, why mplayer2 and not something from scratch?
[23:23:56] <Sean_McG> anyways yeah don't worry about it too much, I'm pretty sure this is my fault
[23:24:30] <uau> mru: you mean why didn't i write a player from scratch? there's still useful code in mplayer even if much of it sucks
[23:24:58] <uau> less work to modify it than start writing a player from scratch
[23:25:01] <mru> separating suck from non-suck is often harder than writing new code
[23:25:46] <uau> well not for me really
[23:25:46] <Sean_McG> if this is pkg-config crap I'mma scream
[23:26:00] <uau> i've done architecture improvement changes before in other programs
[23:26:31] <uau> and i find it easier to work with some existing code
[23:27:41] <uau> also i couldn't personally test all the stuff like video/audio drivers
[23:28:27] <uau> that kind of stuff couldn't be rewritten by one person alone
[23:28:52] <uau> and if you started writing something from scratch it probably wouldn't interest others until after it was already reasonably complete
[23:29:31] <mru> depends on how superior the working parts are
[23:31:23] <uau> well i find it easier to also write new parts when there's already existing infrastructure - even if flawed - that can be used as scaffolding to use/test the new stuff
[23:31:36] <lu_zero> Sean_McG: how?
[23:31:54] <Sean_McG> I'm still looking to see WTF is going on
[23:32:18] <mru> uau: ok, if that's how you like to work
[23:32:23] <mru> uau: I was just curious
[23:36:54] <Sean_McG> oh snap, it's looking for avcore.h!
[23:37:02] <Sean_McG> which um, just disappeared yesterday
[23:39:14] <CIA-15> ffmpeg: Nicolas George <nicolas.george at normalesup.org> master * r6741f7c9be ffmpeg/ffserver.c: (log message trimmed)
[23:39:14] <CIA-15> ffmpeg: ffserver: set the sample aspect ratio
[23:39:14] <CIA-15> ffmpeg: Hi.
[23:39:14] <CIA-15> ffmpeg: It seems that ffserver sets sample_aspect_ratio to an invalid value and lavf
[23:39:14] <CIA-15> ffmpeg: rejects it.
[23:39:15] <CIA-15> ffmpeg: I am not sure what I am doing here, but the attached patch actually solves
[23:39:16] <CIA-15> ffmpeg: something: using the following config:
[23:39:24] <CIA-15> ffmpeg: Martin Storsjö <martin at martin.st> master * r2c35a6bde9 ffmpeg/libavformat/rtsp.c:
[23:39:24] <CIA-15> ffmpeg: rtsp: udp_read_packet returning 0 doesn't mean success
[23:39:24] <CIA-15> ffmpeg: If udp_read_packet returns 0, rtsp_st isn't set and we shouldn't
[23:39:24] <CIA-15> ffmpeg: treat it as a successfully received packet (which is counted and
[23:39:25] <CIA-15> ffmpeg: possibly triggers a RTCP receiver report).
[23:39:25] <CIA-15> ffmpeg: This fixes issue 2612.
[23:40:11] <uau> bad commit message?
[23:40:22] <lu_zero> uhm
[23:40:39] <lu_zero> grr
[23:40:46] <mru> lu_zero: looks like you piped the entire message to git, not just the attachment
[23:40:51] <lu_zero> git am had been overzealous
[23:40:54] <lu_zero> =_=
[23:41:02] <mru> I always double-check these things before I push
[23:41:22] <uau> do the ffmpeg-commits mails not show committed anywhere?
[23:41:28] <uau> committer
[23:41:31] <mru> since the time I made that mistake
[23:41:37] <lu_zero> I should do as well
[23:42:01] * lu_zero doublechecked the diff but not the log =|
[23:42:29] <uau> looks like mplayer2 will also have one issue with the libavcore re-merge, though not that configure one
[23:42:41] <uau> there's '#include "libavcore/imgutils.h"' in one file
[23:43:17] <uau> though apparently that's an mga video out file which is not compiled by default
[23:43:30] <lu_zero> uau: that's from mplayer?
[23:44:59] <uau> well that include line is from mplayer2 specifically if that's what you were asking (only explicit mention of avcore)
[23:45:53] <uau> mplayer 1 also contains that, plus several other mentions due to the ugly embedded ffmpeg build hacks
[23:48:36] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r610219a598 ffmpeg/ (8 files in 2 dirs):
[23:48:36] <CIA-15> ffmpeg: lavf: add av_ prefix to dump_format()
[23:48:36] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:48:39] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * rf6c7375a17 ffmpeg/ (8 files in 3 dirs):
[23:48:39] <CIA-15> ffmpeg: Deprecate parse_date() in favor of av_parse_time().
[23:48:39] <CIA-15> ffmpeg: The new av_parse_time() is created in libavutil/parseutils.h, all the
[23:48:39] <CIA-15> ffmpeg: internal functions used by parse_date are moved to
[23:48:40] <CIA-15> ffmpeg: libavutil/parseutils.c and made static.
[23:48:40] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:48:43] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r5b54d4b376 ffmpeg/ (3 files in 3 dirs):
[23:48:43] <CIA-15> ffmpeg: ac3enc: fix bug in stereo rematrixing decision.
[23:48:43] <CIA-15> ffmpeg: The rematrixing strategy reuse flags are not reset between frames, so they
[23:48:43] <CIA-15> ffmpeg: need to be initialized for all blocks, not just block 0.
[23:48:43] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:48:54] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r9fcae9735e ffmpeg/ (ffserver.c libavformat/rtsp.c):
[23:48:54] <CIA-15> ffmpeg: Replace remaining uses of parse_date with av_parse_time.
[23:48:54] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:52:27] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r610219a598 ffmpeg/ (8 files in 2 dirs):
[23:52:27] <CIA-15> ffmpeg: lavf: add av_ prefix to dump_format()
[23:52:27] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:52:31] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * rf6c7375a17 ffmpeg/ (8 files in 3 dirs):
[23:52:31] <CIA-15> ffmpeg: Deprecate parse_date() in favor of av_parse_time().
[23:52:31] <CIA-15> ffmpeg: The new av_parse_time() is created in libavutil/parseutils.h, all the
[23:52:31] <CIA-15> ffmpeg: internal functions used by parse_date are moved to
[23:52:32] <CIA-15> ffmpeg: libavutil/parseutils.c and made static.
[23:52:32] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:52:35] <CIA-15> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r5b54d4b376 ffmpeg/ (3 files in 3 dirs):
[23:52:35] <CIA-15> ffmpeg: ac3enc: fix bug in stereo rematrixing decision.
[23:52:35] <CIA-15> ffmpeg: The rematrixing strategy reuse flags are not reset between frames, so they
[23:52:35] <CIA-15> ffmpeg: need to be initialized for all blocks, not just block 0.
[23:52:35] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:52:36] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r9fcae9735e ffmpeg/ (ffserver.c libavformat/rtsp.c):
[23:52:37] <CIA-15> ffmpeg: Replace remaining uses of parse_date with av_parse_time.
[23:52:37] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[23:52:41] <mru> oops
[23:52:50] * mru playing with the notificatino script