[FFmpeg-devel-irc] IRC log for 2010-07-10

[irc at mansr.com]

[00:04:58] <peloverde> hmm... I wonder if I'm screwing up the conversion from 24-bit pcm
[00:05:27] <mru> are you using the iso ref files?
[00:05:43] <peloverde> yes
[00:05:52] <mru> I couldn't make sense of them either
[00:06:26] <mru> it looks like ffaac outputs a swath of near-zero samples at the start that's not in the ref files
[00:07:03] <Dark_Shikari> windowing issue?
[00:07:11] <Dark_Shikari> mdct priming?
[00:07:20] <peloverde> The reference decoder seems to delay the files 2048 samples more than the reference rendering
[00:07:48] <peloverde> The SBR conformance tool requires those samples
[00:08:31] <Dark_Shikari> is that the mdct size or something?
[00:09:03] <peloverde> It's twice the mdct size
[00:11:48] <peloverde> I wonder what rounding policy sox uses when I convert them
[00:41:45] <CIA-99> ffmpeg: mru * r24153 /trunk/libavutil/pixdesc.c: pixdesc: add missing includes
[00:41:46] <CIA-99> ffmpeg: mru * r24154 /trunk/libavutil/lfg.c: lfg: add missing includes
[00:41:46] <CIA-99> ffmpeg: mru * r24155 /trunk/libavutil/intreadwrite.h: intreadwrite: common.h is not needed, attributes.h is sufficient
[00:46:59] <peloverde> On one of these files the information at the begining is on-zero, wonder-fucking-ful
[00:47:18] <peloverde> Why do the reference renderings not match the reference decoder delay wise?
[01:05:27] <Compn> wow
[01:05:34] * Compn likes turbo option
[01:05:47] <Compn> 3fps > 24fps for first pass
[01:06:04] <Dark_Shikari> "turbo option"?
[01:06:15] <Compn> mencoder -lavcopts turbo
[01:06:20] * Compn forgets what it does
[01:06:34] <Dark_Shikari> for xvid or something?
[01:06:41] <Compn> for ... lavc
[01:06:51] <Dark_Shikari> lavc what
[01:06:58] <Compn> lavc encoding
[01:07:04] <Dark_Shikari> lavc is a library
[01:07:05] <Dark_Shikari> it has many encoder
[01:07:08] <Dark_Shikari> *many encoders
[01:07:10] <Compn> ooh sorry
[01:07:12] <Compn> mpeg4 asp
[01:07:32] <Compn> but i fink it works on other codecs
[01:07:38] <Compn> it maybe motion est etc
[01:07:41] * Compn looks up
[01:08:18] <Compn> To shave off some encoding time, you can specify the turbo option on the first pass; this reduces subq and frameref to 1.
[01:08:44] <Dark_Shikari> Those are x264 options.
[01:09:12] <Compn> well, i pasted that from the x264 part yes
[01:09:18] <Compn> but turbo is listed under libavcodec section too
[01:09:26] <Compn> btw i still havent fixed the b-pyramid stuff in the mencoder docs ;\
[01:10:30] <Compn>       turbo (two pass only)
[01:10:30] <Compn>               Dramatically speeds up pass one using faster algorithms and disabling CPU-intensive options.  This will probably reduce  global  PSNR  a  little  bit (around 0.01dB) and change individual frame     type and PSNR a little bit more (up to 0.03dB).
[01:10:49] <Compn> from man, under lavcopts
[01:11:10] <Compn> so i guess whatever 'cpu-intensive options' exactly means is still a mystery
[01:11:25] * Compn capturing vhs
[01:11:32] <Compn> any point in using x264 for vhs captures? :P
[01:11:58] <peloverde> I sent an e-mail to mp4-tech, if no one responds, I'll escalate to mpam next week
[01:12:27] <Dark_Shikari> Compn: of course, x264 already does its own turbo automatically
[01:12:30] <Dark_Shikari> mencoder is just old and doesn't use it
[01:12:57] <Compn> mencoder isnt old, it died and became a zombie. it just wont stop!
[01:13:05] <Compn> isnt just old*
[01:13:23] <Compn> but ok, thats a good idea Dark_Shikari :)
[01:13:31] <Dark_Shikari> you should write a patch
[01:13:33] <Dark_Shikari> it takes 5 minutes
[01:13:42] <Compn> Dark_Shikari : also, i wonder... is it worth it to use grayscale decoding for 1st pass ?
[01:13:50] <Compn> i heard somewhere gray decode was faster...
[01:13:54] <Dark_Shikari> extremely marginally
[01:13:55] <Dark_Shikari> not worth it
[01:13:59] <Dark_Shikari> and it'll be less accurate
[01:14:13] <Compn> ah
[01:14:32] <Compn> well if i can dig up a commit that added some other x264 option to mencoder, i guess i can copy pasta
[01:14:58] <Compn> but i'm in that non-programmer boat that diego is stuck in
[01:16:34] <ohsix> Dark_Shikari: what parameters would you use for the best quality regardless of cpu time spent
[01:16:44] <Dark_Shikari> --qp 0
[01:16:45] <Dark_Shikari> done ;)
[01:16:52] <ohsix> for something that would end up, say, 700mb
[01:17:01] <Dark_Shikari> ok, in that case --preset placebo.
[01:17:24] <ohsix> i got to mess with some 264 stuff in handbrake the other day and there was some obvious stuff
[01:17:42] <ohsix> is qp 0 lossless or something?
[01:17:44] <Dark_Shikari> yes
[01:17:52] <Dark_Shikari> you asked best quality
[01:17:55] <Dark_Shikari> so I answered lossless
[01:17:55] <Dark_Shikari> =p
[01:17:58] <ohsix> right :P
[01:18:02] <ohsix> at least you winked
[01:18:21] <Compn> hmm
[01:18:22] <ohsix> will fancy motion search and stuff get you much if you're crunching 80 minutes into 700mb?
[01:18:33] <Compn> ohsix : always.
[01:18:59] <Compn> Dark_Shikari : did you guys all take a break from porting x264 optimizations > ffwebm ?
[01:19:40] <Compn> ohsix : in fact... the more cpu intensive options you use, the better bang (quality) for your buck (bitrate)
[01:20:06] <ohsix> so just turn them all on?
[01:20:14] <ohsix> or where i can pick an integer pick the largest
[01:20:21] <Compn> if <any encoder> knows there are 100 frames without motion, it can save bits from there to use in other high motion frames ;p
[01:20:46] <Compn> read ahead motion estimation
[01:20:56] <Compn> or something
[01:20:59] <ohsix> hm, how can i measure the difference between the source and what i encode; that might be a more useful question
[01:21:07] <Dark_Shikari> ohsix: --preset placebo
[01:21:10] <Dark_Shikari> =p
[01:21:15] <Compn> psnr or ssrn or whatever its called
[01:21:18] <ohsix> is that ironically named?
[01:21:19] <Dark_Shikari> Compn: we're waiting on bbb to stop being lazy
[01:21:20] <Compn> best to measure using eyes tho
[01:21:30] <Dark_Shikari> ohsix: It's named for the people who would pick ANY OPTION that made things slower
[01:21:36] <ohsix> can only trust eyes when it gets _really_ bad
[01:21:37] <Dark_Shikari> And you know those people =p
[01:21:45] <ohsix> ah, cool
[01:21:49] <Dark_Shikari> placebo is the slowest option
[01:21:53] <Compn> its ironic and unironic at the same time
[01:21:58] <Dark_Shikari> it's very very marginally better than the next-slowest ("veryslow")
[01:22:01] <ohsix> theres no junk in there that really doesn't need to be slow?
[01:22:01] <Dark_Shikari> and a lot slower.
[01:22:16] <Dark_Shikari> everything that's on in placebo does actually help, it just helps so little it's a waste of time
[01:22:25] <ohsix> k cool
[01:22:28] <Dark_Shikari> <ChronoCross> I feel as though ----------------------tesa should be an option. it should be compareable to lossless with the side effect of it taking an eternity to encode.
[01:22:29] <Compn> sounds like Dark_Shikari needs to write a faq on x264 options
[01:22:32] <Dark_Shikari> <ChronoCross> I guarantee 90% of the people in this channel and doom9 would use it.
[01:22:32] <ohsix> waste of time is what i'm looking for \m/
[01:22:35] <Dark_Shikari> <pengvado> no, it has to be blatantly obvious.
[01:22:37] <Dark_Shikari> <pengvado> --placebo
[01:22:40] <Dark_Shikari> <pengvado> which makes your encode 10x slower and donates the difference to folding at home
[01:22:43] <Dark_Shikari> Compn: --help
[01:22:44] <Dark_Shikari> --fullhelp
[01:22:46] <Dark_Shikari> --longhelp
[01:22:52] <Dark_Shikari> --wtfgigantichelp http://mewiki.project357.com/wiki/X264_Settings
[01:22:56] <Compn> well ohsix , read some manuals or join #x264
[01:23:06] <Compn> and stop user questions in devel chans
[01:23:10] <ohsix> not that interested yet; when i'm comparing snr i might
[01:23:17] <Dark_Shikari> psnr is horrible to compare
[01:23:22] <ohsix> it is OT, but i was asking Dark_Shikari, i'll stfu now
[01:23:24] <Dark_Shikari> particularly among encoders not optimized for it
[01:23:30] <Dark_Shikari> It's not OT, there's nothing else going on.
[01:25:02] <ohsix> if you're doing Eyes, is there something to do a rough scan and tell you possible trouble scenes so you don't have to watch a large portion of the video to look
[01:25:20] <Dark_Shikari> I'm not sure what you're trying to do
[01:25:22] <Compn> custom matrices? no clue
[01:25:30] <Dark_Shikari> using different options usually will not change the bit distribution
[01:25:32] <Compn> Dark_Shikari : he only wants to scan 50x60 box for motion
[01:25:37] <Dark_Shikari> so it won't change what scenes are "trouble" and what aren't
[01:25:56] <ohsix> oic
[02:07:52] <Dark_Shikari> mru:
[02:07:55] <Dark_Shikari> you should have said who it was
[02:07:59] <Dark_Shikari> fuck no do not recommend me to that guy
[02:08:15] <Dark_Shikari> Please fucking no
[02:09:32] <ohsix> who
[02:10:10] <saintdev> peloverde: ping
[02:10:15] <peloverde> pong
[02:13:10] <saintdev> peloverde: actually let me think out this question, not exactly sure how to word what i want to ask :P
[04:08:54] <CIA-99> ffmpeg: ramiro * r24156 /trunk/configure:
[04:08:55] <CIA-99> ffmpeg: configure: properly check for mingw-w64 through installed headers.
[04:08:55] <CIA-99> ffmpeg: mingw-w64 can also target 32-bit code.
[05:26:18] <peloverde> The more I read about phonon the more I can't decide if I should laugh or headdesk
[05:28:09] <ohsix> laugh, and read the impetus behind it and laugh more
[05:32:46] <elenril> how is it worse than other layers of wrappers?
[05:36:31] <peloverde> Mostly that they wrap other wrappers, and that they don't want a phonon FFmpeg because it doesn't uses libmad and libfaad and all those other libraries we've obsoleted
[05:37:55] <ohsix> and people writing wrappers usually know the software they're wrapping, and have a reason to wrap it; not knowing the subject matter makes for some amazing bodges once some tard loaded up on c++ has stubbed out a wonderful pile of classes
[05:40:24] <ohsix> though i suspect its more someone wanting to do something before they know they need to do it
[05:42:40] <elenril> isn't ffmp3 faster than libmad?
[05:43:27] <peloverde> even if not, the difference is negligible
[05:44:00] <peloverde> But people have a cargoculted affinity for these libs
[05:44:00] <elenril> http://forum.doom9.org/showthread.php?t=155516
[05:47:16] <peloverde> yes I saw that
[05:58:39] <peloverde> Wow, even our lawyer doesn't think FFmpeg is free software "Watched my first YouTube video using all free software and codecs. I feel so... clean.  #WebM"
[06:00:07] <ohsix> huhuhuhuhuhuuh
[06:00:21] <Dark_Shikari> gg sflc
[06:02:10] <pross-au> mru: u about?
[06:11:38] <elenril> anyways, i thought phonon wrapped gstreamer/dshow/xine/etc
[06:11:54] <elenril> and didn't use the libs that actually DoStuff directly
[06:13:34] <peloverde> It does
[06:13:37] <elenril> peloverde: tell him that by that logic linux isn't free software as it violates tons of patents
[06:14:33] <peloverde> elenril: It's funny that all the asshats who have made ffmpeg the new patent posterchild never seem to bitch about patents in the kernel and especially in drivers
[06:15:14] <ohsix> is there an mpeg-la for os patents; one that is constantly bloviating
[06:15:23] <pross-au> its called selective love peloverde
[06:15:43] <ohsix> the companies already making a business out of lunix have defensive portfolios if the need ever arise
[06:15:58] <peloverde> ohsix: See the FAT driver debacle
[06:16:21] <peloverde> MS suing TomTom (which was in retaliation for othershit but still)
[06:17:14] <peloverde> MPEG-LA selectively enforces on free software too, so I don't see much of a difference
[06:17:35] <ohsix> is there an ibm for ffmpeg yet
[06:18:03] <pross-au> I prefer the sweep it under the rug approach
[06:18:18] <peloverde> What does that have to do with anything, IBM didn't come to TomTom's defense
[06:18:31] <ohsix> when you're talking fud you just really need to know where it comes from, that theres a lot of fud is neither here nor there
[06:19:05] <ohsix> the penultimate attack on linux was the sco thing
[06:19:59] <Dark_Shikari> that was less of an attack and more of a comedy sketch
[06:20:00] <peloverde> ohsix: you are continuing to ignore my factual argument
[06:20:09] <ohsix> nein
[06:20:23] <ohsix> they aren't comparable, i'm saying linux is entirely different
[06:20:36] <peloverde> ohsix: What are your thoughts on MS's successful use of the FAT patent(s) against TomTom's use of Linux kernel
[06:20:49] <ohsix> moreover the scope is larger and any patent can likely be worked around, to decode a given file format you might be dead
[06:21:11] <ohsix> i think its just fat and they didn't have to air much dirty laundry to do it
[06:21:24] <peloverde> The FAT patent is essential
[06:21:38] <peloverde> In this case decoders are analogous to drivers
[06:21:52] <ohsix> if you don't create short names then you don't run afoul of the patent
[06:22:22] <ohsix> and thats how it was worked around afterwards
[06:24:11] <peloverde> And that's the equivalent of say dropping B-Frame support from the MPEG-4 encoder
[06:24:34] <ohsix> and nobody was fudding fat even though they new there were patents involved before tomtom
[06:24:52] <Dark_Shikari> peloverde: you mean mpeg-4 decoder
[06:24:55] <ohsix> nah; you can read it, and distros can even build kernels that still create short names
[06:25:21] <peloverde> Dark_Shikari: in this case I actually mean encoder because the patent was on generating long and short names at the same time
[06:25:38] <Dark_Shikari> .... that's a pretty retarded patent
[06:25:40] <ohsix> well it doesn't happen at the same time, but its good enough
[06:25:45] <peloverde> Dark_Shikari: I know
[06:25:54] <ohsix> Dark_Shikari: and how they bodged long file names in is retarded too :D
[06:26:16] <ohsix> dumb things are unique enough for a patent too, though
[06:26:55] <ohsix> and it was a defensive move to other DOS implementations right around when they started messing with stuff, and making software randomly fail "requiring" dos
[06:28:17] <ohsix> practical implication for other DOS vendors is they couldn't generate long names
[06:31:25] <peloverde> See also http://en.swpat.org/wiki/Duds_and_non-solutions
[06:35:50] <CIA-99> ffmpeg: darkshikari * r24157 /trunk/libavcodec/options.c:
[06:35:51] <CIA-99> ffmpeg: Change qmax/qmin limits to 63 instead of 51.
[06:35:51] <CIA-99> ffmpeg: VP8 supports quantizers up to 63.
[06:36:57] <ohsix> fud may as well be real; because you'll be paying someone for an opinion or a proactive defense/research
[06:37:55] <ohsix> works best where you cant be certain, and apply liberally
[07:15:45] <peloverde> Is there a way to adjust the delay for CMP = oneoff?
[07:49:48] <peloverde> Interesting main profile doesn't seem to have the delay issue
[07:55:55] <CIA-99> ffmpeg: reimar * r24158 /trunk/ (6 files in 3 dirs): Add native GSM 06.10 audio decoder.
[07:58:45] <elenril> \o/ yet another lib goes away
[08:27:17] <peloverde> mru: I have a set of AAC scattershot tests from the conformance suite
[08:31:39] <peloverde> I've kind of stuck to things that are essential or that I'm curious as to how they play on all the targets we support
[08:32:11] <peloverde> notable holes include the rigorous tests on the SBR tools, Independent coupling, downsampled SBR, IPD/OPD, PS mixing mode B
[08:32:23] <peloverde> also the uncompressed PCM references seem large
[08:32:35] <peloverde> do you think we should flac or gz them?
[08:37:39] <peloverde> I suppose I should copypasta that into an e-mail
[08:37:49] <peloverde> also why I am I still awake
[08:38:24] <peloverde> Oh also it doesn't cover any of the broken files we hack around
[08:38:50] <peloverde> ...some vague comments about cyborgs...
[08:43:26] <mru> morning
[08:43:51] <mru> Dark_Shikari: sorry, never heard of that guy before, didn't know he's a total troll (as you imply)
[08:44:59] <peloverde> mru: Do you have any thoughts on above before I send my [RFC/PATCH]?
[08:46:10] <Dark_Shikari> mru: more like one of those stupid managers who doesn't understand shit
[08:46:37] <mru> Dark_Shikari: ok, noted
[08:46:53] <mru> I'll file anything from him to /dev/null henceforth
[08:49:29] <mru> peloverde: you asked for a delay parameter...
[08:50:09] <peloverde> never mind that, I've hacked on the first few samples of my local reference rendering
[08:50:38] <peloverde> I'm hope the AHG on ASM will issue new vectors
[08:50:50] <mru> what's the problem?
[08:51:07] <peloverde> in regard to delay or otherwise?
[08:51:11] <mru> delay
[08:51:22] <mru> and otherwise
[08:51:43] <peloverde> Delay is more-or-less fixed
[08:52:36] <peloverde> Should I go ahead with my subset? should I try to get better coverage? Is 31 MB of vectors ok?
[08:53:04] <mru> go ahead and post the patch
[08:53:37] <mru> I don't think we can avoid the size
[08:54:20] <peloverde> Well we could flac or gz the pcm files
[08:55:03] <peloverde> 6 of the 7 signaling tests have identical payloads, the last makes me want to punch someone at CT in the face
[08:55:09] <mru> flac would require flac or ffmpeg installed on the test machine
[08:55:24] <peloverde> don't we already require ffmpeg on the test machine?
[08:55:29] <mru> no
[08:55:53] <peloverde> can't we just unflac it with the ffmpeg under test?
[08:56:35] <mru> I'd rather not
[08:56:51] <mru> it gets complicated for the embedded stuff
[08:57:24] <peloverde> ok
[08:58:05] <mru> it would also make all those test fail if the flac decoder breaks
[08:58:36] <peloverde> true but you could make the same argument about the mp4 demuxer
[08:59:04] <mru> aac decoder isn't very useful w/o mp4 demuxer anyway
[08:59:35] <peloverde> aac-in-adts?
[08:59:54] <mru> sure, that exists too
[08:59:59] <peloverde> It was probably the prevalent form of AAC pre iTunes
[09:00:14] <mru> possibly
[09:00:18] <mru> but not anymore
[09:01:24] <peloverde> AAC pre iPod probably had around the same marketshare as TwinVQ
[09:01:44] <peloverde> and we support .vqf
[09:02:09] <mru> so?
[09:02:20] <mru> aac in mp4 is very, very common _now_
[09:02:37] <mru> for a long time ffaac didn't even work with adts at all
[09:02:51] <mru> because the authors at the time didn't think it important
[09:03:31] <peloverde> for a long time FFmpeg didn't support twinvq
[09:03:53] <mru> look, forget history
[09:04:01] <mru> aac in mp4 is everywhere
[09:04:24] <mru> relying on the mp4 demuxer to test aac is reasonable
[09:04:34] <mru> relying on a totally unrelated decoder is not
[09:05:09] <mru> the first rule of testing is not to entangle your tests
[09:05:44] <peloverde> If I wasn't entangling tests my 13 MB archive would be 1.3 GB
[09:06:10] <mru> then don't entangle more than necessary
[09:06:21] <peloverde> using flac or gz gives me room to test more AAC features
[09:06:47] <mru> how well do the files compress with gzip or lzma?
[09:08:05] <peloverde> xz saves 25%
[09:08:17] <mru> and flac?
[09:11:56] <peloverde> flac saves 60%
[09:12:32] <mru> are people tight on diskspace?
[09:12:46] <Dark_Shikari> bandwidth?
[09:12:49] <peloverde> I'm tight on bandwidth
[09:15:09] <CIA-99> ffmpeg: mstorsjo * r24159 /trunk/libavcodec/psymodel.c: Fix a leak in the AAC encoder
[09:19:15] <mru> bandwidth doesn't matter
[09:19:22] <mru> you only download the samples once
[09:21:16] <peloverde> people are also constantly bitching about space on samples.mplayerhq.hu
[09:22:41] <mru> 30MB is nothing
[09:23:22] <Dark_Shikari> might as well compress when you can
[09:23:32] <mru> we can do it later just as well
[09:25:42] <peloverde> ok
[10:09:58] <jai> what is a "channel conversion"?
[10:10:27] <jai> and why do we care what liba52 does
[10:11:12] <markuman> i've got a question to the "missing picture in access unit" message. does parse_nal_units search for a pair of frame? http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2009-July/073538.html
[10:50:20] <mru> jai: I don't think we do care
[10:50:25] <mru> we certainly shouldn't care
[10:53:03] <jai> mru: well, the thread is "Audio conversion and floating-point codecs"
[10:53:35] <jai> some part sounded weird
[10:53:37] <jai> *parts
[10:54:05] <jai> err, libavfilter audio - af_resample
[10:54:11] <jai> ^ that thread
[10:54:57] <jai> too much focus on sdl and ffplay doesnt help either
[10:57:53] <Dark_Shikari> multimedia.cx is down
[10:58:03] <mru> jai: OH FUCK
[10:58:11] <mru> I thought I'd have more time with this
[10:58:23] <mru> he's fucking up the audio conversion all over again
[10:58:31] <jai> mru: yep :|
[10:58:37] <mru> Dark_Shikari: works for me
[10:58:42] <jai> mru: maybe you can "mentor" him or something
[10:58:46] <Dark_Shikari> 404 here
[10:58:47] <mru> I don't have time
[10:58:49] <Dark_Shikari> times out nicely
[10:58:52] <kshishkov> mru: not for me
[10:59:13] <Dark_Shikari> http://downforeveryoneorjustme.com/http://www.multimedia.cx/
[10:59:18] <Dark_Shikari> It's not just you! http://www.multimedia.cx  looks down from here.
[10:59:51] <Dark_Shikari> back up now, it seems.
[10:59:58] <mru> hmm, it was slow there for a bit
[11:00:28] <jai> ah, k
[11:00:28] <kshishkov> mru: you're not using certain Norwegian browser, are you?
[11:00:34] <mru> oh no
[11:08:38] <Transport> and down here in the uk, and ping www.multimedia.cx fails too ATM
[11:09:09] <mru> works here in southampton
[11:09:21] <Transport> virgin cable here
[11:09:27] <kshishkov> mru, try wiki
[11:09:51] <mru> loads but a bit slow
[11:11:21] <mru> dns for that domain seems down
[11:11:24] <Transport> i get the dns lookup ip number 207.45.186.114 but request time out odd
[11:11:35] <bilboed> works from spain
[11:12:06] <Compn> mru : ask some other maintainer to look at it if you dont have time
[11:12:07] <Compn> :)
[11:12:15] <Compn> -maintainer / mentor
[11:12:40] <mru> all my time is taken up fending off stupid ideas
[11:13:40] <kshishkov> hmm, wget works, browser does not
[11:14:08] <Compn> lol
[11:15:10] <Compn> multimedia.cx seems slower than www.multimedia.cx , maybe its just me :P
[11:15:17] <Compn> but all three (wiki) come up fine
[11:15:35] <mru> they're all on the same IP address
[11:16:04] <Transport> its pinging fine now.....
[11:16:19] <jai> Compn: maybe it wont be required at all since peter is looking into it as well ?
[11:16:25] <Transport> and http://downforeveryoneorjustme.com/http://www.multimedia.cx/ works to
[11:16:43] <mru> jai: I want a proper replacement for audioconvert.c, not a silly filter
[11:16:51] <jai> mru: of course, i agree
[11:16:59] <mru> please say so in the thread
[11:17:01] <Compn> mru : btw , your mail i think lacks some details as what you want the guy to do
[11:17:02] <mru> if you didn't already
[11:17:19] <jai> mru: well, i could go +1 since you phrased it better than i could :)
[11:17:24] <mru> Compn: I probably want him to crawl under some rock where he'll do no damage
[11:17:32] <Compn> which is a general problem i've seen in ffmpeg mails. e.g. lots of 'dont do this' and not so much 'do this and that'
[11:17:33] <Compn> lol
[11:18:06] <mru> I thought I was pretty clear about first making planar audio work
[11:18:15] <mru> or at least put the data structures in place
[11:18:25] <Compn> well i havent read the whole thread sooo i'm just going on that one mail
[11:18:28] <mru> who is this guy anyway?
[11:18:56] <jai> Compn: well, in this specific case, i'd say a much better discussion is happening
[11:19:14] <Compn> jai : ok i'll butt out :)
[11:19:28] <jai> Compn: wait what :) thats not that i meant
[12:23:48] <mru> DonDiego: is there a way to make doxygen use a different name for a function than what is in the code?
[12:24:16] <mru> it's currenly spitting out docs for av_clip_*_c()
[12:24:28] <mru> the correct name people should use is av_clip_*()
[12:28:56] <siretart> mru: perhaps \fn could work here: http://www.stack.nl/~dimitri/doxygen/commands.html#cmdfn
[12:30:02] <mru> yeah, possibly
[12:30:18] <mru> would be nice if it allowed to just override the name though
[12:35:24] <_av500_> http://mobile.osnews.com/story.php/23525/Deep_Analysis_of_the_VP8_Codec_by_H_264_Experts
[12:35:42] <mru> lol
[12:35:55] <mru> that's the msu comparison
[12:36:04] <mru> they don't even document what settings they used
[12:36:11] <mru> and the graphs look dubious to say the least
[12:36:43] <kshishkov> BBB may be proud to be called x264 dev
[12:37:14] * mru should probably take his name off the x264 web page
[12:37:55] <mru> there's not much left of what I once did there
[12:38:01] <mru> maybe some vui code
[12:38:09] <mru> and they lifted some asm from ffmpeg
[12:38:22] <kshishkov> mru: that page still features some weird email for you
[12:38:32] <mru> it still works
[12:38:53] <mru> every email address I've used in the last 10 years still works
[12:39:02] <mru> and some that I haven't used
[12:39:51] <kshishkov> good thing then
[14:04:05] <Vitor10011> mru: Nice changes to fate-run.sh, but one problem remains
[14:04:16] <mru> go
[14:04:41] <Vitor10011> mru: the decoder can have decode_frame() return an error, and for error concealing, ffmpeg.c will keep decoding the file
[14:04:57] <mru> yes...
[14:04:59] <Vitor10011> if it happens with every frame, ffmpeg will return success and an empty file
[14:05:03] <mru> ah
[14:05:08] <Vitor10011> with MAXDIFF = 0...
[14:05:12] <mru> let me fix that then
[14:05:18] <Vitor10011> great, thanks
[14:06:23] <Vitor10011> mru: Just please check the size, to be sure it still fail if it decode correctly just half of the file
[14:27:24] <CIA-99> ffmpeg: aurel * r24160 /trunk/libavcodec/arm/Makefile: fix VP5/6 neon dependencies
[14:37:43] <CIA-99> ffmpeg: kostya * r24161 /trunk/libavcodec/ (vc1dec.c vc1.c):
[14:37:43] <CIA-99> ffmpeg: Make WMV3 decoder print more errors when decoding beta WMV9 files.
[14:37:43] <CIA-99> ffmpeg: As a side effect it will also decode a lot of P-frames from those.
[15:26:32] <CIA-99> ffmpeg: ramiro * r24162 /trunk/doc/faq.texi:
[15:26:33] <CIA-99> ffmpeg: faq: remove note that says avisynth "has just been added". it has been there
[15:26:33] <CIA-99> ffmpeg: for almost 4 years.
[15:28:35] <kierank> lol
[15:29:44] <kshishkov> we have a lot of still experimental things though
[15:42:16] <DonDiego> why is libxvidff.o and libxvid_rc.o compiled conditional to CONFIG_LIBXVID and not CONFIG_LIBXVID_ENCODER?
[15:42:43] <DonDiego> this is causing a compilation failure in mplayer
[15:42:55] <kshishkov> fix mplayer
[15:43:15] <DonDiego> mplayer is not in need of fixing
[15:44:20] * kshishkov files that into the fourth category of lies
[15:46:31] <DonDiego> wtf?
[15:48:25] <kshishkov> BTW, aren't those configs always in the same state?
[15:50:27] <mru> DonDiego: that is to _fix_ a damn build failure
[15:50:33] <mru> read the commit message
[15:50:45] <mru> --enable-libxvid --disable-encoder=libxvid fails otherwise
[15:51:15] * pJok is aparantly not the only person with bad taste in this city
[15:51:38] <pJok> what are the odds that two yellow mondeo station wagons are parked right next to each other?
[15:51:44] <kshishkov> pJok: city?
[15:52:05] <kshishkov> also I find Ford cars to be of bad taste indeed
[15:52:08] <pJok> kshishkov, Landskrona
[15:52:14] <mru> an ex-workmate's wife drives a yellow pt cruiser...
[15:52:14] <pJok> kshishkov, http://sphotos.ak.fbcdn.net/hphotos-ak-ash2/hs080.ash2/37363_413924883630_600348630_4391880_6026687_n.jpg
[15:52:24] <kshishkov> pJok: I thought it was rather a town
[15:52:25] <pJok> mru, thats not bad taste... thats just horrible taste
[15:52:38] <pJok> kshishkov, 28k inhabitants... its a city ;)
[15:52:54] <mru> and that's after she sold the yellow porsche boxter
[15:54:05] <pJok> a yellow boxter is ok...
[15:54:13] <pJok> but a pt cruiser isn't... no matter what color
[15:54:13] <mru> of course
[15:54:22] <kshishkov> pJok: I lived in a city with population of Stockholm, so everything significantly smaller is a town to me
[15:54:32] <mru> I'm just putting it in the proper perspective
[15:54:52] <pJok> kshishkov, you live in germany now... it doesn't count ;)
[15:55:58] <kshishkov> pJok: ok, in Sweden everything with population >10k was a city it seems. So you're right
[15:56:36] <kshishkov> pJok: and my current "city" still has > 290k people
[15:56:57] <mru> kshishkov: I'd say it has the necessary elements for a city
[15:58:08] <jai> hey there pJok
[15:58:14] <pJok> hey jai :)
[15:58:49] <pJok> mru, i have a 24hr/day gas station, a mcdonalds and 3 major supermarket chains (4th one coming soon)
[15:58:55] <kshishkov> mru: by your definition Ukraine has no cities
[15:58:56] <pJok> that pretty much qualifies for a city
[15:59:20] <mru> how many cinemas?
[15:59:28] <mru> casino?
[15:59:33] <mru> university?
[16:00:40] <pJok> 1
[16:00:45] <pJok> i dont think there's a casino
[16:00:55] <pJok> but the closest to a casino is in helsingborg at the station
[16:01:05] <pJok> they have roulette and blackjack
[16:01:25] <pJok> and university is in lund
[16:01:35] <pJok> the cinema, only one very small one
[16:01:43] <mru> then it's no city
[16:01:53] <mru> what about pubs and nightclubs?
[16:01:57] <kshishkov> Storkyrkan?
[16:02:00] <mru> sports stadium?
[16:03:05] <pJok> there are a few pubs and nightclubs
[16:03:14] <pJok> one stadium
[16:51:55] <CIA-99> ffmpeg: alexc * r24163 /trunk/tests/fate2.mak: AAC fate2 tests.
[16:58:56] <CIA-99> ffmpeg: mru * r24164 /trunk/tests/fate-run.sh: fate: ensure file sizes match in oneoff tests
[16:59:05] <mru> Vitor10011: that better?
[17:02:05] <Vitor10011> mru: Great, thanks!
[17:12:18] <CIA-99> ffmpeg: ramiro * r24165 /trunk/configure: mingw32: avisynth does not need w32api >= 3.13
[17:42:11] <mru> peloverde: ping
[17:48:06] <peloverde> pong
[17:48:42] <mru> some of the aac tests fails with maxdiff=2 on arm
[17:48:47] <mru> ok to increase fuzz?
[17:49:03] <peloverde> How much?
[17:49:06] <mru> 2
[17:50:24] <peloverde> Are you talking about al04_44 or the others?
[17:50:36] <peloverde> I'm ok with bumping any/all of them to FUZZ=2
[17:50:37] <mru> all but al04_44
[17:51:01] <peloverde> You can bump any of those that you need to to FUZZ=2
[17:51:08] <peloverde> Anything above that I'd like to manually verify first
[17:54:56] <mru> ok
[18:02:06] <CIA-99> ffmpeg: mru * r24166 /trunk/tests/fate2.mak: fate: some AAC tests need FUZZ=2 on ARM
[18:43:50] <CIA-99> ffmpeg: vitor * r24167 /trunk/tests/fate2.mak: Add fate2 test for RA288
[18:47:00] <CIA-99> ffmpeg: vitor * r24168 /trunk/tests/fate2.mak: Add RealAudio COOK fate2 test
[20:44:09] <mru> \o/ michael in email mode
[20:46:06] <kierank> i'm not getting any emails from ffmpeg-devel
[20:46:12] <kierank> i haven't got the last 15 or so
[20:46:14] <mru> are you subscribed?
[20:46:15] <kierank> yes
[20:46:18] <mru> :-)
[20:47:08] <mru> firstname at lastname?
[20:47:14] <kierank> yes
[20:47:26] <kierank> hmm one just appeared but there's a big gap still
[20:48:42] <mru> status=deferred (host mx5.biz.mail.yahoo.com[74.6.140.31] refused to talk to me: 421 4.7.0 [TS01] Messages from 213.144.138.186 temporarily deferred - 4.16.55.1; see http://postmaster.yahoo.com/errors/421-ts01.html)
[20:48:56] <mru> summary: yahoo mail admins are idiots
[20:49:38] <mru> and I get connection refused trying to open that url
[20:49:43] <kierank> so do I...
[20:49:47] <mru> so their webmaster is also an idiot
[20:50:01] * mru recommends staying off yahoo
[22:09:55] <CIA-99> ffmpeg: mru * r24169 /trunk/ (27 files in 3 dirs):
[22:09:55] <CIA-99> ffmpeg: bswap: change ME to NE in macro names
[22:09:55] <CIA-99> ffmpeg: Other parts of FFmpeg use NE (native endian) rather than ME (machine).
[22:09:55] <CIA-99> ffmpeg: This makes it consistent.
[22:13:23] <CIA-99> ffmpeg: mru * r24170 /trunk/ (51 files in 8 dirs): Add av_ prefix to bswap macros
[22:22:44] <CIA-99> ffmpeg: mru * r24171 /trunk/libavutil/bswap.h: Make bswap.h safe to install as public API
[22:22:44] <CIA-99> ffmpeg: mru * r24172 /trunk/configure: Set fast_unaligned in avconfig.h
[22:22:45] <CIA-99> ffmpeg: mru * r24173 /trunk/libavutil/intreadwrite.h: Make intreadwrite.h installation-safe
[22:22:46] <CIA-99> ffmpeg: mru * r24174 /trunk/libavutil/Makefile: Install bswap.h and intreadwrite.h
[22:25:19] <CIA-99> libswscale: mru * r31679 /trunk/libswscale/ (rgb2rgb.c yuv2rgb.c swscale.c): Add av_ prefix to bswap macros
[22:58:08] <CIA-99> ffmpeg: vitor * r24175 /trunk/tests/ (fate2.mak ref/fate/mpeg2-field-enc): Add MPEG2 field encoding fate2 regtest
[23:16:39] <CIA-99> ffmpeg: vitor * r24176 /trunk/tests/fate2.mak: Add QCELP regtest
[23:20:58] * Kovensky prefers to think of "NE" as "neither endian"
[23:21:46] <pJok> or No Endian
[23:22:59] <Kovensky> < CIA-99> ffmpeg: mru * r24173 /trunk/libavutil/intreadwrite.h: Make intreadwrite.h installation-safe <-- finally
[23:23:18] <Kovensky> there was some function that was deprecated months ago; its replacement was on a public header that depended on intreadwrite
[23:23:46] <Kovensky> forgot which, but it's sth that ffms2 used ._.
[23:36:05] <CIA-99> ffmpeg: reimar * r24177 /trunk/libavcodec/avcodec.h: Document that and why subtitle decoders do not support direct-rendering.
[23:42:15] <CIA-99> ffmpeg: vitor * r24178 /trunk/tests/fate2.mak: Add QDM2 test
[23:43:08] <CIA-99> ffmpeg: reimar * r24179 /trunk/libavformat/gxf.c: Check url_fseek results in gxf demuxer.
[23:51:06] <CIA-99> ffmpeg: vitor * r24180 /trunk/tests/fate2.mak: Add Intel Music Coder regtest
[23:57:25] <mru> Kovensky: I find that hard to believe
[23:57:55] <mru> at least I don't see any currently installed headers depending on it
[23:58:16] <mru> therefor, no public functions can depend on it being available to the user