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

Tue Feb 22 01:00:46 CET 2011

[00:57:58] <BBB> oh wth, pavgw is mmx, not mmx2
[00:58:01] <BBB> awesome
[01:04:34] <iive> BBB: hum? where did you read that?
[01:15:03] <iive> i'm quite sure it is mmx2. (pavgw 0x0F, 0xE3)
[01:28:54] <BBB> it says katmai in my guide
[01:30:09] <iive> katmai is Pentium3 and it is SSE (1) capable
[01:30:29] <BBB> oh
[01:30:30] <iive> actually that is the only thing that differs from P2 (and the clock of course).
[01:30:31] <BBB> fuck
[01:30:34] <BBB> you're right
[01:31:01] <BBB> ohwell
[01:31:05] <BBB> no mmx idct then
[01:31:05] <iive> :) and mmx2 is sse integer.
[01:31:07] <BBB> mmx2 is fine
[01:31:26] <iive> there is macro/trick that emulates avg
[01:31:48] <iive> it should still be faster than C
[01:32:11] <iive> I've seen it in the MC code.
[01:32:23] <BBB> it doesn't work over 17 bits
[01:32:28] <BBB> I need 17 bits
[01:32:29] <BBB> :(
[01:32:34] <iive> yes it does
[01:32:36] <BBB> ?
[01:32:41] <BBB> I'll look
[01:32:46] <BBB> I'm probably confused
[01:32:52] <BBB> still, who cares about mmx
[01:32:55] <BBB> it's 10 years old
[01:33:13] <BBB> it's more like "hey, if I can do this hell of a function in mmx, just guess how much easier and more efficient it'll be in sse2"
[01:33:18] <BBB> :-p
[01:34:10] <iive> last time I heard nasa was still using 486... something with cosmic rays and stuff.
[01:34:29] <Sean_McG> flip the wrong bit and kaboom
[01:35:42] <BBB> iive: right
[01:35:44] <BBB> iive: so...
[01:35:48] <BBB> iive: nasa is using vc1 for ...
[01:35:48] <BBB> ?
[01:35:52] <BBB> please fill in my blank
[01:35:59] <Sean_McG> space porn?
[01:36:01] <iive> huble
[01:36:01] <kierank> you'd be surprised
[01:36:07] <BBB> to compress their cosmic rays?
[01:36:14] <kierank> they used vc-1 on some videos once ;)
[01:36:15] <BBB> I mean, I feel really sorry for those guys
[01:36:24] <BBB> not only is al detail in their rays gone
[01:36:29] * kierank wonders why BBB is working on vc-1
[01:36:29] <BBB> if their porn was indeed in vc1
[01:36:36] <BBB> they'd have no idea about what they're looking it
[01:36:38] <BBB> imaginary porn
[01:36:44] <BBB> kierank: good question
[01:36:53] <BBB> kierank: I found a movie, it played disastrously sloly
[01:36:56] <BBB> so I work on it
[01:36:56] <kierank> next we're going to hear that you're going to write vc-1 interlaced
[01:37:01] <BBB> \o/
[01:37:07] <BBB> pay me
[01:37:26] <Dark_Shikari> I think we could justify at least a $5k foundation bounty for that.
[01:37:29] <iive> have you asked the foundation?
[01:37:33] <Dark_Shikari> It's the one thing missing for blu-ray decoding
[01:38:00] <kierank> and mvc ;)
[01:38:10] <Dark_Shikari> mvc isn't part of original blu-ray
[01:38:17] <BBB> dudes
[01:38:22] <Dark_Shikari> and you can decode 3D blu-ray without an mvc decoder
[01:38:23] <BBB> I'm not gonna implement vc1 interlaced
[01:38:26] <BBB> I'm lazy
[01:38:28] <BBB> besides I have a job
[01:38:29] <Dark_Shikari> then why'd you say pay me
[01:38:34] <kierank> iirc we still fail on backwards compatible 3d
[01:38:39] <kierank> might be wrong though
[01:39:05] <BBB> Dark_Shikari: usually people shut up when ypu say that :)
[01:40:49] <iive> you used to be such a nice guy.
[01:40:58] <Dark_Shikari> and then google hired him and sucked his soul
[01:42:41] <BBB> iive: :( I'm no longer nice?
[01:42:52] <BBB> iive: besides I do work on vc1 opts
[01:42:55] <BBB> I try at least
[01:43:13] <BBB> but yeah I'll give my soul for my kid's college
[01:43:17] <BBB> he's cute :)
[01:44:34] <iive> I had no idea education is so much expensive in USA.
[01:45:56] <BBB> depends on the college ...
[01:47:08] <saintdev> Mudd
[01:47:10] * saintdev runs
[01:49:31] <Dark_Shikari> You can get him like me and get him to pay half of it `-`
[01:52:14] <saintdev> Dark_Shikari: how does mudd's tuition compare to mit or cmu?
[01:52:25] <iive> BBB: well... imho if things keep going on like this, there will be second financial crysis, most probably in about 2 years, maybe even on time for electing the correct president.
[01:52:44] <BBB> who's the correct president
[01:52:44] <Dark_Shikari> saintdev: same
[01:52:50] <Dark_Shikari> ~$52000 per year including room/board
[01:54:11] <iive> BBB: too early to say.
[01:54:19] <BBB> well that's useful :)
[01:54:20] <BBB> anyway
[01:54:23] <BBB> I'll just work on vc1
[01:54:31] <BBB> surely nobody will complain about me improving vc1 :)
[01:54:47] <saintdev> i object!
[01:56:15] <iive> n8 ppl.
[02:21:03] <asdf1234> saintdev: pretty much *every* private college in the US costs $50k+ a year
[02:21:18] <asdf1234> (undergrad)
[02:21:36] * mru is happy with his free swedish education
[02:22:10] <asdf1234> that is, if your family makes under $50k a year
[02:22:27] <asdf1234> then private colleges are actually usually cheaper than public schools
[02:22:39] <asdf1234> as in free
[03:21:46] <Jumpyshoes> where are the deblock functions for h264 initialized?
[03:24:36] <Dark_Shikari> grep
[03:25:42] <frunksock> how can I get make to show me the entire compile command instead of abbreviating it to "CC  foo.o"
[03:36:39] <frunksock> does ffmpeg include the ffmpeg-mt stuff yet?
[03:37:03] <Dark_Shikari> some of it
[03:40:24] <peloverde__> frunksock: make V=1
[03:40:50] <frunksock> thanks peloverde__
[03:41:07] <frunksock> I had been trying VERBOSE=1 to no effect
[06:11:45] <cartman> moin
[06:19:40] <dalias> hi
[06:24:23] <thresh> moroning
[06:40:56] <Dark_Shikari> Actual quote from the Google C++ style guide:
[06:41:03] <Dark_Shikari> "If your function crashes upon error, you should append OrDie to the function name."
[06:41:11] <Dark_Shikari> (e.g. "OpenFileOrDie")
[06:41:19] <spaam> God morgon :)
[06:41:25] <cartman> Dark_Shikari: Perl like
[06:41:29] <Dark_Shikari> Yup
[06:45:06] <KotH> ohayou gozaimasu!
[06:56:36] <KotH> cartman: Türk insan\u0131 para gibidir; \u0131\u015f\u0131\u011fa  tut,\u0130çinde Atatürk yoksa sahtedir....
[06:57:52] * elenril drops an anvil on KotH 
[06:58:01] <cartman> KotH: ;>
[07:07:06] <kurosu> BBB: is that really 17bits or 16bits with an offset (for instance [-13000;48000]) ?
[08:37:35] <kshishkov> lu_zero: http://satwcomic.com/art/your-time-is-up.jpg
[08:39:32] <lu_zero> kshishkov: god morgon
[08:39:42] <cartman> nice one
[08:40:21] <lu_zero> sigh...
[08:43:57] <lu_zero> close
[08:44:22] <spaam> lu_zero: Hur Ã¤r det idag? :)
[08:44:38] <kshishkov> spaam: kanske inte sÃ¥ bra
[08:44:46] <spaam> kshishkov: varfÃ¶r dÃ¥?
[08:45:17] * spaam sitter och dricker trocadero
[08:45:26] <kshishkov> spaam: fel, du mÃ¥ste fraga "voffor dÃ¥"
[08:45:53] * kshishkov vill gÃ¤rna dricka Trocadero men hon har inget
[08:46:01] <wbs> hon? ;P
[08:46:14] <spaam> kshishkov: han menar du.
[08:46:17] <kshishkov> I always confise
[08:46:22] <kshishkov> *confuse
[08:46:22] <spaam> kshishkov: du Ã¤r vÃ¤l en man?
[08:46:29] <kshishkov> those two pronouns
[08:46:44] <spaam> wbs: han kanske blev en kvinna i helgen :)
[08:47:16] <kshishkov> spaam: riktig, men engelska("he")==ryska("Ð¾Ð½"("on"))
[08:47:32] <lu_zero> =)
[08:51:03] <lu_zero> wbs: poing
[08:51:14] <wbs> lu_zero: pong
[08:51:40] <lu_zero> do you still have your applehttp-as-protocol patch around?
[08:51:59] <wbs> yes, one sec
[08:52:25] <lu_zero> I'm trying to sort out whose fault of what
[08:52:47] <wbs> what issue are you having? incomplete packets at segment boundaries should at least be fixed by that patch
[08:53:05] <lu_zero> the equal dts seem an artefact of timestamp guessing
[08:53:29] <lu_zero> I have an additional issue with the streaming expiring the buffers in realtime
[08:53:44] <lu_zero> (so stuff like find_info or just slow network cause problems)
[08:53:55] <wbs> hmm, ok, I don't think that should be affected - do you get the same issue if you play the segment files straight without the applehttp playlist inbetween?
[08:54:20] <lu_zero> and then there is the wonderful 5k or problems issue due the mpegts demuxer
[08:54:41] <lu_zero> your patch should fix that one at least
[08:54:58] <wbs> yes
[08:55:26] <lu_zero> using url_read or url_read_complete doesn't seem to change anything btw
[08:56:02] <wbs> then everything's right at that layer at least - changing which one of those is given to AVIOContext shouldn't matter
[08:56:18] <wbs> except that it might give slightly different buffer usage, helping weird seeks and such, but not much else
[09:01:20] <wbs> lu_zero: https://github.com/mstorsjo/ffmpeg/tree/applehttp-urlprotocol
[09:01:29] <wbs> rebased on top of the latest master
[09:01:42] <lu_zero> thank you =)
[09:25:47] <Kovensky> 22:37.34 Dark_Shikari: It's the one thing missing for blu-ray decoding <-- and .ts seeking
[09:27:25] <kshishkov> Kovensky: well, speak to mru about accurate .ts seeking and to me about implementing interlaced VC-1 decoder. You'll get the same answer
[09:28:23] <lu_zero> curious it complains about usleep
[09:28:54] <Kovensky> kshishkov: doesn't have to be *accurate*, being just as inaccurate as the other demuxers would be better already =p
[09:30:03] <Kovensky> without seeking you can't use -ss on ffmpeg nor make playback software using ffmpeg unless they make their own demuxers
[09:30:31] <Kovensky> and having to make your own demuxer kinda defeats the point of libavformat
[09:38:07] <superdump> swedes: i confuse hon/han as well for two reasons
[09:38:31] <superdump> 1) in most other european languages, 'a' is feminine and 'o' is masculine
[09:39:24] <superdump> and 2) honom is him and henne is her
[09:39:39] <superdump> hon, henne; han, honom
[09:39:41] <superdump> eh?
[09:39:42] <superdump> :)
[09:39:59] <wbs> :-)
[09:40:19] <wbs> finnish is great then, too - you don't have any gender-specific personal pronouns at all, only "hÃ¤n" meaning both he and she
[09:40:47] <lu_zero> ^^;
[09:40:50] <superdump> awesome
[09:43:20] <vipw> han solo -- easy to remember
[09:45:23] <superdump> weird - /usr/local/lib is at the top of my /etc/ld.so.conf and libx264.so.114 is in there but when building ffmpeg it gets an undefined reference to x264_encoder_open_114
[09:45:53] <spaam> old header somewhere? :)
[09:46:29] <superdump> shouldn't matter as the build numbers are the same
[09:46:53] <uau> superdump: correct .so symlink?
[09:48:04] <uau> -lx264 won't make the the linker try to access libx264.so.114 directly, but rather libx264.so
[09:48:07] <superdump> some interesting stuff here - /usr/local/lib is a symlink to /usr/local/lib64; in there /usr/local/lib/libx264.so -> libx264.so.114
[09:48:18] <superdump> so it's correct
[09:48:22] <superdump> afaict
[09:49:58] <superdump> how do i make the ffmpeg makefile print commands?
[09:50:14] <andoma> V=1
[09:50:24] <andoma> IIRC
[09:50:28] <spaam> yes
[09:52:31] <superdump> hmmmmm
[09:52:32] <Kovensky> superdump: check if there isn't any -L/usr/lib before the -lx264, or if there is put a -L/usr/local/lib/ right before -lx264
[09:53:04] <Dark_Shikari> superdump: is local lib in your ld.so.conf?
[09:53:06] <Dark_Shikari> I am going to assume no.
[09:53:10] <Dark_Shikari> because distros are fucking retarded.
[09:53:48] <superdump> it is (gentoo)
[09:54:06] <superdump> and i did ldd on the libavcodec.so that was failing with the undefined reference
[09:54:13] <Dark_Shikari> LD_LIBRARY_PATH?
[09:54:27] <superdump> it is looking at a .107 so from /usr/lib
[09:54:37] <superdump> and i don't see any /usr/lib in the command
[09:54:40] <superdump> check env
[09:54:47] <thresh> it's kind of stupid to put /usr/local/lib in ld.so.conf
[09:54:56] <superdump> nope
[09:54:57] <thresh> in distros
[09:55:03] <superdump> no LD_LIBRARY_PATH
[09:55:16] <superdump> very weird indeed
[09:55:25] <Kovensky> better double check then?
[09:55:37] <Kovensky> (the ld.so.conf thing)
[09:55:47] <Kovensky> and add the -L/usr/local/lib anyway for good measure if it still doesn't fix
[09:56:58] <superdump> local is the first non-comment line in ld.so.conf
[09:57:26] <superdump> and local is the first LD_PATH in the first file (alphanumerically) in /etc/env.d (gentoo people might know what i mean there)
[09:57:41] <superdump> /etc/env.d/00basic:LDPATH="/usr/local/lib"
[09:58:48] <superdump> meh
[09:58:54] * superdump unmerges the system x264
[09:59:29] <superdump> there we go
[10:05:23] <lu_zero> superdump: emerge the 9999 one
[10:05:53] <superdump> lu_zero: is that masked?
[10:05:59] <lu_zero> yup
[10:06:28] <lu_zero> for certain packages we keep the live ebuilds in portage and not in overlays...
[10:22:41] <lu_zero> uhm
[10:22:57] <lu_zero> what's including unistd.h w/out defining _BSD_SOURCE now?
[10:23:09] <lu_zero> (in the global headers)
[10:24:54] <superdump> lu_zero: you have a query message :)
[11:46:33] <Dark_Shikari> hahahahhahaha
[11:46:39] <Dark_Shikari> Leonardo Chiariglione is trolling again
[11:47:05] <lu_zero> where?
[11:47:30] <elenril> the "it's not h.264" guy?
[11:47:32] <lu_zero> should I go and deliver a message from you directly?
[11:47:44] * kshishkov looks at http://www.fsf.org/campaigns/priority-projects/index_html and thinks what PowerVR drivers are doing there
[11:47:57] <thresh> omg, my C compiler will expire in 28 days
[11:48:14] <kshishkov> thresh: HP-SUX one?
[11:48:20] <thresh> kshishkov: you knew
[11:48:23] <lu_zero> thresh: put it in the fridge
[11:48:37] <lu_zero> or bake it
[11:48:44] <mru> thresh: there are always ways to extend a licence
[11:49:15] <kshishkov> mru: you tell that a man from a country with software piracy being almost a governmental policy?
[11:51:48] <Dark_Shikari> elenril: yes
[11:51:55] <Dark_Shikari> the its not h264 guy
[11:51:59] <Dark_Shikari> the Stallman of MPEG
[11:52:03] <Dark_Shikari> ITS GNU/LINUX
[11:52:59] <mru> Dark_Shikari: url?
[11:53:33] <kshishkov> Dark_Shikari: http://www.gnu.org/philosophy/open-source-misses-the-point.html
[11:53:48] <Dark_Shikari> mru: this time it's just
[11:53:55] <Dark_Shikari> >I am writing a wrapper to H.264 decoder.
[11:53:55] <Dark_Shikari> In that case this is not the right forum to address the question
[11:53:56] <Dark_Shikari> Leonardo
[11:54:20] <mru> where?
[11:54:20] <Dark_Shikari> because he's talking about "H.264" as opposed to "ISO/IEC alskjdfksjadlfkjsadlkjf MPEG-4 Part 10 AVC"
[11:54:23] <Dark_Shikari> jvt-experts
[11:54:42] <mru> what a troll
[11:54:47] <Dark_Shikari> he's like a head mpeg guy
[11:54:54] <mru> I know
[11:55:00] <lu_zero> still a troll
[11:55:08] <Dark_Shikari> yup
[12:20:14] <Compn> Dark_Shikari : you should photoshop his face onto stallmans
[12:20:35] <Compn> Its called AVC herpppp
[12:20:58] * Compn actually thinks stallman is a cool dude
[12:25:46] <lu_zero> stallman is fun in small doses
[12:26:07] <mru> his rambling gets old quickly
[12:26:23] <kshishkov> mru: isn't he political activist stuck in 60s?
[12:50:49] <DonDiego> if we didn't have rms we would have to invent him :)
[12:51:18] <DonDiego> plus, he gave the world a very lasting contribution: copyleft
[12:51:46] <BBB> kurosu: docs don't say, they just say 10-bit block post-idct, which means 17-bit inside the end of idct
[12:52:30] <BBB> lu_zero: ping
[12:52:35] <BBB> lu_zero: ppc ops in patch please?
[12:54:56] <BBB> everyone: naming of get_strz -> avio_get_str, is get_str() really what we want?
[12:55:07] <BBB> should it be avio_read_str()? or rstr()?
[12:59:52] <Zor> the former makes much more sense without looking at what the function does
[13:00:53] <lu_zero> BBB: which ops?
[13:01:04] <BBB> vc1 idct dude
[13:01:06] <lu_zero> drop me an email and I'll write them =)
[13:01:09] <lu_zero> uhm?
[13:01:29] <lu_zero> I wrote you already the missing bit or I misunderstood the function?
[13:02:41] <BBB> I didn't see that
[13:05:43] <lu_zero> last night ^^;
[13:05:48] <lu_zero> I nopasted it
[13:06:10] <lu_zero> basically I made the idct have 2 more parameters
[13:06:13] <lu_zero> and then
[13:06:34] <BBB> I do that for C also
[13:06:50] <BBB> can you send me the patch?
[13:06:54] <BBB> I didn't see the nopaste
[13:06:57] <BBB> nopasta?
[13:06:58] <BBB> antipasta
[13:07:09] <lu_zero> if (rangered ) { if (!sign) {vec_sub() ...} vec_sl()... }
[13:07:18] <lu_zero> let me pick the one
[13:09:28] <lu_zero> http://ffmpeg.pastebin.com/VMSP4Zzh
[13:09:41] <lu_zero> that should do what you want
[13:10:14] <BBB> where does this thing do the >>= 7 that the C code does?
[13:10:17] <BBB> (the original)
[13:10:23] <BBB> I couldn't understand a bit of the original code
[13:10:51] <lu_zero> there are some macros
[13:12:12] <lu_zero> SHIFT_VERT8
[13:12:15] <lu_zero> and SHIFT_VERT4
[13:12:33] <lu_zero> btw I guess might be useful implementing the 8x4 as well, am I wrong?
[13:12:49] <Dark_Shikari> BBB: did you go back and look at my old overlap filter asm code?
[13:12:51] <Dark_Shikari> while you're at it?
[13:13:43] <BBB> Dark_Shikari: no
[13:13:46] <BBB> Dark_Shikari: where is it?
[13:13:50] <Dark_Shikari> ml
[13:14:30] <BBB> later
[13:14:33] <BBB> I'm not doing overlap right now
[13:14:35] <Dark_Shikari> put it on your list
[13:14:37] <Dark_Shikari> don't forget about it
[13:14:40] <BBB> one thing at a time
[13:14:44] <BBB> right now idct8x8
[13:14:48] <Dark_Shikari> I was never able to test it because vc-1 decoding on my only overlap filter sample was nondeterministic on my computer
[13:14:51] <BBB> I'll do other idcts after, they are much cimpler
[13:15:03] <BBB> then I'll look at overlap etc.
[13:15:22] <BBB> I think we can easily speed this up to be twice as fast
[13:15:28] <BBB> but need to stay organized :)
[13:15:40] <BBB> so sure will look but haven't yet so far
[13:15:51] <BBB> kshishkov: go review my patch!
[13:15:56] * BBB goes shower
[13:15:57] <kshishkov> ok
[13:16:35] <BBB> after this the C code is done and I can re-do the asm to be faster and better and nicer and 17-bit-capable
[13:17:19] <kshishkov> BBB: you forgot a line
[13:17:26] <kshishkov> <<=1 after each coeff
[13:17:54] <Dark_Shikari> do you have rangered samples for testing?
[13:17:56] <kshishkov> err, "<<= 1 for each coeff"
[13:18:18] <kshishkov> there were some in test bitstreams
[13:18:33] <Dark_Shikari> also wtf is rangered for?
[13:18:42] <Dark_Shikari> shifting up every coeff just sounds like a higher quant t ome
[13:19:19] <kshishkov> it's centered around 128
[13:20:16] <Dark_Shikari> it still doesn't make sense
[13:20:44] <BBB> kshishkov: which line where?
[13:20:57] <kshishkov> BBB: see in review in a minute
[13:21:07] <BBB> kshishkov: I moved the <<= 1 inside the idct
[13:21:18] <BBB> I want to merge the idct and the putpixels(), so <<= is now inside the idct
[13:22:33] <kshishkov> sent
[13:23:25] <BBB> oh
[13:23:35] <BBB> lu_zero: you didn't send me that as part of your patch
[13:23:36] <BBB> darnit
[13:23:37] <BBB> :-p
[13:23:52] <BBB> kshishkov: I'll fix that, the idct does that in altivec also but I didn't update the function calls
[13:25:04] <BBB> I guess I have to test it now
[13:25:14] * BBB goes figure out if ppc crosscompile works on his mac
[13:27:58] <BBB> hm, seems to work
[13:28:00] <BBB> not bad
[13:33:45] <lu_zero> BBB: which?
[13:36:42] <BBB>  /Users/ronaldbultje/Projects/ffmpeg-git/libavcodec/ppc/vc1dsp_altivec.c:222: error: invalid parameter combination for AltiVec intrinsic
[13:36:58] <BBB> that's             vec_sub(src0, unsigned_bias);
[13:37:12] <kshishkov> signedness mismatch I think
[13:37:33] <lu_zero> strange
[13:37:43] <kshishkov> maybe bias should be signed?
[13:37:53] <lu_zero> they should be the same...
[13:37:55] <lu_zero> let me look
[13:39:16] <lu_zero> right
[13:39:22] <lu_zero> unsigned_bias should be signed =P
[13:47:49] <BBB> kshishkov: new msg sent
[13:48:07] <kshishkov> let's see...
[13:48:21] <BBB> michaelni: yeah I'm a terrible coder, you should just never accept any of my code in ffmpeg at videolan, I'm useless and my code is slow and cranky
[13:48:38] <BBB> michaelni: also, make sure to never look at my code, it might be infectious
[13:49:02] <lu_zero> what's going on?
[13:49:22] <kshishkov> BBB: does that no spew a warning/error on signed_bias init?
[13:49:36] <BBB> kshishkov: not for me
[13:49:37] <BBB> should it?
[13:49:52] <BBB> because of the u16 init?
[13:49:56] <BBB> seems to work here
[13:49:58] <BBB> should it be s16?
[13:50:17] <BBB> both fit
[13:50:19] <BBB> so it's fine
[13:51:14] <BBB> the second one has to be u16
[13:51:18] <BBB> the first one can be either s16 or u16
[13:51:22] <BBB> maybe s16 is more correct
[13:51:30] <BBB> I'm not an altivec expert, just trying to not break existing ops
[13:51:44] <lu_zero> ^^;
[13:51:53] <lu_zero> and I should be out in -15min...
[13:51:54] <lu_zero> =|
[13:53:03] <Kovensky> hm, I wonder how to "cyrillize" a syllable that sounds like "ã‚ã‚“ãŠ", but there's no pause between "ã‚ã‚“" and "ãŠ", so it isn't Ð°Ð½ÑŠÐ¾ or Ð°Ð½Ð¾
[13:54:13] <kshishkov> Kovensky: Ð°Ð½'Ð°
[13:54:53] <Kovensky> Ð°Ð½'Ð¾ you mean, or Ð°Ð½'Ð° indeed?
[13:55:23] <kshishkov> Ð°Ð½ÑŠÐ¾ it should be officially - see http://en.wikipedia.org/wiki/Polivanov_System
[13:55:53] <kshishkov> not that anyboady cares about that
[13:56:00] <Kovensky> except I'm not trying to transliterate japanese, it's a portuguese phoneme, it's just that it's the closest one I could think of to explain ._.
[13:56:34] <kshishkov> what's original?
[13:56:36] * Kovensky is having a try at memorizing cyrillic by using it as a substitution cypher for portuguese / english
[13:56:44] <kshishkov> (in Portuguese)
[13:56:46] <Kovensky> "Ã£o"
[13:56:58] <kshishkov> Ð°Ð½ÑŒÐ¾
[13:57:13] <Kovensky> so my blind guess was correct? :D
[13:57:25] <kshishkov> not exactly
[13:57:49] <kshishkov> it's Ð½ÑŒ for Ã±
[13:57:57] <Kovensky> well, that's what I used to write "sÃ£o", ÑÐ°Ð½ÑŒÐ¾
[13:58:14] <kshishkov> we write simply "ÑÐ°Ð½"
[13:59:21] <Kovensky> well, I want the ÑÐ°Ð½ sound but with a vowel following it
[14:00:02] <kshishkov> it's Russian, nobody cares much since it often sounds differently from written form
[14:07:37] <BBB> kshishkov: thanks, will get back to simd now
[14:07:45] <BBB> time to make this codec faster
[14:07:55] <kshishkov> :)
[14:08:08] <kshishkov> I'd like it to have more supported features instead
[14:08:16] <BBB> the two are orthogonal
[14:08:19] <kshishkov> i.e. WVP2
[14:08:26] <BBB> why don't you make it have more features, and I'll work on more speed
[14:08:29] <BBB> wvp2 would be nice
[14:08:40] <BBB> I looked at it and I have to admit, the dll was cryptic to me
[14:09:00] <kshishkov> I'm maintaining it (newspeak for not doing anything if you forgot)
[14:09:11] <BBB> I notice :-p
[14:09:20] <BBB> why don't you give up maintainership and go do cool stuff with it
[14:09:23] <BBB> say, interlaced
[14:09:34] * kshishkov is working on SMUSH instead
[14:09:35] <kierank> interlaced is not cool
[14:09:43] <kshishkov> by definition
[14:10:00] <kshishkov> BBB: http://codecs.multimedia.cx/?p=295 to refresh your memory
[14:12:28] <BBB> "include me out" ? :-p
[14:12:31] <BBB> =exclude me
[14:13:32] <BBB> kshishkov: I'll buy you beer if you finish vc1-interlaced
[14:13:47] <BBB> brb
[14:14:22] <kshishkov> BBB: 1) those were famous words of Samuel Goldwyn 2) I don't drink beer, so include me out there as well
[14:14:24] <kierank> that's going to do a lot of good...
[14:14:52] <Kovensky> BBB: buy kshishkov trocadero instead
[14:15:12] <kshishkov> Kovensky: exactly!
[14:15:24] <kshishkov> Kovensky: though good luck finding it outside Sweden
[14:15:36] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * rc8c0189d62 ffmpeg/libavfilter/ (Makefile vf_pad.c vsrc_color.c):
[14:15:36] <CIA-15> ffmpeg: lavfi: put color source in a dedicated file
[14:15:36] <CIA-15> ffmpeg: Move the color source code from vf_pad.c to vsrc_color.c.
[14:15:36] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:15:40] <CIA-15> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * r5ad06110e0 ffmpeg/libavfilter/ (Makefile drawutils.c drawutils.h vf_pad.c):
[14:15:40] <CIA-15> ffmpeg: lavfi: add drawutils
[14:15:40] <CIA-15> ffmpeg: Add drawutils.h and drawutils.c, and use them in the pad filter.
[14:15:40] <CIA-15> ffmpeg: The new functions are going to be shared by other filters.
[14:15:41] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[14:15:53] <kierank> probably some trocadero in london
[14:16:21] <lu_zero> 15:15 <@kshishkov> Kovensky: though good luck finding it outside Sweden
[14:16:45] <lu_zero> if it is a apple+lemon juice diluited in water
[14:16:47] <lu_zero> I found it
[14:16:56] <kshishkov> apple+orange+cola
[14:17:09] <lu_zero> cola or soda?
[14:17:35] <kshishkov> http://en.wikipedia.org/wiki/Trocadero_%28drink%29 <- look for word Caffeine
[14:17:42] * lu_zero grew fond of apple+lemon+still water
[14:18:19] <kshishkov> some Germans love cola+orange juice but they still haven't reinvented Trocadero
[14:19:10] <mru> germans are crazy
[14:19:15] <mru> they mix beer with other things
[14:19:34] <kshishkov> because they're not allowed to premix them
[14:19:45] <kshishkov> (and still call it beer)
[14:20:10] <twnqx> you can buy Diesel or Radler just fine (beer+cola, beer+applejuice+soda)
[14:20:36] <mru> kshishkov: proper english bitter ain't mixed with anything
[14:20:52] <mru> it's brewed from the purest barley, hops, yeast, and pond water
[14:21:53] <Kovensky> reminds me to go play Pharaoh
[14:21:59] <Kovensky> beer was srsbsnss in ancient egypt
[14:23:34] <kshishkov> so?
[14:23:49] <thresh> mmmm, beer
[14:24:05] <kshishkov> hmm, Homer Simpson
[14:24:06] <lu_zero> pond water?
[14:24:20] <lu_zero> as in murky water?
[14:24:34] <kshishkov> lu_zero: yep, if nobody lives in that water it's not suitable for drinking
[14:24:36] <mru> lu_zero: ale can be similar in appearance to pond water
[14:25:01] <lu_zero> ^^'
[14:25:37] <mru> kshishkov: you should go to new york then, they have little critters living in the tap water
[14:25:48] <lu_zero> o_O
[14:25:51] <mru> much to the annoyance of the local jews
[14:25:59] <lu_zero> why?
[14:26:06] <mru> not kosher
[14:26:12] <lu_zero> ...
[14:26:47] <kshishkov> mru: well, I liked water from lake MÃ¤laren
[14:28:14] <kierank> I drank a bottle of holy water once
[14:28:25] <mru> lu_zero: http://www.wwdmag.com/wwd/index.cfm/fuseaction/shownewsitem/newsitemid/7199
[14:31:24] <kshishkov> kierank: well, for you it's not as bad as eating holy beef
[14:31:44] <kierank> for me?
[14:31:48] <kshishkov> yep
[14:32:16] <mru> and unholy beef?
[14:32:28] * kierank wasn't aware beef was holy
[14:32:53] <mru> a well-prepared steak sure tastes divine...
[14:33:00] <kshishkov> kierank: come to British outsourced ex-colony and ask
[14:33:24] * kshishkov prefers holy and kosher prok instead
[14:33:36] <kierank> kshishkov: I don't plan to go there
[14:33:51] <mru> remember the time ods15 ate pork?
[14:34:00] <cartman> kierank: fear of cavity search?
[14:34:20] <kshishkov> mru: I fear not many people here remember Oded at all
[14:34:34] <mru> wiesbaden '06
[14:34:45] * cartman remebers Oded
[14:34:52] <cartman> and his damn broken vorbis encoder
[14:35:03] <cartman> so does some people over at youtube I think :P
[14:35:07] <mru> he and kshishkov are running a competition
[14:35:18] * kshishkov is still in winning position
[14:35:33] <lu_zero> ods15: still alive?
[14:36:52] <cartman> wbs: they finally fixed my crasher bug \Ã¶/ (NDK)
[14:36:58] <mru> "Moore's Law of Mad Science: Every 18 months, the minimum IQ necessary to destroy the world drops by one point." - Eliezer Yudkowsky
[14:37:46] <lu_zero> "press button to end"
[14:38:14] <lu_zero> cartman: \o/
[14:38:28] <kshishkov> lu_zero: when it will be that easy people would be complete morong not able to do it anyway
[14:38:32] <wbs> cartman: wooh, congrats
[14:38:42] <wbs> cartman: any link to info about it?
[14:38:46] <mru> cartman: which bug?
[14:39:04] <cartman> wbs, mru https://review.source.android.com//#change,21309
[14:40:16] <lu_zero> eh eh
[14:40:38] <kshishkov> lu_zero: see, it's good to be an optimist
[14:41:07] <mru> well, pessimism isn't likely to work
[14:41:19] <kierank> cartman: gerrit code review is horrible
[14:41:31] <cartman> kierank: agreed
[14:41:39] <mru> kierank: yes, we know
[14:41:52] <kierank> though not as bad as melange
[14:41:57] <cartman> in other news my boss claims to find an Android tablet with Android *2.5*
[14:42:06] <kierank> cartman: fake chinese one?
[14:42:16] <kshishkov> cartman: you can hack it to report any version you like
[14:42:17] <cartman> kierank: at least I warned him :D
[14:42:23] <cartman> kshishkov: I know
[14:42:30] <kshishkov> cartman: I owned RAR version 5.0
[14:42:34] <lu_zero> kierank: why horrible?
[14:42:44] <cartman> kshishkov: nice patching skillz
[14:42:46] <kshishkov> cartman: in the time when only v2.0 was available
[14:42:52] <mru> lu_zero: try using it
[14:43:01] <lu_zero> did
[14:43:11] <cartman> Gerrit works fine with read only mode
[14:43:12] <mru> did you succeed?
[14:43:15] <lu_zero> at least in the vpx incarnation
[14:43:17] <lu_zero> sure
[14:43:24] <lu_zero> was quite easy...
[14:44:32] <kierank> lu_zero: gerrit looks awful. totall unreadable
[14:44:39] <kierank> needs a ux consultant stat
[14:48:12] <mru> why are _all_ the search bots crawling my server at the same time?
[14:48:21] <mru> google, yandex, and bing
[14:48:31] <mru> and yahoo
[14:49:01] <thresh> well, I can surely say for yandex one
[14:49:10] <thresh> it tries to be as good as goog one
[14:49:30] <mru> bing is evil
[14:49:30] <thresh> and why does bing try to crawl your server is unknown...
[14:49:44] <mru> well, try it might... I blocked it
[14:49:53] <lu_zero> ^^;
[14:49:56] <mru> it was way too aggressive
[14:50:08] <mru> google is much nicer
[14:50:18] <mru> doesn't pull everything as fast as possible
[14:50:39] <mru> and I don't care about bing
[15:04:48] <elenril> BBB: ping
[15:05:58] <mru> who the hell wrote this?  while (h --> 0)
[15:06:06] <elenril> lol
[15:06:23] <kshishkov> mru: it's self-explanatory
[15:06:30] <kierank> as h tends to zero
[15:06:31] <elenril> a mathematician
[15:06:31] <mru> git says it was Yuvi
[15:06:50] <kierank> FruitCode (tm)
[15:06:51] <mru> points for creative use of C operators
[15:07:05] <Tjoppen> hah, awesome
[15:09:17] * elenril wonders what happened to mergig -mt
[15:09:28] <kshishkov> BBB happened
[15:09:44] <elenril> he said it's working and ready
[15:13:08] <BBB> mru: I saw that somewhere also
[15:13:12] <BBB> mru: I thought it looked funny
[15:13:19] <BBB> kshishkov: ?
[15:13:27] <mru> BBB: vp8 altivec code
[15:13:32] <BBB> elenril: pong, patch is queued, was waiting for kostya to review my vc1 patch so I can commit together
[15:13:41] <BBB> mru: aha... the one that's still broken
[15:13:49] <mru> should be easy to fix
[15:14:01] <BBB> kshishkov: so ok to commit all my stuff?
[15:15:20] <BBB> elenril: unless the ping was for something else
[15:15:53] <BBB> elenril: oh and for -mt, atrange had a patch but told me to not commit it yet (huffyuv)
[15:16:03] <BBB> elenril: so I'm waiting for astrange to respond to that
[15:22:05] <kshishkov> BBB: not all, only the one I sayed okay to commit
[15:22:22] <BBB> right :)
[15:22:36] <BBB> did someone ok the non-static'ing of ff_put/add/put_signed_pixels?
[15:22:47] <BBB> *_clamped_c()
[15:23:10] <ruggles> if i get "(standard_in) 1: syntax error" when running a fate test, where should i start looking for the problem?
[15:23:13] <BBB> I think mru and alex did
[15:23:26] <BBB> ruggles: make V=1
[15:23:57] <elenril> BBB: what about get_*
[15:24:07] <BBB> elenril: will review after that
[15:24:18] <elenril> ok
[15:24:20] <mru> ruggles: that usually means the decoder died without producing any output
[15:24:20] <BBB> elenril: sorry, I do think full review of these patches is good, even if the conceptually look good
[15:24:25] <BBB> and you have to admit, they are massive :)
[15:24:28] <elenril> "full"
[15:24:34] <ruggles> mru: thanks
[15:24:35] <BBB> so I like your "small" patches, I can at least read them
[15:24:38] <elenril> you're going to read through 3k lines?
[15:24:42] <BBB> sorta
[15:24:47] <elenril> good luck with that :)
[15:24:48] <BBB> someone has to do it
[15:25:00] <BBB> did you fix the rbe32 -> rb32?
[15:25:04] <mru> ruggles: I suppose the error message could be improved
[15:25:13] <elenril> you said you'd fix it yourself
[15:25:23] <elenril> but i think i fixed that locally too
[15:25:27] <BBB> oh right I did
[15:25:28] <elenril> should i send it?
[15:25:29] <BBB> no
[15:25:31] <BBB> I'll do it
[15:25:43] <BBB> I'm just getting in office, so I'm a little sleepy
[15:25:45] <BBB> need coffee
[15:25:50] <BBB> please excuse my nonsense
[15:26:09] * elenril mumbles something about people in weird timezones ;)
[15:26:27] <BBB> make -j8 fate is awesome indeed
[15:26:29] * BBB pets mru
[15:26:33] <BBB> good boy
[15:26:42] <BBB> now can we make fate use threads by default if the codec supports it?
[15:26:45] * elenril wishes he had a cpu for that
[15:27:21] <elenril> also anybody with knowledge of mpegaudio here?
[15:27:39] * mru knows it's obsolete
[15:27:55] * elenril deprecates mru 
[15:27:57] <kshishkov> elenril: probably me
[15:28:20] <BBB> committed
[15:28:24] <BBB> elenril: on the get_ patch now
[15:28:27] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rbbfd2e7ab4 ffmpeg/libavcodec/vc1dec.c:
[15:28:27] <CIA-15> ffmpeg: VC1: inline vc1_put_block() in vc1_decode_i_blocks().
[15:28:27] <CIA-15> ffmpeg: Advantage is that it allows us to combine several loops into a single
[15:28:27] <CIA-15> ffmpeg: one, and these can eventually be merged into the IDCT itself. Also, it
[15:28:27] <CIA-15> ffmpeg: allows us to remove vc1_put_block(), and makes CODEC_FLAG_GRAY faster.
[15:28:29] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r8d9ac969cb ffmpeg/libavformat/ (avidec.c avio.h aviobuf.c rdt.c wtv.c):
[15:28:29] <CIA-15> ffmpeg: avio: rename av_alloc_put_byte -> avio_alloc_context for consistency
[15:28:29] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[15:28:33] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * rf8bed30d8b ffmpeg/libavcodec/ (ppc/vc1dsp_altivec.c vc1.c vc1dec.c vc1dsp.c vc1dsp.h):
[15:28:33] <CIA-15> ffmpeg: VC1: merge idct8x8, coeff adjustments and put_pixels.
[15:28:33] <CIA-15> ffmpeg: Merging these functions allows merging some loops, which makes the
[15:28:33] <CIA-15> ffmpeg: results (particularly after SIMD optimizations) much faster.
[15:28:34] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r484a337cd7 ffmpeg/libavcodec/ (dsputil.c dsputil.h): dsputil: make {add/put/put_signed}_pixels_clamped() non-static.
[15:29:01] <elenril> kshishkov: does http://pastebin.com/h9wNxjtV look remotely sane as a solution to https://roundup.ffmpeg.org/issue2598
[15:29:57] <BBB> oh yeah
[15:29:58] <kshishkov> elenril: yes and no
[15:30:03] <BBB> elenril: ping, what about read_partial
[15:30:04] <BBB> ?
[15:30:19] <BBB> elenril: I'd prefer it private if we can't figure out why specifically it would have to be exposed
[15:30:24] <kshishkov> elenril: it will make results the same but I don't know if that's wanted behaviour
[15:30:26] <elenril> dunno, looks potentially useful
[15:31:04] <elenril> kshishkov: why not?
[15:31:14] <mru> elenril: I think it makes sense
[15:31:36] <mru> flush() should reset all state
[15:32:48] <elenril> BBB: ok, i'll make it private for now and wait for people to complain
[15:34:30] <elenril> fortunately it's only used in one place so splitting it out is easy
[15:35:04] * elenril <3 git checkout -p
[15:38:32] <Kovensky> 12:37.16 marcan: last time I tried comparing MSVC vs. gcc, gcc produced 30% faster code, but only if you optimize for i386 instead of core2 :P
[15:38:35] <Kovensky> 12:37.36 marcan: (i.e. i386 gcc was 30% faster than core2 msvc, core2 gcc was roughly the same)
[15:38:39] <Kovensky> 12:37.40 marcan: (beats me)
[15:38:43] <BBB> elenril: simply ignore read_partial for now
[15:38:53] <BBB> elenril: so leave it as get_buffer_partial
[15:38:58] <BBB> we'll rename it with the other private symbols later
[15:39:03] <BBB> smaller patch = awesome
[15:39:16] <elenril> i'll split it in a separate patch
[15:39:22] <BBB> elenril: if you can send a new patch I'll review it right away
[15:39:49] <Kovensky> 12:39.03 BBB: smaller patch = awesome <-- no, no, you're doing it wrong, it's "smaller = awesomer"
[15:40:50] * elenril make -j4
[15:41:20] <elenril> arrrgh, it's rebuilding lavc for whatever reason again
[15:41:41] <mru> get a real computer
[15:41:44] <mru> then you won't care
[15:41:58] <elenril> ENOMONIES
[15:42:22] <mru> get a job
[15:42:23] <spaam> elenril: use ccache!
[15:42:32] <mru> or use cash
[15:42:43] <elenril> physics > job
[15:42:47] <spaam> "get a job"++
[15:42:57] <spaam> even i got a job ;)
[15:43:07] <elenril> anyway, patch sent
[15:44:18] <mru> there, valgrind is happy again
[15:50:06] <BBB> mru: \o/
[15:50:19] <spaam> mru: good boy
[15:51:08] <mru> why do people write such sloppy code
[15:51:20] <mru> the proper one is faster too
[15:51:29] <BBB> because we're lazy
[15:53:07] <spaam> mru: time to get better to review code ;)
[15:56:23] <BBB> -        if ((ret = get_buffer(s->pb, header, 8)) < 0)
[15:56:24] <BBB> +        if ((ret = avio_read(s->pb, header, 8)) < 0)
[15:56:24] <BBB>              return ret;
[15:56:24] <BBB>          fourcc_tag = AV_RL32(&header[0]);
[15:56:24] <BBB>          size = AV_RL32(&header[4]);
[15:56:27] * BBB wonders ...
[15:56:37] <elenril> i was just wondering if you fell asleep yet
[15:57:04] <BBB> I guess I was about to
[15:58:26] <elenril> what's so interesting in the abov code?
[15:59:26] <elenril> and what do you hope to prove by reading through it? bugs in sed?
[16:01:12] <BBB> fourcc_tag = avio_rl32(s->pv); etc.
[16:01:30] <BBB> it's not a bug in your patch
[16:01:36] <BBB> it's an inconsistency in the original code
[16:01:44] <BBB> -    get_le32(pb); /* CRYO */
[16:01:44] <BBB> -    get_le32(pb); /* _APC */
[16:01:44] <BBB> -    get_le32(pb); /* 1.20 */
[16:01:44] <BBB> +    avio_rl32(pb); /* CRYO */
[16:01:45] <BBB> +    avio_rl32(pb); /* _APC */
[16:01:45] <BBB> +    avio_rl32(pb); /* 1.20 */
[16:01:50] <elenril> yeah i guess
[16:01:50] <mru> elenril: ffmpeg is known to expose bugs in almost anything
[16:01:52] <BBB> another one, this should be url_fskip()
[16:02:20] <BBB> elenril: don't change your patch, I'm just rambling about stuff as coffee takes effect
[16:02:22] <BBB> your patch is fine so far
[16:02:25] <mru> BBB: sure, but that's orthogonal to this patch
[16:02:30] <elenril> i think you're wasting time on this
[16:02:38] <BBB> ok I'll go quicker
[16:03:10] <elenril> obviously you'll find tons of broken/suboptimal code
[16:03:17] <elenril> we can't fix all of it at once
[16:03:43] <BBB> ff_ape_parse_tag(), your patch misaligns comments
[16:04:14] * BBB fixes locally
[16:04:15] <elenril> and in a zillion other places i guess
[16:04:25] <elenril> there should be a tool for aligning comments
[16:04:50] <elenril> more importantly though -- what should we do about put_nbyte/put_tag?
[16:05:02] <elenril> make them private perhaps?
[16:05:13] <elenril> and wait if anyone complains
[16:06:11] <merbzt> put_nbyte is new
[16:07:27] <elenril> i see it's only used in the spdif muxer
[16:07:30] <BBB> what is put_nbyte()?
[16:07:57] <elenril> memset
[16:08:01] <elenril> basically
[16:21:08] <BBB> elenril: sounds like it can be internal for now, I don't see a need for that to be exposed
[16:23:28] <elenril> put_tag looks much more useful OTOH
[16:23:47] <elenril> git grep returns 170 lines
[16:24:37] <BBB> so that's basically put_str() except you don't need to tell it the length of the string?
[16:24:44] <BBB> it sounds like the equivalent of get_strz()
[16:25:10] <BBB> patch looks good, I did some formatting things but nothing major
[16:25:23] <BBB> let's run make fate
[16:25:26] <elenril> not it's exactly the same as put_str, but it doesn't terminate the string
[16:27:14] <BBB> sounds like put_str() doesn't need to always write the null anyway
[16:27:39] <BBB> it doesn't use put_buffer, so it wouldn't be as fast
[16:30:06] <BBB> it makes me wonder whether we shouldn't just merge the two, have an extra argument "int needs_zero" or so
[16:30:43] <mru> BBB: was that you who broke the ppc build?
[16:30:49] <BBB> mru: no! I tested it!
[16:30:59] <mru> fate disagrees
[16:31:13] <BBB> :'(
[16:31:16] <BBB> I really tested it
[16:31:18] <BBB> I promise
[16:31:24] <mru> tell that to fate
[16:31:40] <elenril> yeah, that might be better
[16:31:55] <mru> it's fussing about signed/unsigned mismatch
[16:32:04] <elenril> but adding a new argument to all those put_tag() will be fun
[16:32:06] <mru> iirc lu_zero was saying something to the same effect a while ago
[16:32:15] <BBB> mru:     const vector   signed short signed_bias = vec_sl(vec_splat_u16(4),
[16:32:15] <BBB>                                                      vec_splat_u16(4));
[16:32:19] <BBB> mru: change the first u16 into s16
[16:32:23] <BBB> mru: that would fix it
[16:32:38] <BBB> my compiler didn't care
[16:33:35] <BBB> as for the "statement with no effect", I don't know, lu_zero wrote it
[16:33:48] <BBB> maybe you need to store the result, as in src0 = vec_sl(src0, ..);?
[16:33:58] <mru> blaming the italians, are we?
[16:34:05] <BBB> he should know altivec better than me
[16:34:19] <mru> better than me as well
[16:34:26] <BBB> not good enough apparently
[16:34:57] <mru> how did you test it?
[16:34:59] <BBB> can you fix or should I fix?
[16:35:05] <BBB> I tested that it compiled
[16:35:16] <mru> on what system?
[16:35:27] <BBB> cross-compile using powerpc-gcc on x86
[16:35:35] <BBB> I have a cross-compile toolchain from apple for ppc
[16:35:42] <BBB> altivec and so on was enabled
[16:36:10] <mru> you're using apple stuff to test things!???!!!
[16:36:23] * BBB associates ppc with apple
[16:36:33] * mru associates apple with rotten
[16:36:47] * BBB learns that ppc associates with rotten
[16:37:07] * divVerent associates Amiga with 68k
[16:37:16] * elenril learns that rottenness is transitive
[16:37:17] * divVerent associated 68k with Apple
[16:38:09] <BBB> mru: you or me?
[16:38:17] <BBB> mru: I can re-test it on your ppc and fix it properly
[16:38:24] <BBB> it just takes forever
[16:38:31] <mru> do you have a file that uses that code?
[16:38:58] <BBB> not in fate
[16:39:03] <mru> anywhere?
[16:39:16] <BBB> probably in my collection, I have to scan it
[16:40:19] <BBB> for now, use src0 = vec_sub/sl(src0, ...) instead of vec_sub/sl(src0, ...)
[16:40:25] <BBB> and change u16 -> s16
[16:40:27] <BBB> should work
[16:40:35] <mru> that builds
[16:40:35] <BBB> I'll figure out a test that we can add to fate
[16:40:44] <mru> but I'd prefer to test it too
[16:40:52] <BBB> I don't have a sample right now
[16:45:55] <BBB> mru: elenril's last patch ok?
[16:50:43] <mru> hmm, seems like old gcc is less picky about that code
[16:50:52] <mru> and apple is old
[16:50:57] <mru> old apples are rotten
[16:51:48] <BBB> apple <3
[17:02:51] <_av500_> gm
[17:04:22] <elenril> libavformat/movenc.c         |  880 +++++++++++++++++++++--------------------- << wow
[17:08:44] <BBB> elenril: ?
[17:09:36] * _av500_ guesses somwe av prefixing work
[17:09:41] <_av500_> -w
[17:10:14] <mru> _av500_: I see you already got yours
[17:10:31] <_av500_> yeah
[17:10:41] <_av500_> i was but number
[17:10:44] <_av500_> +a
[17:10:56] <_av500_> damn tiny kbd
[17:28:12] <elenril> BBB: that's prefixes for put_
[17:29:02] <elenril> so are we waiting for something?
[17:29:13] <BBB> nobody else wants to review?
[17:29:17] <BBB> last one looked ok to me
[17:29:18] <BBB> let me apply
[17:29:56] * elenril creates a mailbox for death threats
[17:30:14] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rb7effd4e83 ffmpeg/libavformat/ (107 files): (log message trimmed)
[17:30:14] <CIA-15> ffmpeg: avio: avio_ prefixes for get_* functions
[17:30:14] <CIA-15> ffmpeg: In the name of consistency:
[17:30:14] <CIA-15> ffmpeg: get_byte -> avio_r8
[17:30:14] <CIA-15> ffmpeg: get_<type> -> avio_r<type>
[17:30:15] <CIA-15> ffmpeg: get_buffer -> avio_read
[17:30:15] <CIA-15> ffmpeg: get_partial_buffer will be made private later
[17:33:00] <Tjoppen> damnit, psu fan is starting to give up
[17:34:57] * elenril kicks clang
[17:35:13] <elenril> why doesn't it warn about return foo; in a void function
[17:40:52] <Tjoppen> does it warn about non-void not returning anything?
[18:25:16] <BBB> elenril: read_partial doesn't apply
[18:25:24] <BBB> elenril: it looks good, can you rebase and such?
[18:26:11] <elenril> rebases fine for me
[18:28:39] <BBB> odd
[18:28:44] <BBB> let me look at it again after lunch
[18:29:15] <elenril> sent rebased version
[18:29:22] <elenril> and a little bonus
[18:29:34] <DevilCode2> hey all
[18:30:40] <DevilCode2> Can anyone tell me why when i try to make a   .mpeg   from a folder of jpg's i get just a black video
[18:32:06] <elenril> DevilCode2: user questions belong in #ffmpeg
[18:32:16] <DevilCode2> i know but there is no one there
[18:33:13] * elenril sees 176 people there
[18:33:15] <DevilCode2> oh i mistyped
[18:33:18] <DevilCode2> dam ././
[18:33:20] <DevilCode2> sry
[18:34:47] <elenril> BBB: any ideas for a new name for put_nbyte
[18:34:57] <elenril> ffio_wn8 sounds obfuscated
[18:35:13] <mru> ffio_fill?
[18:37:40] <BBB> ffio_memset, ffio_fill, ffio_splat
[18:37:45] <BBB> whichever you want
[18:37:58] <mru> mem?
[18:38:06] <BBB> good point
[18:38:10] <BBB> ffio_set sounds stupid
[18:38:15] <BBB> so let's forget about that one
[18:38:19] <BBB> ffio_fill/splat is ok with me
[18:39:02] <mru> elenril: take your pick
[18:41:09] <BBB> and get_partial applied
[18:41:49] <BBB> (locally)
[18:41:54] <BBB> now on to the put one
[18:42:01] <BBB> elenril: the put one is the last massive one right?
[18:50:07] <elenril> BBB: i hope so
[18:50:13] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rb3db9ceef1 ffmpeg/libavformat/ (avio.h avio_internal.h aviobuf.c rawdec.c):
[18:50:13] <CIA-15> ffmpeg: avio: make get_partial_buffer internal.
[18:50:13] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[18:50:17] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r78e2380a6d ffmpeg/libavcodec/targa.c: targa: prevent integer overflow in bufsize check.
[18:50:28] <elenril> BBB: what's up with CCs
[18:50:45] <mru> git-send-email config thing
[18:51:20] <elenril> no, those aren't git-send-emailed
[18:51:30] <mru> git send-email sets a cc by default
[18:51:37] <mru> and that's picked up various mailers when you reply
[19:05:49] <BBB> ah damnit, I lost
[19:06:37] * elenril devises a regexp to add an argument to all instances of put_tag
[19:09:30] <BBB> elenril: don't, yet
[19:09:31] <Kovensky> /elenril/d
[19:09:39] <BBB> elenril: that was just my personal opinion, make sure others agree
[19:09:46] <BBB> otherwise you waste your time
[19:09:48] <BBB> which would suck
[19:10:03] <BBB> so ffio_splat() is not fashionable?
[19:10:20] * elenril is iowaiting anyway
[19:10:23] <mru> I would choose fill personally
[19:10:35] <BBB> he did too
[19:10:37] <mru> but I'm not going to fuss over the name
[19:10:37] <BBB> ok, will apply
[19:10:42] <BBB> no, fill is fine
[19:10:48] <BBB> just spat sounds fancy
[19:11:11] <elenril> obscure to non-native speakers
[19:11:32] <mru> native to obscure speakers
[19:12:05] <BBB> I guess that patch needs put first
[19:12:09] <BBB> ok, will continue on that one then
[19:12:11] <BBB> blegh
[19:15:20] <BBB> elenril: now, as for put_tag
[19:15:29] <BBB> I'm seeing a lot of four-letter strings being written that way
[19:15:36] <BBB> that is not a great way of doing business
[19:16:32] <BBB> not sure how difficult that is to do regexp-wise, but can you cahnge put_tag("????") into avio_wl32(AV_RL32("????")) for these cases?
[19:16:45] <BBB> or alternatively use MKTAG(), but that may be supercomplex
[19:17:01] <mru> we really shouldn't be doing AV_RL32("....")
[19:17:04] <BBB> the compiler should be able to optimize out the AV_RL32("????") into a proper 32-bit int
[19:17:10] <mru> no, it can't
[19:17:14] <BBB> hm
[19:17:16] <mru> it's inline asm on some targets
[19:17:18] <BBB> I've seen it used in various places
[19:17:24] <mru> those should be fixed
[19:17:26] <BBB> ok
[19:17:27] <elenril> i'd go with MKTAG
[19:17:30] <BBB> then it should be MKTAG
[19:17:33] <BBB> now, I agree this sucks
[19:17:38] <BBB> but it would perform much better
[19:18:04] <mru> perhaps we should introduce a variant of the macro to be used on constant data
[19:18:24] <elenril> BBB: your mind was corrupted by writing speed-critical code too long =p
[19:19:03] <mru> no, his mind was cleansed
[19:20:00] <elenril> in most/all those put_tag() calls, readability is much more important than performance
[19:21:06] <BBB> I think it makes sense to keep the "...." as a string
[19:21:12] <mru> yes
[19:21:22] <BBB> but for four-letter ones, I think it makes sense to write all four bytes at once
[19:21:26] <BBB> using avio_wl32
[19:22:48] <BBB> unless you want to define it as a private wrapper around it, e.g. #define (or static inline) ffio_write_tag(pb, "xxxx") ffio_wn32(pb, *(uint32_t*)"xxxx")
[19:22:53] <BBB> where wn32 is the native variant
[19:22:59] <BBB> there's probably a reason why the above isn't valid
[19:23:08] <BBB> but something along those lines would be ok
[19:23:14] <BBB> and probably remove 99% of all put_tag() uses
[19:23:35] <mru> *(uint32_t*)"xxxx" is a bad idea
[19:24:01] <elenril> is that even valid?
[19:24:06] <mru> the compiler might do the right thing, but the C spec doesn't guarantee it
[19:24:25] <mru> gcc is extra buggy actually
[19:24:36] <mru> it believes string literals aren't lvalues
[19:24:58] <mru> and throws a wobbly if you use them with memory constraints in inline asm
[19:25:32] <BBB> hm
[19:25:34] <BBB> so
[19:25:39] <BBB> something along those lines then
[19:26:29] <BBB> #define ffio_wtag(pb, str) av_wl32(pb, MKTAG(str[0],str[1],str[2],str[3]))
[19:26:35] <BBB> should be valid
[19:27:51] <mru> should be
[19:28:24] <BBB> elenril: is that useful?
[19:28:51] <elenril> rewriting all those put_tag() will be PITA
[19:29:09] <mru> sed it
[19:29:11] <BBB> elenril: you can even do (if you care a lot) #ifdef LITTLE_ENDIAN the above #else #define ffio_wtag(pb, str) av_wb32(pb, MKBETAG(str[0], str[1], str[2], str[3])) #endif
[19:29:49] <BBB> but I don't think it matters much right now
[19:29:51] <BBB> so don't do it
[19:29:58] <mru> lu_zero: ping
[19:30:41] <BBB> mru: could we cheat and make av_wn{16,32} abuse proper-endianness of input and write multiple bytes at once?
[19:30:49] <BBB> or is that again undefined?
[19:31:22] <mru> they could use AV_W* macros internally
[19:31:52] <mru> lu_zero: please review my ppc patches
[19:41:55] <BBB> would require a lot of ifs
[19:42:15] <BBB> if (buf_end-buf>=4)AV_WL32() else av_w8 loop
[19:42:21] <BBB> but would be useful, ues
[19:56:14] * lu_zero is just back...
[19:58:26] <BBB> no more comments on the put patches?
[19:59:43] <lu_zero> let thunderbird fetch the emails =)
[20:00:06] * Flameeyes replaces lu_zero's thunderbird with gnus
[20:00:25] <lu_zero> Flameeyes: it would have problems with the threads I'm afraid...
[20:00:49] <Flameeyes> why would it? gnus was born to handle newsgroups, it's tremendously nice for mailing lists as well
[20:00:57] <mru> and mail in general
[20:01:11] <mru> it's a tad slow opening huge imap folders
[20:01:14] <lu_zero> I'll give a try
[20:01:24] <lu_zero> mru: ugh...
[20:01:36] <mru> Flameeyes: have you noticed that too?
[20:01:40] <mru> or am I holding it wrong?
[20:02:23] <mru> lu_zero: what I mean is it takes a few seconds to open a folder with several years worth of ffmpeg-devel
[20:03:04] <Flameeyes> mru: I have actually stopped using it a while back for various issues
[20:04:22] <mru> I haven't found anything better
[20:04:28] <lu_zero> mru: I'll give a try sooner or later
[20:05:32] <bilboed> takes 2s to open a folder with 834092 mails in evolution...
[20:05:41] <lu_zero> bilboed: which network?
[20:05:55] <lu_zero> thunderbird is perfect on decent networks...
[20:06:11] <bilboed> what do you mean "which network" ? You're a masochist if you don't cache the headers locally
[20:06:58] <mru> I think the problem has something to do with gnus liking to keep a private record of exactly which messages I've replied to or done other things with
[20:07:04] <lu_zero> bilboed: even if you cache it...
[20:07:49] <bilboed> lu_zero, try 2.91.6.2 :)
[20:07:49] <mru> on ffmpeg-devel I reply to a lot of messages, so it ends up with a _very_ long list
[20:09:29] * BBB hears no more comments
[20:09:38] * BBB pushes elenril's last patches
[20:10:14] * Kovensky sees no push
[20:10:20] <BBB> slow...
[20:10:23] <BBB> big patch
[20:10:29] * BBB gives elenril the evil look
[20:10:36] * Kovensky wonders what about h264-mt
[20:10:44] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r77eb5504d3 ffmpeg/ (59 files in 2 dirs): (log message trimmed)
[20:10:45] <CIA-15> ffmpeg: avio: avio: avio_ prefixes for put_* functions
[20:10:45] <CIA-15> ffmpeg: In the name of consistency:
[20:10:45] <CIA-15> ffmpeg: put_byte -> avio_w8
[20:10:45] <CIA-15> ffmpeg: put_<type> -> avio_w<type>
[20:10:45] <CIA-15> ffmpeg: put_buffer -> avio_write
[20:10:45] <CIA-15> ffmpeg: put_nbyte will be made private
[20:10:46] * elenril gets moar git blame points
[20:10:53] <CIA-15> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r0ac8e2bf2b ffmpeg/libavformat/ (avio.h avio_internal.h aviobuf.c spdifenc.c):
[20:10:53] <CIA-15> ffmpeg: avio: make put_nbyte internal.
[20:10:53] <CIA-15> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[20:10:54] <BBB> there you go
[20:10:59] <elenril> \\o//
[20:11:04] <BBB> you must be top patch committer in number of lines at least now
[20:11:17] <BBB> maybe we should subtract number of lines removed
[20:11:21] <gnafu[away]> elenril: Is that Goro when he's rejoicing?
[20:11:26] <elenril> i think mru's dca prettyprinting is still bigger
[20:11:49] <BBB> what's next?
[20:11:57] <elenril> put_tag?
[20:12:02] <BBB> is the macro ok?
[20:12:27] <BBB> #define ffio_wtag(pb, tag) ffio_wl32(pb, MKTAG(tag[0], tag[1], tag[2], tag[3]))
[20:12:49] <mru> lu_zero: and the altivec vp8 epel patch?
[20:13:11] <mru> BBB: maybe add some () like so: (tag)[0] etc
[20:13:14] <mru> just in case
[20:14:43] <BBB> I see only 2 cases whereit's not 4 chars
[20:14:58] <mru> and what is it there?
[20:15:02] <BBB> for these, we can figure out something else... maybe avio_put_str() can be converted
[20:15:05] <mru> and what might someone do in the future?
[20:15:11] <BBB> libavformat/swfenc.c:    put_tag(pb, "FWS");
[20:15:12] <BBB> libavformat/swfenc.c:            put_tag(pb, "video");
[20:15:14] <dalias> greets
[20:15:18] <BBB> libavformat/rmenc.c:                put_tag(s,"VIDORV10");
[20:15:18] <BBB> libavformat/rmenc.c:                put_tag(s,"VIDORV20");
[20:15:29] <BBB> the rmenc ones can be replaced by two put_tags
[20:15:38] <BBB> the one in swfenc ... well ... dunno
[20:15:53] <mru> it has a terminating nul byte
[20:15:59] <BBB>             put_tag(pb, "video");
[20:15:59] <BBB>             avio_w8(pb, 0x00);
[20:16:02] <BBB> easy enough
[20:16:04] <BBB> :)
[20:16:21] <BBB> FWS has no zero byte
[20:16:23] <siretart> how's the big bump coming along? how far do you guys estimate it from now?
[20:16:35] <mru> BBB: what does put_tag() do?
[20:16:39] <BBB> oh
[20:16:41] <BBB> it abuses put_tag
[20:16:45] <elenril> haha
[20:16:46] <BBB> put_tag(3 letters)
[20:16:54] <BBB> then put_byte(version)
[20:17:00] <BBB> so you can make it 4 chars also
[20:17:11] <elenril> siretart: finish avio rename first
[20:17:25] <elenril> i guess the same should be done in lavc/lavu too
[20:17:27] <mru> maybe those really ought to be put_somethingelse
[20:18:50] <drv> libavformat/mmf.c:    put_tag(pb, "VN:libavcodec,"); /* metadata ("ST:songtitle,VN:version,...") */
[20:19:52] <drv> and the ones in ffmetaenc
[20:19:55] <BBB> libavformat/gif.c:        put_tag(pb, "NETSCAPE2.0");  // bytes 4 to 14
[20:20:51] <drv> gfxenc has some too
[20:20:54] <mru> so put_tag() is actually "put string"
[20:21:05] <elenril> mru: put string without NULL
[20:21:08] <BBB> it seems it is indeed sometimes put_string without null
[20:21:12] <BBB> and sometimes put_fourcc
[20:22:12] <mru> so if you want a special function to write "fourcc" tags, you'll have to provide something else for those places where an arbitrary-length string is passed
[20:24:14] <drv> so really avio_put_str should perhaps be avio_put_strz and current put_tag could be avio_put_str
[20:25:16] <elenril> i doesn't have to be public
[20:26:04] <ods15> 16:33:52 <@mru> remember the time ods15 ate pork?
[20:26:07] <ods15> 16:34:34 <@mru> wiesbaden '06
[20:26:20] <mru> he's alive!!
[20:26:24] <ods15> damn, 06?? that was 5 years ago???
[20:26:29] <ods15> time flies
[20:26:57] <ods15> anyway, i don't remember at all.. i wonder if that was my first time then
[20:27:25] <mru> you were looking for non-pork options but finally gave in
[20:27:27] <mru> as I recall
[20:27:40] <ods15> i don't eat pork at all in israel, i'm rarely in such restaurants, but in u.s. i ate bacon every morning at the hotel...
[20:27:58] <mru> of course you don't eat pork in israel, the stuff doesn't exist there
[20:28:01] <ods15> wow, weird.. don't remember it at all
[20:28:09] <ods15> it exists, but fairly rare
[20:28:27] <mru> since few people would buy it
[20:28:42] <bilboed> it's like negative-spain
[20:28:51] <ods15> quite a few restaurants serve meat with cheese, and a small subset of those also have pork
[20:28:55] <ods15> lol
[20:29:30] <bilboed> (Spain pushed strongly for porc while trying to kick out the maures)
[20:29:35] <ods15> in tel aviv i think kosher restaurants are more rare than non-kosher
[20:30:03] <mru> kosher by which definition?
[20:30:04] <ods15> ("more-rare" is a bad phrase. i mean simply, "in the minority"...)
[20:30:09] <ods15> certified
[20:30:32] <ods15> i think there are a whole bunch of different kind of certifications, some more strict than others
[20:30:45] <mru> but most people don't really care about certification, do they?
[20:30:52] <ods15> but i can simply divide them by "have any certif", vs. "none at all"
[20:31:06] <ods15> oh, most that care about it at all, do
[20:31:20] <ods15> the question "are you kosher" means "do you have kosher certif"
[20:31:45] <ods15> it hardly means, "is your food kosher" :) cause anyone who has a clue knows that the whole certif is just a money fraud
[20:31:53] <mru> yeah
[20:32:20] <ods15> only the very crazy care about which certif you have
[20:32:23] <Flameeyes> [just wondering out of my mind while trying not to get myself too down on the stuff I'm doing... anybody tried OpenMP lately?]
[20:32:23] <mru> what I meant was, there are probably more people who don't eat pork than who care about the certificate
[20:32:35] <mru> Flameeyes: for what purpose?
[20:32:38] <ods15> oh, yeah, thats true
[20:32:51] <Flameeyes> mru: media-related :)
[20:33:04] <mru> Flameeyes: I'd say it's useless
[20:33:12] <ods15> because pork is just a rarity in israel, it's still quite stigmitizedas "unclean"... perpetuating the rarity...
[20:33:36] <CIA-15> ffmpeg: Mans Rullgard <mans at mansr.com> master * r381efba0ec ffmpeg/libavcodec/ppc/vc1dsp_altivec.c:
[20:33:36] <CIA-15> ffmpeg: ppc: fix vc1 inverse transform, unbreak build
[20:33:36] <CIA-15> ffmpeg: GCC 4.3 and later are more particular about signedness matching
[20:33:36] <CIA-15> ffmpeg: in vector operations. The operations under if(rangered) were
[20:33:36] <CIA-15> ffmpeg: missing assignments and thus had no effect.
[20:33:37] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:33:37] <mru> that's the impression I've got from meeting israelis
[20:33:38] <CIA-15> ffmpeg: Mans Rullgard <mans at mansr.com> master * re0e46cae37 ffmpeg/libavcodec/ppc/vp8dsp_altivec.c:
[20:33:38] <CIA-15> ffmpeg: vp8: ppc: fix invalid reads in altivec epel mc
[20:33:39] <CIA-15> ffmpeg: The 4-tap filters should only access one row/column before the
[20:33:39] <CIA-15> ffmpeg: reference block.
[20:33:40] <CIA-15> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:33:52] <Flameeyes> mru: k.. was just wondering â€” I started looking into that years ago for xine but then never had the time to work on it seriously
[20:34:17] <mru> Flameeyes: openmp is only (possibly) useful when you have parallelism at a high level
[20:34:21] <ods15> whats up with "signed-off-by"? is this a gpl thing?
[20:34:57] <mru> so each thread processes its slice for a fairly long time without interaction with others
[20:35:09] <mru> typical hpc stuff
[20:35:15] <ods15> hey, i just noticed that the revisions CIA-15 says are git revisions... is this a CIA-15 thing, or is ffmpeg finally git?
[20:35:26] <mru> ods15: it's git all the way
[20:35:26] <bilboed> finally git :)
[20:35:33] <mru> ods15: what rock have you been under?
[20:35:33] <ods15> insanity!
[20:36:22] <ods15> mru, actually, it's rather surprising that i knew at all that you guys were STILL working on the switch to git just a few months ago, i was bored and happenned to catch on that mailing list thread and read it
[20:36:28] <mru> Flameeyes: the only video coding parts that a compiler has any hope in hell of parallelising are the ones best done in simd anyway
[20:36:35] <ods15> but otherwise, i have no clue at all whats going on in mplayer/ffmpeg
[20:36:39] <Flameeyes> mru: i see
[20:37:03] <mru> Flameeyes: I'm sure the hpc compiler guys will tell you another story of course
[20:37:20] <mru> one about how openmp is the salvation from all evil and will cure cancer etc
[20:37:25] <ods15> a few months ago, some of my friends from uni, who are studying CS, got a homework project with ffmpeg :)
[20:37:38] <ods15> i showed em my names in the credits, which was funny :)
[20:37:41] <ods15> name*
[20:38:43] <mru> BBB: elenril: !!!!!!!!!!!!!
[20:38:52] <BBB> ?
[20:38:54] <BBB> what?
[20:38:55] <mru> you killed fate
[20:38:58] <BBB> huh?
[20:39:00] <mru> second time today
[20:39:02] <BBB> I did not
[20:39:12] <mru> libavformat/spdifenc.c:528: error: implicit declaration of function 'ffio_fill
[20:39:25] <BBB> oh that
[20:39:30] <BBB> my compiler doesn't error on that
[20:39:35] <BBB> I'm not sure why
[20:39:37] <BBB> let me fix that
[20:39:42] * BBB goes hide in shame
[20:40:43] <BBB> email sent
[20:40:57] <mru> compiler too old
[20:40:57] <elenril> oops
[20:41:03] <mru> I've told you not to use apple crap
[20:41:11] <BBB> but I love my mac
[20:41:25] <mru> sorry pal, she's cheating on you
[20:41:31] <BBB> :'(
[20:41:42] <BBB> I'll win her back! I WILL!
[20:41:49] <BBB> now go ack my patch
[20:42:08] <mru> nak
[20:42:15] <BBB> ?
[20:42:21] * elenril o_0 at the amount of put_tag() in movenc.c
[20:42:28] <elenril> what's wrong with that muxer
[20:42:36] <mru> it's a mov muxer
[20:42:45] <BBB> elenril: good luck with that
[20:43:19] <BBB> mru: what's wrong with the patch?
[20:43:26] <mru> read your email
[20:43:29] <BBB> oh
[20:43:46] <ods15> mru, got a Q, i use git at work
[20:44:01] <mru> authorised or unauthorised?
[20:44:08] <ods15> is the general git philosophy, if i have local topic branches, i should NOT sporadically update?
[20:44:25] <mru> you do whatever you feel like
[20:44:28] <elenril> is it because movenc sucks or because mov sucks?
[20:44:28] <ods15> if by "nonauthorized" you mean, we still use svn, then yes, we still use svn
[20:44:32] <mru> git doesn't dictate how you work
[20:44:32] <elenril> or both
[20:44:52] <mru> I know mov sucks
[20:44:54] <BBB> oh I guess I should keep it alphabetical?
[20:45:09] <mru> BBB: why don't you go and read my reply?
[20:45:10] <ods15> well, for this end i made a script "git-update" which does the equivalent of "for `git for-each-ref`; git rebase master $I"
[20:45:16] <BBB> mru: I did
[20:45:17] <mru> BBB: and for the record, I am not DonDiego
[20:45:18] <BBB> mru: I responded
[20:45:28] <BBB> mru: so I figured "maybe something else is wrong also"
[20:45:36] <BBB> where is dondiego anyway
[20:45:39] <BBB> he isn't reviewing patches
[20:45:39] <ods15> and, well, it really doesn't work very well when starting to collaborate...
[20:45:48] <mru> he tab completes, that's something
[20:46:32] <BBB> there's another guy starting with don also
[20:47:32] <Flameeyes> BBB: there's also another Diego :P
[20:47:53] <BBB> not on irc :)
[20:48:12] <BBB> (as in: nick doesn't look like diego on irc)
[20:48:14] <elenril> srsly, wtf is with movenc being a pile of lasagna
[20:48:33] <merbzt> elenril: what are you talking about ?
[20:48:37] <merbzt> what is the problem ?
[20:49:27] <elenril> merbzt: it takes up a huge part of my renaming patches
[20:49:43] <elenril> which probably doesn't mean anything nice
[20:50:12] <BBB> well our mov muxer is tons more complete than most others, and supports a lot more features than most others
[20:50:27] <BBB> multiple video/audio codecs, with special extradata, stuff like that, rtp hinting, subtitles
[20:50:35] <BBB> only matroskaenc supports as much, I think
[20:50:49] <BBB> and that's a pile of ebml_puts instead of put_tags
[20:51:29] <CIA-15> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r0f86fcabdf ffmpeg/libavformat/spdifenc.c: spdifenc.c: fix compile because of missing include avio_internal.h.
[20:51:41] <BBB> also, shall we deprecate MAINTAINERS?
[20:52:11] <merbzt> BBB: yes, at least apply Reimars patch
[20:52:34] <merbzt> I oked it
[20:53:02] <Kovensky> 17:48.14 elenril: srsly, wtf is with movenc being a pile of lasagna <-- it isn't object oriented, so it's plain old spaghetti
[20:53:31] <ohsix> all my objects are oriented
[20:56:26] <elenril> anyway, i'd just make put_tag internal for now
[20:56:37] <elenril> or do we want it public?
[20:56:48] <Flameeyes> ohsix: pointing north?
[20:57:01] <ohsix> just oriented
[20:57:10] <BBB> elenril: no, not public
[20:57:24] <BBB> elenril: internal is fine, as long as we can remove it and replace it with something better
[20:57:27] <elenril> BBB: then i'll just rename it and we can fix it later
[20:57:34] <BBB> that's ok
[20:57:38] <ohsix> that was the joke, just because their oriented doesn't say about their grouping or where they're facing, or if they're tipped over and thats not the proper state of them ... huhu
[20:59:06] <elenril> oriented == surface+normal
[21:03:26] <BBB> ok, whoever is in for another flame, let's remove MAINTAINERS
[21:05:33] <bilboed> +1
[21:05:38] <bilboed> there's git for that
[21:06:01] <Flameeyes> BBB: I'm always in on the flame!
[21:06:11] <Flameeyes> I suggest we add a .mailmap file though, in that case
[21:06:25] <Flameeyes> [i.e. I'm pretty sure I currently appear with a couple different identities over the repository]
[21:17:30] <elenril>  20 files changed, 196 insertions(+), 170 deletions(-)
[21:17:35] <elenril> hmm, this one is pretty big too
[21:19:15] <Kovensky> git doesn't say who the maintainer is does it
[21:19:27] <BBB> git has a solution for world hunger
[21:19:47] <elenril> BBB: patch sent
[21:19:52] <BBB> noticed
[21:21:36] <elenril> so shall we do url_ffoo next?
[21:22:32] <BBB> yeah, let's
[21:22:45] * Flameeyes just loves emacs
[21:22:48] <BBB> now
[21:22:49] <BBB> so
[21:22:52] <BBB> for put_tag
[21:22:58] <BBB> ffio_wtag I mean
[21:22:59] <BBB> :-p
[21:23:21] <BBB> do we want to put any effort in merging this with avio_put_str or avio_wl32()?
[21:23:42] <elenril> you mean weffort
[21:24:22] <elenril> when it's used for fourccs it should be eliminated
[21:24:28] <elenril> in other places, :effort:
[21:24:35] * Kovensky flames Flameeyes with TECO
[21:24:47] * Kovensky wonders what happens if one writes "Flameeyes" on TECO
[21:24:57] <Flameeyes> Kovensky: probably something very very bad
[21:26:24] <Flameeyes> it could either go up in smoke
[21:26:31] <Flameeyes> or decide to write a ruby-based clone of itself
[21:27:40] <wbs> anyone care to comment on the ff_neterrno() patch I sent a few days ago?
[21:28:25] <elenril> url_fopen/fclose/fseek/fskip/ftell/fsize look ObviouslyPublic
[21:28:57] <Flameeyes> wbs: poke lu_zero :P
[21:29:08] * Kovensky wonders if there'll ever be a way to make ffmpeg open a file descriptor, or a way to feed it a FILE*
[21:29:25] <Kovensky> s/ffmpeg/libavformat/
[21:37:28] <elenril> Kovensky: send patches
[21:37:43] <elenril> (see them being rejected)
[21:38:31] <BBB> url_fdopen()
[21:38:35] <BBB> with fileno(FILE*)
[21:38:46] <BBB> anything else?
[21:38:54] <wbs> BBB: url_fdopen takes an URLContext
[21:38:59] <BBB> oh
[21:39:00] <BBB> that sucks
[21:39:01] <BBB> ohwell
[21:40:36] <Kovensky> that's terribly named then =p
[21:41:11] <wbs> no, it's perfectly right named, just like fdopen() wraps a file descriptor into a high-level buffered FILE*, url_fopen takes a low-level, unbuffered URLContexts and wraps it into a buffered AVIOContext
[21:41:23] <wbs> Kovensky: btw, pipe:<number> lets you use an existing fd
[21:41:53] <Kovensky> does fileno() work even on windows?
[21:42:17] <Dark_Shikari> "man fileno" returns a man page
[21:42:19] <Dark_Shikari> so I'd assume yes.
[21:42:49] <Kovensky> Dark_Shikari: cygwin != windows
[21:44:23] <Dark_Shikari> what, are you going to build ffmpeg in visual studio now?
[21:44:43] <Flameeyes> Dark_Shikari: I thought people did already?
[21:44:53] <Flameeyes> [or at least with mingw
[21:49:19] <Kovensky> Dark_Shikari: mingw
[21:49:45] <Dark_Shikari> mingw has wrappers for posix functions
[21:49:47] <elenril> ok, enough api breakage for today
[21:49:49] * elenril sleeps
[21:52:19] <Kovensky> Dark_Shikari: not enough wrappers
[21:56:58] <mru> ENOWRAPPER
[22:36:05] <Compn> arg bbb left
[22:36:54] <saintdev> Compn: wow, that was a good summoning
[23:13:52] <DonDiego> gnite