[FFmpeg-devel-irc] IRC log for 2011-01-31

[irc at mansr.com]

[00:01:54] <Anaerin> ...And still sitting there even longer...
[00:01:59] <Anaerin> I don't think it's going to return.
[00:04:15] <Anaerin> Nope. Ctrl-C, here we come.
[00:18:36] <lu_zero> Anaerin: I'll try to get a proper fix during the next week
[02:23:42] <DonDiego> mru: is mem.h the only place where attribute_used appears?
[02:23:48] <mru> yes
[02:24:01] <mru> at least git grep says so
[02:24:04] <mru> and gcc agrees
[02:24:50] <DonDiego> i guess.. - it was just surprising..
[02:25:54] <mru> same here
[03:07:32] <Sean_McG> can I run an individual fate test in gdb to see where it's segfaulting?
[03:08:41] <peloverde_> do "make testname V=1" to get a command line
[03:13:17] <mru> Sean_McG: play with the TARGET_EXEC variable
[03:13:31] <mru> or perhaps that doesn't play well with gdb
[03:13:53] <mru> I'd simply enable core dumps
[03:14:47] <Sean_McG> OK so I have to add -g to CFLAGS
[03:15:00] <ohsix> .
[03:15:07] <mru> should be there already
[03:15:25] <Sean_McG> oh...crap yes it is
[03:15:31] <Sean_McG> my bad
[03:32:28] <Sean_McG> blah, no dump created
[03:33:19] <ohsix> need to set a ulimit if the core size is set to nothing
[03:33:52] <Sean_McG> sean at tsukimi:/var/opt/BUILD/ffmpeg-fate.amd64/build$ ulimit -a | grep core
[03:33:53] <Sean_McG> core file size          (blocks, -c) unlimited
[03:34:14] <ohsix> theres also a core file pattern thing that can send it to a pipe
[03:39:27] <mru> Sean_McG: what are you debugging?
[03:51:17] <Sean_McG> atrac3-1
[03:52:02] <mru> Sean_McG: do you have this patch applied? http://patches.ffmpeg.org/patch/697/
[03:52:26] * mru recalls something about gcc 4.6 being looked at
[03:52:44] <Sean_McG> ah... looking at the logs here... it's not segfaulting which is why I'm not getting a dump... it segfaults on Linux though
[03:53:00] <mru> try that patch
[03:53:04] <Sean_McG> yeah I'm building with 4.6
[03:53:22] <Sean_McG> OK... I'mmma go shower and then try again with the patch
[03:53:30] <mru> all those audio codec crashes are probably related
[03:53:44] <mru> no idea about the pixfmt one
[03:53:46] <peloverde_> all the audio crashes were in imdct
[03:54:05] <peloverde_> the reason it was only those codecs was because it was only full imdct
[03:54:13] <mru> ah
[03:54:25] <mru> do you think I should push the patch?
[03:54:32] <mru> or wait for BBB or Dark_Shikari?
[03:54:42] <peloverde_> wait for an x86 guy
[03:54:45] <Dark_Shikari> which one
[03:54:56] <mru> Dark_Shikari: http://patches.ffmpeg.org/patch/697/
[03:55:04] <Sean_McG> OK so if you folks are all looking at these I might as well stop
[03:55:19] <mru> it's more of an inline asm constraint thing than an x86 thing though
[03:55:30] <mru> Sean_McG: every set of eyes helps
[03:55:36] <Dark_Shikari> no idea
[03:55:42] <Dark_Shikari> die inline asm die
[03:55:52] <Sean_McG> lol
[03:57:50] <mru> it was never intended for such usage
[03:58:03] <peloverde_> what usage?
[03:58:11] <mru> writing entire functions
[03:59:08] <mru> inline asm is intended, and works well, for small fragments of a few instructions where call overhead would be too high
[03:59:46] <mru> and even there, intrinsics that actually work would be better
[04:00:00] <mru> some compilers can do it...
[04:06:55] <peloverde_> ugh I sent the wrong one
[04:16:16] <DonDiego> gnite
[04:28:58] <Sean_McG> OK, trying with that patch
[04:47:01] <BBB> peloverde: which patch?
[04:47:07] <BBB> peloverde: I can review, sorry, was wacthing a movie
[04:47:24] <peloverde> BBB: http://patches.ffmpeg.org/patch/704/
[04:47:58] <peloverde> that whole files needs some love but this puts out the immediate fires
[04:49:00] <saintdev> but does it put out the ffflames?
[04:49:26] <BBB> peloverde: yes patch is fine
[04:49:39] <Sean_McG> what's the difference between MANGLE and LOCAL_MANGLE?
[04:49:45] <mru> _
[04:49:53] <mru> sometimes
[04:50:01] <mru> no difference on linux
[04:50:16] <Sean_McG> SunOS shinobu 5.10 Generic_142901-08 i86pc i386 i86pc
[04:50:24] <mru> not there either
[04:50:27] <Sean_McG> OK
[04:50:32] <BBB> local_mangle() is for symbols within the function, mangle() is for things declared outside the scope of the function?
[04:50:35] <mru> only on silly systems that put prefixes on global symbols
[04:50:39] <BBB> I remember always using mangle in similar situations
[04:50:45] <BBB> osx is a silly system :)
[04:51:26] <mru> of course it is
[05:01:41] <Sean_McG> OK this seems to fix all the atrac3 tests
[05:02:05] <Sean_McG> only thing still failing is pixfmt
[05:03:10] <peloverde> If i need to use ecx/cl from yasm how do I do that wrt yasm's renaming?
[05:03:37] <Dark_Shikari> It's hard.
[05:03:45] <Dark_Shikari> Look at cabac-a.asm in x264 for an example.
[05:03:59] <Dark_Shikari> well not hard, just an annoyance.
[05:04:18] <peloverde> maybe we should just add a 1 << nbits field to the FFTContext?
[05:04:21] <Dark_Shikari> you bypass the main macro system
[05:04:29] <Dark_Shikari> and you use DECLARE_REG_TMP
[05:04:40] <Dark_Shikari> which lets you declare a different register order for the function for each of win32, x86_64, x86_32
[05:04:43] <Dark_Shikari> er, win64
[05:05:13] <Dark_Shikari> example from a very complex function:
[05:05:15] <Dark_Shikari> %ifdef WIN64 DECLARE_REG_TMP 3,1,2,0,4,5,6,10,2
[05:05:15] <Dark_Shikari> %elifdef ARCH_X86_64 DECLARE_REG_TMP 0,1,2,3,4,5,6,10,6
[05:05:15] <Dark_Shikari> %else DECLARE_REG_TMP 0,4,2,1,3,5,6,2,2
[05:05:16] <Dark_Shikari> %endif
[05:05:29] <Dark_Shikari> in this function, "t3b" is our shift register.
[05:09:20] <Dark_Shikari> You could also do the shift in simd if it's convenient.
[05:42:27] <peloverde> dumb question: why don't i see a call to memcpy in the disasm of ff_fft_permute_sse?
[05:44:02] <Dark_Shikari> peloverde: gcc inlined it?
[05:44:21] <peloverde> that would make sense
[05:46:49] <peloverde> memcpy()ing the buffers seems silly but i suppose it is frozen api now
[05:49:37] <peloverde> It seems like the caller should just pass in two buffers and do its own memcpy if absolutely necessary
[05:49:50] <peloverde> thoughts?
[05:50:33] <Dark_Shikari> this is the problem with exposing internal apis
[05:51:03] <peloverde> well we can change it for the next major bump?
[05:57:00] <peloverde> we could even do an fft_permute2
[05:57:07] <peloverde> and phase the old one out
[06:00:30] <peloverde> actually av_fft_premute wraps ff_fft_permute so we wouln't be breaking public api
[06:00:38] <peloverde> we can just do the memcpy in the wrapper
[06:01:28] <peloverde> It looks like only x86 and ARM have optimized versions, mru would you be willing to help with ARM?
[06:22:11] <peloverde> (I)MDCT merges the copy with the pre-twiddle though so the changes are largely unimportant
[06:28:03] <peloverde> I suppose someone might want to do the permute inplace
[06:28:48] <peloverde> though an inplace permute is usually branchy and gross
[06:29:14] <Dark_Shikari> random question
[06:29:27] <Dark_Shikari> Suppose you have a function that takes a size N input array, and a size N permute mask (i.e. how to permute it).
[06:29:46] <Dark_Shikari> Is it possible to perform any arbitrary permute with no more than O(1) temporary data?
[06:30:14] <Dark_Shikari> Also, you can't write to the permute mask, it's constant.
[06:30:39] <Dark_Shikari> Oh, and can it be done in O(N) time
[06:30:56] <peloverde> for arbitrary permute IDK
[06:31:25] <peloverde> the comments in fft.c imply that in place permute is reasonable
[06:31:42] <peloverde> "TODO: handle split-radix permute in a more optimal way, probably in-place"
[06:34:03] <pengvado> Dark_Shikari: yes
[06:34:12] <peloverde> if you have a permute that is just based on swaps, only swap at the lower index
[06:34:15] <pengvado> any permute can be decomposed into a disjoint set of cycles
[06:34:44] <pengvado> each of which can be handled with 1 value copied out of place
[06:36:33] <Dark_Shikari> Can that be done with O(1) space?
[06:36:38] <Dark_Shikari> A set of cycles requires space.
[06:37:02] <Dark_Shikari> I guess in practice you could change your permute mask to be represented as a set of cycles
[06:37:03] <pengvado> it's O(N) constant space
[06:37:05] <Dark_Shikari> instead of a set of indices
[06:37:15] <pengvado> just like the array of indices already is
[06:37:52] <Dark_Shikari> It is?
[06:38:00] <pengvado> revtab[]
[06:38:04] <Dark_Shikari> Oh, in ffmpeg.
[06:41:20] <peloverde> pengvado: do you think giving the permute function two buffers and always doing it out of place is smarter?
[06:41:30] <pengvado> yes
[06:46:04] <peloverde> right now the (i)mdct, does handle the copy in its pretwiddle though so I question how important this is. very few codecs use raw fft
[06:56:55] <cartman> moin
[07:02:48] <_av500_> +1
[07:16:52] * elenril yawns
[07:32:54] * elenril updates on the fflames
[07:33:07] <thresh> moroning
[07:34:58] <andoma> morning
[07:35:53] * cartman brrrrrs its damn cold
[07:37:41] * pross-au is sweating like a pig
[07:38:56] <pross-au> 70% humidity atm
[07:41:23] <cartman> pross-au: I'd prefer that instead
[07:50:52] <superdump> morning
[07:52:34] <elenril> "Free software's awfully like sausages - wonderfully tasty, but sometimes you suddenly discover that you've been eating sheep nostrils for the past 15 years of your life."
[07:56:49] <KotH> salut
[08:51:51] * Dark_Shikari pokes BBB to bench that patch
[08:52:27] * elenril thinks KotH is scary
[08:53:13] <superdump> elenril: why?
[08:53:38] <elenril> superdump: did you see his speech just now
[08:54:40] <superdump> not scary, just history
[08:54:41] <elenril> kinda feels like http://tvtropes.org/pmwiki/pmwiki.php/Main/YouShallNotPass
[08:58:29] <KotH> elenril: lol
[09:09:29] <elenril> though i'm really suprised by the godwin's law failing
[09:11:06] <kshishkov> ?
[09:11:28] <elenril> kshishkov: still no mention of nazis in those threads
[09:11:32] <elenril> or did i miss something?
[09:12:56] <kshishkov> elenril: well, direct translation of "leader" into German is "Führer" though it's not used much these days because of different Austrian
[09:13:05] <kshishkov> elenril: so it's no need to mention it
[09:17:02] <kshishkov> but speaking of it...
[09:17:26] <kshishkov> av500: can we have Das FFmpeg Wechsel Lied for anthem?
[09:18:03] <av500> kshishkov: send a patch
[09:18:14] <Tjoppen> oh, the flames
[09:18:23] * elenril prefers союз нерушимый
[09:19:06] <kshishkov> elenril: current Ukrainian anthem is more optimistic
[09:19:28] <elenril> ще невмерла?
[09:19:33] <elenril> or something like that
[09:19:39] <kshishkov> exactly
[09:19:47] <elenril> wow, i even remember it a little
[09:19:51] <Dark_Shikari> I'm surprised nobody's godwinned it
[09:19:59] <Dark_Shikari> considering michael's nationality
[09:20:21] <kshishkov> elenril: in winter time it's changed into "ще не змерзла"
[09:22:18] <elenril> michaelni: i hereby apply godwin's law to you ;)
[09:23:14] <cartman> michaelni is a bot :P
[09:23:35] <Dark_Shikari> is michael from austraia or germany?
[09:23:54] <cartman> former I believe
[09:23:58] <siretart> Dark_Shikari: austria
[09:23:59] <av500> austraia is the mythical continents that split into austria and australia?
[09:24:05] <Dark_Shikari> So he's even CLOSER to hitler!!
[09:24:30] <Dark_Shikari> av500: http://ohforfuckssake.com/files/australiak.jpg
[09:24:31] * siretart sighs
[09:25:07] <Dark_Shikari> It's the worst country in Europe!
[09:25:14] <kshishkov> av500: Austria is a land of mountains and streams and Australia is girt by sea, how can one not distinguish them?
[09:25:16] <av500> Dark_Shikari: is there a matching piv for austria?
[09:25:23] <Dark_Shikari> av500: don't think so
[09:25:23] <av500> pic
[09:25:24] <kshishkov> Dark_Shikari: you hurt my Ukrainian pride
[09:25:46] <Dark_Shikari> this meme came from that news story about the austrian guy who kept a girl his basement for 18 years
[09:25:51] <Dark_Shikari> people kept calling him australian
[09:25:56] <Dark_Shikari> and that spawned this meme
[09:26:52] <av500> makes no sense, im australia he would have kept her free roaming
[09:27:01] <siretart> please, no fritzl jokes. it's already tasteless enough like it is now.
[09:27:44] <pross-au> That map is incorrect. Sydney is not the capital!!
[09:28:07] <Dark_Shikari> siretart: "tasteless" is the fuel that runs 4chan
[09:28:15] <Dark_Shikari> for that matter, the internet.
[09:28:40] <av500> Dark_Shikari: so egypt ran out of tasteless?
[09:28:47] * elenril would hope we're higher level than 4chan
[09:29:01] <Dark_Shikari> 4chan is already max level
[09:29:04] <kshishkov> pross-au: ask any guy from Sydney
[09:29:11] <av500> elenril: we go up to 11
[09:29:19] <Dark_Shikari> 4chan is level 85
[09:29:23] <elenril> av500: http://kecy.roumen.cz/tweet_z_egypta.jpg
[09:29:49] <Dark_Shikari> http://i.imgur.com/RgDGZ.jpg
[09:29:53] <av500> elenril: so, the govmt has to airdrop harddrives with p
[10:01:37] * elenril discovers git add --intent-to-add
[10:01:58] <elenril> http://tvtropes.org/pmwiki/pmwiki.php/Main/TheDevTeamThinksOfEverything
[10:05:06] <Tjoppen> and of course, http://tvtropes.org/pmwiki/pmwiki.php/TheDevTeamThinksOfEverything/NetHack
[10:15:33] <elenril> how do i change the author name for several commits at once?
[10:15:52] <Zor> I don't think you can
[10:15:56] <wbs> elenril: you can try filter-branch
[10:16:14] <elenril> wbs: any more specific hints?
[10:16:20] <elenril> filter-branch is still black magic for me :)
[10:16:34] <elenril> Zor: you can do anything with git!
[10:16:36] <elenril> it's magic!
[10:16:44] <Zor> very true...
[10:17:03] <wbs> elenril: git filter-branch --env-filter "if [ "$GIT_AUTHOR_NAME" = "foo" ]; then export GIT_AUTHOR_NAME="bar"; fi" old-commit..HEAD
[10:17:18] <wbs> elenril: the docs for filter-branch has some quite useful examples
[10:17:59] <wbs> elenril: that way, you could e.g. choose to change the author name just for commits where it is something specific before
[10:18:18] <elenril> nice
[10:18:32] <Zor> ...git really can do anything
[10:18:39] <wbs> old-commit might usually be `git merge-base master cur-branch`
[10:21:42] <elenril> wow, it worked
[10:21:46] <elenril> wbs: thanks
[10:23:11] <av500> merbzt: ping
[10:23:46] <merbzt> pong
[10:24:28] <wbs> elenril: np, git filter-branch is like the most awesome tool ever :-)
[10:28:30] <j-b> or not
[10:30:50] <wbs> sure, it's not the most easy to use tool
[10:40:28] <j-b> wbs: and it lacks some features
[10:40:50] <j-b> like changing author and message at the same time
[10:41:08] <wbs> hmm, can't you do that with an env-filter?
[10:41:21] <wbs> or that perhaps was a separate filter
[10:42:45] <cartman> http://static.whalesalad.com/north_korea/
[10:43:27] <jannau> j-b: you can use multiple --*-filter commands. see http://git.jannau.net/git/FFmpeg.git.convert/tree/merge_FFmpeg_libswscale_git.sh#n200 ff for an ugly example
[10:45:18] <kshishkov> cartman: well, caption "North Koreans are always amazed when they see a white man." is incomplete, he's written over the picture "look, negro in pink clothes!"
[10:45:31] <cartman> heheh
[11:17:15] <Kovensky> "It seems that the goal of the NK architects was to make stations more impressive that Moscow's metro." <-- reminds me to finish Metro 2033
[11:18:10] * kshishkov prefers Tunnelbanan
[11:18:15] <elenril> metro 2033 is overrated
[11:18:42] <elenril> it has an interesting premise
[11:18:55] <elenril> but it gets pretentious and starts AuthorTracting
[11:19:08] <Dark_Shikari> Eh?  It was fine.
[11:19:09] <elenril> and the ending is incredibly meh
[11:19:17] <Dark_Shikari> It wasn't as good as Stalker, but it was fun.
[11:19:44] * elenril wonders why does everybody keeps calling пикник на обочине by the weird name
[11:20:01] <kshishkov> elenril: because they've not read it
[11:20:52] <kshishkov> elenril: but don't worry, co-author of that sanctioned fanfics after Обитаемый остров
[11:22:47] <elenril> kshishkov: their books got close to unreadable after волны гасят ветер anyway
[11:23:54] * Kovensky wonders why the sovietspeak
[11:24:17] <elenril> those are the original names of the books
[11:24:22] <elenril> and you should go read them RightNow
[11:24:56] * thresh doesnt like стругацких
[11:25:12] * elenril stops liking thresh  =p
[11:25:21] <Kovensky> "bonhbl tacrt betep"?
[11:25:32] <Kovensky> "ctpyrauknx"?
[11:25:33] * Kovensky runs
[11:25:57] <thresh> elenril: well, some of their stuff is OK, I just dont like science fiction that much
[11:26:33] * elenril stabs Kovensky 
[11:33:25] <elenril> Dark_Shikari: i agree that it's interesting, but it has too much Fauxlosophy, especially in the second half
[11:33:41] <Dark_Shikari> stop using tvtropes words
[11:33:54] <elenril> they're convenient
[11:34:04] <elenril> and exactly express what i think
[11:34:22] <Compn> kshishkov : you didnt add kgv1 decoder into mplayer? :P
[11:37:16] <Kovensky> Dark_Shikari: TvTropesWillRuinYourVocabulary
[11:39:39] <kshishkov> Compn: only because it was Daniel (aka drv) who finished and comitted it
[11:39:56] <kshishkov> Compn: and adding codecs from third parties is your job
[11:41:54] <Compn> doh
[11:42:12] * Compn thought someone added it
[11:47:27] <spaam> mmmm julmust. vad gott
[11:58:41] <Compn> someone remind me to make roundup report about blox mpeg2 codec http://samples.mplayerhq.hu/V-codecs/blox.avi
[11:58:50] <Compn> feature request
[11:59:28] <lu_zero> ok
[12:02:01] <Compn> or someone do it for me :)
[12:04:08] <elenril> why do both ffmpeg.git and ffmpeg repos exist?
[12:04:15] <elenril> it's pretty confusing
[12:04:22] <kshishkov> where?
[12:04:50] <superdump> elenril: follow http://ffmpeg.org/download.html
[12:05:04] <superdump> the ffmpeg repo, is iirc, a git-svn read only repo
[12:05:12] <elenril> superdump: i know, but it's still confusing
[12:05:35] <elenril> when i'm constructing an address out of my head i'm likely to get that wrong
[12:05:37] <superdump> shouldn't be difficult to either take it down or move it
[12:06:00] <superdump> also, i think one can generally drop the .git and cloning will still work
[12:06:21] <jannau> yes, it's the old repo git-svn repo
[12:06:31] <elenril> superdump: that's exactly the point
[12:06:35] <elenril> it should work that way
[12:06:41] <elenril> but now it'll clone the wrong repo
[12:06:44] <superdump> right
[12:06:51] <superdump> it should be moved or removed
[12:57:31] <kshishkov> why do we have libpostproc in FFmpeg?
[12:58:14] <siretart> kshishkov: I think for hysterical raisins. and because other applications like xine still use it.
[12:58:33] <kshishkov> siretart: who cares if FFmpeg does not use it?
[12:58:33] <elenril> what does it even do?
[12:58:40] <kshishkov> postprocesses
[12:59:02] <elenril> really?
[12:59:17] <siretart> kshishkov: xine devs, distro packagers and possibly other users would be quite annoyed, I imagine
[12:59:41] <thresh> indeed
[12:59:41] <kshishkov> is Xine still alive?
[12:59:44] <siretart> is that really worth dropping it?
[12:59:49] <thresh> VLC uses it as well
[13:00:05] <thresh> I never found a use case though nor seen the difference with postproc enabled video
[13:00:18] <av500> thresh: well, thats a strong point
[13:00:37] <BBB> isn't postproc supposed to be a avfilter at some point?
[13:00:53] <kshishkov> it has two dozens of filters inside IIRC
[13:01:21] <siretart> michaelni: see above, and could you perhaps clarify the relationship between postproc and avfilter?
[13:04:23] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * rfa34a3626c ffmpeg/ffmpeg.c:
[13:04:23] <CIA-38> ffmpeg: Make ffmpeg warns the user when the selected sample format is ignored.
[13:04:23] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[13:20:53] <mru> about the fft...
[13:21:15] <mru> why don't we simply leave the permutation as is without copying back?
[13:44:08] <michaelni> BBB, siretart , one avfilter should use libpostproc
[13:44:44] <michaelni> thresh, low bitrate flv or anything else that shows blocks you will see a huge difference
[13:45:50] <siretart> ah, the postproc avfilter is yet to be written. I see.
[13:46:09] <mru> there are other apps that use postproc
[13:46:19] <kshishkov> mru: but not FFmpeg
[13:46:22] <mru> true
[13:46:36] <wbs> isn't such deblocking part of the decoder in h264, and mandated by the spec?
[13:46:38] <siretart> so? do we want to annoy these external users for no benefit?
[13:46:43] <mru> wbs: h264 yes
[13:46:53] <mru> siretart: annoy?
[13:47:01] <kshishkov> wbs: in-loop vs. out-of-loop deblocking
[13:47:02] <siretart> mru: by removing libpostproc
[13:47:18] <wbs> ok
[13:47:21] <kshishkov> siretart: s/removing/making it standalone
[13:48:13] <thresh> michaelni: ah, thanks. I suppose I dont watch videos like that =)
[13:48:14] <siretart> kshishkov: that's something different. do you (or know someone) that would volunteer to maintain a standalone version of it?
[13:48:39] <kshishkov> siretart: is it maintained at all?
[13:48:42] <mru> no
[13:49:32] <kshishkov> and it looks like written in sws-style i.e. in need of major cleanup/restructuring
[13:49:40] <mru> yes
[13:49:47] <mru> both api and internal structure
[13:50:42] <kshishkov> siretart: http://codecs.multimedia.cx/?p=315
[13:51:01] <kshishkov> siretart: not about libpp but the notion is the same
[13:59:08] <CIA-38> ffmpeg: Ronald S. Bultje <rsbultje at gmail.com> master * r4543009943 ffmpeg/libavformat/asf.c:
[13:59:08] <CIA-38> ffmpeg: asf/wtv: use service_provider and service_name metadata tags
[13:59:08] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[14:02:51] <BBB> ?
[14:02:54] <BBB> wth
[14:03:13] <mru> ?
[14:03:20] <BBB> the from: should be peter ross
[14:03:27] <BBB> I used git am to import the patch
[14:03:31] <mru> you obviously didn't apply it correctly
[14:03:36] <BBB> gitk showed it as from: peter ross
[14:03:42] <BBB> then I amended it to add the sign-off line
[14:03:48] <BBB> and then push
[14:03:51] <BBB> and now the from: is wrong
[14:04:00] <mru> you should have told it to keep the original author when amending
[14:04:20] <mru> to add a sign-off, use "git am -s"
[14:04:43] <mru> or to add one to the last commit "git commit --amend -s -C HEAD"
[14:04:43] <BBB> git gui has no such checkout... I'll use git am -s next time
[14:05:03] <BBB> checkout=checkbox
[14:05:05] <BBB> weird anyway
[14:05:09] <mru> at least it's only two entries in a table
[14:05:27] <mru> not like you're claiming credit for something big
[14:05:37] <BBB> right, I chose a small patch to practice git am
[14:12:17] <wbs> hmmm, git commit --amend always keeps the original author name/date for me, did that change in some version, or is it controllable with some option?
[14:13:45] <mru> wbs: git gui replaces author
[14:13:57] <jannau> maybe in ancient version. the author can be changed with --amend --author="..."
[14:14:12] <wbs> mru: hmm, that's a weird inconsistency
[14:14:42] <wbs> jannau: yeah, I recently had to look up --reset-author in order to do that
[14:17:48] <michaelni> siretart, i volunteer to maintain libpostproc somewhere outside ffmpeg if you guys want it out
[14:20:42] <BBB> it'd be easier to move it to lavfilter also at some point
[14:20:56] <BBB> by itself it doesn't belong there but is part of api, so let's keep it for now
[14:21:18] <mru> BBB: I don't see why it doesn't belong
[14:21:32] <mru> there are lots of things ffmpeg.c doesn't use
[14:21:44] <mru> doesn't make them any less useful
[14:21:58] <mru> what libpostproc does need is a major overhaul of both api and code
[14:22:42] <michaelni> mru libpostproc is fine
[14:22:53] <mru> not the api and not the internal structure
[14:22:53] <michaelni> both api and code
[14:23:06] <mru> but I'm not going to argue that with you
[14:23:20] <michaelni> ok
[14:23:30] <BBB> how do I amend just the log msg but not the author using git tools?
[14:23:38] <BBB> I want to delete some lines from the commit msg
[14:23:42] <mru> BBB: git commit --amend -c HEAD
[14:23:50] <mru> that opens an editor with the old message
[14:23:54] <mru> edit and save
[14:24:54] <michaelni> BBB, libpostproc is usefull for projects without full libavfilter, like resampling is too
[14:24:57] <wbs> doesn't need any -c HEAD either, just "git commit --amend" works too
[14:25:17] <mru> I could have sworn it didn't use to
[14:25:41] * mru needs to read git release notes more carefully
[14:26:42] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r22e9277aa5 ffmpeg/libavformat/vc1testenc.c:
[14:26:42] <CIA-38> ffmpeg: VC1testenc: convert pts values to correct time-base.
[14:26:42] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[14:29:11] <BBB> hah, that looks better now
[14:29:55] * thresh bangs his head against the table http://dumpz.org/30383/
[14:30:30] * cartman helps thresh 
[14:31:12] <cartman> thresh: SloWaris?
[14:31:19] <thresh> cartman: worse, hpux
[14:31:23] <cartman> w00t
[14:31:31] <cartman> then mru will fix it :P
[14:31:51] <thresh> I think hpux is unfixable
[14:32:14] <Kovensky> 11:23.43 mru: BBB: git commit --amend -c HEAD <-- `git commit --amend` by itself will always edit the HEAD commit (will also merge anything you `git add`ed with it)
[14:32:33] <superdump> that's handy
[14:32:44] <cartman> j-b: http://news.ycombinator.com/item?id=2161449
[14:32:57] <superdump> for those "oops i forgot this" or bugs noticed after a commit
[14:33:11] <thresh> yeah but don't use that if you pushed already :)
[14:33:15] <cartman> yep
[14:33:34] <superdump> :)
[14:34:23] <kierank> cartman: lol
[14:34:38] <benoit-> thresh: the non fast forward pushes can be forbidden on the server side.
[14:34:40] <cartman> kierank: GPL code is not for the lulz
[14:34:46] <thresh> benoit-: yeah and they are
[14:34:50] <cartman> benoit-: its already forbidden atm.
[14:34:52] <kierank> cartman: GPL: serious business
[14:35:09] <cartman> RMS approvedâ„¢
[14:35:33] <kierank> also they're actually using correct x264 presets
[14:35:35] <benoit-> thresh, cartman: then cool, amend as much as you want, even after pushing :)
[14:35:43] <cartman> benoit-: heheh :D
[14:36:12] <uau> so you need to delete the current branch and start using a new one instead :)
[14:38:07] <mru> uau: the server forbids pushing new branches too
[14:42:40] <Kovensky> why forbid branches?
[14:43:04] <elenril> because we generally fail at git
[14:43:45] <cartman> You don't git it, do you?
[14:43:56] <wbs> people can keep branches in personal repos, unless it's an officially sanctioned branch
[15:13:22] <siretart> michaelni: if you maintain libpostproc seperately, I volunteer to package and maintain it in debian
[15:13:48] <siretart> for ffmpeg, I really don't mind much, both would work for me
[15:14:03] <lu_zero> it will be managed by me for gentoo for sure
[15:16:03] <mru> let's see if we can clean it up first, if that's too much work, we can consider dropping it
[15:17:17] <kshishkov> mru: it's built in the same way as swscaler
[15:17:28] <siretart> do we care enough for that?
[15:17:55] <lu_zero> uff
[15:18:07] <lu_zero> I barely touched swscale.c
[15:18:22] <kshishkov> FFmpeg code quality is important, libpostproc - who knows?
[15:18:27] <kshishkov> lu_zero: and?
[15:18:31] <lu_zero> now the init is first call C then call the arch specific
[15:18:48] <lu_zero> but I couldn't untangle the scale function variants so far
[15:19:21] <mru> libpostproc is rather small
[15:19:33] <mru> fixing it shouldn't be too hard
[15:19:33] * lu_zero needs to fetch enough guarana` to try w/out breaking the x86 asm
[15:33:50] <CIA-38> ffmpeg: Stefano Sabatini <stefano.sabatini-lala at poste.it> master * re771d2e3fe ffmpeg/doc/muxers.texi:
[15:33:50] <CIA-38> ffmpeg: Add documentation for the image2 muxer.
[15:33:50] <CIA-38> ffmpeg: Signed-off-by: Ronald S. Bultje <rsbultje at gmail.com>
[15:36:08] <BBB> wbs: would you be interested in modifying ffmpeg.c, ffplaty.c and all functions that are necessary to be able to use AVOptions with (autodetected) demuxers?
[15:36:33] <BBB> so we can use --rtsp-protocol=tcp or so instead of ?tcp to force tcp
[15:36:45] <BBB> wbs: you seem the best candidate to do that (if you have time)
[15:36:58] <mru> wbs: consider yourself volunteered
[15:38:08] <spaam> woho!
[15:38:13] <spaam> wbs: grattis!
[15:41:18] <lu_zero> ^^;
[15:47:04] <CIA-38> ffmpeg: Georgi Chorbadzhiyski <gf at unixsol.org> master * r445996aa51 ffmpeg/ (doc/muxers.texi libavformat/mpegtsenc.c): (log message trimmed)
[15:47:04] <CIA-38> ffmpeg: Replace defines in libavformat/mpegtsenc.c with AVOptions
[15:47:04] <CIA-38> ffmpeg: Around 01/28/11 18:56, Ronald S. Bultje scribbled:
[15:47:04] <CIA-38> ffmpeg: > That patch is now merged, can you submit the update to muxers.texi?
[15:47:04] <CIA-38> ffmpeg: > Then we'll apply the whole thing.
[15:47:05] <CIA-38> ffmpeg: See attached. I hope the documentation is enough.
[15:47:06] <CIA-38> ffmpeg: --
[15:48:15] <Tjoppen> even cooler might be to have something like ffmpeg --options-for foo://example.com/bar
[15:48:16] * elenril glares at BBB 
[15:48:27] <elenril> who's playing with git again
[15:48:33] <BBB> ?
[15:48:43] <mru> you messed up a commit
[15:48:47] <BBB> huh?
[15:48:50] <BBB> what happened
[15:48:54] <mru> you put the entire quoted thread in the commit message
[15:48:58] <BBB> oh no it imported the thread
[15:48:59] <BBB> argh
[15:49:13] <BBB> now what do I do?
[15:49:15] <mru> nothing
[15:49:23] <mru> but don't do it again
[15:49:32] <BBB> git has no undo function?
[15:49:34] <mru> no
[15:49:39] <mru> not a remote undo
[15:49:43] <BBB> uhm...
[15:50:05] <BBB> so if you fuck up, you're stuck with it?
[15:50:09] <mru> yes
[15:50:12] <mru> so don't fuck up
[15:50:16] <bilboed-pi> for *EVER*
[15:50:19] <BBB> that's easier said then done
[15:50:22] <mru> run "git log origin..master" before pushing
[15:50:38] <bilboed-pi> git commit -v helps also (you can review your commit that way)
[15:50:38] <mru> make sure everything looks ok
[15:50:45] <Kovensky> git does have a remote undo
[15:50:55] <mru> push -f, yes
[15:50:55] <Kovensky> but it will fuck up everyone's trees if they pulled from the tree before you undid it
[15:51:18] <mru> shall I fix it on the server quickly before it propagates?
[15:52:27] <jannau> mru: it's already to late with auto pushing
[15:52:36] <mru> where do we auto-push?
[15:52:47] <mru> only patchwork afaik
[15:53:02] <jannau> patchwork repo and github
[15:53:25] <jannau> not sure how fast the mirror for gitorious is
[15:53:30] <mru> BBB: so please double-check next time
[15:54:00] <thresh> also, git push -n
[15:54:12] <jannau> that doesn't help
[15:54:26] <thresh> well I usually check git log with sha ids :)
[15:54:52] <jannau> mru: we both made already the same mistake
[15:55:07] <BBB> mru: ok
[15:55:16] <mru> yes, I've done it myself as well
[15:55:32] <mru> and started checking more carefully afterwards
[15:55:40] <BBB> I'll be more careful
[15:55:45] <BBB> "oops"
[15:58:08] <BBB> shall I try to import vasyil's patch?
[15:58:13] <BBB> maybe I can try better now
[15:58:29] <mru> which patch?
[15:58:50] <mru> I applied one from him
[15:59:36] <BBB> I guess this must be an old one then
[15:59:56] <mru> what's the title?
[16:00:32] <BBB> you already applied it
[16:00:35] <BBB> I just checked git log
[16:00:37] <BBB> so n/m
[16:00:59] <mru> there are some patches with wrong status in patchwork
[16:01:48] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r365e3c7878 ffmpeg/libavutil/ (attributes.h internal.h mem.h):
[16:01:48] <CIA-38> ffmpeg: Rename attribute_used to av_used and move it to attributes.h
[16:01:48] <CIA-38> ffmpeg: This is consistent with most of the other attribute macros.
[16:01:48] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:03:49] <mru> ruggles: ping
[16:04:05] <ruggles> mru: hi
[16:04:18] <mru> did you see the updated patches I sent for the dsputil stuff?
[16:05:09] <ruggles> yes. looks good.
[16:05:26] <mru> can someone else please have a look as well?
[16:05:40] <mru> BBB: perhaps you could cast an eye on the x86 parts
[16:08:53] <ruggles> mru: i see you changed the vfp part to always build, but the original was wrapped in HAVE_ARMV6
[16:09:05] <mru> that's handled in the makefile now
[16:09:09] <ruggles> ah, ok
[16:09:13] <mru> ifdefs around entire files are silly
[16:09:27] <mru> other than headers of course
[16:10:06] <BBB> mru: ok, will look, what's the threadname?
[16:10:44] <BBB> remove unneeded bias from ...?
[16:10:52] <mru> yes
[16:11:00] <mru> and the fmtconvert one
[16:11:18] <ruggles> Separate format conversion DSP functions from DSPContext
[16:13:26] <BBB> mru: first oen reviewed
[16:15:16] <BBB> hm, the fmtconv one mixes moving inline asm to yasm and moving it from one struct to the other
[16:15:19] <BBB> that kind of sucks
[16:15:23] <BBB> anyway, I'm looking at it
[16:32:18] <BBB> mru:  [PATCH] Add muxers.texi as dependency to ffmpeg.pod OK with you? or you want ot make it a varlist?
[16:32:29] <mru> I want a list
[16:34:14] <ruggles> BBB: i don't see where the fmtconvert patch moves inline asm to yasm...
[16:37:04] * mru yells at BBB
[16:42:16] <BBB> mru: ?
[16:42:18] <BBB> I did nothing!
[16:42:25] <mru> you applied a patch that broke ts test
[16:42:32] <BBB> huh?
[16:42:38] <mru> fate is crying
[16:43:01] * elenril pats fate
[16:44:03] <BBB> hum
[16:44:06] <BBB> what changed?
[16:44:07] <BBB> I'm confused
[16:44:22] <jannau> probably changed PIDs
[16:44:37] <mru> but I don't see how
[16:44:43] <BBB> -    service->pmt.pid = DEFAULT_PMT_START_PID + ts->nb_services - 1;
[16:44:43] <BBB> +    service->pmt.pid = ts->pmt_start_pid + ts->nb_services;
[16:44:47] <BBB> the -1 went missing
[16:44:57] <mru> ah, there it is
[16:45:08] <BBB> can you fix it?
[16:45:14] <BBB> I have student proposals to read
[16:45:18] <gfto> BBB: no it is not :)
[16:46:00] <mru> what is not what?
[16:46:01] <gfto> DEFAULT_PMT_START_PID was constant when replaced with variable, -1 gives the wrong pid
[16:46:15] <mru> patch or gtfo :)
[16:46:18] <gfto> thats why I removed it :)
[16:46:34] <mru> the patch changes the default output
[16:46:34] <BBB> the -1 is because nb_streams starts at one
[16:46:47] <BBB> and start_pid should be the number itself
[16:46:54] <BBB> so you crrect for nb_streams being 1 by subtracting one
[16:46:57] <BBB> it should be there
[16:47:07] <BBB> mru: can you run lavf-ts with -1 re-added to confirm it fixes it?
[16:47:09] <mru> putting the -1 back makes the test pass
[16:47:14] <BBB> please commit
[16:47:28] <jannau> no. change the default instead
[16:47:40] <mru> that makes no sense
[16:47:41] <BBB> jannau: then it's lexicographically wrong
[16:47:52] <BBB> the -1 is correct from a user perspective
[16:47:55] <mru> yes
[16:48:05] <BBB> the number should be set to start_pid for the first program
[16:48:10] <BBB> right now it's set to start_pid+1
[16:48:10] <mru> pid == base+index
[16:48:15] <BBB> -1 sets it back to start_pid
[16:48:15] <mru> index == count - 1
[16:48:22] <BBB> exactly
[16:48:25] <jannau> ah, yes. I was confused
[16:51:05] <gfto> BBB: may be it is better to set default in AVOpiton to be 0x1001 to preserve the old numbering when the ption is not used
[16:51:30] <gfto> my logix was that setting -pmt-start pid you want this pid to be the pmt pid, not something else
[16:51:53] <mru> that's exactly what you get with my patch
[16:52:01] <mru> you were setting it to one more
[16:53:56] <BBB> gfto: read mru's explanation up there, it's not start_pid that's wrong, it's stream_idx that is wrong; you're not reading stream_idx, you're readng stream_cnt, which is stream_idx+1, so you're etitng start_pid one too high
[16:54:00] <BBB> er, stream_pid
[16:56:03] <BBB> mru: "[PATCH] In video_thread(), disable logging of rescaled timestamps if DEBUG is not enabled" - why did you say it's ok to _not_ fold the calculation innto the av_dlog()?
[16:56:26] <mru> because the calculation is always needed
[16:56:41] <mru> the dlot() prints both the old and new values
[16:57:08] <mru> dlog
[16:57:45] <BBB> ok, feel free to commit then
[16:58:08] <mru> I already did
[16:58:45] <CIA-38> ffmpeg: Mans Rullgard <mans at mansr.com> master * r740ad0d14d ffmpeg/libavformat/mpegtsenc.c:
[16:58:45] <CIA-38> ffmpeg: mpegtsenc: fix PMT PID calculation
[16:58:45] <CIA-38> ffmpeg: 445996aa51f4f1d9a26456a8511988291a720ba0 caused the PMT PID to be
[16:58:45] <CIA-38> ffmpeg: off by one. This corrects it.
[16:58:45] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[16:59:43] <BBB> can you say "queued" - so I don't look at the threads then? :-p
[16:59:55] <gfto> hmm, I was mistaken in thinking that pmt start_pid should be the first pid :) tricky. It is pmt_start_pid-1, may be the docs should be fixed as wall
[17:00:11] <mru> no, that's not it
[17:01:13] <BBB> gfto: service->pmt.pid = DEFAULT_PMT_START_PID + ts->nb_services - 1;
[17:01:18] <BBB> gfto: see how that's calculated?
[17:01:29] <gfto> BBB: yes, and DEFAULT_PMT_START_PID was 0x1000
[17:01:32] <BBB> gfto: START_PID (or your AVOption setting) is the first pid right?
[17:01:36] <BBB> what is nb_services?
[17:01:51] <mru> sounds like number of services to me
[17:02:00] <BBB> mru: sshhhh, I want him to see it ;)
[17:02:15] <gfto> when I replaced with options, I saw that setting the option give me one less so I presumed I was doing something stupid and removed the -1 (that was obviously stupid :)
[17:02:21] <mru> BBB: have you considered a career in teaching?
[17:02:35] <av500> ho chose teching
[17:02:38] <av500> he
[17:02:40] <BBB> mru: I'm actually teaching a class right now
[17:02:46] <av500> while on irc?
[17:02:51] <BBB> no
[17:02:57] <BBB> while at university in general
[17:03:11] <BBB> gfto: explain to me in your own words what the variable nb_services represents in the above line of code
[17:03:14] * mru has dabbled a little in teaching
[17:03:20] <mru> quite frustrating at times
[17:03:38] <gfto> BBB: number of services (rfrom the top of my mind)
[17:04:03] <BBB> gfto: right
[17:04:09] <BBB> gfto: so let's assume a simple case
[17:04:22] <BBB> gfto: where we have a simple file with just one single audio service, that's all, nothing else
[17:04:28] <BBB> gfto: what is the value of that variable?
[17:05:00] <gfto> zero if it is used as index 1 if it is used as count
[17:05:11] <BBB> is it an index or a count?
[17:05:43] <gfto> "for(i = 0; i < ts->nb_services; i++) " I would say count
[17:06:04] <BBB> right
[17:06:07] <BBB> so what is the value then?
[17:07:00] <gfto> one
[17:07:05] <BBB> ok
[17:07:09] <BBB> let's go back to the line of code now
[17:07:10] <BBB> service->pmt.pid = DEFAULT_PMT_START_PID + ts->nb_services - 1;
[17:07:32] <BBB> what is the value that will be written in service->pmt.pid, if DEFAULT_... is 0x1000, ts->nb_services is 1?
[17:07:49] <av500> 42?
[17:08:08] <gfto> 0x1000 :)
[17:08:29] <BBB> gfto: and is that what you would expect to happen?
[17:08:38] <bunniefoofoo> is there a trick to ffmpeg encoder when setting thread_count in AVCodecContext? I have set it to "2" and only see a slight boost in mpeg2 encoding
[17:08:52] <BBB> as a user, using --start_pid=0x1000, do you think it should write 0x1000 for the first service?
[17:08:56] <{V}> BBB in teacher mode is a little scary :)
[17:09:20] <bunniefoofoo> do I have to use a bigger encoding buffer perhaps?
[17:09:30] <BBB> bunniefoofoo: #ffmpeg please
[17:09:36] <bunniefoofoo> ok
[17:10:30] <BBB> gfto: and now also look at your code: service->pmt.pid = ts->pmt_start_pid + ts->nb_services; <-  if pmt_start_pid is 0x1000 and ts->nb_services is 1, what is the value that it writes now? and is that value still correct if a user specified --start_pid=0x1000?
[17:14:06] <gfto> BBB: now I'm testing with "-mpegts_pmt_start_pid 0x1000" and the output file have PMT pid set 0x0fff (that is with mru's fix to add back -1)
[17:14:39] <gfto> the input file have 1 program with audio and video
[17:15:41] <BBB> uh
[17:15:45] <BBB> then the original test is wrong
[17:15:47] <BBB> hm
[17:16:04] <BBB> mru: look below
[17:16:08] <BBB>     service->pmt.pid = ts->pmt_start_pid + ts->nb_services;
[17:16:09] <BBB>     service->sid = sid;
[17:16:09] <BBB>     service->provider_name = av_strdup(provider_name);
[17:16:09] <BBB>     service->name = av_strdup(name);
[17:16:09] <BBB>     service->pcr_pid = 0x1fff;
[17:16:10] <BBB>     dynarray_add(&ts->services, &ts->nb_services, service);
[17:16:15] <BBB> I think fate is wrong
[17:16:18] <mru> I was just looking at that
[17:16:31] <BBB> who on earth wrote that fate test?
[17:16:47] <mru> that's not the question
[17:16:56] <mru> who wrote the muxer is
[17:17:19] <gfto> it always generated 0xfff for pmt even if the define says 0x1000
[17:17:46] <gfto> "always" as in when there is one program
[17:18:06] <gfto> so fate was right to be become red (thats my fault)
[17:18:15] <BBB> gfto: apologies, I'm wrong and fate is wrong
[17:18:28] <BBB> anyway, let's fix fate
[17:18:36] <gfto> BBB: no probs, it is the end of day and can't really think straight
[17:18:39] <mru> the code is fucked up
[17:19:17] <mru> besides, generating dvb tables is ridiculous
[17:19:27] <mru> nobody would ever use ffmpeg to feed a broadcaster
[17:19:43] <gfto> I'm to blame here because silently fixed that bug forgeting about fate tests that will expect old default values, cest la vie :)
[17:19:55] <mru> we're all at fault here
[17:20:53] <gfto> well I'm using for some kind of broadcast application althou I don't care about SDT being there or pmt pids, etc :)
[17:21:29] <mru> the real sdt has to be generated by the broadcaster
[17:21:34] <mru> nobody else knows what to put in it
[17:21:43] <Tjoppen> mru: a user was appearently able to use it to feed a QAM modulator using a hackish patch of mine to fix the current pcr issue
[17:22:04] <mru> a qam modulator can be fed with any stream of bits
[17:22:07] <mru> it's just a modulator
[17:22:30] <Tjoppen> true. appearently it didn't accept the stream before though
[17:22:37] <Tjoppen> he probably meant something else
[17:22:57] <Tjoppen> and of course, the real test is whether an stb will take it :o
[17:23:22] <mru> on the modulators I've used you'd just set the modulation parameters and start feeding bits
[17:34:12] <av500> BBB: might be too late now for your NY flat: http://www.ikeahackers.net/2011/01/when-imac-goes-to-work.html
[18:06:02] <jannau> mru: fabrice did the dvb tables for his hacked graphic card^W^W^W custom built DVB-T modulator
[18:07:04] <jannau> http://bellard.org/dvbt/
[18:07:15] <mru> oh yes, that thing
[18:35:36] <ruggles> do i have to reply directly to the previous patch in order for patchwork to not duplicate it?
[18:35:58] <mru> patchwork still duplicates
[18:36:54] <ruggles> oh, ok. i've been manually mark my previous patch as superceded. is that the right thing to do?
[18:37:17] <mru> I haven't found a better way
[18:37:21] <mru> jannau might know
[18:40:42] <jannau> wait for me doing it
[18:41:53] <jannau> I need a little time make patchwork useful
[19:13:17] <wbs> BBB: I can give it another look, I started looking at it some weeks ago, but it was less trivial than I had hoped for
[19:51:22] <Jumpyshoes> BBB: make fate if failing for me on HEAD on h264-lossless
[19:52:29] <wbs> nitpick point of the day: HEAD isn't equal to trunk in SVN-land - HEAD is whatever you have checked out currently (which may be an old version or whatever), master is the name of the main branch
[19:52:39] <Jumpyshoes>  BBB: oh wait, i might need to update my fate samples
[20:18:30] <mru> wbs: nitpick2: there's no requirement to have a 'master' branch
[20:19:29] <wbs> mru: true
[20:20:04] <wbs> but that's probably what people mean in most of those cases. if really nitpicky, one should of course say which repo's master one refers to, too
[20:20:16] <Jumpyshoes> BBB: http://ffmpeg.pastebin.com/qaWi8ga8 patch to remove the GPL stuff
[20:20:25] <mru> wbs: or just say the sha1
[20:21:02] <mru> Jumpyshoes: someone gave permission to relicense?
[20:21:20] <wbs> mru: yeah, that's of course the best if you want to refer to something that specific
[20:21:51] <Jumpyshoes> mru: holger, yes
[20:22:00] <BBB> mru: they all did
[20:22:03] <elenril> the commit message should say that then
[20:22:08] <BBB> mru: I chased holger until he said yes/no
[20:22:19] <BBB> Jumpyshoes: yeah, make sure that's clear from the commit msg, and then send to the ML, I'll apply for you
[20:22:25] <CIA-38> ffmpeg: Reimar Döffinger <Reimar.Doeffinger at gmx.de> master * r8cb3c557a9 ffmpeg/libavformat/oggparsevorbis.c:
[20:22:25] <CIA-38> ffmpeg: Ogg: discard non-essential metadata from Vorbis header when creating extradata
[20:22:25] <CIA-38> ffmpeg: The first part of the metadata, the "vendor" string, is required by
[20:22:25] <CIA-38> ffmpeg: libvorbis, it will refuse to play when it is not available.
[20:22:25] <CIA-38> ffmpeg: Also we do not currently parse that part into metadata so it would also
[20:22:26] <CIA-38> ffmpeg: be lost if we removed it as well.
[20:22:27] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[20:22:33] <Jumpyshoes> BBB: ok, just making sure fate works
[20:22:35] <BBB> permission was given by Jason/Loren earlier, and by Holger just a few days ago
[20:22:40] <mru> the commit message should if possible reference a public notice about the relicensing
[20:23:50] <Jumpyshoes> BBB: was there a public notice?
[20:26:35] <mru> ruggles: what's new in your latest bias removal patch?
[20:27:29] <BBB> Jumpyshoes: no
[20:27:34] <BBB> Jumpyshoes: but I have chatlogs
[20:27:48] <BBB> Jumpyshoes: I'll ask holger to ack it on the ML once you've sent the patch
[20:28:19] <Jumpyshoes> BBB: okay, what's his last name again?
[20:28:42] <BBB> lubitz
[20:28:48] <Jumpyshoes> oh, thx
[20:37:01] <Jumpyshoes> BBB: so about the other project, i had some of the registers loaded inside the code for the predicts. making another function will = slower code, is that okay?
[20:37:17] <Jumpyshoes> BBB: probably will cut code size by a lot though
[20:38:21] <elenril> Jumpyshoes: are you going for gsoc?
[20:38:53] <Jumpyshoes> elenril: too young
[20:38:58] <Jumpyshoes> elenril: otherwise i would
[20:39:18] <ruggles> mru: i just changed HAVE_6REGS per comment from BBB
[20:39:31] <Jumpyshoes> elenril: developing for open source projects = resume++, and i like working on asm
[20:39:37] <Jumpyshoes> elenril: so just doing this for fun
[20:39:52] <elenril> gsoc is so restrictive?
[20:39:53] <elenril> o_0
[20:40:09] <Jumpyshoes> elenril: i'm 17, you need to be 18
[20:40:48] <wbs> don't you have to be enrolled at a university/college or similar, too?
[20:41:39] <Jumpyshoes> i will be by the time gsoc starts, but i'm still too young
[20:42:10] <wbs> ah, ok
[20:42:37] <wbs> too bad
[20:42:48] * elenril feels old
[20:42:48] <Jumpyshoes> well, there's always next year
[20:44:47] <BBB> Jumpyshoes: you don't have to unload registers when calling
[20:44:55] <BBB> Jumpyshoes: if you call a function, the registers are still intact
[20:45:11] <BBB> Jumpyshoes: so you can load, call, work on the loaded regs, ret and then continue specific stuff
[20:45:29] <mru> custom calling conventions ftw
[20:45:33] <Jumpyshoes> BBB: unless you want me to have four different load functions, i don't know if that will work
[20:46:20] <BBB> Jumpyshoes: are values loaded in different registers for each function?
[20:46:25] <BBB> that would kind of suck
[20:46:29] <BBB> can you "generalize" that?
[20:46:39] <BBB> mru: indeed, custom calling convention ftw
[20:46:41] <BBB> \o/
[20:46:57] <mru> and multiple entry points
[20:47:04] <Jumpyshoes> BBB: yes, but not without a speed decrease
[20:47:18] <BBB> Jumpyshoes: these functions aren't used terribly much, so a 1 cycle loss is ok
[20:47:23] <BBB> if size decreases with a few kb
[20:47:24] <Jumpyshoes> BBB: okay
[20:47:41] <BBB> Jumpyshoes: but don't go out of your league, this is not terribly important, if it takes more than afew minutes, do something else that is more fun
[20:47:42] <BBB>  :)
[20:47:55] <Jumpyshoes> oh, this will take more than a few minutes <_<
[20:48:14] <BBB> then don't do it :-p
[20:48:19] <Jumpyshoes> heh, okay
[20:49:20] <BBB> what would you like to learn?
[20:49:24] <BBB> that's much more important
[20:49:33] <BBB> what do you want to do if you were to, say, do ffmpeg for another year
[20:50:00] <elenril> we could use a new leader
[20:50:04] * elenril hides
[20:50:06] <Jumpyshoes> LOL
[20:50:30] <Jumpyshoes> BBB: hrm, that's a good question... i don't have anything in mind atm except asm
[20:50:58] <Jumpyshoes> BBB: i think that since i plan to work on this for a while, i'd also like to learn more about ffmpeg in general, since it's important to broading your scope when learning
[20:51:13] <Jumpyshoes> BBB: so i guess i'm pretty open to anything really
[20:51:32] <_av500_> pts guessing?
[20:54:40] <BBB> Jumpyshoes: asm is really just "the cpu-intensive tasks that can be vectorized" - you could do more on generic video coding structure
[20:54:58] <BBB> Jumpyshoes: have you ever considered - just for a change - to implement a video decoder for a simple format yourself?
[20:55:06] <BBB> Jumpyshoes: at some point we can teach you how to RE a video codec
[20:55:11] <BBB> kshishkov is really good at that
[20:55:42] <Jumpyshoes> BBB: hrm... that sounds interesting
[20:56:19] <Jumpyshoes> BBB: no clue how complex/hard that would be, but it would allow me to learn more about video decoding in general
[20:56:27] <BBB> that was my idea
[20:57:11] <Jumpyshoes> BBB: haha yea, that sounds like something i could like. also, what is RE a video codec?
[20:57:41] <BBB> reverse engineer
[20:58:00] <BBB> so rather than working from a defined video coding structure, work from a binary that decodes a video file and try to recreate it in c
[20:58:05] <Jumpyshoes> oh, i'm also interested in reverse engineering in general too, that works out real nice
[20:58:21] <BBB> it's a little more obsessive, very complex in a way, so I'd go with a simple video codec first before going to more complex reverse engineering
[20:58:33] <BBB> you have asm knowledge, so reverse engineering is not completely impossible
[20:58:38] <BBB> in fact you'd be quite good at it
[20:58:41] <mru> it helps being familiar with common coding methods
[20:58:42] <BBB> since you can read/write asm
[20:58:47] <saintdev> bink-b ^_^
[20:58:49] <mru> so you recognise a dct when you see one
[20:58:54] <BBB> yeah
[20:59:09] <BBB> and then you don't have to RE it only to throw it away later because ffmpeg already has a better one
[20:59:13] <_av500_> mru: if you are lucky that the codec has one :)
[20:59:20] <Jumpyshoes> i see
[20:59:21] <Jumpyshoes> that makes sense
[21:00:05] <_av500_> thresh: the eagle has landed
[21:01:33] <BBB> Jumpyshoes: let's take it slowly and have you work on a defined video codec first, you already know h264 so a simpler one should be super-easy
[21:01:49] <BBB> if you're interested
[21:01:58] * BBB goes look for unimplemented video codecs or features
[21:02:18] <mru> vp7
[21:02:28] <Jumpyshoes> i don't actually know h264 that well, since i've only been working on asm
[21:02:33] <BBB> a pretty interesting thing would be wmv2 j-frames (or was that done already?) or rv40 bidir prediction (but that involves RE'ing)
[21:02:45] <mru> http://wiki.multimedia.cx/index.php?title=Category:Undiscovered_Video_Codecs
[21:02:48] <mru> ^^ take a pick
[21:02:49] <BBB> Jumpyshoes: well it goes two ways, you'll get to know h264 better by working on other video codecs
[21:03:12] <Jumpyshoes> BBB: yea, true
[21:03:21] <mru> working on vp8 is so full of wtf moments
[21:03:22] <BBB> coding techniques are often similar
[21:03:27] <BBB> mru: whehe :)
[21:03:44] <mru> why can't they just use normal rounding everwhere?
[21:04:10] <saintdev> i thought we had a REDcode decoder?
[21:04:42] <mru> we have a demuxer
[21:04:48] <Dark_Shikari> But Jumpyshoes said he was going to do useful stuff, like k-mean or non-local RD =p
[21:04:54] <Dark_Shikari> don't steal him ;)
[21:05:27] <Jumpyshoes> i'm working on avx actually
[21:05:39] <Jumpyshoes> but it's kinda annoying backtracking to find out where the slowdowns occured
[21:06:00] <mru> you have avx hw?
[21:06:23] <Jumpyshoes> oh, no
[21:06:32] <Dark_Shikari> You don't need it to convert 2 operand to 3 operand code
[21:06:42] <Dark_Shikari> But I'm getting some benching hardware soon
[21:06:42] <Jumpyshoes> ^ yea
[21:06:49] * mru sends Jumpyshoes an old vax machine
[21:06:55] <Dark_Shikari> and one of the .jp guys who hangs around #x264 just installed a sandy bridge
[21:06:58] <Dark_Shikari> so he can bench
[21:07:02] <Dark_Shikari> Jumpyshoes: harass boiled_sugar to bench for you~
[21:07:17] <boiled_sugar> ?
[21:07:22] <Jumpyshoes> Dark_Shikari: oh, i mean in non-avx mode
[21:07:35] <Dark_Shikari> Oh, it'd be useful to bench your avx changes too though.
[21:07:38] <Jumpyshoes> http://x264.pastebin.com/euy21LYE so like all these are slower w/ the 3 operand abstraction layer
[21:07:46] <Jumpyshoes> oh, i plan on doing that too
[21:07:55] <Jumpyshoes> as soon as i actually initialize the function <_<
[21:17:22] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * r80ba1ddb58 ffmpeg/libavcodec/ (21 files in 4 dirs):
[21:17:22] <CIA-38> ffmpeg: Remove unneeded add bias from 3 functions.
[21:17:22] <CIA-38> ffmpeg: DSPContext.vector_fmul_window()
[21:17:22] <CIA-38> ffmpeg: DCADSPContext.lfe_fir()
[21:17:22] <CIA-38> ffmpeg: SynthFilterContext.synth_filter_float()
[21:17:23] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:17:24] <CIA-38> ffmpeg: Justin Ruggles <justin.ruggles at gmail.com> master * rd19b744a36 ffmpeg/libavcodec/x86/dsputil_mmx.c:
[21:17:24] <CIA-38> ffmpeg: cosmetics: indentation
[21:17:25] <CIA-38> ffmpeg: Signed-off-by: Mans Rullgard <mans at mansr.com>
[21:31:30] <BBB> ruggles: nice work!
[21:32:16] * Dark_Shikari pokes BBB to bench his patch.
[21:32:25] <BBB> oops, forgot
[21:32:25] <ruggles> BBB: thanks
[21:32:36] <BBB> I still have it here, I'll bench tonight, promise
[21:32:40] <BBB> at work  now, can't bench
[21:32:46] <BBB> Dark_Shikari: please review my emu_ege patch in return
[21:35:00] <Jumpyshoes> BBB: what do you think the chances are of me getting a summer internship at google <_< the microsoft thing didn't work since i'm too young
[21:35:29] <merbanan> ruggles: \o/
[21:35:30] <Dark_Shikari> BBB: why do you have special x86_64 code to use rax instead of an mmx register?
[21:35:34] <Dark_Shikari> it's not any faster
[21:35:45] <Dark_Shikari> why are you using movdqu ?
[21:39:13] <Dark_Shikari> for left/right: try pshufb
[21:48:10] <BBB> Dark_Shikari: shorter opcode
[21:48:25] <BBB> Dark_Shikari: the x86-64 code is really tight, one of them is exactly 128 bytes
[21:48:36] <BBB> any change for the worse and I need to move to 256-byte blocks
[21:48:39] <BBB> which would suck
[21:48:55] <Dark_Shikari> ah
[21:49:27] <Dark_Shikari> on FASTSHUFFLE CPUs, pshufb can go from a -> aaaaaaaaaaaaaaaaa in one cycle
[21:49:38] <BBB> using pxor as third reg?
[21:49:41] <BBB> that's nice
[21:49:46] <BBB> hm, should look into that
[21:49:50] <Dark_Shikari> on Atom, it's 6 cycles, unpipelined
[21:49:56] <Dark_Shikari> on Conroe, it's 2, unpipelined
[21:50:12] <Dark_Shikari> I suggest you rip cpu detection code from x264 to detect this, and possibly add the fastshuffle flag to ffmpeg.
[21:52:59] <Flameeyes> mru: ping
[21:53:41] <BBB> even on atom that may be faster than what I currently do (mov ah, al; movd mm, eax; pshufw mm, mm, 0, movqx2
[21:54:33] <Dark_Shikari> punpcklbw is slower than that?
[21:54:35] <Dark_Shikari> punpcklbw + pshufw
[21:54:36] <mru> Flameeyes: pong
[21:54:56] <Flameeyes> mru: am I missing something or for whatever reason the symbol and string tables of ELF libraries are loaded into memory?
[21:56:39] <BBB> Dark_Shikari: I need the ax for shorter movs anyway (e.g. 18 bytes = movq+movq+mov-word)
[21:56:52] <mru> Flameeyes: perhaps for use when resolving symbols in shared objects loaded later
[21:56:55] <BBB> so I always fill byte->word using mov ah, al
[21:57:08] <BBB> by lack of pextrw in mmx basic instruction set
[21:57:21] <Dark_Shikari> Also, BBB, what about the fact that in filling 'right', you're allowed to write more bytes than necessary
[21:57:25] <Dark_Shikari> but you can't do so when filling 'left'?
[21:57:25] <Flameeyes> mru: yeah I know many of the possible "whatever reason".. just wanted to confirm I wasn't on drug when I saw them loaded
[21:57:35] <Dark_Shikari> Well, I guess you can do that on left, just not on the first row.
[21:58:00] <BBB> Dark_Shikari: "write more bytes"? I don't think you can do that, I copy body first
[21:58:05] <BBB> you don't want to overwrite that
[21:58:16] <Dark_Shikari> er...
[21:58:23] <Dark_Shikari> [left] [body] [right]
[21:58:30] <Dark_Shikari> [left] [body] [rightXXXXXXXXXXXXX]
[21:58:32] <Dark_Shikari> where X are extra bytes
[21:58:35] <Dark_Shikari> what did I overwrite?  nothing.
[21:58:43] <BBB> no, but wrt left
[21:58:52] <Dark_Shikari> [XXXXXXleft] doesn't overwrite anything either
[21:59:20] <BBB> on emu_edge, XXX is the last pixels of the previous line, which for line=0 is the previous block
[22:00:36] <Dark_Shikari> The previous line is of size stride.
[22:00:37] <Dark_Shikari> It's big.
[22:00:46] <Dark_Shikari> Though I guess in theory it might not be big enough?
[22:00:50] <Dark_Shikari> for tiny tiny images?
[22:00:57] <Dark_Shikari> ... we should have a fate test for that.
[22:03:47] <Kovensky> talking about fate, I see that the docs all refer to svn
[22:11:00] <BBB> Dark_Shikari: it could be packed, I don't trust it... besides, this is shit-ass fast already :-p
[22:11:21] <BBB> Dark_Shikari: don't optimize too much for 16-byte left/right edges, for both h264 and vp8, most edges are 1 or 2 pixels
[22:11:27] <BBB> most being like 90%
[22:11:45] <BBB> brb
[22:12:12] <Dark_Shikari> k
[22:12:53] <Dark_Shikari> BBB: lgtm'd
[22:12:54] <Dark_Shikari> afk
[23:02:10] <Sean_McG> mru: any more motion on patch 704?
[23:03:39] <mru> poke peloverde
[23:33:20] <saintdev> ruggles: what's the reasoning behind using an iir filter for attack detection?