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

[irc at mansr.com]

[00:19:17] <Jumpyshoes> what does RFC stand for?
[00:19:26] <mru> request for comments
[00:19:35] <Jumpyshoes> oh, i see
[00:21:48] * lu_zero wonder if the replacement of libjpeg really works
[00:21:51] <lu_zero> wonders
[00:21:59] <mru> replacement?
[00:22:25] <lu_zero> media-libs/libjpeg-turbo
[00:22:53] <mru> oh that
[00:23:01] <mru> that's just a hacked-up libjpeg
[00:23:06] <lu_zero> yup
[00:23:25] <lu_zero> still might work better
[00:24:08] <lu_zero> wbs patches pushed now
[00:25:05] <CIA-38> ffmpeg: Martin Storsjö <martin at martin.st> master * rd9c0510e22 ffmpeg/libavformat/ (rtsp.c rtspenc.c): (log message trimmed)
[00:25:05] <CIA-38> ffmpeg: rtsp: Don't store RTSPStream in AVStream->priv_data
[00:25:05] <CIA-38> ffmpeg: For mpegts in RTP, there isn't a direct mapping between RTSPStreams
[00:25:05] <CIA-38> ffmpeg: and AVStreams, and the RTSPStream isn't ever stored in
[00:25:05] <CIA-38> ffmpeg: AVStream->priv_data, which was earlier leaked. The fix for this
[00:25:06] <CIA-38> ffmpeg: leak, in ea7f080749d68a431226ce196014da38761a0d82, lead to
[00:25:07] <CIA-38> ffmpeg: double frees for other, normal RTP streams.
[00:25:12] <CIA-38> ffmpeg: Martin Storsjö <martin at martin.st> master * rce41c51b0c ffmpeg/libavformat/ (movenchint.c rtpenc_chain.c rtsp.c):
[00:25:12] <CIA-38> ffmpeg: Free AVStream->info in chained muxers
[00:25:12] <CIA-38> ffmpeg: This fixes memory leaks in the RTSP muxer and RTP hinting in the
[00:25:12] <CIA-38> ffmpeg: mov muxer present since SVN rev 25418.
[00:25:13] <CIA-38> ffmpeg: Signed-off-by: Luca Barbato <lu_zero at gentoo.org>
[00:27:28] <CIA-38> ffmpeg: Nicolas George <nicolas.george at normalesup.org> master * r62ecd3635a ffmpeg/libavcodec/utils.c:
[00:27:28] <CIA-38> ffmpeg: Set pkt_pts in avcodec_default_reget_buffer()
[00:27:28] <CIA-38> ffmpeg: This was missed when pkt_pts was first added.
[00:27:28] <CIA-38> ffmpeg: Signed-off-by: Nicolas George <nicolas.george at normalesup.org>
[00:27:28] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:50:51] <CIA-38> ffmpeg: Clément Bœsch <ubitux at gmail.com> master * rdc75d6dbf2 ffmpeg/libavutil/mem.c:
[01:50:51] <CIA-38> ffmpeg: Avoid pointless check before calling free
[01:50:51] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:51:01] <CIA-38> ffmpeg: Clément Bœsch <ubitux at gmail.com> master * r437fb1c87d ffmpeg/ (9 files in 2 dirs):
[01:51:01] <CIA-38> ffmpeg: Remove a few if (p) av_free(p) forms
[01:51:01] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[01:51:45] <ubitux> the was *really* quick, thanks mru
[01:52:15] <Sean_McG> they're low to no impact changes
[01:52:16] <mru> that's a pet peeve of mine, glad to see them all gone
[01:52:34] <mru> and yes, easily verified
[01:52:41] <Sean_McG> and I like that av_free() already DTRTs
[01:54:14] <ubitux> well, bbl, thanks for the reactivity :)
[01:57:51] <mru> Sean_McG: btw, any idea about the remaining gcc 4.6 failure?
[01:58:57] <Sean_McG> I was actually gonna look into that tonight, unless somebody else is
[01:59:20] <mru> not that I know of
[01:59:27] <Sean_McG> OK, I'll see what I can dig up
[01:59:45] <mru> that would be most appreciated
[02:04:18] <Sean_McG> is there a way to quickly run just that 1 test? (pixfmt)
[02:04:26] <mru> make fate-$test
[02:04:30] <Sean_McG> OK
[02:04:53] <mru> where $test is whatever fateweb shows
[02:05:23] <mru> make fate-list prints a list of all tests
[02:31:56] <Sean_McG> how do I know which code a test is working when all I see is "TEST lavf-pixfmt"?
[02:34:07] <mru> add V=1
[02:34:14] <mru> that'll print the exact commands
[02:34:16] <Sean_McG> ah
[02:34:18] <Sean_McG> sweet
[03:12:17] <Sean_McG> I'm still kinda lost, but I'm guessing this is some inline asm issue, not unlike the imdct stuff
[03:12:54] <Sean_McG> maybe getting gcc to keep the temps, and then comparing 4.5.2 against 4.6?
[05:03:03] <Sean_McG> meh, I've been mucking around with this and still no closer to an answer
[05:20:59] <peloverde> Sean_McG: did you see if valgrind has any insights?
[05:21:28] <Sean_McG> I'm on Solaris, no valgrind
[05:22:03] <peloverde> for some reason I thought you were on linux
[06:39:24] <Dark_Shikari> So, I should add AVX detection to ffmpeg.
[06:39:25] <Dark_Shikari> deblock_luma[1]_c: 7123
[06:39:25] <Dark_Shikari> deblock_luma[1]_mmx: 2159
[06:39:25] <Dark_Shikari> deblock_luma[1]_sse2: 936
[06:39:26] <Dark_Shikari> deblock_luma[1]_avx: 860
[06:54:41] <Dark_Shikari> fuck, does anyone know about inline asm?
[06:54:58] <_av500_> m r u
[06:55:01] <Dark_Shikari> #define xgetbv(index,eax,ebx,ecx,edx)\
[06:55:02] <Dark_Shikari>     __asm__ volatile\
[06:55:02] <Dark_Shikari>         ("xgetbv\n\t"\
[06:55:02] <Dark_Shikari>          : "=a" (eax), (edx)\
[06:55:02] <Dark_Shikari>          : "0" (index));
[06:55:31] <Dark_Shikari> according to libavutil/x86/cpu.c, this would seem to put "index" in eax
[06:55:39] <Dark_Shikari> ... why?
[06:55:41] <Dark_Shikari> how do I put it in ecx instead?
[06:56:00] <astrange> "0" means the same as constraint 0 (the =a)
[06:56:02] <astrange> use "c"
[06:56:15] <Dark_Shikari> ok
[07:18:32] <Dark_Shikari> it's the video version of PLZ SEND ME TEH CODEZ!
[07:18:35] <Dark_Shikari> Dear experts,
[07:18:35] <Dark_Shikari> An urgent help needed now.
[07:18:35] <Dark_Shikari> I am testing the H.264/MVC decoder part using JM17.1 version source code, would you like provide me any encoded bitstream with "MVC_EXTENSION_ENABLE". It will be great if you also provide me the original stereo clips. either QCIF or CIF format is better.
[07:24:04] <siretart> good morning
[07:25:09] * Dark_Shikari loves jvt-experts.
[07:26:11] <KotH> bon giorno
[07:30:58] <pJok> ohayou gozaimasu
[07:33:30] <elenril> лунный язык оверрейтед
[07:37:16] * pJok should fix his screen+irssi setup to actually show utf-8 and not just recode it to iso8859-1
[07:37:37] <elenril> doesn't it JustWork?
[07:38:29] <wooster> depends on your temrinal client
[07:38:32] <pJok> it would if i didn't explicitly made it do that
[07:38:48] * pJok uses a few terminal clients that aren't happy about utf-8
[07:40:05] <cartman> moin
[07:46:36] <av500> Dark_Shikari: yeah, I feel subscribing jvt was worth it :)
[07:57:10] <cartman> http://digitaldaily.allthingsd.com/20100520/googles-royalty-free-webm-video-may-not-be-royalty-free-for-long/ is this for real? Patent pool for VP8?
[07:58:24] <Dark_Shikari> Look at the date
[07:58:26] <Dark_Shikari> May
[07:58:27] <Dark_Shikari> 2010
[07:58:53] <cartman> yes and it takes time I guess :P
[07:59:51] <spaam> cartman: fail
[08:00:07] <spaam> cartman: why do you read old news??
[08:00:14] <cartman> spaam: reddit :)
[08:00:51] <spaam> i thought they have new stuff there.
[08:01:14] <cartman> it was posted as "Reminder"
[08:10:35] <Zor> people use reddit?
[08:10:55] <KotH> people read?
[08:11:30] <superdump> people?
[08:11:40] <cartman> think about the children!
[08:14:48] <wbs> Dark_Shikari: another favorite of mine is all the "how do I use ffmpeg on android?" - http://groups.google.com/group/android-ndk/browse_thread/thread/f05edc8949cbe5a8
[08:15:28] <cartman> wbs: that was a good one
[08:17:41] <Dark_Shikari> wbs: How do I patch KDE2 on FreeBSD?
[08:18:16] <wbs> Dark_Shikari: yeah :-)
[08:18:17] <cartman> Dark_Shikari: emerge World
[08:22:34] <elenril> sup kshishkov
[08:22:43] <elenril> there's something wrong with your address
[08:22:50] <kshishkov> of course
[08:23:13] <kshishkov> looks like Ukrainian reality striked again
[08:23:24] <kshishkov> so I'll use this machine for a while
[08:25:35] <pJok> kshishkov, so its the ukranian reality strike that has affected our busses here in denmark?
[08:26:10] <kshishkov> pJok: nope, Denmark can manage by itself
[08:27:57] <pJok> well, you never know about things like that
[08:29:32] * kshishkov reminds pross-au his favourite word (and it's not "sheep")
[08:29:54] <pross-au> Boobies?
[08:30:07] <pJok> trocadero?
[08:30:16] <kshishkov> pJok: not mine, his
[08:30:27] <kshishkov> pross-au: you've guesses the first letter correctly
[08:30:43] <pJok> ah
[08:31:33] <elenril> why don't you write it yourself if you want it so much
[08:32:05] * kshishkov has to work on one codec used in EA game instead
[08:32:16] <pross-au> Whoa
[08:32:19] <pross-au> Which one kshishkov ?
[08:32:20] <pJok> hehe
[08:32:40] <spaam> wait what? kshishkov going to do something? :D
[08:32:56] <elenril> spaam: sounds like a cake
[08:33:13] <spaam> elenril: yeah
[08:34:47] <kshishkov> pross-au: look at publisher name in http://en.wikipedia.org/wiki/Wing_Commander_IV
[08:34:58] <pross-au> K
[09:36:29] <spaam> kshishkov: haha
[09:38:10] <Dark_Shikari> http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2011-February/105460.html oh wow
[09:38:41] <spaam> kshishkov++
[09:38:46] * elenril kicks roundup
[09:38:58] <elenril> why does searching show closed bugs
[09:38:59] <peloverde> nice work kshishkov
[09:39:15] <kshishkov> I told them I was working on something!
[09:39:26] <peloverde> I suppose you might be looking for a new task now... might I interest you in the aac encoder?
[09:39:45] <elenril> haha
[09:39:47] <Dark_Shikari> come help us on x264!  We have AVX code to write.
[09:39:49] * kshishkov is trying to interest his colleague to write opensource one
[09:39:54] <Tjoppen> kshishkov: wc4 decoder \o/
[09:40:06] <kshishkov> Dark_Shikari: it's too sandy path to AVX
[09:40:59] <spaam> Dark_Shikari: x264? FFmpeg need it
[09:41:06] <Dark_Shikari> ffmpeg too!
[09:41:11] <Dark_Shikari> I posted a patch to add AVX support
[09:41:31] <av500> meh, h264 coding happens on gfx cards these days...
[09:41:45] <kshishkov> Dark_Shikari: the one with hidden hope mru will fix it?
[09:42:50] * Dark_Shikari punts av500 
[09:44:39] <kshishkov> av500: ftp://download.nvidia.com/XFree86/Linux-x86_64/195.36.15/README/vdpausupport.html look for "VDPAU features note 1"
[09:45:49] <cartman> buy a Quadro GPU then
[09:45:49] <cartman> :P
[09:46:26] * kshishkov waits for KotH to give OGP cards along with Swiss chocolate
[09:46:40] <cartman> OGP still alive?!
[09:47:23] <KotH> ofc
[09:47:26] <KotH> but no ogp cards
[09:47:35] <cartman> meh :)
[09:47:35] <KotH> these beasts are expensive!
[09:47:45] <KotH> buy one yourself! :)
[09:47:50] <cartman> OGP was supposed to produce something :P
[09:48:19] <kshishkov> KotH: have you translated ffmpeg sources to verilog already?
[09:48:36] * KotH refuses to speak verilog, it's the language of the devil
[09:49:38] <kshishkov> what have you used for design instead?
[09:49:43] <siretart> http://www3.informatik.uni-erlangen.de/Persons/potyra/potyra.html is working on a C->VHDL compiler
[09:49:54] <siretart> I know him, he is a nice guy :-)
[09:50:31] <av500> kshishkov: so? some minor resolutions not supported
[09:50:54] <KotH> Subject: [FFmpeg-devel] [PATCH 0/2] Origin Wing Commander IV video decoder
[09:50:56] <KotH> rotfl
[09:51:05] <kshishkov> av500: and those guys made Tegra platform as well so I won't trust their GPU encoding either
[09:51:36] <kshishkov> KotH: well, Reimar mentioned nobody's going to review obscure game codec so here's a test
[09:52:27] <KotH> kshishkov: if i'd have the time and the knowledge, i'd review it, just for the fun of it :)
[10:07:34] * av500 wonders how many obscure decoders kshishkov has stashed away to use in emergencies...
[10:08:05] <mru> av500: remember all those games mike was playing?
[10:09:29] <pross-au> mru: like the Barbie series...
[10:09:36] <cartman> ...
[10:09:37] <mru> and taco bell
[10:10:06] <pross-au> Guiness Book of Records needs an obscure hobby section
[10:11:57] * elenril was just going to say that psx str don't work
[10:12:09] <elenril> but wow, they actually do work
[10:12:45] <astrange> psxstr plays at the wrong framerate
[10:13:02] <astrange> i discovered that in... hmm... 2005?
[10:13:02] <kshishkov> av500: there's also LucasArts format and Discworld II
[10:13:25] <kshishkov> av500: and everything else that comes across
[10:13:28] <astrange> and then i read the str spec and couldn't figure out how it worked
[10:13:45] <astrange> iirc the framerate is detected based on how many audio frames there are between video frames
[10:14:19] <elenril> at least the xenogears movies i'm playing right now work fine
[10:14:49] <elenril> .....except for the double free or whatever this is
[10:15:25] <elenril> yay, and it's apparrently random
[10:15:28] * elenril blames -mt
[10:16:01] * kshishkov blames it for not being merged
[10:16:11] <elenril> yes, goes away with threads=1
[10:16:17] <elenril> astrange: you broke it!
[10:16:19] <peloverde> If -mt isn't merged before my birthday, it will be a very sad birthday
[10:17:04] <astrange> the patches i sent are done but lost in confusing email threads. i'll repost them tomorrow and then the rest of the tree as RFC
[10:17:22] <siretart> do we want -mt for the 0.7 release, or rather, how likely is -mt going to cause regressions?
[10:17:30] <kshishkov> peloverde: make a present for yourself - improve AAC encoder
[10:17:56] <astrange> likely. when do you want to release?
[10:18:15] <siretart> astrange: I'm actually only waiting for the libavfilter API to become fixed
[10:18:45] <kshishkov> siretart: i.e. never
[10:18:49] <siretart> saste told me he wants to change things for audio filter, but other than that, I consider current master to be ready to branch
[10:18:54] <peloverde> kshishkov: how about I implement some weird AOT in the decoder instead?
[10:19:27] <elenril> how about working on libvorbis ;)
[10:19:27] <siretart> kshishkov: read stable as 'future API/ABI breaks require major bump', which is currently not the case
[10:19:31] <elenril> err i mean vorbisenc
[10:20:20] <astrange> aotuv is good enough
[10:20:37] <siretart> lunchtime.now
[10:20:51] <kshishkov> peloverde: who needs it? and encoder is rather needed
[10:20:57] <astrange> get ahead of the curve by writing xiph ghost enc
[10:21:22] <astrange> http://pastebin.com/rXv2Jbbq it might help something if someone sends me review notes for this
[10:21:29] <astrange> as well as "i completely don't understand this"
[10:22:39] <peloverde> kshishkov: I wouldn't want to steal that fun from you
[10:22:42] <Dark_Shikari> are we ever going to bump lavc btw?  we have like five million things queued up for bump
[10:23:09] <astrange> not enough things
[10:23:10] <kshishkov> peloverde: you can't so go work on aacenc
[10:23:21] <kshishkov> peloverde: I'm not good with encoders anyway
[10:23:27] <astrange> i don't think anyone has proposed removing nearly enough of AVCodecContext
[10:23:43] <mru> go for it, chop chop
[10:24:02] <astrange> e.g. x264-only fields should be removed on bump and replaced by codec options, has_b_frames could be renamed delay, i think some other fields might be single-codec specific
[10:24:04] <peloverde> the only bug free code is removed code
[10:24:31] <kshishkov> astrange: probably some Michael would be against it, that's why it wasn't proposed
[10:24:32] <elenril> won't people hate us even more for removing them so suddenly
[10:25:16] <kshishkov> it's always sudden
[10:25:20] <astrange> there's a field named slice_count and a field named slices
[10:25:40] <elenril> kshishkov: it's slightly less sudden when it's marked as deprecated for a few months
[10:26:14] <Dark_Shikari> in x264 we randomly remove an option every year or so
[10:26:17] <Dark_Shikari> it's fun
[10:26:19] <Dark_Shikari> keeps people on their toes
[10:26:22] <kshishkov> elenril: you mean years?
[10:26:45] <kshishkov> elenril: I don't see anything deprecated removed from FFmpeg after just months
[10:27:05] * mru thinks it's time for The Big Bump
[10:27:06] <elenril> because we didn't do a major bump in years
[10:27:43] <elenril> it's not like we can't do another one a year later or so
[10:27:44] * kshishkov had an evil plan to bump minor version till overflow
[10:27:54] <elenril> kshishkov: IKnewIt!
[10:28:04] <av500> kshishkov: rev 2.50.NAN
[10:28:05] * elenril is all for bumping lavf
[10:28:21] <astrange> enum Motion_Est_ID should have half the entries removed (no code implements them)
[10:28:27] <KotH> somehow, all this talk about bumping reminds me of 4chan :)
[10:28:34] <kshishkov> av500: rev 52.-127.0 for lavc
[10:28:35] <astrange> i'll write an email if i don't sleep though the whole day
[10:28:41] * elenril sages KotH 
[10:28:42] <astrange> which is possible, as i'm up past 5am
[10:29:04] <KotH> astrange: living in the japanese timezone?
[10:29:49] <kshishkov> KotH: why are you asking?
[10:30:12] <astrange> living in est but talking to some people in jst did mess me up
[10:30:48] <DonDiego> i also like the big bump idea
[10:31:02] <mru> siretart: ping
[10:31:28] <av500> FFmpeg 0.7 "the big bump"
[10:31:34] <noname^^> http://git.ffmpeg.org/?p=ffmpeg.git;a=blob;f=libavcodec/resample.c;h=272831520dd2608762f3cea052ea3d7020e91ef6;hb=HEAD#l243 <- has someone disabled this for a reason (&& 0) or is it a bug?
[10:31:54] <DonDiego> av500: we need a more revolutionary slogan i guess
[10:32:01] <DonDiego> what about "the tidal wave"? :)
[10:32:34] <KotH> wennschondenschon "The Tidal Wave!"
[10:32:37] <elenril> av500: big bump BBB?
[10:32:50] <av500> "BBB's Big Bump"
[10:32:56] <av500> or B5
[10:33:09] <peloverde> DS9
[10:33:30] <mru> noname^^: one beer says michael put that there
[10:33:36] <mru> so there's no way we'll ever know why
[10:33:41] <noname^^> haha
[10:34:22] <elenril> well you could ask him
[10:34:45] <mru> lol
[10:34:45] <astrange> it looks like it doesn't check s->sample_size
[10:34:52] <astrange> so it'd be wrong if it was enabled
[10:34:58] <lu_zero> good morning
[10:35:05] <kshishkov> mru: maybe it was there just to prevent it running on copy case but then he realised it eats precious cycles and moved condition elsewhere?
[10:35:17] <pJok> i thought BBB was already Big Buck Bunny ;)
[10:35:39] <benoit-> hi
[10:35:49] <mru> hi benoit-
[10:36:15] <kshishkov> bonjour
[10:36:17] <benoit-> whoever is "administrating" the -devel mailing list please list themselves as an admin
[10:36:28] <noname^^> astrange, I see
[10:36:29] <pJok> mru, can't remember how long my "first" boot took... but i cleared the cache yesterday, pulled the battery out after 10 min and it booted fine right after
[10:37:12] <mru> benoit-: I've been clearing out the spam from the moderation queue from time to time, since none of the listed admins bothered
[10:37:22] <pJok> mru, rather odd feature about android aparantly
[10:37:47] <elenril> siretart: you want to branch the release before or after the big bump?
[10:37:51] <mru> pJok: I think the thing was just mighty confused for a while
[10:37:55] <benoit-> mru: that's fine, I just want you to be listed if you're doing it
[10:38:34] <pJok> mru, possibly... android is not quite there yet in terms of a really good phone os
[10:38:34] <mru> ok, I'll add myself
[10:38:56] <benoit-> thank you
[10:39:17] <noname^^> http://git.ffmpeg.org/?p=ffmpeg.git;a=commitdiff;h=b9d2085ba14aa733503ff02d966204992f46ff00
[10:39:23] <noname^^> "various resampling fixes"
[10:39:33] * mru wins
[10:39:35] <noname^^> :D
[10:39:39] * noname^^ gives mru a beer
[10:39:48] <DonDiego> benoit-: didn't you use to help with ml administration?
[10:40:19] <benoit-> DonDiego: I'm back at it
[10:40:35] <benoit-> I've been pretty busy for the last months
[10:41:00] <benoit-> DonDiego: I'm not doing it anymore for the -users ML though
[10:41:01] <mru> yeah, I noticed the moderation backlog...
[10:41:15] <benoit-> and it seems I was the only one who cared about it
[10:41:30] <benoit-> I don't think that michael or baptiste are doing it
[10:41:40] * mru cares
[10:42:08] <benoit-> so there were a lot of emails in the moderation list when I (sort of) came back to it
[10:42:11] <kshishkov> mru: that's because you're not admin. Become one and you'll stop.
[10:43:43] <benoit-> mru: cool
[10:44:34] <DonDiego> benoit-: would you be willing to work as ml moderator/admin (again)? it would be very helpful and appreciated...
[10:45:01] <lu_zero> av500: poing
[10:48:13] <siretart> mru: pong
[10:48:52] <mru> siretart: did you read the discussion about bumping major versions?
[10:48:57] <siretart> elenril: TBH, I'd prefer to include the bump, because not doing so will make backporting patches to the release branch harder. AFAIUI the bump won't destabilise the tree by itself
[10:49:16] <siretart> mru: just reading the backlog
[10:49:20] <mru> good, we agree
[10:51:52] <cartman>         int uvdxy;              /* no, it might not be used uninitialized */
[10:51:55] <cartman> heh
[10:52:52] <siretart> btw, I like the release code name "The Big Bump" :-)
[10:53:19] <mru> +1
[10:53:40] <kshishkov> mru: you don't like codenames anyway
[10:54:33] <mru> I don't like it when undocumented codenames are the primary identification used by people
[10:55:02] <Dark_Shikari> undocumented?
[10:55:14] <mru> Dark_Shikari: exactly what is "debian kenny"?
[10:55:23] <av500> sw that dies often
[10:55:28] <mru> and why does it not allow a bug to be fixed?
[10:55:29] <cartman> mru: possibly my friend
[10:55:59] <Dark_Shikari> Kenny?
[10:55:59] <Dark_Shikari> WTF?
[10:56:03] <cartman> Lenny
[10:56:04] <cartman> :P
[10:56:05] <siretart> you killed kenny, you bastards!
[10:56:10] <Dark_Shikari> Lenny is a release name
[10:56:13] <Dark_Shikari> Like Hardy Heron
[10:56:15] <Dark_Shikari> or Maverick
[10:56:20] <cartman> or Masturbating Monkey
[10:56:21] <cartman> etc.
[10:56:25] <Dark_Shikari> That's not undocumented.
[10:56:26] <mru> at least the ubuntu ones are in alphabetical order
[10:56:34] <kshishkov> mru: it's well-known fact that Debian has sponsored Toy Sotry 3 to get a source for new codenames
[10:56:42] <Dark_Shikari> You complain about all codenames, even documented ones
[10:56:45] <av500> Dark_Shikari: so, can I put Kenny on Sandy?
[10:56:47] <Dark_Shikari> you don't like penryn, conroe, nehalem, sandy bridge, etc
[10:56:53] <mru> no, I don't
[10:57:01] <cartman> there is i3 i5 i7 :P
[10:57:06] <mru> it's impossible to tell which is more recent without memorising the full list
[10:57:07] <av500> or does Sandy need HArdy?
[10:57:19] <mru> Sandy Salamander
[10:57:25] <siretart> av500: sandy requires natty
[10:57:28] <cartman> everybody needs a sane versioning system
[10:57:31] <kshishkov> cartman: but 80186 precedes i386 which precedes i7 :P
[10:57:33] <av500> how naughty
[10:58:08] <mru> and then there's the debian stable/unstable thing
[10:58:28] <kshishkov> well, version of something = MD5 of all its sources would be good
[10:58:30] <av500> mru: no "next"?
[10:58:35] <mru> it's fine for debian people to talk like that with each other, but it bothers me when they do it to outsiders
[10:58:40] <av500> kshishkov: thats the git revision
[10:58:46] <mru> av500: nope, debian lives in the past
[10:59:57] <kshishkov> av500: it can be applied to hardware as well since it has blueprints in electronic form
[11:00:17] * siretart is mildly annoyed that Debian 6.0 (AKA 'squeeze') will be shipped with FFmpeg 0.5 :-/
[11:00:42] <cartman> siretart: they ship a version that can decode PNG and animated gifs
[11:00:46] <Dark_Shikari> siretart: it's debian
[11:00:51] <kshishkov> siretart: well, Debian competes with FFmpeg in release delay terms
[11:01:00] <elenril> siretart: can you imagine debian stable not having a lolold ffmpeg?
[11:01:07] <Dark_Shikari> If debian shipped packages new enough to be useful to someone, they would have to change their name.
[11:01:12] <Dark_Shikari> to something like "ubuntu" or "arch".
[11:01:53] <mru> debian needs more qualifiers for their versions: testing, unstable, stable, decomposed, petrified...
[11:02:05] <siretart> at least debian delivers a suitable environment to develop on ffmpeg
[11:02:18] <Dark_Shikari> so does a 3 year old version of cygwin
[11:02:25] <Dark_Shikari> that's not a very good resume item
[11:02:37] <cartman> just use your bare (or bear) hands
[11:02:41] <kshishkov> mru: what's wrong with their default "stale" and "unusable" statuses?
[11:02:45] <lu_zero> why are we picking on debian today?
[11:02:47] <DonDiego> siretart: why 0.5?
[11:02:58] <elenril> wtf, ffmpeg uses FF_API?
[11:03:03] <kshishkov> lu_zero: wanna picks on Gentoo?
[11:03:23] <elenril> lu_zero: because flaming about the revolution got old
[11:03:39] <siretart> DonDiego: too much breakage in depending packages, and "it would have delayed the freeze"
[11:03:56] <lu_zero> elenril: I'd use change instead of revolution
[11:04:08] <lu_zero> and it would be great if that's the reason
[11:04:23] <mru> reminds of the time jörg schilling demanded that a fix in the linux scsi drivers be reverted because cdrecord was in release freeze and depended on the bug
[11:04:31] <lu_zero> kshishkov: I had my share of debian vs gentoo already
[11:04:39] <siretart> yeah, that sounds like joerg
[11:05:11] <kshishkov> lu_zero: is it true that lamps belonging to Gentoo users emit faster light?
[11:05:11] <mru> of course he got nothing but ridicule
[11:05:45] <mru> lu_zero: where did this idea about gentoo being only about OMG FAST come from?
[11:05:46] <lu_zero> kshishkov: only if painted in red and if the users have a green skin
[11:05:52] <kshishkov> mru: he should have demanded that fro M$ instead and probably he would get it
[11:06:05] <lu_zero> mru: kids trying that and spreading the voice
[11:07:14] <kshishkov> lu_zero: is supercomputer speed now measured in "emerge world" per second?
[11:07:29] <lu_zero> kshishkov: nope
[11:07:30] <Dark_Shikari> you mean per day
[11:07:35] <lu_zero> emerge system
[11:07:48] <lu_zero> Dark_Shikari: emerge world could take seconds
[11:08:06] <lu_zero> @world is a set that could be quite small
[11:08:46] <Kovensky> 08:05.45 mru: lu_zero: where did this idea about gentoo being only about OMG FAST come from? <-- CFLAGS="-O9001 -vomit-frame-pointer -fomg-fast"
[11:09:16] <kshishkov> lu_zero: do you think Dark_Shikari will ever install Gentoo?
[11:09:26] <lu_zero> kshishkov: probably
[11:09:31] <thresh> funroll-loops.info is awesome indeed
[11:09:32] <Dark_Shikari> mru: http://funroll-loops.info/
[11:09:44] <mru> yes, I've seen it
[11:09:44] <Dark_Shikari> read every single thing on that page, now
[11:10:19] <mru> look, I use gentoo mostly because it lets me not have a fucking gnome dependency on _everything_
[11:10:31] <mru> and because the init system is sane
[11:10:46] <kshishkov> and because it's still not complete BSD
[11:11:07] <mru> bsd is stuck in 1995
[11:11:14] <kshishkov> that new?
[11:11:38] * elenril kicks freenode
[11:11:59] <Kovensky> 08:11.07 mru: bsd is stuck in 1995 <-- can we blame schilling for that too? can we? can we?
[11:12:04] <Kovensky> (he's a freebsd maintainer)
[11:12:20] <mru> isn't schilling in love with solaris?
[11:12:27] <pJok> Kovensky, probably a lot of people you can blame for that
[11:12:40] <Kovensky> I wonder how will bsd deal with C1x
[11:12:45] <Kovensky> bsd can barely deal with c99
[11:12:46] <mru> I like DonDiego's observation about bsd
[11:12:53] <pJok> when is the release date for ffOS?
[11:12:57] <KotH> mru: schillings relation to solaris is better described by the old EAV song "fata morgana" :)
[11:14:05] <av500> KotH: eav, lol
[11:14:39] <Kovensky> mru: which were...?
[11:15:47] <av500> # of BSDs approaches # of BSD users over time
[11:16:38] * av500 is reminded that the BSD guy that sat next to him at GSOC summit was a guy with a beard
[11:16:59] <elenril> wow, lavf almost builds after a bump
[11:17:02] <cartman> av500: and?
[11:18:28] <wbs> j-b: nice question on vlc/amr ;P who told him to forward his question to us?
[11:18:40] <j-b> clearly not me
[11:18:43] <elenril> haha
[11:18:46] <wbs> j-b: I guess it is fixable, if someone says which parts of the amr support in lavf needs improving
[11:19:18] <elenril> his usage of gpg is inconsistent with his level of cluelessness
[11:19:18] <j-b> wbs: although I believe raw amr is demuxed by lavf, if it is inside a 3gp, I am quite sure the fault is ours.
[11:20:00] <wbs> j-b: I guess he means raw amr
[11:20:08] <j-b> wbs: you guess too much :)
[11:20:17] <wbs> j-b: yeah, I know :-)
[11:20:22] <j-b> wbs: the guy doesn't even mention his VLC version
[11:20:38] <j-b> 1.1.7 has AMR-NB and WB support, while 1.0.5 has almost nothing...
[11:20:41] <kshishkov> wbs: for raw AMR you have constant bitrate, don't you? So no problem at all
[11:20:57] <wbs> kshishkov: not necessarily, nothing stops you from having different modes in each block (iirc)
[11:21:04] <av500> kshishkov: no you need epic amr parser thread on -devel
[11:21:05] * kshishkov resists to mention multichannel WavPack support
[11:27:51] <j-b> wbs: anyway, someone can tell him: "we can do that: $1000"
[11:28:41] <wbs> j-b: :-)
[11:30:06] <j-b> wbs: what? not expensive enough?
[11:30:16] <kshishkov> j-b: hire mru for that then
[11:30:32] <kshishkov> it should be the sweet spot
[11:32:25] <DonDiego> kshishkov: there, first xxan review...
[11:33:00] <wbs> j-b: you clearly have more guts in demanding consulting fees than I do :-)
[11:33:19] <DonDiego> Dark_Shikari: nit: the _deps hunk in your configure change for avx is not in alphabetical order
[11:34:03] <DonDiego> av500: hey, copyright of that bsd joke is mine!
[11:34:34] <av500> DonDiego: yes, I just reproduced it
[11:34:41] <av500> [12:12:46] <mru> I like DonDiego's observation about bsd
[11:34:54] <{V}> av500, did you check the license? :p
[11:35:17] <mru> yay, more recruitment spam
[11:35:28] <av500> {V}: no, I am stronger
[11:35:46] <j-b> wbs: well, one day of your time is at least 700EUR/day
[11:35:52] <mru> for "a major broadcasting company in West London" looking for "strong C++ knowledge (Boost libraries, Memory management etc) as well as having a working knowledge of Flash"
[11:36:00] <wbs> j-b: true
[11:36:06] <wbs> mru: sounds exactly like you then ;P
[11:36:39] <av500> mru: demand london city payment
[11:36:55] <av500> and boni
[11:37:10] <j-b> wbs: small addition to a format in lavc/lavf, is worth at least 500EUR. Important feature is at least 5000EUR. RE of a codec is 10000EUR minimum. Except for bink
[11:37:44] <wbs> j-b: true
[11:37:47] <kshishkov> DonDiego: it's funny but most your nits are related to the function I reused from xan_wc3
[11:38:02] <av500> kshishkov: so, you blindly copy pasted
[11:38:11] <cartman> ClipboardInheritance
[11:38:24] <kshishkov> av500: nope, look at libavcodec/xan.c for original one
[11:38:53] <Dark_Shikari> DonDiego: someone else will need to muck with configure anyways
[11:38:57] <Dark_Shikari> I don't know crap about bash/configure/etc
[11:39:07] <mru> this is not bash :)
[11:39:08] <DonDiego> kshishkov: :) - the const stuff as well?
[11:39:13] <j-b> DonDiego: well, .amr is directly lavf, :D
[11:39:51] <Dark_Shikari> mru: same shit
[11:41:32] <kshishkov> DonDiego: almost - look at libavcodec/xan.c
[11:43:05] <CIA-38> ffmpeg: Benjamin Larsson <benjamin at southpole.se> master * raa42cce57d ffmpeg/libavformat/isom.c:
[11:43:05] <CIA-38> ffmpeg: Add AVC-Intra identifiers used by Flip4Mac for mov files
[11:43:05] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[11:43:06] <DonDiego> well, time to clean up that stuff as well then :)
[11:43:10] <CIA-38> ffmpeg: Tomas Härdin <tomas.hardin at codemill.se> master * rf5b82f45dc ffmpeg/libavcodec/avcodec.h:
[11:43:10] <CIA-38> ffmpeg: Add CODEC_ID_PRORES and bump lavc minor version
[11:43:10] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[11:43:12] <CIA-38> ffmpeg: Tomas Härdin <tomas.hardin at codemill.se> master * r75fd0668df ffmpeg/doc/APIchanges:
[11:43:12] <CIA-38> ffmpeg: Add APIchanges entry for lavc 52.109.0
[11:43:12] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[11:43:13] <CIA-38> ffmpeg: Tomas Härdin <tomas.hardin at codemill.se> master * re65b1934bf ffmpeg/libavformat/isom.c:
[11:43:13] <CIA-38> ffmpeg: Add ProRes FOURCCs to isom.c
[11:43:13] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[11:43:30] <DonDiego> merbanan: so is prores progressing?
[11:43:35] <kshishkov> DonDiego: go for it!
[11:44:26] <j-b> wbs: I'll mail the guy privately, so we'll know where the fix should be.
[11:44:36] <kshishkov> DonDiego: also second patch is independent, feel free to queue
[11:46:17] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r9ad4c65f6f ffmpeg/libavformat/rtmpproto.c:
[11:46:17] <CIA-38> ffmpeg: rtmpproto: rename URLContext* argument in rtmp_write()
[11:46:17] <CIA-38> ffmpeg: Now the first argument is URLContext *h. However, the function logs to
[11:46:17] <CIA-38> ffmpeg: LOG_CONTEXT, which is #defined as 's' for new lavf major versions.
[11:46:17] <CIA-38> ffmpeg: Therefore, rename h -> s.
[11:46:18] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[11:46:35] <DonDiego> kshishkov: i don't have a working ffmpeg git setup here at work, but please feel free to ping somebody else
[11:46:40] <Dark_Shikari> mru: write my configure stuff, I'll fix the rest
[11:47:15] <mru> Dark_Shikari: answer my question about ssse3
[11:47:29] <Dark_Shikari> done on ml
[12:00:34] <elenril>  19 files changed, 5 insertions(+), 585 deletions(-)
[12:00:35] <elenril> nice
[12:00:50] <mru> ?
[12:00:55] <elenril> lavf major bump
[12:01:18] <DonDiego> elenril: can you post numbers for the other version bumps as well?
[12:01:33] <elenril> i'm not sure i should do lavc, i have zero experience with it
[12:02:15] <DonDiego> in theory you should just have to remove #ifdefs and bump the number
[12:02:25] <DonDiego> see if it compiles if you bump the number
[12:04:59] <elenril> in theory
[12:05:33] <elenril> won't -mt introduce new incompatible changes?
[12:08:12] <elenril> bleh, tons of incompatibilities because of moves lavc->lavcore
[12:08:17] * elenril glares at saste 
[12:08:52] <kshishkov> elenril: if you by any chance think lavcore was not a good idea I agree with you
[12:09:06] <DonDiego> well, let's just reunify libavutil and libavcore again
[12:09:20] <DonDiego> i think nobody except michael liked that split anyway...
[12:09:38] <elenril> not many people will like us breaking api again
[12:09:45] <cartman> indeed
[12:09:59] <mru> libavcore was never in a release
[12:10:07] <cartman> good point
[12:10:08] <cartman> :p
[12:10:22] <elenril> we don't gain anything significant by merging it with lavu
[12:10:29] <elenril> except new incompatibilities
[12:11:03] <kshishkov> better tab completion
[12:11:05] <mru> we reduce library proliferation
[12:11:09] <DonDiego> we spare users an api change
[12:11:10] <kshishkov> less libraries
[12:11:18] <lu_zero> or we could but we could discuss in the ml
[12:11:28] <lu_zero> and hopefully get input from the users
[12:11:34] <mru> of course we could
[12:11:36] <elenril> DonDiego: those api changes were needed anyway
[12:11:38] <lu_zero> (so poll also libav-users)
[12:11:39] <elenril> they add av_ prefix
[12:11:57] <DonDiego> that i don't disagree with
[12:12:13] <DonDiego> merge libs, add prefixes, bump major...
[12:13:33] <elenril> i know -- let's vote!
[12:13:35] * elenril is shot
[12:13:45] <kshishkov> elenril: yep, that was a good vote
[12:26:58] <DonDiego> vote with your shotgun? :)
[12:27:13] <DonDiego> i thought we had already voted with our feet recently..
[12:27:44] <kshishkov> well, I'm Ukrainian, I hate voting
[12:28:14] <merbzt> DonDiego: from the info I have yes
[12:28:23] <mru> kshishkov: then use shovel
[12:29:58] <kshishkov> mru: why not?
[12:30:30] <kshishkov> especially since shovel is less suspicious than shotgun, doesn't run of ammo and doesn't need silencer
[12:30:36] <kshishkov> *out of ammo
[12:31:12] <av500> its a bit more limited in range
[12:31:48] <kshishkov> you can throw it too
[12:32:02] * av500 watches how vlc and ff devs blame each other instead of helping poor users
[12:33:03] <Kovensky> I thought you ex-soviets preferred hammers and sickles
[12:33:13] <mru> av500: it's the first step towards forming a proper government
[12:33:27] <av500> Kovensky: both have been collected and used to forge new shovels
[12:33:39] <Compn> http://abstrusegoose.com/strips/ars_longa_vita_brevis.PNG
[12:33:50] <JEEB> that reminds me of a certain Soviet-related joke
[12:34:07] <Kovensky> hammers are better for throwing
[12:34:13] <Kovensky> but I suppose nothing beat a norse axe
[12:34:35] <mru> thor's weapon of choice was a hammer...
[12:34:45] <av500> Kovensky: shovel is much more versatile
[12:35:01] <Compn> are you going to see the new thor movie mru ?
[12:35:26] <kshishkov> Compn: so you need only 3627 additional days compared to book and ~11000 days to fix that?
[12:35:41] <mru> Compn: based on the comic book?
[12:35:55] <Compn> mru : yes
[12:36:02] * mru never read the comics
[12:36:05] <Compn> kshishkov : i have no idea
[12:37:04] <kshishkov> mru: why? you're American, you're supposed to read comics (if not them who else?)
[12:37:22] <mru> do I _look_ american?
[12:37:29] <mru> so I sound american?
[12:37:31] <mru> do
[12:38:07] <cartman> whoa
[12:38:29] <Compn> mru has a circle above an a in his name, americans dont go for that
[12:38:39] <Compn> no extra circles and such in our letters
[12:38:44] <mru> two As in fact
[12:39:10] <mru> it is true that I have a US passport, but that's just to get across the border with less hassle
[12:39:20] <cartman> that surely helps
[12:48:21] * Kovensky is reminded of that email exchange that decides that å is not cool, it's hot
[12:50:27] <DonDiego> mru has always reminded me of a viking - just give him a hammer instead of an axe and he will look like thor....
[12:53:38] <kshishkov> mru: well, I'm from the part of the world where your documents define who you are
[12:55:29] * mru waves a swedish passport in front of kshishkov 
[12:55:39] <mru> that one helps getting across other borders
[12:55:53] <elenril> can you make one for me too?
[12:56:00] <JEEB> herp, American borders
[12:56:04] <JEEB> Got to hate them
[12:56:09] <wbs> mru: how do you get a us passport?
[12:56:19] <mru> sssh
[12:56:23] <JEEB> serving in the US military?
[12:56:26] <cartman> ssh?
[12:56:32] <wbs> cartman: lol
[12:56:33] <av500> hmm, sure looks like A with circle on top to me: http://imagebin.org/135956
[12:56:48] <JEEB> yah, it's a "Swedish O"
[12:57:06] <JEEB> lol
[12:57:07] <kshishkov> JEEB: reused in many countries
[12:57:26] <JEEB> We have it in our alphabet purely to write the Swedish surnames :3
[12:57:30] <mru> av500: what did you search for to find that?
[12:57:41] <av500> mru: gimp
[12:57:53] <kshishkov> av500: was that the first hit?
[12:58:15] <av500> kshishkov: like bing, I do not comment on my search results
[12:58:33] <av500> excet that they are 100% geniune
[12:58:38] <av500> +spelling
[12:58:57] <cartman> Did you mean _except_?
[12:59:29] <av500> _yes_
[13:00:56] <kshishkov> av500: have you ask your kid to do search?
[13:00:59] <cartman> bureaucracy takes so looooong time
[13:01:13] <kshishkov> cartman: nope, it takes _all_ time
[13:01:28] <kshishkov> cartman: read about Parkinson's law
[13:01:41] <cartman> kshishkov: Hopefully will finish before I die
[13:02:08] <cartman> Work expands so as to fill the time available for its completion.
[13:02:11] <cartman> LOL
[13:02:35] <av500> kshishkov: as said, I types gimp into command line
[13:02:38] <av500> typed
[13:03:47] <Kovensky> cartman: the bureaucracy expands to fulfill the needs of the expanding bureaucracy
[13:04:06] <mru> whose law is that?
[13:04:17] <cartman> mru: Parkinson's Law as kshishkov pointed out
[13:04:25] <Kovensky> it's some quote that appears on civilization 4 once you research code of laws (I think) :)
[13:04:41] <mru> hehe
[13:05:09] <kshishkov> mru: his book is definitely one of the best British books ever written
[13:05:43] * av500 nominates kshishkov as assistant chairman of the subcommitte for the redesign of the ffmpeg-devel minor patch submit form
[13:06:39] <kshishkov> av500: as another British author put it, committes are just a form of isolating people from activity
[13:06:58] <elenril> bleh, lavc is full of breakage on bumping major
[13:07:17] <elenril> anyone with more experience than me wants to look at it?
[13:07:46] <kshishkov> mru: and I really recommend you reading his book
[13:09:10] <mru> does it say something I don't already know?
[13:09:19] <kshishkov> could be
[13:09:45] <Kovensky> isn't Parkinson the one that wrote down the bikeshed example
[13:10:06] <kshishkov> yes, it's him
[13:12:13] * mru is reminded of the time it took nds to put up a second bikeshed...
[13:13:07] <DonDiego> elenril: maybe you can pastebin the result of 'make -k'
[13:13:18] <KotH> mru: did they paint it?
[13:13:45] <kshishkov> KotH: not yet
[13:13:46] <mru> no, the walls are polycarbonate or something
[13:15:11] <kshishkov> mru: please read http://en.wikipedia.org/wiki/The_Dilbert_Principle
[13:15:29] <kshishkov> the last sentence in first abstract at least
[13:15:44] * KotH wants a paint bucket with red-viollet with yellow-green dots colour in it
[13:17:46] <elenril> ok, it doesn't seem so bad after all
[13:18:11] <elenril> the only thing i'm not sure what to do about is AVCodecContext.request_channels
[13:18:31] <mru> what about it?
[13:18:36] <elenril> it's deprecated
[13:18:42] <mru> undeprecate it
[13:18:57] <mru> ah, it's replaced by the _layout version
[13:19:06] <mru> which carries more information
[13:19:07] <elenril> is _layout the same thing?
[13:19:22] <mru> first one is number of channels, second also includes order
[13:19:43] <elenril> but are they compatible
[13:19:50] <mru> not really
[13:20:11] <mru> request_channels is a number, _layout a bit mask
[13:20:39] <mru> there are many ways you can end up with, say, 3 channels
[13:21:01] <elenril> ah, ok
[13:21:07] <mru> 2f1r, 3f, and 2f+lfe all being used
[13:21:13] <elenril> btw don't apply the patch i just sent
[13:21:15] <kshishkov> that reminds me of combinatorics for some reason
[13:21:29] <elenril> the one with CH_* renaming
[13:21:33] <mru> ok
[13:21:40] <elenril> it's missing some headers which break on major bump
[13:26:05] <CIA-38> ffmpeg: Martin Storsjö <martin at martin.st> master * r1f56f5ed6d ffmpeg/libavformat/sapenc.c:
[13:26:05] <CIA-38> ffmpeg: sapenc: Free AVStream->info on cleanup
[13:26:05] <CIA-38> ffmpeg: This fixes yet another memory leak, present since SVN rev 25418.
[13:26:05] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:34:58] * elenril spams the ML some more
[13:35:07] <elenril> ok, now only the request_channels problem remains
[13:36:12] <elenril> anybody feels like fixing it?
[13:36:23] <kshishkov> merbzt should
[13:36:29] <mru> fixing it fully is non-trivial
[13:39:27] <elenril> or we can postpone it to next major bump if everybody's too lazy
[13:39:40] <kierank> elenril: can you fix metadata with weird characters in ts files
[13:40:04] <elenril> "weird characters"?
[13:40:06] <elenril> samples?
[13:40:48] <kierank> i'll see if i can find one i can shre
[13:41:06] <kierank> or maybe it was a problem with my shell
[13:41:39] <elenril> and i didn't ever touch the ts stuff, so i don't know how metadata works in it
[13:42:48] <kierank> I think ts uses a different character map
[13:43:19] <av500> yes, there are some wierd char maps
[13:43:41] * kierank blames all the weird languages
[13:43:49] <mru> dvb uses some obscure maps sometimes
[13:44:06] * kierank also blames people with funny characters in their name
[13:44:08] <av500> latin-5
[13:44:26] <mru> ever had to deal with hebrew text in dvb?
[13:44:33] <av500> mru: nope
[13:44:38] <av500> only on tags
[13:44:40] <av500> in
[13:44:46] <kierank> mru: must have been commonplace at nds i guess
[13:45:06] <mru> they have/had customers in israel
[13:45:43] <kshishkov> kierank: ever heard about Cyrillic?
[13:46:01] <kierank> kshishkov: yes but as a true brit I ignore all foreign langauges
[13:46:32] <mru> kierank: so do I, but my definition of foreign is a little different
[13:46:45] <elenril> saste: did you finish adding av_ prefixes to audio stuff in lavf?
[13:47:21] <kshishkov> mru: inte Älvdalska?
[13:47:32] <mru> kshishkov: I don't speak that
[13:47:34] <jannau> DVB defaults to iso 6937
[13:48:21] <saste> elenril: no, I just did that as I was moving stuff from lavc -> lavcore
[13:48:35] <kshishkov> mru: Orsamål?
[13:48:36] <saste> elenril: but major work need to be done with the audio API anyway
[13:48:49] <saste> elenril: so prefixing could go with that...
[13:48:49] <mru> kshishkov: that I understand, not speak
[13:48:55] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * r151595fe2e ffmpeg/libavcodec/amrwbdec.c:
[13:48:55] <CIA-38> ffmpeg: Rename remaining occurrences of SAMPLE_FMT_* to AV_SAMPLE_FMT_*
[13:48:55] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:49:05] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * rb2ed95ec48 ffmpeg/ (5 files in 2 dirs):
[13:49:06] <CIA-38> ffmpeg: Replace remaining occurrences of CODEC_TYPE_* with AVMEDIA_TYPE*
[13:49:06] <CIA-38> ffmpeg: Tested to compile with lavc major bump.
[13:49:06] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:49:07] <CIA-38> ffmpeg: Anton Khirnov <anton at khirnov.net> master * ra9d921cbad ffmpeg/libavformat/tty.c:
[13:49:07] <CIA-38> ffmpeg: tty.c: rename PKT_FLAG_KEY to AV_PKT_FLAG_KEY.
[13:49:07] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:49:30] <elenril> saste: well i'm wondering if it should be removed now or postponed until next major bump
[13:49:51] <saste> elenril: what do you want to remove?
[13:50:31] <elenril> all the deprecated stuff under FF_API_AUDIO_OLD
[13:50:54] <kierank> lol someone made subs for the troll film using google translate
[13:51:02] <kshishkov> mru: be glad you don't live in Hungary. Their equivalent to word "skål" would make one sober
[13:51:21] <mru> kshishkov: btw, I do speak Moramål
[13:51:34] <kshishkov> kierank: that's traditional way of subbing movies and games
[13:51:34] <saste> elenril: major bump or you break applications linked to the old libavcodec
[13:51:59] <kshishkov> mru: well, I just misplaced your location then
[13:52:19] <mru> in that region, every street has its own dialect
[13:52:20] <elenril> saste: well yes, that's why i'm doing it
[13:52:28] <elenril> we think it's time for a big bump
[13:52:44] <kshishkov> mru: that's no problem for me
[13:52:49] <saste> of all the libs?
[13:53:02] <mru> that's why it's big
[13:54:23] <saste> there is a problem in error.h.. AVERROR(EINVAL) and AVERROR_INVALIDDATA share the same code
[13:54:39] <saste> I proposed a "big bump" sometimes ago for resolving that problem
[13:54:47] <saste> note that michael was against
[13:55:02] <saste> but if we want to go for that then that problem should be fixed
[13:55:39] <kshishkov> patchiswelcome
[13:55:43] <saste> indeed changing the error code in libavutil is going to change the behavior of all the depending libs
[13:56:33] <mru> lavc was last bumped in 2008
[13:57:38] <siretart> saste: what's the status of lavfi-audio? - I'd like to see your changes to the API included before the big bump.
[13:58:01] <saste> siretart: what's your schedule
[13:58:14] <kshishkov> mru: and what was release gap between 0.4.9 and 0.5.0?
[13:58:21] <siretart> saste: I'm trying to make one :-)
[13:58:26] <saste> siretart: I'm quite busy and those changes need some thought
[13:59:24] <siretart> saste: ok. I think march or april would be okay, however it seems that people here seem to be pretty keen on merging -mt, which i'd prefer to happen after branching off 0.7
[13:59:49] <mru> lavf last bump was in 2007
[13:59:57] <saste> siretart: it may take some weeks or some months..
[14:00:16] <saste> siretart: but maybe for march / april may be ready
[14:00:26] <DonDiego> siretart: what about declaring libavfilter API unstable?
[14:00:38] <saste> DonDiego: already is
[14:00:59] <DonDiego> we can leave it out of the release also
[14:01:01] <siretart> DonDiego: is it really such a big deal to promise bumping major of avfi for api/abi breaks?!
[14:01:29] <DonDiego> or say it's unstable and merely include it with a promise that code written against it will soon break
[14:02:30] <saste> I don't see the problem with the second approach.. it is what we did for 0.6
[14:03:35] <siretart> AFAIR, avfi did not break interfaces from 0.5->0.6. however, it didn't hardly matter. now with 0.7, I expect avfi to do matter
[14:04:04] <siretart> err, I think you get what I meant to write
[14:06:09] <tetsuo55> mt merge is going to kill me :P
[14:06:15] <tetsuo55> but im happy for it
[14:06:32] <lu_zero> tetsuo55: why?
[14:06:50] <tetsuo55> lu_zero:  it will most probably become incompatible with the DXVA1 patches we apply
[14:07:07] <tetsuo55> i believe we don't already use the -mt because of that
[14:07:12] <kierank> tetsuo55: that's not true
[14:07:28] <kierank> there are two version of ffmpeg in mpc-hc
[14:07:43] <kierank> one which is torn apart in order to do the h.264 handling
[14:07:48] <kierank> and a near-vanilla one
[14:07:50] <tetsuo55> sure, but the mt version is only used as an optional backup for failing dxva
[14:09:19] <tetsuo55> too bad casimir isnt around to help port over DXVA1 support to the already existing DXVA2 code
[14:10:35] <siretart> I guess that as soon as -mt is merged, this problem will be resolved within a reasonable timeframe
[14:11:41] <tetsuo55> maybe it will make the changes more urgent
[14:12:14] <tetsuo55> we're tired of having so many patches over ffmpeg for our directshow fork, its time to clean house and and use an as vanilla as possible ffmpeg
[14:12:24] <elenril> ok, all the cruft removed
[14:12:30] * elenril wonders how many things did he break
[14:14:04] <tetsuo55> kierank: we've voted on removing any remainng code to make lavc compile with msvc, so once everyone replies and agrees it will be easier to use vanilla
[14:14:22] <kierank> finally
[14:15:11] <tetsuo55> nobody ever does it anyway, just test the file in ffplay and its clear which part of the code is at fault
[14:16:14] <tetsuo55> even if ffmpeg new management did want to be able to compile with msvc officially, we've only patched a tiny amount of the total codebase
[14:17:10] <lu_zero> tetsuo55: the stance had always being that we try to not break msvc, but the ffmpeg target is a c99 compiler (and system headers)
[14:17:39] <tetsuo55> lu_zero: yes and i assume it will remain that way
[14:17:51] <lu_zero> so if your changes aren't invasive or not break other systems
[14:17:57] <kierank> merbzt: find anybody to do h264 422 yet?
[14:17:57] <Kovensky> MSVC has got stdint now
[14:17:59] <Kovensky> but no inttypes yet
[14:18:39] <lu_zero> they won't be rejected just because they are msvc-related
[14:19:00] <lu_zero> but might be rejected because they break other supported platforms
[14:19:26] <lu_zero> anyway if you have a public repo for your changes we could add it to the website
[14:19:39] <Kovensky> idk, I've seen mingw compatibility changes being rejected before just because
[14:20:10] <mru> nothing was ever rejected just because
[14:20:17] <lu_zero> Kovensky: which ones?
[14:20:19] <tetsuo55> would full support of C++0x in msvc solve any incompatibilities it currently has with c99 specific code?
[14:20:35] <lu_zero> tetsuo55: might add more =|
[14:20:37] <mru> but dirty, invasive hacks to support a non-standard platform are rarely accepted
[14:20:50] <tetsuo55> it says on wikipedia they target backwards compatibility with c98 not c99
[14:21:29] <lu_zero> tetsuo55: if they provide system headers probably there would be less problems
[14:21:41] <Kovensky> well yes, but such a platform (which despite the non-standardness is the only one available to run the software on a major OS (cygwin and virtualization don't count)) might require those dirty hacks to work at all
[14:22:09] <lu_zero> Kovensky: hopefully not
[14:22:13] <kshishkov> tetsuo55: of course, who've ever heard about win99?
[14:22:21] <Kovensky> well, the biggest culprit is usually pthread-w32
[14:22:32] <Kovensky> not really mingw
[14:22:46] <lu_zero> (said the guy who replaced the bada headers to build ffmpeg)
[14:23:04] <Kovensky> but in order to, for example, support unicode filenames on windows, you need special casing for all filesystem calls
[14:23:22] <Kovensky> I remember someone (ramiro? TheFluff?) was working on something like that but it was dropped on bikeshedding
[14:23:26] <mru> that gets really ugly really quickly
[14:23:42] <lu_zero> Kovensky: macro-renaming doesn't work?
[14:23:43] <mru> some things are just not worth supporting
[14:23:53] <Kovensky> lu_zero: no, you also need to do charset conversion
[14:24:23] <tetsuo55> this is our patched fork http://code.google.com/p/mpc-hc/source/browse/#svn%2Ftrunk%2Fsrc%2Ffilters%2Ftransform%2FMPCVideoDec%2Fffmpeg%2Flibavcodec
[14:24:30] <tetsuo55> unfortunately google code search is broken
[14:24:38] <tetsuo55> so i cannot single out our patches
[14:24:53] <mru> I'd like to point out that we _do_ work around broken systems when this is possible in a clean way
[14:24:54] <tetsuo55> we dont host them seperately :(
[14:25:08] <mru> cf libavutil/libm.h
[14:25:28] <lu_zero> Kovensky: uhm?
[14:25:34] <lu_zero> tell me more
[14:26:15] <lu_zero> tetsuo55: would be great if you could host those changes in a git repo ^^;
[14:26:43] <Kovensky> lu_zero: mingw / msvcrt don't support unicode on the standard calls (fopen, printf, etc)
[14:26:58] <Kovensky> you need to use the 'w' variants and feed them UTF-16 strings for it to work
[14:27:18] <tetsuo55> lu_zero: it would wouldnt it :P
[14:27:33] <lu_zero> ^^;
[14:27:39] <Kovensky> and there's still the issue of the console; by default it will convert anything to the computer's default charset
[14:28:01] <Kovensky> you could just set the codepage to 65001 (secret, unmaintained UTF-8 codepage), but then the console has a few rendering errors
[14:28:20] <tetsuo55> most patches are marked with a comment like this  "Start patch MPC" "End patch MPC"  but the wording is not consistent, and there are also patches marked with ffdshow, and a few are unmarked. Many of them are DXVA related in h264 and VC1
[14:28:44] <tetsuo55> in our case we basically use a wrapper to translate directshow stuff to lavc stuff
[14:29:06] <tetsuo55> all the patches in the code itself only solve compiling errors and add dxva (in theory)
[14:29:25] <tetsuo55> the whole talking to windows part is handled by windows specific wrapper
[14:30:40] <tetsuo55> and the compiling with msvc is probably only interesting for us with regards to debugging those dxva patches
[14:31:04] <tetsuo55> ofcourse others might be interested in doing other stuff
[14:32:23] <lu_zero> uhmm
[14:32:37] <lu_zero> sounds quite hard to split them up =|
[14:32:44] <tetsuo55> im sorry the changes in our code are not ready to use patches, but the people who made them are all MIA, so its up to the remaining non-experts in this area to mark them and keep them when we update from ffmpeg git
[14:33:02] <kierank> blame clsid
[14:33:05] <tetsuo55> thats also one of the mainreasons we're voting for deleting them
[14:33:16] <tetsuo55> kierank:  yes hes a big cause, he refuses to mark them
[14:35:33] <tetsuo55> the project he works on ffdshow, is also responsible for creating most of the patches in the source i showed you, and since they use a slightly larger portion of lavc there are many more (unmarked) ones in their fodk
[14:35:34] <tetsuo55> fork
[14:36:02] <tetsuo55> all of them are to make lavc play nice with msvc and the directshow wrappers
[14:38:10] <tetsuo55> i dont have a link to the source due to sourceforge's stupidness
[14:41:09] <tetsuo55> lu_zero: maybe its better to start over, make a clean wrapper and then an as vanilla as possible ffmpeg inside that, and then work together on solving compiling errors
[14:41:41] <tetsuo55> the wrapper should not be comitted, but the compiler errors in ffmpeg code could be cleanly solvable
[14:41:44] <mru> tetsuo55: reformatting the code to your style rules doesn't help diffing...
[14:42:05] <tetsuo55> mru:  our project doenst do that
[14:42:15] <tetsuo55> mru:  must be ffdshow then :(
[14:42:58] <mru> look at e.g. r1783 in your svn
[14:43:09] <tetsuo55> that was reverted
[14:43:18] <tetsuo55> was a mistake
[14:43:26] <mru> ah, so I see
[14:44:22] <tetsuo55> we now have strict rules on thirdparty stuff, all changes must have a patch comment decleration (but ffdshow does not have this rule)
[14:44:44] <tetsuo55> and something like astyle may never be applied
[14:44:56] <tetsuo55> that formatting actually broke compilation becaue it messed with inline assembly
[14:44:57] <tetsuo55> :P
[14:46:02] <lu_zero> ^^;
[14:46:09] <DonDiego> tetsuo55: try uncrustify instead, works infinitely better than astyle
[14:46:57] <tetsuo55> thanks ill check that out
[14:51:29] <kierank> bye
[14:53:41] <elenril>  33 files changed, 44 insertions(+), 768 deletions(-)
[14:53:44] <elenril> ^lavc major bump
[14:56:06] <lu_zero> wow
[14:57:16] <kshishkov> heh, any mru can affect more files by simply adding FATE tests
[15:10:53] * elenril glares at kshishkov 
[15:10:57] <elenril> my patch is waiting
[15:14:58] <spaam> kierank: going to leave us? :(
[15:15:23] <kierank> spaam: no
[15:15:27] <kierank> was saying bye to michaelni
[15:15:29] <kierank> belatedly
[15:15:51] <spaam> he like to leave this channel
[15:33:27] <michaelni> uhm, where did my op status go?
[15:33:39] * michaelni kicks ChanServ
[15:34:00] <spaam> michaelni: you forgot to auth? :)
[15:34:16] <michaelni> fuck no
[15:34:22] <michaelni> i identified
[15:34:36] * michaelni kicks ChanServ harder
[15:34:43] <spaam> michaelni: try /msg chanserv op #ffmpeg-devel
[15:34:47] <kierank> yeah
[15:35:09] <michaelni> tried
[15:35:13] <iive> spaam: he got auto-op-ed in mplayer.
[15:35:19] <spaam> iive: i saw that
[15:37:05] * elenril does TheBigSpam
[15:37:39] <elenril> michaelni: what do you think about bumping major
[15:38:11] <michaelni> elenril, no objection but id like to look over what that changes and IMHO this should be discused on ML
[15:38:25] <elenril> sure, i just sent the mail/patches
[15:38:49] <elenril> it doesn't really change anything except LIBAV{CODEC,FORMAT}_VERSION_MAJOR++
[15:38:57] <elenril> and removing everything deprecated
[15:39:16] <iive> isn't major bumped after release?
[15:39:37] <elenril> our relese managers want to bump first, release after
[15:39:46] <spaam> elenril: can i haz some cheese with that?
[15:40:09] * michaelni guesses the new maintainers have decided to silently deop him
[15:40:27] <elenril> michaelni: IT'S THE CONSPIRACY!!!!!111one
[15:40:29] <iive> try with voice
[15:40:38] <michaelni> iive, ?
[15:40:42] <kshishkov> have you tried leaving and coming again?
[15:41:03] <DonDiego> michaelni is not in the access list, just checked
[15:41:22] <michaelni> DonDiego, is that intended? or mistake?
[15:41:32] <iive> well, that's deigo's channel.
[15:41:53] <DonDiego> i did not remove you, but i plain don't remember if you were ever added
[15:42:03] <DonDiego> you were never on irc, so...
[15:42:06] <benoit-> DonDiego: IIRC yes
[15:42:17] <michaelni> Dark_Shikari, gave me op i dont know if he added me to any lists
[15:42:17] <benoit-> he was in the access list
[15:43:01] <DonDiego> michaelni: if you are not in the access list, then op only lasts until you leave
[15:43:15] <DonDiego> michaelni: try leaving and entering again
[15:44:16] <michaelni> :))))))))))))))))))))))))))))))))))))))))))))))))
[15:44:29] <spaam> woho
[15:44:38] * michaelni loves ChanServ and ?DonDiego??? 
[15:44:40] <spaam> michaelni: going to celebrate? ;D
[15:45:02] * kshishkov writes that down to blackmail michaelni at appropriate occasion
[15:45:10] <michaelni> DonDiego, was that you who added me bak?
[15:47:02] <DonDiego> sure, who else?
[15:47:14] * michaelni thanks DonDiego 
[15:47:50] <DonDiego> np
[15:51:36] <michaelni> DonDiego, you have new mail :)
[15:54:44] * elenril waits for somebody using the gmail web client to bash him for spamming
[16:02:36] <j-b> Adding a field to AVCodecContext needs a minor API bump, right?
[16:02:53] <kshishkov> of course
[16:03:03] <j-b> Does it require a Changelog entry ?
[16:03:16] <elenril> yes
[16:03:16] <kshishkov> APIChanges
[16:03:21] <j-b> kshishkov: no Micro, then?
[16:03:22] <elenril> err yes
[16:03:44] <elenril> it'd be better if you removed some fields though ;)
[16:03:54] <kshishkov> j-b: nope, micro is for binary-compatible but slightly different things
[16:03:59] <michaelni> j-b, dont forget updating that AVOption list
[16:04:18] <michaelni> ... when you add a field or change things
[16:04:40] <j-b> elenril: sure :D
[16:04:46] <j-b> michaelni: got you
[16:05:46] <j-b> elenril: if it was my code, yes. But it isn't
[16:06:11] <j-b> kshishkov: APIChanges?
[16:06:49] <michaelni> doc/APIchanges
[16:07:14] * michaelni forgets one of these things normally when adding fields :)
[16:08:33] <j-b> got you. Info fwd-ed
[16:08:50] <j-b> thx guys
[16:10:57] * michaelni wonders if we could maybe drop doc/APIchanges and rather mark commit messages with a keyword and use git to generate it
[16:11:26] <michaelni> that also would work alot better with branches and multiple repos that have different hashes/versions
[16:11:32] <elenril> or we could use git tags
[16:11:38] <michaelni> yes
[16:12:02] * elenril wonders where did all the people who wanted to edit commit message disappear to
[16:12:28] <mru> shhh, don't wake them
[16:12:45] <michaelni> They probably think expelling me solved the problem
[16:13:08] <elenril> no more typos!
[16:13:30] <j-b> you could have a hook checking for common typos
[16:14:50] <lu_zero> michaelni: thanks for repeating what I was long ago
[16:15:15] <elenril> oh well, time for some quantum fields :/
[16:15:19] * elenril detaches
[16:15:23] <lu_zero> not thanks for twisting it to look like it is your idea and we are against it
[16:15:30] <kierank> elenril: you're attached and detached at the same time
[16:15:50] <michaelni> lu_zero, what!?
[16:15:54] <lu_zero> and demoting you solves more than a problem
[16:18:17] <michaelni> lu_zero, i dont remember tags/commit message keywords being discussed previously
[16:18:30] <michaelni> for a replacement of doc/APIchanges
[16:18:39] <michaelni> or did i misunderstand you?
[16:19:44] <lu_zero> I wrote an email with a proposal for tags mapping that apparently everybody agreed with at least in the idea
[16:20:05] <michaelni> lu_zero, do you remember the subject?
[16:20:12] <michaelni> so i can search ?
[16:21:05] <michaelni> i cant remember and id be surprised if i was against reducing work (i really hate) namely updating APIchanges
[16:21:41] <iive> are these tags something xml/doc specific, or git specific?
[16:21:51] <lu_zero> the whole APIchanges can be autogenerated indeed
[16:22:32] <michaelni> and instead of fighting whos idea it was (surely iam not the first who suggested it on this planet) we should rather discuss how t implemet it IMHO
[16:22:47] <spaam> git down on git.f.o?
[16:22:58] <spaam> nvm
[16:23:06] <spaam> i wrote fffmpeg ;S
[16:23:18] <lu_zero> too many f
[16:23:21] <lu_zero> michaelni: sure
[16:24:57] <lu_zero> anyway
[16:26:58] <kierank> spaam: that's what happens when you don't spell spam correctly
[16:27:12] <spaam> :(
[16:28:31] <DonDiego> go figure, i'm getting a videolan account now...
[16:28:41] <spaam> wow
[16:29:07] <michaelni> :)
[16:30:21] <iive> michaelni: i guess your wild whitespace days are over...
[16:37:56] <DonDiego> gtg, bye
[16:44:06] <lu_zero> I need a better way to show up tag messages
[16:44:21] <lu_zero> since I usually pick them with -n
[17:40:08] <BBB> astrange: ping again, can you please rebase your patch to master os I can compare to my tree and see why for you make fate fails and for me it doesn't?
[18:08:16] <mru> BBB: so on -mt, aside from this little bug, how much work to get vp8 multithreaded?
[18:16:52] <j-b>  wait a bit to give
[18:17:15] <j-b> users of the libs [...] a chance to comment...
[18:17:18] <j-b> that would mean us?
[18:19:28] <mru> was that a comment?
[18:30:24] <mru> damn... I went digging for euros and found a fat wad, only most of it was dollar notes
[18:36:18] <spaam> j-b: who else? :D
[18:53:48] <BBB> mru: not much
[18:53:57] <BBB> mru: I've got a volunteer to do it already maybe
[18:54:00] <BBB> mru: so don't work on it
[18:54:02] <BBB> mru: it'll be done
[18:54:17] <mru> I'm not doing anything, but ARM are keen to see it done
[18:54:19] <BBB> mru: get astrange to rebase patch so I can test further
[18:59:39] <j-b> mru: because someone is an "*SS" and thinks it is a clever design
[19:00:32] <j-b> spaam: like I care :)
[19:05:53] <lu_zero> j-b: uh?
[19:20:47] <j-b> ?
[19:25:36] * lu_zero re-reads the backlog
[19:26:09] <j-b> lu_zero: what part did "uh?" ?
[19:30:44] <lu_zero> 19:59 < j-b> mru: because someone is an "*SS" and thinks it is a clever design
[19:31:05] <j-b> lu_zero: oh, that's an explanation for mru than I cannot say on #videolan :)
[19:31:29] <lu_zero> I was trying to understand what's the design in question ^^;
[19:31:31] <lu_zero> brb
[19:31:49] <j-b> lu_zero: a stupid vlc design using thread cancellation
[19:44:41] <spaam> haahah
[19:44:45] <spaam> ops
[19:52:43] <lu_zero> I see..
[20:00:56] <j-b> lu_zero: it is a weird, but I cannot fight it, because I can't fix it/replace it. So I shut  up
[20:03:30] <j-b> is Nicolas George on IRC?
[20:08:20] <lu_zero> j-b: uh
[20:08:40] <mru> guy who sends patches on ml
[20:10:04] <lu_zero> the uh was about the part that is't unreplaceable
[20:10:49] <mru> it's not unreplacable as such
[20:10:56] <mru> but I guess j-b can't do it himself
[20:11:43] <j-b> lu_zero: it is a political decision, indeed. I cannot fight people on important parts of VLC, if I cannot do their work.
[20:14:13] <lu_zero> I see =|
[20:15:36] <j-b> lu_zero: but I believe mru is right here. A weird decision it is.
[20:27:06] <TheFluff> 15:23:22 < Kovensky> I remember someone (ramiro? TheFluff?) was working on something like that but it was dropped on bikeshedding <--- ramiro made a good patch that made it Just Work both on the commandline and in the API and had the switch enabling it as a configure flag
[20:27:17] <TheFluff> but mru didn't like it on vague grounds and so it never got committed
[20:27:33] <TheFluff> hence everyone on windows works around it by hijacking the file protocol handler
[20:27:37] <mru> it was a dreadful patch
[20:27:54] <mru> it used an environment variable to move information from one place to another
[20:28:10] <TheFluff> oh right it used an env variable that enabled or disabled it
[20:28:15] <mru> worse
[20:28:15] <TheFluff> the configure flag was mine
[20:28:20] <TheFluff> it did?
[20:28:33] <mru> the command line flag set an env var, and the file protocol read it
[20:28:51] <TheFluff> I don't remember that but if you say so
[20:29:00] <TheFluff> that would be pretty ugly yes
[20:29:00] <mru> it morphed into that
[20:29:59] <TheFluff> extern URLProtocol *first_protocol;
[20:30:09] <TheFluff> I'm pretty sure this isn't part of the lavf api
[20:30:13] <mru> it's not
[20:30:14] <TheFluff> +public
[20:30:20] <TheFluff> I figured
[20:30:28] <elenril> i think it still is
[20:30:30] <elenril> but deprecated
[20:30:32] <mru> no
[20:30:39] <TheFluff> it's what windows apps uses to work around the issue
[20:30:41] <mru> didn't Flameeyes hide it even?
[20:30:47] <TheFluff> it still works
[20:30:57] <elenril> ah, it was first_{i,o}format
[20:31:03] <elenril> nvm then
[20:31:50] <TheFluff> just grab the list of protocol handlers, loop over it until you find the file one and replace it with your own that converts utf8 in char* to utf16 in wchar_t and calls the windows functions
[20:32:06] <TheFluff> if there's a sanctioned way of doing this I'd be glad to know about it
[20:32:53] <wbs> TheFluff: iirc there's a public av_ prefixed function that gives you the first protocol
[20:33:02] <mru> windows is just hopeless
[20:33:24] <TheFluff> wbs: oh?
[20:33:42] <mru> filenames from open dialogs have one format, command has another, and the syscall expect any of a zillion others
[20:33:55] <mru> *command line
[20:34:05] <TheFluff> what do you mean "format"
[20:34:16] <mru> encoding
[20:34:36] <TheFluff> everything uses utf16 in wchar_t afaik...
[20:34:39] <wbs> TheFluff: av_protocol_next(NULL) will give you the first protocol
[20:35:02] <TheFluff> wbs: is that in libavutil?
[20:35:09] <wbs> TheFluff: libavformat
[20:35:37] <TheFluff> it's not in my avformat.h...
[20:35:41] <mru> TheFluff: if everything used utf16 the patch wouldn't be so ugly
[20:35:43] <TheFluff> was it added in like, the last week?
[20:35:53] <wbs> TheFluff: it's in avio.h, just below first_protocol
[20:36:02] <TheFluff> oh ok
[20:36:47] <TheFluff> mru: I don't think I understand
[20:37:00] <mru> I never quite understood it fully either
[20:37:26] <TheFluff> wmain() (the unicode version of main) uses utf16 in wchar_t
[20:37:35] <TheFluff> so does _wopen and its friends
[20:37:47] <TheFluff> so does everything else really
[20:37:55] <TheFluff> so I think I'm missing something here
[20:38:06] <TheFluff> wbs: thanks by the way
[20:38:08] <mru> playlist files?
[20:38:23] <TheFluff> what about playlist files
[20:38:32] <mru> they could contain any encoding
[20:38:48] <mru> so you'd have to a) know which one, and b) convert it to utf16
[20:39:04] <mru> unix is so much nicer
[20:39:52] <TheFluff> you have the exact same issue on unix, it's just that everyone expects everything to be in utf8
[20:40:15] <mru> no
[20:40:26] <mru> a filename is just a string of bytes other than nul or /
[20:40:30] <TheFluff> in this case you'd convert the playlist file to utf8 because we haven't changed any lavf api calls, they just expect utf8 instead of iso8859-1
[20:40:44] <mru> so you can simply assume that the playlist uses the same encoding as the filename
[20:40:50] <mru> and just pass it through
[20:40:52] <lu_zero> btw there isn't any way to force utf8 ?
[20:40:59] <TheFluff> force utf8 where
[20:41:32] <astrange> POSIX apis for hfs+ require utf8
[20:41:46] <astrange> as i recall this made linus very mad at some point and i wasn't convinced he had a point
[20:42:23] <TheFluff> mru: I still don't see why you're so opposed to supporting unicode on windows anyway
[20:42:28] <TheFluff> it certainly doesn't make things any worse
[20:42:36] <mru> I'm not opposed to supporting anything
[20:42:39] <TheFluff> playlist files won't work correctly on windows right now anyway
[20:42:44] <mru> I'm opposed to dirty, unmaintainable hacks
[20:42:49] <TheFluff> 15:23:42 <@mru> some things are just not worth supporting
[20:42:52] <TheFluff> excuse me
[20:42:59] <TheFluff> but this is hard to interpret as anything else
[20:43:12] <mru> given the amount of effort and ugliness
[20:43:13] <wbs> astrange: the issue with hfs is that they use utf8 NFD - if you write a file with an utf8 filename in composed form, it will actually store it in another format, messing up things like git
[20:45:44] <lu_zero> TheFluff: forcing everything reaching ffmpeg to utf8
[20:46:19] <mru> the latest I can find on that patch says this:
[20:46:24] <mru> > Won't this break the command line tools?
[20:46:24] <mru> It will for all filenames that aren't effectively 7-bit ASCII, at least until a
[20:46:27] <mru> patch to add Unicode support for the command line tools is accepted. (My first
[20:46:30] <mru> attempt at a reworking of Ramiro's old patch does add input support that works
[20:46:33] <mru> just fine, but when ffmpeg attempts to print the input filename it just prints
[20:46:36] <mru> garbage because the vanilla printf doesn't expect UTF8. Maybe a patch that adds
[20:46:39] <mru> Unicode support should fix that too.)
[20:59:52] <TheFluff> printing unicode to cmd.exe in a way that makes it actually show up properly on all systems is probably impossible
[21:00:07] <TheFluff> even using _wprintf and whatnot usually doesn't work
[21:00:28] <TheFluff> maybe it's better in powershell but I haven't tried
[21:02:25] <TheFluff> (it prints the right thing, as it works if you redirect stderr/stdout to a file, but cmd.exe can't show it properly)
[21:02:53] <lu_zero> uhmm
[21:03:00] <mru> you mean the terminal app, not cmd.exe
[21:03:02] <lu_zero> but is that important?
[21:03:32] <TheFluff> mru: cmd.exe is the terminal app on windows, to which this patch applies
[21:03:36] <TheFluff> lu_zero: not to me it isn't
[21:03:45] <TheFluff> but mru would probably disagree
[21:04:12] <mru> cmd.exe is the windows shell interpreter
[21:04:21] <mru> the window itself is rendered by something else
[21:04:35] <mru> cmd.exe will run inside xterm, if a bit oddly
[21:05:16] <TheFluff> I'm not sure where you're trying to get with this splitting of hairs but sure if you insist
[21:05:46] <Plorkyeran> http://blogs.msdn.com/b/michkap/archive/2008/03/18/8306597.aspx
[21:06:29] <Plorkyeran> (tldr is _setmode(_fileno(stdout), _O_U16TEXT); makes it work)
[21:06:44] <TheFluff> interesting
[21:07:02] <TheFluff> then I'd just need to find and replace all the relevant printf's with one that converts to utf16
[21:07:09] <lu_zero> TheFluff: probably there are some workarounds related to the shell and the terminal
[21:07:46] <Plorkyeran> you do still have font issues though
[21:09:25] <TheFluff> right
[21:09:55] <Kovensky> 18:00.08 TheFluff: even using _wprintf and whatnot usually doesn't work <-- I remember seeing something that would make it work in one of the microsoft blogs
[21:09:58] <Kovensky> the problem is finding it again D:
[21:10:01] <TheFluff> yes plork just linked it
[21:10:04] <Kovensky> a workaround is to use ConsoleWriteW, but what if your output is not a console?
[21:10:22] <Kovensky> oh
[21:51:02] <Dark_Shikari> BBB: question
[21:51:16] <Dark_Shikari> in vp8, what happens to t_nnz[8] and l_nnz[8] for a non-skipped block that's i4x4 or splitmv?
[21:51:21] <Dark_Shikari> they seem to be left uninitialized??
[21:51:37] <mru> maybe that's the spec
[21:51:45] <Dark_Shikari> >implying it has a spec
[21:55:22] <Yuvi> t_nnz[8] / l_nnz[8] predictions are only updated for i4x4 / splitmv, regardless of whether it's skip or not
[21:55:22] <Yuvi> so they point to the last i4x4/splitmv macroblock or are 0 if there haven't been any
[21:56:11] <Dark_Shikari> er... but I thought t_nnz is supposed to be the top macroblock
[21:56:14] <Dark_Shikari> and l_nnz is supposed to be the left
[21:56:16] <Dark_Shikari> what _are_ they then?
[21:56:26] <Yuvi> for [0..7], yes
[21:56:51] <Yuvi> [8] can be arbitrarily far back
[21:57:00] <Yuvi> but it's still to the left or top
[21:57:10] <Dark_Shikari> so it could be 10000 mbs ago
[21:57:33] <Yuvi> yes
[21:57:39] <Dark_Shikari> that's pretty pants-on-head retarded.
[22:36:37] <pross-au> it
[22:52:31] <spaam> pross-au: check
[22:55:58] <Jumpyshoes> BBB: okay so my finals are finally over. i thought about it and i'm more interested in vp8 encoding. i also might have a job over the summer (still unsure about that) if it matters
[22:56:33] <Dark_Shikari> BBB should be done with xvp8 by the summer
[22:56:35] <Dark_Shikari> if he's not he's slow
[22:56:50] <Dark_Shikari> Jumpyshoes: you have all this other cool stuff to do though~
[22:57:03] <Jumpyshoes> Dark_Shikari: give me access to your sandy bridge and i'll finish my patch :P
[22:57:13] <Dark_Shikari> Use boiled_sugar's machine.
[22:57:18] <Dark_Shikari> Why do you need another one?
[22:57:22] <Jumpyshoes> linux for profiling
[22:57:26] <Dark_Shikari> why do you have to profile?
[22:57:38] <Jumpyshoes> also, 64-bit
[22:57:45] <Jumpyshoes> since cross compiling fails on boiled_sugar's machine
[22:58:03] <boiled_sugar> ah I found the way
[22:58:07] <Jumpyshoes> but i'd like to know if the functions actually sped up or not
[22:58:15] <Jumpyshoes> boiled_sugar: oh, how?
[22:58:31] <boiled_sugar> ./configure --host=x86_64-w64-mingw32 --cross-prefix=x86_64-w64-mingw32- --enable-win32thread
[22:58:49] <Jumpyshoes> ah, thanks
[22:58:52] <Dark_Shikari> Jumpyshoes: but I already saw a checkasm
[22:59:08] <Dark_Shikari> so clearly you have something
[22:59:12] <Jumpyshoes> yea, i do
[22:59:19] <Jumpyshoes> also, i guess i have 64-bit now
[22:59:54] <Jumpyshoes> hrm, i'd like to time overall speedups
[23:00:49] <Dark_Shikari> That's not really important
[23:00:50] <Dark_Shikari> you can do that later
[23:01:00] <Dark_Shikari> and we can hire 2chers to time for us `-`
[23:01:06] <Jumpyshoes> lol, okay
[23:26:16] <BBB> hi yuvi btw :)
[23:26:47] <BBB> Jumpyshoes: hm, encoding... darn, means I have to start working on that also, I ws hoping you'd do decoding :-p
[23:26:56] <BBB> ok, let me think where we can get you started
[23:34:04] <Dark_Shikari> Jumpyshoes: how about 10-bit?
[23:34:06] <Dark_Shikari> Given you wrote all that asm =p
[23:40:29] <Dark_Shikari> you can help irock
[23:40:31] <Dark_Shikari> make your asm useful
[23:40:46] <Dark_Shikari> oh btw BBB
[23:40:59] <Dark_Shikari> http://pastebin.com/6Qi4XnJ9
[23:41:08] <Dark_Shikari> I can't make this faster.  Or maybe my benches are inaccurate, since my stddev is ridiculous
[23:41:17] <Dark_Shikari> feel free to test it.  it definitely won't be faster on a non-nehalem though
[23:41:35] <Dark_Shikari> ideas to make it less bad welcome
[23:42:20] <Jumpyshoes> BBB: okay
[23:42:23] <Jumpyshoes> Dark_Shikari: 10-bit decoding?
[23:42:37] <Dark_Shikari> Jumpyshoes: yes
[23:42:42] <Dark_Shikari> irock has a large part already done
[23:42:47] <Dark_Shikari> you could work with his tree to help finish
[23:42:51] <Dark_Shikari> and also a bit later to help write some asm
[23:43:00] <Dark_Shikari> I'll help with asm too
[23:43:14] <Jumpyshoes> Dark_Shikari: hrm, i see... i don't know too much about actual h264 decoding though
[23:43:23] <Dark_Shikari> You don't need to know that much
[23:43:27] <Dark_Shikari> And learning helps
[23:43:51] <Dark_Shikari> Learning is good.  You'll need to do it anyways to work on an encoder.
[23:44:09] <Jumpyshoes> true
[23:44:30] <Jumpyshoes> hrm, okay, i'll consider
[23:44:34] <Jumpyshoes> where can i find the tree?
[23:45:00] <Dark_Shikari> Ask him
[23:45:07] <Dark_Shikari> It's probably not public, but he can certainly put it on github
[23:45:24] <Jumpyshoes> okay
[23:45:33] <Jumpyshoes> irock: where can i find your 10-bit decoding tree?