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

[irc at mansr.com]

[00:01:53] <kierank> mmu_man: it'll probably work but the file won't be spec compliant
[00:04:58] <mmu_man> well the idea is to just join back parts and remove advertisements, and to remux to a .mp4 anyway
[00:05:20] <mmu_man> but I'll need to remux to a PS to seek correctly anyway to locate where to cut
[00:05:44] <mmu_man> VLC nor ffplay seem to find the time when seeking
[00:06:24] <kierank> there are tons of ts cutting apps
[00:06:59] <mmu_man> ffmpeg being one of them, just can't locate where to cut easily
[00:10:26] <mmu_man> SGU in HD with en & fr audio on NRJ12...
[00:11:00] <kierank> french channel with English audio. wow
[00:13:14] <mmu_man> yeah, quite rare
[00:13:34] <mmu_man> France4 used to broadcast DrWho in english during the night
[00:13:38] <mmu_man> but not anymore :(
[00:13:53] <mmu_man> then they wonder why they suck so much at english
[00:14:10] <kierank> someone has to defend the liberte, equalite and fraternite
[00:14:21] <mmu_man> arte shows antique eps of The Avengers though
[00:14:29] <mmu_man> oddly they have german dubbing but no french
[00:14:46] <kierank> arte's good
[00:14:54] <kierank> tons of interesting stuff
[00:15:00] <mmu_man> well, sadly those are getting weaker at least on the net due to all those HADOPI and LOPPSI crap
[00:15:16] <mmu_man> yeah they just show more and more pr0n :D
[00:15:29] <mmu_man> supposedly artistic :D
[00:19:32] <BBB> kshishkov: I've got many more questions coming
[00:22:47] <mmu_man> #define FFMPEG_VERSION "git-svn-rgit: 'svn' is not a git-command...
[00:22:50] <mmu_man> f*
[00:24:45] <mmu_man> I guess git is too old and I'm stuck as I can't update it
[00:26:52] <mmu_man> damn can't install git-svn on this box, too old
[00:32:43] <mmu_man> http://revolf.free.fr/beos/patches/ffmpeg-version-old-git-no-gitsvn.diff
[00:32:58] <mmu_man> seems old git with no git-svn installed spit stuff to stdout...
[00:53:51] <mmu_man> [mp4 @ 0x101022c00] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 73000 >= 73000
[00:53:55] <mmu_man> WTF
[00:54:53] <Flameeyes> WTF has Oki to do with H.264?!
[00:55:52] <kierank> ?
[00:56:05] <Flameeyes> kierank: RFC3016
[00:56:11] <Flameeyes> [RTP/H.264 payload]
[00:56:25] <Flameeyes> all japanese authors.. one coming from Oki.. I thought they did printers..
[00:56:52] <kierank> 3016 is mpeg-4 visual
[00:57:21] <ohsix> oki does a _ton_ of stuff
[00:57:43] <Flameeyes> kierank: okay I'm definitely on acid, let me check I didn't fill it in the wrong table now =_= thanks!
[01:29:32] <mru> mmu_man: what were you trying to do?
[01:37:51] <mmu_man> mru: cut something out of a dump from my DSL box
[01:38:19] <mmu_man> which streams stuff on rtsp which I saved as a .mp4 from vlc
[01:38:48] <mmu_man> seems VLC managed to cut it by itself once I realized it wanted numbers of seconds as units
[01:39:13] <mmu_man> maybe it was some dupped frame
[07:03:48] <elenril> BBB: are you really sure ByteIOContext should be public?
[07:04:09] <elenril> i don't see much people accessing its contents
[07:04:42] <elenril> michaelni: ^
[07:19:22] <uau> elenril: demux_lavf sets read_seek in ByteIOContext directly (it's not at argument to the init functions)
[07:19:45] <elenril> ok then
[08:08:59] <wbs> elenril: accessing ByteIOContext is critical for getting custom IO for muxers (e.g. when outputting straight into memory, instead of to a file)
[08:45:36] <CIA-15> ffmpeg: Reinhard Tartler <Reinhard.Tartler at informatik.uni-erlangen.de> release/0.5 * r2adad90ae7 ffmpeg/Changelog: Amend Changelog for 0.5.4
[08:45:47] <CIA-15> ffmpeg: Reinhard Tartler <Reinhard.Tartler at informatik.uni-erlangen.de> release/0.5 * r31c8dcedb2 ffmpeg/RELEASE: release notes for 0.5.4
[08:50:18] <siretart> fuck
[08:50:38] <siretart> git picked up my 'university' email adress
[08:51:24] <spaam> you forgot to change it :)
[08:51:38] <siretart> no idea how this happened
[08:51:59] <siretart> and I suppose that's really not worth rewriting the branch
[09:07:52] <mmu_man> plop
[09:08:01] <mmu_man> hmm damn again an error reading a .ts
[09:22:54] <siretart> what would be a good benchmark for daniel kangs avx patches?
[09:24:08] <kurosu> he worked on the same thing in x264 so maybe h264 decoding ?
[09:24:38] <Dark_Shikari> read the patches and see what they change?
[09:28:03] <siretart> so this sample should do, I think, no? http://samples.mplayerhq.hu/V-codecs/h264/HD-h264.ts
[09:31:29] <spaam> try?
[09:31:51] <spaam> or you can try Big buck bunny
[09:37:22] <siretart> preliminary results on my sandy bridge: http://pbot.rmdir.de/ca03aa087199e1f5ebed93407affa75d
[09:37:31] <siretart> downloading big buck bunny now
[09:43:24] <Dark_Shikari> his patch doesn't do any optimizations
[09:43:27] <Dark_Shikari> ok, it does like two lines
[09:43:28] <Dark_Shikari> nothing of note
[09:43:37] <Dark_Shikari> the main important part (deblock) isn't ported yet
[09:43:40] <Dark_Shikari> his patch is mostly infrastructure
[09:43:42] <Dark_Shikari> not optimizations yet
[09:43:45] <Dark_Shikari> same as his first patch in x264
[09:45:01] <siretart> sure, still I can confirm that they work :-)
[09:45:06] <Dark_Shikari> of course~
[09:47:54] <siretart> Subject: [PATCH 3/3] Implement pred8x8l_down_right_avx for h264.
[09:48:12] <Dark_Shikari> Yes, that's a single rarely-used function as a starting point
[09:48:14] <siretart> that third patch seems to already optimize a few percent
[09:50:57] <siretart> hm,  ok hardly
[11:36:23] <ubitux> mru: it looks like the 185 also has the issue
[11:40:15] <lu_zero> good morning
[11:40:19] <lu_zero> wbs: poing
[11:58:28] <BBB> siretart: that's what I wanted to know - does it work
[11:58:51] <BBB> siretart: and if that particular function is a little faster that'd be nice
[12:06:21] <mru> shall go ahead and push the configure and flags patch?
[12:08:48] <lu_zero> astrange: you around?
[12:10:27] <lu_zero> mru: dropping all the timestamp heuristics fixes my mpegts sample as well
[12:10:39] <mru> I figured it might
[12:12:23] <lu_zero> and result is a quite improvement on aviad mpegts streams on ffplay and a strange behaviour on ffmpeg
[12:12:46] <lu_zero> but I guess there are other issues to be fixed...
[12:33:03] <BBB> mru: yes, the patch looks fine to me
[12:36:53] <BBB> mru: don't forget to merge the two #if's
[12:37:15] <mru> that's not in my patch
[12:37:39] <mru> I was talking about the first one only
[12:42:52] <BBB> elenril: <bikeshed> I was hoping to prevent ff_av*() function names
[12:43:11] <BBB> elenril: e.g. ff_init_io_context()
[12:45:09] <BBB> elenril: don't send a new patch, I can sed that in the patch itself without problem
[12:45:16] <BBB> let's just prevent further flames and trolls :)
[12:45:29] <BBB> michaelni, mru: ff_init_io_context() fine as function name?
[12:45:35] <BBB> anyone else have opinions?
[12:45:42] <mru> what's in a name?
[12:45:51] <Dark_Shikari> What is a man?
[12:46:05] <mru> Dark_Shikari: someone old enough to drink beer
[12:46:14] <Dark_Shikari> A miserable little pile of secrets!
[12:46:40] <BBB> oh boy dark_shikari's awake, and it smells like he had beer indeed
[12:46:49] <Dark_Shikari> Nope~
[12:47:11] <Dark_Shikari> That smell on my breath is tea, not beer.
[12:50:00] <lu_zero> BBB: right now we have this av+ff namespace but we could extend it to pick other names IMHO
[12:50:50] <mru> we have av_ and avfoo_ for public things
[12:51:05] <lu_zero> yup
[12:51:30] <BBB> I'd like to prevent having ff_av_ or ff_avfoo_ for private things
[12:51:34] <BBB> it's a little double
[12:51:38] <lu_zero> indeed
[12:51:38] <BBB> long typing
[12:51:42] <mru> yeah
[12:51:51] <BBB> hence my request for ff_init_io_context
[12:52:00] <lu_zero> it's fine IMHO
[12:52:00] <BBB> the public equivalent allocating the context is called av_alloc_put_byte()
[12:52:07] <BBB> and should be renamed to av_alloc_io_context()
[12:52:15] <mru> not avio_?
[12:52:34] <BBB> maybe yes
[12:52:36] <lu_zero> if the namespace picked is avio_ makes sense
[12:52:39] <mru> we could use ffio_ for corresponding internals
[12:52:52] <BBB> ff_io or ffio? :-p
[12:53:02] <BBB> just make sure to hide all ff symbols then, not just ff_
[12:53:03] <mru> what's in an underscore?
[12:53:06] <BBB> or ff_ + ffio_
[12:53:38] <BBB> so ffio_init_context() and avio_alloc_context()?
[12:53:46] <BBB> elenril: ^^
[12:54:39] <Kovensky> 09:46.40 BBB: oh boy dark_shikari's awake, and it smells like he had beer indeed <-- what's so good about beer anyway, it's just a bitter drink that makes you dumb for a while after drinking it :S
[12:55:01] <wooster> uh
[12:55:04] <BBB> Kovensky: beer's like wine, you need to know it to appreciate it
[12:55:07] <BBB> some beers are fantastic
[12:55:12] <BBB> some are bitter
[12:55:17] <BBB> just like people
[12:55:19] <BBB> some are fantastic
[12:55:21] <BBB> some are bitter
[12:55:24] <mru> ah, ringwood's best bitter...
[12:55:40] * Kovensky doesn't like anything bitter
[12:55:48] <mru> it's a nice local brew
[12:58:35] <michaelni> BBB, maybe we should throw a b in the ffio_init stuff somewhere to make it clear its about ByteIO and not url stuff
[12:59:06] <mru> let the bikeshedding begin
[12:59:12] <BBB> I started it this time
[12:59:18] <mru> ffio is fine
[12:59:25] <mru> the url ones should have url in the name
[12:59:32] <BBB> michaelni: we'll call url ff_url or ffurl_*()
[12:59:44] <michaelni> id prefer something shorter
[12:59:47] <lu_zero> hopefuly we won't have different io stuff
[12:59:54] <mru> shorter than 3 chars?
[12:59:57] <michaelni> yes
[13:00:02] <michaelni> like 1 char
[13:00:04] <mru> you're being silly
[13:00:10] <BBB> ffx?
[13:00:11] <michaelni> thanks
[13:00:13] <mru> and inconsistent
[13:00:20] <michaelni> ffu
[13:00:20] <lu_zero> ffu is too short IMHO
[13:00:21] <mru> you wanted to _add_ something to io
[13:00:27] <mru> and now url is too long
[13:00:32] <mru> you can't have it both ways
[13:00:41] <mru> ffio+ffurl it is
[13:00:41] <michaelni> 3+0 is worse than 1+1
[13:00:42] <mru> done
[13:00:43] <BBB> michaelni: let's leave url for a little later
[13:00:56] <BBB> ffu and ffio don't conflict
[13:00:59] <BBB> ffio ok then?
[13:01:11] * michaelni still would prefer ffbio
[13:01:20] <mru> bio makes me think of block io
[13:01:25] <BBB> bio = biology
[13:01:29] <BBB> where I got my PhD in
[13:01:29] <michaelni> ffbyio
[13:01:30] <mru> or that
[13:01:33] <andoma> same here (block io) that is
[13:01:34] <mru> byo
[13:01:46] <michaelni> ok too
[13:01:52] <BBB> byo has no input
[13:01:59] <BBB> man we are trolls here
[13:02:00] <michaelni> it has its a typo
[13:02:01] <mru> ffio is fine
[13:02:03] <mru> just do it
[13:02:07] <BBB> ffio is fine I think
[13:02:29] <lu_zero> byouki =P
[13:02:31] <wooster> gnu_ffio_ffurl_*
[13:02:51] <lu_zero> being serious
[13:03:20] <lu_zero> namespaces could be ffurl and ffbio if we want to keep them consistent on 3 letters
[13:03:21] <BBB> we can rename all get/put byte functions into ffio_[wr]{byte,[lb]e{16,24,32}}()?
[13:03:41] <mru> why should those be private?
[13:03:47] <michaelni> lu_zero, looks nice
[13:03:51] <lu_zero> if we keep the namespace to "easy to spot"
[13:04:02] <lu_zero> then ffu is harder to spot than ffio
[13:04:04] <BBB> mru: I'm not sure if they should
[13:04:13] <mru> they seem quite useful
[13:04:17] <michaelni> yes
[13:04:17] <lu_zero> they are
[13:04:24] <lu_zero> and apparently already used around
[13:04:36] <michaelni> iam not against making them public
[13:04:36] <mru> then make them public
[13:04:45] <michaelni> iam against rushing it without tjought
[13:04:55] <BBB> btw if we use ffbio, it should also be avbio
[13:05:05] <michaelni> yes
[13:05:13] <BBB> I'm gonna make this my pet project, "Audio/Video combined with Biology"
[13:05:21] <michaelni> :)
[13:05:22] <BBB> "see, mom, my PhD was not useless"
[13:05:23] <BBB> oops
[13:05:44] <lu_zero> BBB: and... damn could _really_ make sense...
[13:06:01] <Kovensky> 10:05.13 BBB: I'm gonna make this my pet project, "Audio/Video combined with Biology" <-- like every other documentary on Animal Channel?
[13:06:01] <mru> the get_foo() functions take a single argument and return a number, I don't see how they could be improved
[13:06:21] <BBB> we can make 'em public now
[13:06:37] <BBB> get_byte/[bl]e{16,24,32} are perfect
[13:06:41] <BBB> nothing to be improved about
[13:06:51] <BBB> get_buffer is fine also
[13:07:04] <BBB> the rest we can leave private if we feel uncertain
[13:07:07] <michaelni> mru, static inline (not suggesting it just saying it would improve something that is speed)
[13:07:16] <mru> that's unrelated
[13:07:25] <mru> and you are deliberately stalling
[13:07:27] <mru> stop it
[13:07:37] <mru> we will ignore you
[13:07:42] <michaelni> ohh my
[13:07:54] <mru> if you keep being obstructive
[13:08:09] <michaelni> iam neither obstructive nor deliberate stalling
[13:08:15] <mru> sure looks like it from here
[13:08:34] <michaelni> perception ...
[13:08:45] <michaelni> subjective perception
[13:08:48] <lu_zero> just soemthing
[13:08:50] <lu_zero> something
[13:09:02] <BBB> I'll fix up elenril's patches and apply
[13:09:05] <BBB> let's move on from here
[13:09:11] <lu_zero> the bio namespace is used at least by ssl ^^;
[13:09:11] <BBB> the goal is to hide the symbols
[13:09:14] <lu_zero> (and linux)
[13:09:21] <BBB> lu_zero: ffbio, not bio
[13:09:25] <lu_zero> BBB: sure
[13:09:30] <mru> still confusing
[13:09:38] <BBB> or avbio
[13:09:47] <mru> the acronym is established for block io
[13:09:55] <michaelni> ffio / avio is confusing to me
[13:10:02] <mru> only to you
[13:10:05] <mru> you are minority
[13:10:08] <mru> resistance is futile
[13:10:27] <michaelni> iam the one maintaining that code ...
[13:10:59] <elenril> yay, bikesheds
[13:11:06] <michaelni> you dont want ti confuse the one maintaining the code normally
[13:11:11] * mru throws some paint at elenril 
[13:11:24] * elenril paints avio black with purple dots
[13:11:30] <lu_zero> nooo
[13:11:31] <lu_zero> RED
[13:11:44] <elenril> anyway
[13:11:46] <mru> alright, you can have red for input if we make output green
[13:11:49] <lu_zero> because "red un's 'r fasta!"
[13:11:57] <mru> elenril is green here
[13:12:02] <lu_zero> anyway
[13:12:03] <elenril> i don't really like the b/byte part
[13:12:08] <mru> elenril: nobody does
[13:12:10] <elenril> it makes things unnecesarily longer
[13:12:27] <elenril> and AVIOContext is much prettier than AVByteIOContext
[13:12:32] <mru> +1
[13:12:41] <michaelni> AVBIOContext :)
[13:12:50] <mru> stop it
[13:12:58] <elenril> and there will be no confusion if we rename all the rest to av_url or avurl
[13:13:03] <michaelni> kick me when you are out of arguments
[13:13:18] <lu_zero> michaelni: arguments so far
[13:13:36] <michaelni> lu_zero, you dont want ti confuse the one maintaining the code normally
[13:13:52] <lu_zero> - bio stands for at least 2 different contexts outside
[13:14:00] <mru> seems to me elenril is the one maintaining it right now
[13:14:02] <lu_zero> - we don't have different ios
[13:14:13] <michaelni> mru, elenril is doing cleanup aka cosmetics
[13:14:32] <michaelni> lu_zero, we have 2 IO layers
[13:14:38] <mru> michael doing nothing: maintenance
[13:14:40] <lu_zero> which ones?
[13:14:42] <michaelni> the url and byte io stuff
[13:14:43] <mru> others doing stuff: cosmetics
[13:14:44] <lu_zero> mru: quiet!
[13:15:32] <lu_zero> michaelni: so if you find something with url is url, if you find something with io is io
[13:15:48] <lu_zero> as I wrote before
[13:16:21] <lu_zero> 2 letter are enough to match bit&byte (memory) io
[13:16:22] <michaelni> and wheres the logic in this? url being low level, io being high level with buffer ...
[13:16:42] <lu_zero> 3 are the least sufficient to match the protocols
[13:16:50] <lu_zero> (that we identify by urls)
[13:18:36] <lu_zero> the whole "I am special" should be avoided.
[13:18:55] <lu_zero> since that's what you are saying
[13:19:28] <lu_zero> and it is quite childish, or, as mru said at the start, silly.
[13:20:15] <BBB> I personally prefer AVIOContext and avio_*()/ffio_*() also
[13:20:17] <siretart> BBB: yes, it does work, and the first optimization is hardly measurable, cf. http://pbot.rmdir.de/ca03aa087199e1f5ebed93407affa75d
[13:20:19] <BBB> shall we vote?
[13:20:23] <michaelni> lu_zero, author of code and the person who maintains it are 2 special people
[13:20:29] <BBB> siretart: ok, mru feel free to apply avx patch then
[13:20:55] <michaelni> BBB: on the ML yes, here is unfair
[13:21:20] <BBB> takes too long
[13:21:24] <BBB> elenril: your patch, you choose
[13:21:29] <mru> just f*cking do it
[13:21:30] <BBB> easiest solution
[13:21:30] <lu_zero> michaelni: drop it.
[13:21:49] <BBB> I think everyone prefers AVIOContext and av/ffio_*()
[13:22:08] <mru> yes
[13:22:15] <elenril> BBB: i already said what i prefer
[13:22:35] <michaelni> politics ...
[13:23:02] <CIA-15> ffmpeg: Mans Rullgard <mans at mansr.com> master * r87f1355f9b ffmpeg/ (4 files in 3 dirs):
[13:23:02] <CIA-15> ffmpeg: x86: check for AVX support
[13:23:02] <CIA-15> ffmpeg: This adds configure and runtime checks for AVX support on x86 CPUs.
[13:23:02] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:23:09] <michaelni> and manipulation by selective voting
[13:23:21] <michaelni> now kick me
[13:23:24] <lu_zero> michaelni: are you describing your last 3 tries with [vote]?
[13:23:43] <lu_zero> the reversal strategy is well known...
[13:24:15] <lu_zero> the condorcet website is what I proposed if we want to have a proper vote
[13:24:33] <mru> we don't want a vote
[13:24:35] <michaelni> lu_zero, iam still waiting for your better vote with 2+weeks discussion and people proposing option and then condorcet
[13:24:36] <mru> voting is evil
[13:25:04] <lu_zero> michaelni: said what to do, up to the others say yai or nay.
[13:25:33] <michaelni> lu_zero, i cant start it or people will say i manipulated it by magic again
[13:26:02] <lu_zero> I can't start it otherwise somebody we know will say I manipulated it
[13:26:25] <elenril> BBB: will you sed it?
[13:26:31] <BBB> elenril: sure
[13:26:34] <elenril> great
[13:26:35] <mru> what sedding is required?
[13:26:49] <elenril> the latest patch has AVByteIOContext
[13:26:58] <elenril> but we just agreed on AVIOContext
[13:27:00] <mru> yeah
[13:27:15] <mru> BBB: just be sure to test before push
[13:29:30] <BBB> I will test-compile and make-fate
[13:29:48] <elenril> and don't forget to change the commit message
[13:29:49] * BBB does his magic s/AVByteIOContext/AVIOContext/g
[13:29:57] <BBB> elenril: doesn't it sed that automagically also?
[13:30:25] <elenril> if you're sedding the patch file, then yes
[13:30:26] <mru> I don't think anyone implemented git-sed yet
[13:30:41] <mru> ah, sedding the patch
[13:30:45] <BBB> elenril: I'm sedding your email before git am -s
[13:35:58] <BBB> hm, I had to s/AVByteIOContext/AVIOContext/g on the second patch also, or it doesn't apply, of course
[13:36:00] * BBB runs make fate
[13:36:09] <BBB> so AVIOContext and ffio_init_context()
[13:36:22] <BBB> avio_internal.h is fine with me as filename btw
[13:36:33] <BBB> elenril: both are queued
[13:37:43] <BBB> make -j4 fate is awesome
[13:37:59] <mru> make -j8 fate is awesomer
[13:38:11] <BBB> I don't have 8 cores :(
[13:38:15] <BBB> I think
[13:38:23] <BBB> how many cores does an i7 have?
[13:38:27] <mru> 4+ht
[13:38:39] <mru> -j8 runs a bit faster than -j4
[13:38:54] <mru> 20-30% or so
[13:40:20] <BBB> hm
[13:40:21] <BBB> ok
[13:40:22] <BBB> will try
[13:40:31] <BBB> have to write doc/APIChanges and will commit
[13:46:17] <elenril> ok, what next
[13:46:36] <BBB> buy me a 16-core machine
[13:46:48] <elenril> av_alloc_put_byte -> avio_alloc_context
[13:46:49] <BBB> av_alloc_put_byte() should of course be av_alloc_io_context()
[13:46:55] <BBB> avio_alloc_context indeed
[13:46:56] <BBB> sorry
[13:47:00] <BBB> so do that next
[13:47:16] <elenril> can you push now?
[13:47:28] <elenril> or i'll have to repeat your sedding
[13:48:11] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r70aa916e46 ffmpeg/libavcodec/vc1dec.c:
[13:48:11] <CIA-15> ffmpeg: VC1: don't use vc1_put_block() in vc1_decode_i_blocks_adv().
[13:48:11] <CIA-15> ffmpeg: Advanced profile never uses "range reduction", so vc1_put_block() quite
[13:48:11] <CIA-15> ffmpeg: literally just calls put_pixels_clamped() from vc1_decode_i_blocks_adv().
[13:48:11] <CIA-15> ffmpeg: By inlining the function, we can prevent calling IDCT8x8 if
[13:48:11] <CIA-15> ffmpeg: CODEC_FLAG_GRAY is set, and we don't have to scale the coeffs in the
[13:48:12] <CIA-15> ffmpeg: [0,256] range, but can instead use put_signed_pixels_clamped().
[13:48:12] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rae628ec1fd ffmpeg/ (140 files in 2 dirs):
[13:48:13] <CIA-15> ffmpeg: avio: rename ByteIOContext to AVIOContext.
[13:48:13] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:48:14] <BBB> done
[13:48:20] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rd2bbf82e65 ffmpeg/ (doc/APIchanges libavformat/version.h):
[13:48:20] <CIA-15> ffmpeg: Update version and APIchanges.
[13:48:20] <CIA-15> ffmpeg: Update libavformat/version.h and doc/APIChanges after renaming
[13:48:20] <CIA-15> ffmpeg: init_put_byte() and ByteIOContext to ffio_init_context() (private)
[13:48:21] <CIA-15> ffmpeg: and AVIOContext, (public), and deprecating the originals.
[13:48:23] <elenril> awesome
[13:48:23] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * re731b8d872 ffmpeg/libavformat/ (14 files):
[13:48:23] <CIA-15> ffmpeg: avio: move init_put_byte() to a new private header and rename it
[13:48:23] <CIA-15> ffmpeg: init_put_byte should never be used outside of lavf, since
[13:48:23] <CIA-15> ffmpeg: sizeof(AVIOContext) isn't part of public ABI.
[13:48:23] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[13:48:33] <mru> \o/
[13:48:40] <BBB> elenril: sorry this takes so long, bikeshedding is a very delicate business
[13:48:52] * BBB goes have breakfast
[13:48:58] <BBB> I'll apply your avio patch as soon as I finish
[13:59:51] <elenril> bumping minor for each small rename is annoying
[13:59:58] <elenril> maybe we should setup a branch for this
[14:00:07] <elenril> and then merge it after everything is renamed
[14:00:43] <mru> I think it's ok to bump minor once for a batch of related commits
[14:01:01] <elenril> yeah, but bumping for each two or three renames is too much
[14:07:58] <BBB> I can not bump the version for a while
[14:08:28] <elenril> so what about get/put_
[14:08:36] <elenril> we make them public, right
[14:08:39] <BBB> yes
[14:08:45] <BBB> avio_get_ is too long
[14:08:59] <BBB> I was thinking avio_[rw]{byte,[lb]e{16,24,32}}
[14:09:45] <BBB> similar to AV_W[NLB]{16,24,32}{,A}
[14:09:50] <BBB> I meant W or R
[14:10:08] <BBB> others have opinions?
[14:10:25] <BBB> the rename should still be a couple of seds over the whole source tree at best
[14:11:40] <BBB> as for how to do this without version bumps, I can setup a branch for your accepted commits, you can do your own branch, but I'd like to not do that since I'm affraid it'll get lost or forgotten or ignored
[14:13:01] <BBB> this way may be easiesty
[14:13:06] <BBB> we push 'em one by one
[14:13:15] <BBB> you keep a log of all we've done as a APIchanges patch
[14:13:20] <BBB> and we'll commit that when we're satisfied
[14:14:37] <elenril> i don't have a preference here
[14:17:04] <Kovensky> BBB: just commit (and push) everything to a branch (say "api_renames"), and when done do a git merge with "--no-ff --no-commit", git add the version bumps and commit the merge commit
[14:17:25] <Kovensky> that might not be the cleanest thing though; you may want to do the version bumps as the last commmit in the api_renames branch and then just `git merge --no-ff`
[14:17:45] <Kovensky> (the --no-ff keeps a commit saying it was a merge from branch X, even if it applies cleanly)
[14:18:27] <mru> I'd rebase the branch onto master and fast-forward master when ready
[14:19:56] <elenril> BBB: i dunno, e.g. avio_rbuffer doesn't look very readable to me
[14:22:15] <mru> there, another armcc bug filed
[14:22:34] <mru> they've confirmed the previous one
[14:24:28] <mru> oh crap
[14:27:13] <Kovensky> http://tvtropes.org/pmwiki/pmwiki.php/Main/OhCrap
[14:31:58] * elenril going to prague, see you in 3 hours
[14:33:56] <BBB> elenril: let's brainstorm
[14:33:59] <lu_zero> take care
[14:34:05] <BBB> avio_rb32/rl32 is ok?
[14:34:11] <BBB> oh he's gone
[14:34:16] <mru> seems reasonable to me
[14:36:40] <BBB> then avio_rbyte/wbyte is also ok?
[14:36:57] <mru> r8/w8?
[14:37:05] <BBB> yeah, better
[14:37:08] * mru compares to intreadwrite
[14:37:20] <BBB> avio_rbuf/wbuf?
[14:37:34] <mru> how about read/write?
[14:37:39] <BBB> oh, well duh
[14:37:41] <BBB> :)
[14:37:46] <BBB> elenril: ^^ there you go
[14:39:33] <mru> there, fixed
[14:41:55] * BBB thinks vc1 is a piece of crap
[14:43:10] <mru> the world agrees
[15:35:27] <mru> I'm getting frighteningly good at this...  picked the one line triggering an armcc bug in a 1k-line file just be looking at the C code
[15:35:35] <mru> *by
[15:36:18] <DonDiego> time to get paid for armcc testing? :)
[15:43:17] <siretart> DonDiego: can you please have a look at the 0.5 branch? I've already cut tarballs in my home (look in public_html), but if you find issues/corrections, I'm happy to roll them again
[15:45:43] * Flameeyes needs to fix a problem with .pc files
[15:46:02] <mru> delete them
[15:46:05] <mru> should fix it
[15:46:08] <Flameeyes> mru: I wish
[15:46:15] <Flameeyes> would get worse
[15:46:36] <mru> pkgconfig is a bad solution for the wrong problem
[15:47:10] <Flameeyes> "ld-deps" file in .a files would probably be better, agreed
[15:47:45] <mru> with gnu ld it can be done by replacing the .a with a linker script referencing the real .a and all deps
[15:48:16] <siretart> Flameeyes: I wonder if someone actually uses the -uninstalled variants of the .pc files
[15:48:24] <Flameeyes> true, problem is most people have no clue what a linking script is
[15:48:26] <Flameeyes> siretart: I do
[15:48:35] <lu_zero> mru: next large meeting we should try to get more people on fixing it for good
[15:48:42] <mru> impossible
[15:48:49] <lu_zero> why?
[15:48:55] <mru> the hordes don't even see there's a problem
[15:49:40] <lu_zero> the .pc is the best incomplete solution if you come to think about it
[15:49:58] <mru> but it doesn't work
[15:50:08] <siretart> it works for surprisingly many cases
[15:50:13] <mru> and it's open to abuse
[15:50:17] <lu_zero> it does up to a point (now that they fixed some parts of it)
[15:50:25] <mru> people put all sorts of crazy flags in there
[15:50:25] <Flameeyes> okay.. now I'm baffled
[15:50:30] <Flameeyes> the .pc generation is _correct_ in ffmpeg
[15:50:54] <mru> it's not unusual to find very gnu-specific flags in .pc files
[15:51:05] <mru> like -std=gnu99
[15:51:12] <mru> which can seriously fuck up a build
[15:51:29] <lu_zero> mru: I bet we'd get something even worse in the linker scripts
[15:51:44] <mru> provide some tools to generate them
[15:51:50] <siretart> mru: my favorite flag found in a .pc file was '-fvisibility=hidden'
[15:51:59] <mru> another good example
[15:52:41] <siretart> still doesn't mean we should shoot all pkg-config users
[15:52:51] <mru> but we can try
[15:53:09] <lu_zero> please don't kill me
[15:53:18] <mru> /kill lu_zero
[15:53:25] <j-b> 'moroning
[15:53:32] <lu_zero> hi j-b
[15:53:49] <lu_zero> ca va?
[15:54:00] <j-b> 've been better
[15:54:14] <mru> better moron?
[15:57:46] <DonDiego> Flameeyes: fwiw, i did spend some time on reviewing the patches for .pc file generation, but every other month somebody new seemed to pop up complaining about new issues...
[15:58:07] <mru> most of them imagined
[15:59:03] <Flameeyes> DonDiego: I think my first patches to ffmpeg have been about getting those right
[15:59:27] <mru> yours were probably good
[15:59:42] <Flameeyes> I was assuming a small mistake in it for a customer's build failure, but by now I suppose the answer is a conflict with system-installed ffmpeg on ubuntu.. need to review what my colleague wrote for them
[15:59:44] * Flameeyes eyes lu_zero
[16:05:05] * lu_zero is innocent 
[16:05:20] <Flameeyes> you're most definitely not.
[16:08:25] <BBB> bilboed: ping
[16:08:29] <bilboed> pong
[16:08:44] <BBB> so, gst-ffmpeg uses this custom URLProtocol way to interact with lavformat right?
[16:08:51] <bilboed> yes
[16:09:00] <BBB> bilboed: can I urge you to rewrite that by using ByteIOContext, which is what mplayer, xine and VLC do?
[16:09:11] <BBB> bilboed: I'm about to deprecate URLProtocol from our public API
[16:09:27] * mru deprecates gst
[16:09:34] <BBB> I'm trying to be nice :-p
[16:09:46] <bilboed> I need to spend some quality time updating gst-ffmpeg to use new APIs
[16:09:54] <mru> BBB: didn't you just rename that to AVIOContext?
[16:09:59] <BBB> ohright
[16:10:01] <bilboed> BBB, I'm fine if you deprecate it now
[16:10:03] * BBB smacks himself
[16:10:10] <BBB> bilboed: AVIOContext, not ByteIOContext
[16:10:20] <BBB> bilboed: also, if you have more API suggestions, now's a fantastic time
[16:10:31] <bilboed> as long as it clearly says "deprecated, use this instead"
[16:10:36] <BBB> doc/APIchanges
[16:10:41] <BBB> says all of that
[16:10:42] <bilboed> right
[16:10:54] * bilboed scratches head
[16:12:04] <bilboed> apart from having more introspectable info/options/.. from each component, not really.
[16:12:27] <mru> we're getting there, but it's taking time
[16:12:27] <bilboed> ex : being able to know an encoder can only take some width/height/framerate/colorspace in input for ex
[16:12:39] <uau> Flameeyes: there are some bugs in current ffmpeg .pc files for static linking at least
[16:12:43] <mru> pixel formats are already covered
[16:12:44] <bilboed> in a programmatic way, and not via debug messages
[16:12:50] <uau> missing libavutil and libm dependencies
[16:13:21] <BBB> bilboed: got it, we're gonna move a lot of stuff like AVCodecContext stuff into private codec-specific AVOptions
[16:13:29] <BBB> bilboed: this isn't easy, so it won't be done tomorrow, but it'll happen
[16:13:32] <bilboed> BBB, yah, so no, apart from that not much
[16:13:36] <BBB> ok, thanks
[16:13:39] <bilboed> de nada
[16:21:27] <BBB> kshishkov: with the current patch, is a VC1DSPContext.vc1_inv_trans_8x8_put{,_signed}[2] ok? [0] is regular range, [1] is rangeredfrm, which is <<=1 for signed or -64<<=1 for unsigned
[16:21:38] <BBB> kshishkov: once that's done, I'll go back to simd
[16:24:20] <uau> mru: if you complain about a couple of projects using gcc-specific flags in their .pc files, then how would making the whole _infrastructure_ fundamentally depend on a particular linker be an improvement over that?
[16:25:39] <mru> if someone made a sane proposal for a libdeps file in .a archives, I'm sure vendors could be persuaded to adopt it
[16:26:22] <mru> gnu binutils would be a reasonable place to start
[16:27:51] <mru> to answer your question, the "design" of pkgconfig already assumes everybody is using gnu tools
[16:28:00] <uau> and the advantage over the already widely working pkg-config would be what? that after a transition period of years we'd have a system which no longer supports arbitrary library-specific C flags (which also makes many things more cumbersome)?
[16:28:16] <mru> pkgconfig doesn't work
[16:28:19] <mru> that is the problem
[16:28:38] <uau> many people are using it and it works for them...
[16:28:48] <mru> and if fails for many others
[16:29:21] <uau> not using it would fail for a lot more
[16:29:38] <mru> solving the real problem would work for everybody
[16:30:06] <lu_zero> sure
[16:30:10] <uau> there's no single "real problem"
[16:30:18] <mru> yes, deps for static libs
[16:30:19] <lu_zero> in the mean time pkg-config works fine for most usages
[16:30:23] <uau> and nothing depending on linker changes could work for everybody
[16:31:14] <lu_zero> uau: ABI changes happen ^^;
[16:31:14] <mru> try building anything at all on a modern system with an old linker
[16:31:15] <mru> it won't work
[16:31:29] <mru> so linker changes happen and are relied on
[16:32:39] <lu_zero> and switching from flat archives to flat archives with deps
[16:32:48] <lu_zero> doesn't sound _that_ wrong
[16:33:22] <uau> it's take a lot of years before you could rely on linkers being updated "naturally"
[16:33:32] <uau> anyway what advantage would that have over pkg-config?
[16:33:45] <lu_zero> one less program
[16:33:53] <mru> that's a bonus
[16:34:02] <lu_zero> one less program that needs a variant for each toolchain you are using
[16:34:19] <mru> tightly coupling the dep information to the thing that actually has the dependency is more robust
[16:34:19] <lu_zero> one less file around your disk per library
[16:34:39] <mru> no risk of picking up the wrong dep file
[16:34:50] <mru> as pkgconfig has a habit of doing
[16:34:52] <lu_zero> so it isn't that wrong as idea
[16:35:12] <lu_zero> one copy of glib less in your system btw
[16:35:12] <mru> all the other things pkgconfig does don't need to be done
[16:35:26] <lu_zero> mru: which are?
[16:35:33] <mru> --cflags comes to mind
[16:35:36] <uau> why would there be no risk of picking the wrong file?
[16:35:50] <mru> uau: then you'd be picking the wrong lib too
[16:35:54] <uau> how would they be coupled to avoid that?
[16:36:01] <uau> to prevent updating one without the other etc?
[16:36:11] <mru> have you ever seen a linker pick the DT_NEEDED entries from the wrong .so?
[16:36:19] <lu_zero> they are the same file ^^;
[16:37:01] <uau> mru: there's just one .so file
[16:37:07] <mru> exactly
[16:37:08] <uau> you talked about separate linker script file
[16:37:16] <lu_zero> embedded in the .a
[16:37:20] <mru> I talked about placing a dep file inside the .a
[16:38:07] <uau> "replacing the .a with a linker script referencing the real .a and all deps" <- so you meant just the current gnu ld with that, and wanted that to change too?
[16:42:05] <uau> anyway the cflags support in pkg-config is often beneficial
[16:42:13] <mru> I disagree
[16:42:23] <uau> for example it allows switching libraries with a simple PKG_CONFIG_PATH change
[16:42:32] <mru> C_INCLUDE_PATH
[16:43:15] <uau> wouldn't work for linking
[16:43:29] <mru> LIBRARY_PATH
[16:43:49] <mru> and you still need to update the dynamic loader search path separately
[16:50:20] <uau> another thing is different library versions installed simultaneously
[16:50:41] <mru> which pkgconfig has no notion of
[16:51:41] <divVerent> 17:13:21          @BBB | bilboed: got it, we're gonna move a lot of stuff like AVCodecContext stuff into private codec-specific AVOptions
[16:51:46] <uau> you can have /usr/include/foo2/foo/foo.h, /usr/include/foo3/foo/foo.h; applications include <foo/foo.h>, pkg-config file can select which one is added to path
[16:51:51] <divVerent> will you do this keeping the current option names?
[16:52:22] <mru> as can C_INCLUDE_PATH
[16:52:44] <uau> again doesn't work for linking
[16:52:50] <mru> again, LIBRARY_PATH
[16:52:54] <mru> if you want, you can make a tool to manipulate those vars
[16:53:01] <mru> in fact, such tools exist
[16:53:03] <uau> no library_path doesn't help there
[16:53:28] <mru> of course it does
[16:53:38] <mru> the linker searches $LIBRARY_PATH after -L paths
[16:54:20] <uau> and using two variables plus explicit paths gets cumbersome
[16:54:39] <mru> so make a tool to set them for you
[16:54:43] <mru> call it pkgconfig if you like
[16:55:49] <uau> and what would be the benefit over current pkg-config? a lot more cumbersome to use, with a lot less functionality (which you think can be abused, but which is also useful)?
[16:56:58] <uau> also i think i already mentioned before the case of headers exposing functionality from other libraries - in that case you need pkg-config even with shared libraries
[16:57:25] <mru> /ignore uau
[16:58:07] <uau> pkg-config is used to solve real problems by linux distributions and other users
[16:58:24] <uau> and no those problems could not be solved by any linker .a dependency support or other such means
[17:01:41] <divVerent> you two didn't even talk about the same thing
[17:01:54] <divVerent> in MY opinion, we need BOTH pkg-config, and this "libdeps" stuff ideally inside the .a
[17:01:55] <mru> divVerent: that's uau in a nutshell
[17:02:06] <divVerent> these things are meant to solve different problems
[17:02:18] <divVerent> pkg-config = convenient way to get CFLAGS/LDFLAGS/... for linking with a library
[17:02:28] <divVerent> however, IMHO static and dynamic linking should NOT need different -l flags
[17:02:37] <divVerent> which some "libdeps" support would fix
[17:02:41] <mru> it's wrong of a library to require specific cflags
[17:02:47] <divVerent> no
[17:02:57] <mru> show me an example where it's needed
[17:02:58] <divVerent> library has every right to require -I/usr/include/mylib
[17:03:01] <mru> no
[17:03:10] <divVerent> however, this is the ONLY flag the library should require
[17:03:20] <divVerent> so instead of -I options, a list of paths would be just as good
[17:03:22] <mru> if I install it with --prefix=/usr, no more flags should be needed
[17:03:30] <mru> if I install it to some other prefix, that's my problem
[17:03:30] <divVerent> tell that to the Gtk guys
[17:03:42] <mru> yes, gtk et al are badly designed
[17:03:56] <divVerent> it does make sense though... it MAY help at fixing clashes
[17:04:22] <divVerent> one issue BTW: wouldn't it be good to allow installing multiple versions of the same package into one prefix?
[17:04:24] <mru> I don't understand why they put their headers inside an extra level of directories
[17:04:25] <divVerent> in /usr/lib you can
[17:04:31] <divVerent> just multiple libfoo.version.so files
[17:04:40] <divVerent> but in /usr/include there is no support for that
[17:04:42] <mru> but it's not one prefix that way
[17:04:51] <divVerent> this is what people are building with the include path stuff
[17:04:53] <mru> it's different prefixes with a common prefix
[17:04:57] <divVerent> we still NEED some handling for that
[17:05:04] <divVerent> like: you have multiple apps in your distro
[17:05:08] <divVerent> one for libjpeg62
[17:05:10] <divVerent> other for libjpeg8
[17:05:15] <divVerent> this is fine for dynamic linking
[17:05:19] <mru> libjpeg8 sucks anyway
[17:05:24] <divVerent> but you wouldn't be able to recompile them in a single prefix
[17:05:34] <divVerent> IMHO we need a solution that is BETTER than the current -I hack
[17:05:43] <divVerent> but we still need a way to have two versions of one lib in one prefix
[17:05:52] <mru> it's not one prefix
[17:05:56] <divVerent> IT IS
[17:05:57] <mru> it's two
[17:05:59] <divVerent> same /usr/lib directory
[17:06:02] <divVerent> same path of the .so file
[17:06:12] <mru> you're confusing things
[17:06:19] <divVerent> both have --prefix=/usr
[17:06:27] <mru> the dynamic loader works with multiple versions in the same directory
[17:06:30] <mru> the link editor does not
[17:06:42] <divVerent> yes, another thing to be solved there
[17:06:43] <mru> there's only one .so but multiple .so.X
[17:06:49] <divVerent> we also need support for libx.version.a
[17:07:12] <mru> easy: put them in /usr/blah-vX/{include,lib}
[17:07:14] <divVerent> thing is... the current way, you can have applications in your prefix that you cannot recompile on your system
[17:07:16] <divVerent> and THAT sucks
[17:07:35] <divVerent> okay... assume an app needs nondefault libjpeg62, AND nondefault libboost
[17:07:38] <divVerent> where does it go?
[17:07:42] <divVerent> /usr/jpeg-v62
[17:07:45] <divVerent> or /usr/boost-v1.30?
[17:07:59] <mru> neither
[17:08:05] <mru> jpeg goes in jpeg, boost in boost
[17:08:14] <divVerent> yes, but where does your application go that needs both?
[17:08:14] <mru> you _build_ the special app with special flags
[17:08:20] <mru> that makes it link to the right sonames
[17:08:24] <divVerent> so you basically install every single lib into a separate prefix?
[17:08:27] <mru> the .so.X files can be in a common place
[17:08:41] <divVerent> how is that better than the current way of the include subfolders?
[17:08:49] <divVerent> it looks like the very same mess to me
[17:09:02] <mru> you can have one default version available in /usr/include
[17:09:07] <mru> by symlinks or whatever
[17:09:17] <divVerent> I mean... if you do this, do it consistently
[17:09:22] <divVerent> install EVERY app into its own prefix
[17:09:22] <mru> and override with flags or env vars when needed
[17:09:24] <divVerent> and every lib
[17:09:27] <divVerent> and symlink them to the common dirs
[17:09:31] <mru> I'd be fine with that
[17:09:34] <divVerent> THAT would actually be sane in the end
[17:09:46] <divVerent> although... it'd be cloning C:\Program Files :P
[17:09:46] <mru> I used to have a system built like that
[17:09:50] <mru> no
[17:09:53] <divVerent> yes, it was called Windows :P
[17:10:02] <mru> windows is a mess
[17:10:16] <divVerent> yes, it contains many good ideas, but slapped together in a bad way
[17:10:22] <divVerent> C:\Program Files is nice
[17:10:24] <wbs> lu_zero: pong
[17:10:26] <divVerent> but not having the programs in PATH sucks
[17:10:36] <divVerent> and still dumping the DLLs into system32 sucks more
[17:10:37] <mru> and each bundling their own dlls sucks
[17:11:01] <mru> separate install dirs and some symlinks could solve a lot of things
[17:11:10] <j-b> Saying C:\Program Files is nice is a stupid attempt to troll
[17:11:12] <mru> in fact, many distros do just that for selected packages
[17:11:16] <divVerent> still, I am not opposed to include paths per library, as a somewhat "lightweight prefix"
[17:11:20] <j-b> mru: you mean, like /Applications?
[17:11:20] <divVerent> but it should also be optional, IMHO
[17:11:23] <mru> cf debian alternatives or gentoo eselect
[17:11:35] <mru> j-b: now who's trolling?
[17:11:38] <divVerent> j-b: c:\program files is not that bad... just "fix it" ;)
[17:11:42] <divVerent> it is broken, but a good idea
[17:11:44] <divVerent> implemented wrong
[17:12:04] <j-b> divVerent: it is broken in so many ways... /Applications is way betterly done.
[17:12:13] <divVerent> yes, but also broken
[17:12:17] <divVerent> also not in PATH, for example
[17:12:23] <divVerent> but yes, better done than on Windows
[17:12:30] <divVerent> at least it makes installing/uninstalling easy
[17:12:41] <divVerent> as applications are ENTIRELY in their dir (by the idea, not in practice on OS X, though)
[17:13:00] <divVerent> too many OS X apps "install" stuff to system-shared locations for no good reason, though
[17:13:13] <BBB> divVerent: what do you mean? current existing AVOptions? mostly, if they match
[17:13:14] <divVerent> but that is clearly fault of the apps
[17:13:18] <j-b> And it doesn't have the space in the middle of the name, and it doesn't have this stupid (x86) in it
[17:13:19] <BBB> divVerent: we'll keep compatibility of course
[17:13:22] <BBB> divVerent: but only so far
[17:13:24] <divVerent> BBB: great
[17:13:49] <divVerent> I just changed my own code that used 2 x264 specific options from using AVCodecContext->refs (and max_b_frames) to the get_int and set_int functions
[17:13:53] <divVerent> to make this transition easier
[17:14:40] <divVerent> j-b: space in the middle name, solved in German Windows ;)
[17:14:44] <divVerent> C:\Programme
[17:15:06] <divVerent> and of course, you can always hint to another stupid design flaw of windows, and just call it c:\progra~1
[17:15:17] <divVerent> which STILL WORKS ON NTFS FOR NO GOOD REASON WHATSOEVER
[17:15:57] <j-b> divVerent: right, great idea to rename this folder in every $LANG
[17:16:14] <divVerent> j-b: not THAT bad
[17:16:22] <divVerent> applications should not explicitly reference it by name anyway
[17:16:30] <j-b> /Applications is therefore, better
[17:16:38] <divVerent> almost
[17:16:41] <j-b> not to mention simpler
[17:16:48] <divVerent> /Applications is too reliable, unfortunately
[17:17:07] <divVerent> so I am sure some crappy app coder relies on his app to be EXACTLY in /Applications, EXACTLY under the correct name
[17:17:13] <divVerent> so if the user moves or renames it, it breaks
[17:17:23] <divVerent> which is EXACTLY WHAT /Applications IS SUPPOSED TO MAKE EASY
[17:17:47] <divVerent> thing is, everyone knows that hardcoding c:\program files will break your app
[17:17:58] <divVerent> but hardcoding /Applications/Foo.app on OS X... I can see that happen
[17:18:15] <mru> divVerent: localising names of system directories is annoying as hell too
[17:18:24] <divVerent> mru: I do not like that
[17:18:36] <divVerent> but also hate apps that assume they are installed in a hardcoded location
[17:18:52] <divVerent> bad enough that *x binaries typically assume such a thing (or rather, assume to know where the libraries are, although this is fixable)
[17:29:03] <mmu_man> cc7ywhbe.s:273:no such instruction: `xgetbv'
[17:29:05] <mmu_man> oops
[17:31:39] <elenril> o/
[17:34:00] <mmu_man> f* can't seem to get a way to remux those .ts properly :(((
[17:34:19] <mmu_man> ffmpeg complains and stops, and vlc goes along but the resuls doesn't have audio it seems
[17:34:31] <mru> mmu_man: try -fflags +nofillin-genpts
[17:34:52] <mru> and possibly also -strict 1 -vsync 0
[17:35:07] <mru> those should disable most of the insane pts butchering
[17:38:58] <Kovensky> 14:15.18 divVerent: which STILL WORKS ON NTFS FOR NO GOOD REASON WHATSOEVER <-- do you know why files can't have [:/?*><] in their names in windows? because of DOS backwards compatibility, even on NTFS which supposedly treats filenames as opaque data
[17:39:24] <divVerent> sure
[17:39:31] <divVerent> well, : would be a problem anyway
[17:39:33] <Kovensky> they can't have '\' for obvious reasons, but NTFS still doesn't forbid it
[17:39:37] <divVerent> and on POSIX / is not allowed either
[17:39:53] <divVerent> so, forbidding :, \ and / is excusable
[17:40:00] <divVerent> (Windows API allows generally / and \ as path separator)
[17:40:05] <Kovensky> yes, but they don't forbid / because of POSIX, they forbid / because it confuses the DOS parser
[17:40:17] <mru> ntfs also uses : for the ridiculous "forks"
[17:40:24] <divVerent> so they only support POSIX style paths because / was confusing DOS apps anyway
[17:40:29] <divVerent> mru: yes
[17:40:30] <Kovensky> if / was valid then it'd have to decide if "dir/w" was "file w in folder dir" or "dir /w"
[17:40:31] <divVerent> which is funny
[17:40:42] <divVerent> if in your current dir, you have a file "c" with an alternate data stream "foo"+
[17:40:49] <divVerent> how do you e.g. type it?
[17:40:53] <divVerent> type c:foo = FAIL
[17:40:59] <Kovensky> mru: : is forbidden though because of relative paths
[17:41:07] <Kovensky> each drive letter has its own CWD
[17:41:12] <mru> I know
[17:41:14] <mru> it's insane
[17:41:20] <divVerent> still... how to do this
[17:41:23] <divVerent> type .\c:foo
[17:41:25] <divVerent> or what?
[17:41:34] <divVerent> not like POSIX is much better for that...
[17:41:40] <mru> posix doesn't have forks
[17:41:40] <divVerent> as an exercise:
[17:41:42] <divVerent> su -
[17:41:45] <divVerent> cd ~unsuspecting_user
[17:41:45] <mru> well, posix has fork()
[17:41:50] <divVerent> touch -- '-rf *'
[17:41:50] <mru> which windows doesn't
[17:41:53] <divVerent> wait for him to delete it
[17:41:54] <mmu_man> mru: ahh thx, will try this
[17:42:08] <mmu_man> testing with vlc on the mac atm, maybe it's less buggy than the old one
[17:42:08] <mru> mmu_man: the xgetbv patch?
[17:42:16] <mmu_man> pts stuff
[17:42:23] <divVerent> mru: I mean, using : as separator for both drive letters AND alternate dara streams is insanely badly designed
[17:42:29] <mmu_man> got a patch to test for xgetbv ?
[17:42:31] <divVerent> as it makes paths like "c:foo" ambiguous
[17:42:40] <mru> mmu_man: of course
[17:42:46] <mru> if I break stuff, I fix it
[17:43:01] <divVerent> I wonder... "x:foo" - will this be a stream "foo" of file "x" if drive letter x: does not exist, and X:(current cwd of X:)\foo if it does exist?
[17:43:02] <Kovensky> 14:41.54 divVerent: wait for him to delete it <-- that tab completes to -rf\ * though
[17:43:06] <mmu_man> Kovensky: at least : on NTFS serves as named stream separator
[17:43:07] <elenril> so get_buffer -> avio_read?
[17:43:10] <mru> lu_zero: ok to push the xgetbv patch?
[17:43:12] <divVerent> Kovensky: which still fails, though :P
[17:43:16] <mru> elenril: that's the plan
[17:43:20] <elenril> sounds nice
[17:43:25] <elenril> doesn't it conflict with anything?
[17:43:32] <mru> don't think so
[17:43:53] <divVerent> Kovensky: only ways to delete it, apart from using wildcards, are stuff like ./-rf\ \*, or -- '-rf *'
[17:44:13] <mru> './-rf *'
[17:44:16] * Kovensky prefers to use the ../ approach
[17:44:18] <divVerent> especially fun, if you do something on * (wildcard), and have files that start with -
[17:44:20] <Kovensky> ./*
[17:44:23] <Kovensky> derp
[17:44:26] <divVerent> yes
[17:44:32] <divVerent> I also prefer the ./
[17:44:34] <divVerent> but it sucks :P
[17:44:42] <divVerent> I think the UNIX haters handbook mentions this issue already
[17:44:53] <mmu_man> hmm the OSX gui for vlc freaks out sometimes...
[17:44:55] <divVerent> not that windows would do it any better, though
[17:45:02] <mmu_man> [0x10029f9f8] macosx interface debug: input has stopped, refreshing interface
[17:45:06] <mmu_man> [0x10029f9f8] macosx interface debug: input has changed, refreshing interface
[17:45:09] <mmu_man> [0x10029f9f8] macosx interface debug: input has stopped, refreshing interface
[17:45:13] <mmu_man> [0x10029f9f8] macosx interface debug: input has changed, refreshing interface
[17:45:16] <mmu_man> :))
[17:45:55] <mru> I read some horror story somewhere about a script containing the line "rm -rf $foo/$bar" to do some cleanup towards the end
[17:46:01] <divVerent> had they e.g. used "::" for alternate data streams, it would have been SO much nicer
[17:46:13] <mru> as luck would have it, on one run, both $foo and $bar were empty...
[17:46:35] <mru> and the machine had nfs-mounted lots of things as well
[17:46:45] <mru> so before anyone knew it, the entire network was blank
[17:47:15] <divVerent> mru: hehe... mru I once had this in a makefile of a project of mine
[17:47:17] <divVerent> +       [ "$(OS)" != "Darwin" ] || $(RM_R) $(INSTALLDIR_BASE)/
[17:47:26] <mmu_man> mru: ouch :))
[17:47:29] <divVerent> also, INSTALLDIR_BASE was ONLY set if OS is Darwin
[17:47:41] <mmu_man> mru: running as root of course
[17:47:44] <divVerent> it didn't dop any harm...
[17:47:53] <divVerent> but the "rm -rf /" printed by make was quite scary to someone :P
[17:48:57] <mru> guess why I run untrusted scripts in sandboxes
[17:49:17] <divVerent> just, what DO you trust
[17:49:40] <divVerent> also, if you don't trust the scripts of the app you compile
[17:49:45] <divVerent> why would you trust the program itself any more
[17:50:52] <divVerent> speaking of [ ... || ...
[17:51:04] <elenril> BBB: can you look at the av_alloc_put_byte renaming patch?
[17:51:10] <elenril> it's pretty small, shouldn't take you long
[17:51:11] <divVerent> at work, we had a script using if [ foo == bar ]; then notation
[17:51:21] <mru> == is wrong
[17:51:25] <divVerent> not on Linux
[17:51:28] <mru> not in bash
[17:51:31] <divVerent> but that script tested uname result for Solaris :P
[17:51:35] <mru> bash != linux
[17:52:06] <divVerent> indeed, /usr/bin/[ also does not know == here
[17:52:25] <divVerent> just... the code SHOULD have assumed Solaris as the last else case
[17:52:37] <divVerent> BUT: Solaris's shell aborts the script on [/test related syntax error
[17:52:43] <mru> also watch out for [ $foo = $bar ] expanding to something like [ foo = bar -o a = a ]
[17:52:47] <divVerent> yes
[17:52:57] <divVerent> I always use [ x"$foo" = x"$bar" ] if I don't trust the input
[17:52:59] <mru> always good practice to use [ "x$foo" = "x$bar" ]
[17:53:04] <relaxed> bsd's sh will fail with == too
[17:53:04] <divVerent> same thing :P
[17:53:14] <divVerent> I like putting the x outside, but this is just cosmetics
[17:53:25] <mru> yeah, saw your line as I pressed enter
[17:53:55] <mru> people bitch about these things
[17:53:55] <divVerent> zsh has a nice feature... which unfortunately is default
[17:53:59] <divVerent> it prevents word splitting on $foo
[17:54:13] <divVerent> however, I rely on word splitting often in my scripts, at other places
[17:54:17] <mru> but they haven't understood how to use them cleverly
[17:54:38] <divVerent> so I ended up having to setopt SH_WORD_SPLIT in my script if ZSH_VERSION is set
[17:54:56] <mru> the ffmpeg scripts do all sorts of crazy things
[17:54:57] <divVerent> also, many of my scripts have a variable defined like this:
[17:54:59] <divVerent> LF="
[17:55:01] <divVerent> "
[17:55:25] <divVerent> seems to be the only portable way to get a linefeed
[17:55:30] <divVerent> even `echo` is unreliable :P
[17:55:30] * elenril rtfms about some sed-fu
[17:55:42] <divVerent> or even, usually not even generating a linefeed
[17:55:49] <divVerent> because the shell is so nice and strips it again
[17:55:53] <divVerent> LF=`echo;echo` :P
[17:56:09] <Sean_McG> 'lo folks
[17:56:18] <divVerent> wait, not even that works :P
[17:56:49] <mru> I ran into a weird one along those lines once
[17:57:04] <mru> using an alternate expansion containing double-quotes inside a here-doc
[17:57:12] <mru> apparently doesn't work in some shells
[17:57:19] <mru> not quite sure what the spec says
[17:58:01] <mru> but some shells do quote removal on the expansion, some don't
[17:58:18] <Sean_McG> here's lookin' at you, bash
[17:58:18] <mru> quote='"' solved it
[17:58:56] <elenril> get_partial_buffer -> avio_read_partial?
[17:59:02] <Sean_McG> it's "fun" trying to wrestle with that when configure scripts have --extra-[cflags|ldflags|libs]
[17:59:29] <mmu_man> hmm still haven't understood this --sout syntax on vlc... seems it doesn't work the same on old versions
[18:00:31] <mmu_man> and I can't assert if those streams are interlaced or not, there are strange artifacts when things move but deinterlacing isn't much better
[18:00:38] <divVerent> one sometimes broken thing I do rely on in my scripts is "$@"
[18:00:48] <divVerent> I don't go with the ${1+"$@"} crap
[18:01:25] <divVerent> POSIX says "$@" is nothing (not "") if $# is 0, and I do not see any reason to support BROKEN shells
[18:01:38] <divVerent> especially as ${1+"$@"} breaks in zsh :P
[18:01:43] <mru> to my knowledge, ffmpeg configure works with a strict posix shell
[18:02:03] <Sean_McG> what's your reference?
[18:02:04] <mru> zsh doesn't even try to be posix
[18:02:10] <Sean_McG> POSIX compliance is such an iffy thing
[18:02:18] <mru> Sean_McG: I read the spec
[18:02:29] <mru> and I run the scripts in many different shells
[18:02:30] <Sean_McG> OK, and what about the implementations? or
[18:02:39] <Sean_McG> anyways just playing devils advocate
[18:02:59] <mru> it works with bash, dash, ksh, /usr/xpg4/bin/sh, irix sh, tru64 sh, qnx sh, etc, etc
[18:03:13] <divVerent> hehe
[18:03:14] <mru> apple sh too
[18:03:15] <Sean_McG> you have access to a QNX box?
[18:03:19] <mru> sure
[18:03:27] <mru> it's free for non-commercial use
[18:03:45] <mru> and if you say you're a "consultant"
[18:03:58] <mru> a sane business model if you ask me
[18:04:02] <Sean_McG> ah, yeah there's one in FATE...never noticed it before (probably because it's green)
[18:04:17] * kshishkov usually gives name of imaginary friend in Kazakhstan in these cases
[18:04:31] <mru> Sean_McG: note the 0 in the gcc version string there
[18:04:35] <mru> that's a bug in qnx expr
[18:08:23] <CIA-15> ffmpeg: Mans Rullgard <mans at mansr.com> master * ref66953875 ffmpeg/libavutil/x86/cpu.c:
[18:08:23] <CIA-15> ffmpeg: x86: use raw opcode for xgetbv instruction
[18:08:23] <CIA-15> ffmpeg: This allows the CPU detection to work with assemblers not supporting
[18:08:23] <CIA-15> ffmpeg: the xgetbv mnemonic. These include clang and some BSD versions.
[18:08:23] <CIA-15> ffmpeg: All AVX code will be written for yasm, where the main assembler
[18:08:24] <CIA-15> ffmpeg: is not involved.
[18:08:25] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:08:28] <CIA-15> ffmpeg: Mans Rullgard <mans at mansr.com> master * r1efa772e20 ffmpeg/libavcodec/amrnbdec.c:
[18:08:28] <CIA-15> ffmpeg: amrnb: use correct size when copying lsf_r array
[18:08:28] <CIA-15> ffmpeg: lsf_r is an array of int16_t, not float.
[18:08:28] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:08:33] <CIA-15> ffmpeg: Mans Rullgard <mans at mansr.com> master * r08df7f8666 ffmpeg/Makefile:
[18:08:33] <CIA-15> ffmpeg: Makefile: include deps from tools directory
[18:08:33] <CIA-15> ffmpeg: This ensures the tools are rebuilt when necessary. Specifically,
[18:08:33] <CIA-15> ffmpeg: lavfi-showfiltfmts was sometimes not rebuilt causing spurious test
[18:08:34] <CIA-15> ffmpeg: failures.
[18:08:34] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[18:08:53] <mru> mmu_man: xgetbv workaround committed
[18:10:21] <ruggles> ??? where is avcodec_parse_frame() implemented?
[18:11:45] <mru> huh?
[18:12:03] <mru> mmu_man has a shitty assembler that doesn't know the xgetbv instruction
[18:13:02] <kshishkov> mru: don't they still use GCC 2.95 in Haiku?
[18:13:31] <mmu_man> kshishkov: that was in OSX
[18:13:32] <mru> kshishkov: fate says 4.4.4
[18:13:49] <mmu_man> well we use both actually
[18:13:56] <mmu_man> didn't even try to build with 2.95
[18:14:03] <mmu_man> yet
[18:14:10] <ruggles> mru: if you were referring to my question, avcodec_parse_frame() is in avcodec.h but I can't find the actual implementation anywhere.
[18:14:21] <kshishkov> mmu_man: my outdated OSX still had 3.3 and 4.0 IIRC
[18:14:41] <mru> ruggles: it doesn't exist
[18:15:19] <mmu_man> mru: builds now
[18:15:37] <mmu_man> i686-apple-darwin10-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5664)
[18:15:44] <mmu_man> didn't apply the latest OSX update yet
[18:15:50] <mmu_man> the one with this crappy app store
[18:17:44] <ruggles> mru: that's weird. why is the prototype still there? and the documentation for CODEC_CAP_PARSE_ONLY still refers to it.
[18:18:10] <mru> I can't find evidence of it ever existing
[18:18:33] <kshishkov> ruggles: why do we have parsers then?
[18:20:04] <ruggles> kshishkov: this is something different. decoding without writing output. not splitting packets into frames.
[18:20:26] <ruggles> i think...
[18:21:20] <mru> it was meant to decode only the frame headers
[18:21:29] <mru> for things like picture reordering
[18:23:32] <ruggles> the CODEC_CAP is only used by the mpegaudio decoder
[18:25:28] <mmu_man> [mp4 @ 0x8bb6c40] Application provided invalid, non monotonically increasing dts to muxer in stream 0: 30738 >= 30738
[18:25:32] <mmu_man> mru: still no way
[18:25:43] <mmu_man> ffmpeg -i sgu_0008.ts -acodec copy -vcodec copy -fflags +nofillin-genpts -strict 1 -vsync 0 tmp_0003_test.mp4
[18:32:10] <Sean_McG> awwww crap, I forgot... my fate-suite is at home
[18:32:13] <mru> mmu_man: -fflags before -i
[18:32:27] <Sean_McG> oh well, I guess I'll watch some of my Dr. Who DVDs
[18:32:52] <mru> or grab a new copy of the fate suite
[18:32:56] <Sean_McG> mru: maybe we should error out on that?
[18:33:08] <Sean_McG> (the fflags bit)
[18:34:09] <mru> fflags can apply to output as well
[18:34:28] <Sean_McG> ah
[18:35:01] <mmu_man> mru: yeah I noticed that, oddly the result is quite small then
[18:36:42] <mmu_man> vlc seems to work on the mac, just implies reading and writing to SMB shares but well
[18:36:42] <mru> mmu_man: apparently you're victim of the same "illusion" as myself and lu_zero then
[18:36:49] <mmu_man> ah
[18:37:00] <mmu_man> maybe it's just my glasses that need an upgrade
[18:37:07] <mru> certain individuals insist there's nothing wrong with the code
[18:38:10] <Sean_McG> I have a gcc trunk build failure to bugzilla today anyways
[18:38:40] <mmu_man> the resulting file is 261 bytes
[18:38:56] <mmu_man> nice compression from 700MB
[18:42:56] <mmu_man> cartainly competes with I2BP
[18:43:32] <mru> heh
[18:55:28] * elenril wonders what to do with put_nbyte and put_tag
[18:56:49] <Anssi> I'd do to put_nbyte the same as for put_byte, to stay consistent
[18:57:33] <elenril> avio_wn8 doesn't look all that readable
[18:59:09] <lu_zero> bilboed-tp: could you convince Gustavo Noronha to drop the use of cmake?
[19:00:21] <elenril> BBB: appears mpd is using URLContext as well
[19:00:48] <Sean_McG> mru: any objections to a patch to force fate.sh to use LANG=C and LC_*=C ? would prevent those wierd ligature characters in the reports
[19:06:06] <elenril> BBB: yeah, get rid of the 'e'
[19:06:15] <elenril> i was just going to do that myself
[19:15:15] <mru> hmm, this food actually came quite edible...
[19:34:38] <Flameeyes> I .. can't... belive... this ... crap!
[19:35:03] <kshishkov> order to beam it up
[19:35:03] <mru> need some help? I can believe almost any crap
[19:35:22] <kshishkov> mru: believe GSt then :P
[19:35:27] <mru> kshishkov: one crap to beam up?
[19:35:31] <Flameeyes> mru: the bug is NOT in ffmpeg's .pc files
[19:35:34] <Flameeyes> it's in pkg-config itself..
[19:35:42] <elenril> no Flameeyes, you are the demons
[19:35:43] <Flameeyes> or at least in the version available on ubuntu...
[19:35:44] <mru> Flameeyes: I've believed that for a long tmie
[19:37:31] <Flameeyes> flame at yamato static % PKG_CONFIG_PATH=$(pwd)/libavformat:$(pwd)/libavcodec:$(pwd)/libavutil:$(pwd)/libavcore pkg-config --libs 'libavformat >= 52.31.0 libavcodec >= 51'
[19:37:31] <Flameeyes> /home/flame/devel/repos/git/ffmpeg/static/libavformat/libavformat.a -pthread /home/flame/devel/repos/git/ffmpeg/static/libavcodec/libavcodec.a /home/flame/devel/repos/git/ffmpeg/static/libavutil/libavutil.a /home/flame/devel/repos/git/ffmpeg/static/libavcore/libavcore.a -ldl -lasound -lm -lbz2 -lz
[19:37:31] <Flameeyes> flame at yamato static % PKG_CONFIG_PATH=$(pwd)/libavcodec:$(pwd)/libavformat:$(pwd)/libavutil:$(pwd)/libavcore pkg-config --libs 'libavformat >= 52.31.0 libavcodec >= 51'
[19:37:31] <Flameeyes> /home/flame/devel/repos/git/ffmpeg/static/libavcodec/libavcodec.a -pthread /home/flame/devel/repos/git/ffmpeg/static/libavformat/libavformat.a /home/flame/devel/repos/git/ffmpeg/static/libavutil/libavutil.a /home/flame/devel/repos/git/ffmpeg/static/libavcore/libavcore.a -ldl -lasound -lm -lbz2 -lz
[19:37:35] <Flameeyes> [sorry for the small flood]
[19:38:09] <Flameeyes> it prints the libs ordering "first found, first printed", not "first requested, first printed"
[19:38:32] <Flameeyes> _even_ if I don't explicit libavcodec (and is thus brought in as a libavformat Require)
[19:38:41] <Flameeyes> but this breaks positional argument parsing!
[19:41:30] <lu_zero> ...
[19:41:33] <lu_zero> wonderful...
[19:42:45] <Flameeyes> [and since this is Gentoo, the bug is still there..]
[19:44:42] <kshishkov> Flameeyes: ask mru for ffmpeg.m4 instead
[19:45:05] <mru> the only m4 you'll find around here is cortex
[19:45:28] <Flameeyes> kshishkov: uhm, you do know I write on spare time an autotools guide, right? :)
[19:45:48] <kshishkov> Flameeyes: nope, I still had some respect for you
[19:45:59] <kshishkov> mru: but you like macro languages
[19:46:17] <uau> Flameeyes: hmm what exactly broke there?
[19:46:19] <Flameeyes> kshishkov: it is tremendously helpful to write how to do things sanely, when pointing upstreams to fix their crap
[19:47:04] <Flameeyes> uau: ld discards libavcodec.a because it's not required by anything at that point, then it picks up libavformat.a, which requires libavcodec.a, (which was discarded earlier)
[19:48:31] <lu_zero> kshishkov: the autotools guide show how to unbreak autotools
[19:49:10] <kshishkov> lu_zero: 0. don't install autotools 1. tell maintainers not to use it too
[19:52:01] <Flameeyes> kshishkov: so you end up with a bunch of custom-written unusable build systems
[19:52:12] <Flameeyes> trust me, I know they are bad, but I have seen much worse by people trying to avoid them.
[19:52:21] * kshishkov looks at FFmpeg
[19:52:46] <Flameeyes> ffmpeg is a rare exception, really.
[19:53:55] <ohsix> is that sum special pleading i see there
[19:54:20] <lu_zero> kshishkov: the result is cmake
[19:54:25] <lu_zero> that is even more icky...
[19:54:38] <ohsix> and scons
[19:54:49] <ohsix> the problem is you actually need to build software, which is lame!
[19:54:54] <Flameeyes> ohsix: thanks, now I'll have nightmares for anothre week
[19:54:56] <lu_zero> ohsix: scons is getting better usage
[19:55:04] <Flameeyes> lu_zero: no it's not
[19:55:09] <lu_zero> waf on the other hand is getting misused even more
[19:55:31] <Flameeyes> scons makes me wish imake was still in use... wait it is.
[19:55:39] <lu_zero> O_o...
[19:55:42] <lu_zero> imake...
[19:55:47] <mru> imake isn't that bad
[19:55:50] <lu_zero> now I'll have nightmares...
[19:55:51] <Flameeyes> mru: scons is.
[19:55:57] <mru> for the specific domain it was intended for
[19:55:57] <lu_zero> mru: imake IS bad
[19:56:02] <kshishkov> lu_zero: xmkmf -a
[19:56:15] <lu_zero> expecially for xf86 it was bad
[19:56:25] <mru> I never had any trouble with it
[19:56:28] <ohsix> imake was for purpose, if you're saying imake is bad isn't that a knock at any NIH build systems?
[19:56:55] <lu_zero> mru: did, a number of times ^^;
[19:57:11] <ohsix> imake was a blocker for it being broken up even a little, that's about it
[19:57:26] <mru> lies
[19:58:01] <mru> and the damn "modular" x is a disaster
[19:58:18] <mru> with the monolithic one you at least got matched versions of things
[19:58:34] <ohsix> they're putting some of the bits back together to make it easier to build, some things did really belong together when it finally shook out
[19:58:45] <Flameeyes> ohsix: like includes and libraries? :D
[19:58:46] <ohsix> but that's with everyone moving at once
[19:58:47] <mru> now, if you get the wrong micro version of some obscure lib, things start blowing up at runtime
[19:59:22] <ohsix> Flameeyes: like the drm bits and some of the trivial extensions, the rest i don't have a clear picture on
[19:59:23] <lu_zero> mru: it's part of the trade off
[19:59:31] <mru> it's a tradeoff I'd rather not make
[19:59:40] <lu_zero> now it builds in minutes and not hours
[19:59:48] <mru> the old one was faster to build and worked every time
[20:00:02] <lu_zero> and now a breakage in some stupid fringe bit won't bring everything down
[20:00:04] <ohsix> now jhbuild does it for you D:
[20:00:17] <mru> now you have to run configure scripts for minutes to compile a single .c file
[20:00:30] <ohsix> i don't
[20:00:44] <lu_zero> mru: what they do had been overzealous I do agree
[20:00:50] <mru> moving out some of the utilities might be a good idea
[20:00:55] <mru> but the core libs should stay together
[20:00:56] <lu_zero> still better than the past
[20:01:04] <lu_zero> mru: which core libs?
[20:01:05] <ohsix> and config.cache when you're building a bunch of related stuff with matching tests can save some time
[20:01:11] <mru> lu_zero: the ones you can't be without
[20:01:14] <lu_zero> motif? ^^
[20:01:25] <Flameeyes> ohsix: sorta
[20:01:29] <lu_zero> Xt?
[20:01:45] <Flameeyes> ohsix: config.cache is very unreliable on my experience
[20:01:46] <lu_zero> still it might grouped better
[20:01:49] <ohsix> Flameeyes: i know it breaks, was just sayin'
[20:02:03] <lu_zero> it's like we split each libav* in a separate package
[20:02:03] <ohsix> right, mismatched tests and different versions of aclocal
[20:02:08] <mru> lu_zero: most of the libX* ones
[20:02:13] <lu_zero> with ffplay and ffmpeg split as well
[20:02:16] <lu_zero> and every tool
[20:02:32] <Flameeyes> ohsix: even mismatched languages.. ac_cv_* variables are language-agnostic.. breaks pretty badly when you mix C, C99 and C++ :(
[20:03:15] <ohsix> i'm just thinking with jhbuild + the xorg modules; i know its untenable as a global cache
[20:03:49] <ohsix> they could version everything in the cache and make it more ugly :D
[20:04:41] <ruggles> there is no fate test for the mp3 decoder? wtf?
[20:04:58] <ohsix> mp3 is for communists
[20:05:06] <uau> Flameeyes: looks like pkg-config has some logic to keep things in path order, to keep -L arguments in correct search path order; OTOH it looks like -l and -L should get handled separately
[20:05:15] <Sean_McG> lol
[20:05:23] <kshishkov> ruggles: well, you obviously use only AC3 and FLAC for your files
[20:05:33] <ruggles> :P
[20:06:12] <kshishkov> I just try to play whatever I got with my decoders
[20:17:45] <uau> Flameeyes: i think your problem occurs because in your case pkg-config is picking up the -uninstalled variants of the .pc files, and those use 'path/foo.a' instead of '-Lpath -lfoo'; the former isn't recognized as an -l argument that should be sorted in dependency order
[20:18:08] <Flameeyes> uau: it still should reflect the Requires: order not the PKG_CONFIG_PATH order.
[20:18:34] <uau> no, it should not do that for all the arguments
[20:18:49] <uau> doing that for -L would be wrong
[20:19:06] <uau> because it would lead to the wrong library being picked up if versions existed in multiple directories
[20:21:43] <Flameeyes> uau: well it leads to libraries to be dismissed randomly the way it is done now, so what's worse?
[20:22:05] <ruggles> i'm trying to test the mp3float decoder, but i can't seem to get ffmpeg to select it. any suggestions?
[20:22:35] <mru> whatever fate-mp3-float-* does
[20:23:52] <uau> Flameeyes: the problem is specific to the use of arguments other than -lfoo to load the libraries; if you change the .pc file to use "-Lpath -lfoo" instead of "path/foo.a" i think it should work
[20:24:32] <ruggles> mru: ah, thanks. i missed the separate fate Makefile for mp3
[20:25:33] <Sean_McG> mru: what *is* that 0 in the qnx gcc ident?
[20:26:29] <uau> Flameeyes: why are you using the uninstalled versions btw? rather than installing to a temporary dir?
[21:05:27] <BBB> elenril: sorry, was out for a little, so had to communicate using an iDevice
[21:06:19] * elenril almost has a get_strz replacement done
[21:07:58] <ruggles> wow, found a bug in reverse. looking at the code, i thought "this looks like mono mpc will crash on x86". and sure enough it does.
[21:09:32] <ruggles> hmm. nevermind.
[21:10:03] <ruggles> but it should ;)  i'm probably just missing something.
[21:13:15] <ruggles> oh, mpc uses fixed-point not floating-point. that explains it. oops.
[21:14:35] <CIA-15> ffmpeg: Reinhard Tartler <siretart at tauware.de> release/0.5 * r2c4d6aeabc ffmpeg/VERSION: Bump version number for 0.5.4 release.
[21:21:56] * elenril sleeps
[21:34:36] <BBB> omg
[21:34:51] <BBB> ppc/* has no code for clamped pixels (short->byte)
[21:39:57] <BBB> mru: ping
[21:40:01] <BBB> (or anyone knowing ppc asm)
[21:42:29] <Sean_McG> I'd like to learn ppc asm... I bought a used G4 Mini yesterday but haven't set it up yet
[21:43:30] <mru> pong
[21:48:53] <siretart> my prof loves ppc asm for some reason…
[21:49:56] <ohsix> xbux
[21:50:12] <Sean_McG> ps3 has a POWER core too ;)
[21:50:19] <mru> BBB: you had a question?
[21:50:23] <mru> Sean_McG: not really
[21:50:43] <mru> ps3 has a stripped-down hyperthreaded ppc core
[21:51:02] <BBB> mru: can you look at vc1dsp_altivec.c and tell me for the result of inv_trans_8x8_altivec, how do I add or subtract a value from the resulting coeffs or left-shift it by one?
[21:51:04] <mru> and 7 vector coprocessors
[21:51:11] <Sean_McG> it's a slightly anemic G3, plus those SPU processors elements, if I recall correctly
[21:51:16] <mru> no
[21:51:17] <BBB> mru: as in, if I send you a 3/4 finished patch, can you fix make fate on altivec?
[21:51:25] <mru> it's a very anemic 970
[21:51:31] <Sean_McG> oh...G5
[21:51:35] <Sean_McG> my bad
[21:51:38] <mru> it's machine code compatible with 970
[21:51:59] <mru> but has very few execution units
[21:52:00] <BBB> mru: also, altivec has no put/add_{,signed_}pixels_clamped(), which is kinda shameful
[21:52:08] <BBB> mru: someone (you) should implement that
[21:52:18] <mru> doesn't even have a barrel shifter iirc
[21:52:22] <Sean_McG> could the clamping be done with a permute?
[21:52:32] <BBB> ??
[21:52:36] <mru> altivec has saturating arithmetic
[21:52:52] <BBB> I meant grep clamp ppc/*.c comes up empty
[21:53:01] <BBB> I'm sure it has instructions for it
[21:53:03] <BBB> of course it does
[21:53:06] <mru> BBB: I understand what you mean
[21:53:06] <Sean_McG> ah
[21:53:13] <Sean_McG> sorry, forget I said anything
[21:53:18] <mru> BBB: I'm just not highly motivated to work on it
[21:53:23] <BBB> mru: can I send you a patch and you fix it up for me?
[21:53:25] <BBB> oh
[21:53:30] <BBB> who else does ppc here?
[21:53:33] <BBB> Yuvi: ping! :-p
[21:53:42] <mru> I can review patches
[21:53:48] <Sean_McG> mister Conrad did the stuff for vp8
[21:53:54] <BBB> conrad is yuvi
[21:53:57] <Sean_McG> ah
[21:54:25] <mru> I finished up the fft once upon a time
[21:54:28] <mru> that was an adventure
[21:54:46] <siretart> oh. qemu uses launchpad as upstream bugtracker?! interesting.. http://wiki.qemu.org/Contribute/ReportABug
[21:55:00] <mru> ppc abis are not to be taken lightly
[21:56:09] <kierank> BBB: there's also LordRPI in #x264dev
[21:56:26] <mru> BBB: why the interest in ppc?
[21:57:26] <BBB> mru: ppc has existing vc1 optimizations
[21:57:31] <BBB> I will break them in my next patch
[21:57:39] <mru> I see
[21:57:42] <BBB> trying to see if I can unbreak them
[21:58:04] <mru> do you have an altivec manual?
[21:58:09] <BBB> no
[21:58:11] <mru> it's somewhere on ibm's website
[21:58:20] <Sean_McG> sec, I have URLs for those
[21:58:22] <BBB> I hope someone will do it for me if I tell them what I want the code to do :-p
[21:58:27] <BBB> maybe lu_zero
[21:58:33] <BBB> lu_zero: do you know ppc / altivec?
[21:59:32] <Sean_McG> http://www.mactech.com/articles/mactech/Vol.15/15.07/AltiVecRevealed/ <-- scroll to the bottom
[22:00:08] <Sean_McG> errr hrm wait no... those link to sps.mot, which are probably dead links
[22:01:28] <BBB> mru: or alternatively I just break 'em
[22:01:47] <Sean_McG> here we go: http://www.freescale.com/files/32bit/doc/ref_manual/ALTIVECPEM.pdf
[22:01:53] <BBB> mru: I can "just" implement the "add" idct8x8, and leave the 8x8_put ones unoptimized
[22:01:56] <BBB> that way the code is there
[22:02:01] <BBB> and it's easy to fix for whoever wants to
[22:02:11] <BBB> mru: but it'll be a significant slowdown on altivec
[22:05:00] <mru> BBB: https://www-01.ibm.com/chips/techlib/techlib.nsf/techdocs/FBFA164F824370F987256D6A006F424D/$file/vector_simd_pem.ppc.2005AUG23.pdf
[22:06:25] <Flameeyes> BBB: lu_zero definitely knows altivec — the quesiton is whether lu_zero is awake
[22:06:35] <BBB> Flameeyes: can you awaken him?
[22:07:06] <Flameeyes> BBB: I hope he is since he should review stuff from me for work
[22:09:38] <mru> Sean_McG: about that 0 on qnx, it's a bug the expr : operator
[22:10:51] <lu_zero> yawn
[22:11:51] <lu_zero> BBB: what to do?
[22:11:54] <Flameeyes> BBB: see? I did it :D
[22:12:27] <lu_zero> (ps using jabber would have the same effect..)
[22:12:35] <BBB> \o/
[22:12:47] <BBB> lu_zero: can you fix up a function in vc1dsp.c for me now that I'm about to break it?
[22:13:04] <BBB> lu_zero: I can sort of tell you what to fix and set up the functions, and you then fill in the blanks
[22:13:07] <BBB> lu_zero: is that ok?
[22:13:14] <lu_zero> ok
[22:13:36] <mru> great, I don't like altivec loads and stores
[22:21:01] <lu_zero> mru: too inflexible?
[22:21:03] <lu_zero> =)
[22:21:18] <lu_zero> (neon load+shuffle is neat)
[22:22:23] <Sean_McG> ooh cheers for the IBM link
[22:22:50] <mru> lu_zero: I'd be fine with plain unaligned load/store
[22:23:19] <Sean_McG> seems like a lot of the RISC platforms don't have that, or do with a significant performance penalty
[22:23:40] <mru> arm takes a 1-cycle penalty
[22:25:36] <lu_zero> arm from time to time seems too wonderful
[22:25:46] <lu_zero> ppc is _way_ simpler though
[22:25:50] <lu_zero> (and mips even more)
[22:28:13] <BBB> lu_zero: do you want me to pastbein it
[22:28:14] <BBB> ?
[22:28:21] <BBB> (sorry, baby cried)
[22:28:33] <lu_zero> BBB: yes please =)
[22:28:39] <Sean_McG> AltiVec code makes babies cry? that's not good.
[22:29:19] <BBB> lu_zero: http://ffmpeg.pastebin.com/B3952rsB
[22:29:31] <BBB> line 42 and 55 are the blanks for you
[22:29:40] <BBB> feel free to change anything you want on top of this patch to achieve it
[22:30:00] <BBB> lu_zero: also, implementin altivec ff_add,put,put_signed_pixels_clamped would help a lot
[22:31:00] <lu_zero> thinking about it
[22:31:01] <lu_zero> so
[22:31:12] <lu_zero> sub 64 and shift by 1 ?
[22:31:38] <lu_zero> uhmm
[22:31:53] * lu_zero wonders if he should be lazy and let gcc do the work...
[22:31:55] * Sean_McG looks out of idle curiosity
[22:32:16] <lu_zero> in altivec consts are made out of splats and shifts
[22:32:42] <lu_zero> (till 4 ops per const is better than load from memory and splat)
[22:32:56] <lu_zero> gcc does that for you nowadays
[22:33:00] <lu_zero> </lesson>
[22:36:10] <lu_zero> (in case you were wondering why const vector signed int vec_64 = vec_sl(vec_splat_s32(4), vec_splat_u32(4));)
[22:36:55] <Sean_McG> yeah it's cool that the intrinsics are already functions
[22:37:29] <lu_zero> altivec intrinsics are something leave you with mixed feelings
[22:37:49] <lu_zero> they are nicer to write but then if your compiler has bugs...
[22:38:02] * lu_zero still recalls gcc-3.3
[22:38:11] <Sean_McG> seems to be quite a few people at IBM helping with gcc now
[22:38:21] <Sean_McG> (probably because of POWER7)
[22:38:32] <Sean_McG> wonder if Watson was compiled with gcc ;)
[22:38:38] <lu_zero> it's sad they gave up the consumer market
[22:38:44] <Sean_McG> that's Apple's fault.
[22:39:06] <Sean_McG> and partially Motorola for not giving a shit
[22:39:12] <lu_zero> Sean_McG: it's shared with IBM/Freescale
[22:39:37] <lu_zero> inside freescale there were a number of people actively AGAINST going into that market
[22:39:54] <Sean_McG> see I didn't know that
[22:39:58] * lu_zero still recall a meeting/show in Frankfurt
[22:40:15] <Sean_McG> was the Freescale thing after Mot left the PPC alliance?
[22:40:30] <lu_zero> basically we got insulted because we were supporting g4 on desktop and showing up how good it was
[22:40:42] * BBB awaits lu_zero's results
[22:40:46] <lu_zero> (well we got also praised by the other faction
[22:40:47] <lu_zero> )
[22:40:49] <lu_zero> uhm
[22:41:00] <lu_zero> mind if I do something more invasive?
[22:41:07] <lu_zero> I'm feeling lazy
[22:41:27] <Sean_McG> invasive and lazy usually don't go well together ;)
[22:41:39] <lu_zero> Sean_McG: if you are curious
[22:41:41] <lu_zero> static void vc1_inv_trans_8x8_altivec(DCTELEM block[64])
[22:41:52] <Sean_McG> very curious
[22:42:03] <lu_zero> around line 216
[22:44:22] <Sean_McG> 8 separate stores even though the addresses are contiguous
[22:44:47] <lu_zero> ehm
[22:44:56] <lu_zero> count the elements
[22:45:36] <lu_zero> 16*8byte to move
[22:45:39] <Sean_McG> a DCTELEM is a short, yes?
[22:47:43] <Sean_McG> I'm sorry, if I'm talking nonsense don't hesitate to let me know
[22:48:16] <lu_zero> altivec has a register of 16byte
[22:49:20] <Sean_McG> ahhhh... yes of course
[22:49:23] <lu_zero> unsigned has -64 just in a single case?
[23:00:44] <BBB> lu_zero: go for it, you can do anything
[23:01:12] <Sean_McG> I guess I need to start with the basics... I'll read a bit of this IBM PDF
[23:03:56] <mru> arm neon is fantastic
[23:04:18] * BBB pets mru
[23:04:30] <mru> then again, they had the mistakes of sse and altivec to learn from
[23:04:43] <Sean_McG> other than the ones attached to my shoulders, I don't have an arm ;)
[23:04:45] <BBB> so interestingly, MS guarantees not 16bit, but 17bit results
[23:04:48] <Sean_McG> anyways, dinnertime
[23:04:50] <BBB> mru: so how did you do that?
[23:05:13] <BBB> because the result is 10 bit, from a 7 shift right source, so the result of all math is 17bits
[23:05:17] <BBB> how to fit that in 16?
[23:05:17] <mru> BBB: in the idct?
[23:05:20] <BBB> yeah
[23:05:57] <DonDiego> siretart: still online?
[23:08:15] <mru> BBB: I told you neon is good :)
[23:09:12] <mru> BBB: I don't remember how I did it, maybe some halving add trick
[23:09:24] <mru> that instruction can be a lifesaver
[23:10:02] <lu_zero> BBB: something like http://ffmpeg.pastebin.com/9CV4ejwY
[23:10:29] <lu_zero> so you call the function with constants and gcc should do the rest
[23:14:37] <mru> what does "rangered" mean?
[23:17:02] <lu_zero> mru: picked up from ronald patch
[23:17:14] <mru> BBB: ^^
[23:19:36] <DonDiego> siretart: anyway, i have a few minor nits for the release docs
[23:19:50] <DonDiego> will fix tomorrow
[23:24:40] <lu_zero> BBB: I'm heading to bed tell me in 8-9 hours
[23:27:49] <mru> ah, it's range reduction
[23:29:56] <DonDiego> gnite
[23:30:51] <BBB> mru: like averaging? yeah
[23:30:54] <BBB> lu_zero: ok
[23:31:02] <BBB> mru: range reduction frame, yes
[23:31:16] <mru> BBB: neon has an instruction that does (a+b)>>1
[23:31:42] <mru> so yes, average
[23:31:58] <mru> it also has (a-b)>>1
[23:32:03] <Dark_Shikari> and (a+b+1)>>1
[23:32:13] <mru> and (a-b+1)>>1
[23:32:28] <mru> I can't remember ever using the halving sub ones
[23:33:13] <mru> oh, I have
[23:33:16] <mru> in one place
[23:33:28] <Dark_Shikari> Might they be useful in an h264 idct?
[23:33:56] <mru> h264 weighted pred
[23:34:16] <mru> h264 idct doesn't overflow even without trickery
[23:34:22] <Dark_Shikari> h264 idct does (A>>1)-B   and A+(B>>1)
[23:34:46] <mru> which isn't the same thing
[23:34:53] <Dark_Shikari> I wonder if it could be abused for that, hmmph
[23:35:04] <Dark_Shikari> I guess the loss of precision means no.
[23:35:08] <mru> I couldn't think of any tricks for that
[23:35:23] <mru> doesn't mean there aren't any of course
[23:35:49] <mru> the weighted prediction is evil
[23:36:10] <mru> the obvious way needs 17 bits